Sun-Spots Digest, v6n11
William LeFebvre
Sun-Spots-Request at RICE.EDU
Sun Feb 7 11:25:40 AEST 1988
SUN-SPOTS DIGEST Friday, 5 February 1988 Volume 6 : Issue 11
Today's Topics:
Re: Adding a node to a server-based system (2)
Re: Maximum disk space limitation?
Re: Two ND servers on one cable
Re: Problems (bug) with SunOS 3.4
Re: ping bug
Re: FIG (was: MacDraw and/or Macpaint for Sun)
new version of tcpdump available
FBIOGTYPE ioctl bug and Sun video enable/disable program
3.2 vs. 3.4 `time' command
Calentool doesn't know about leap years
Bug in C compiler
Problems with Suns
Sun monitor behaving strangely?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are stored on "titan.rice.edu". For volume X, issue Y,
"get sun-spots/vXnY". They are also accessible through the archive
server: mail the word "help" to "archive-server at rice.edu".
----------------------------------------------------------------------
Date: Sat, 23 Jan 88 15:28:50 GMT
From: James Davenport <jhd%maths.bath.ac.uk at nss.cs.ucl.ac.uk>
Subject: Re: Adding a node to a server-based system (1)
I wondered when some-one was going to ask this question. SUN's official
answer is indeed that you have to install again, and re-run through setup.
We have (twice) added new discless nodes - Here's what we did.
Time 1 (I was fairly green then).
Let SUN do it, which means that they do indeed run setup, and all the
discs get trashed etc. HOWEVER, we unplugged the user file store first, so
that setup didn't know it was there. After it had finished trashing and
re-building the system disc, we restored such bits of the system as we
needed from out backups, merged the old and new fstabs (a touch tricky
here: you want the new fstab + the entries for the user file store from
the old one), do a /etc/mount -a, and we were back without having to
restore the user file store (though I had taken a backup before - I wasn't
that green!). My SUN engineer was quite happy with this process - I
recommend it as a good compromise.
Time 2
0) Back everything up.
1) Add entries for the new machine to /etc/hosts, /etc/ethers, any mailers
you have, your yellow pages domains, /etc/exports etc., and rebuild
yellow pages.
2) SUN engineer arrives and installs the hardware. You then kick him out
of the seat, and he stands around for the rest of the exercise,
disclaiming all responsibility (and taking notes, if he's any good).
3) Decide where to put the / (nd0) and swap (nd1) partition for the new
machine. This will probably involve making another partition smaller.
WARNING: as already mentioned on this net, you can't start a disc with a
swap partition - it will trash the disc label. This is a step you
should think through carefully, and preferably when you do your initial
installs (hence SUN's view that you should reserve the partitions
initially) - it's a lot easier to add disc space than it is to lose it.
Although not explicitly mentioned, I believe that all these boundaries
should be on cylinder boundaries.
[ go single-user on your server]
4) Use diag to re-label the disc. The details depend on what disc you have,
and what you're doing to it. My SUN engineer was actually quite helpful
over this stage of it. What you'll be doing is changing the start/end
places of the partitions you are stealing the disc space off. These should
NOT be /, /pub and preferably not /usr [I didn't change /usr, so won't
pretend I did. That would make life more complex].
5) Change /etc/nd.local to add the two new nd partitions. When we added
"borodin", the two lines we added were:
user borodin 0 /dev/xy0c 326960 16080 3
user borodin 1 /dev/xy0c 343040 65660 -1
meaning that 16080 blocks on /dev/xy0c starting at block 326960 would
be /dev/ndl3 for the server, and /dev/nd0 for borodin, and 65660 blocks
starting at 343040 would be /dev/nd1 for borodin (its swap space).
Then re-run nd.
6) use /etc/mkfs to make the new / filing system (/dev/ndl3 in my case) for
the new client (unfortunately /etc/newfs won't make nd partitions - sigh).
The "size" parameter quoted to mkfs is the 16080 (or equivalent) from
the previous step.
7) use a back-to-back dump/restore pair to copy an existing nd client's
root partition onto the new one. Choose the existing client most like the
new one. It helps if no-one is logged on to this machine at the time.
8) Sanitise the newly created partition. The minimum change is:
a) hostname in etc/rc.boot (else chaos!)
You should also:
b) delete private/usr/spool entries (else the documents will print twice)
c) tidy up private/usr/spool/mail;
d) check over things like private/usr/lib/crontab;
e) check over dev.
9) use newfs to re-make the partitions that you trashed while stealing space
for the new clients. Then restore the data (there was room, wasn't there?).
A) Place a symbolic link in /tftpboot on the server from "hex address in
capitals of client, e.g. CAE1001F" to "ndboot.sun3.pub1" (or whatever).
Incidentally, if you don't like the idea of all your discless machines
running the same kernel, this directory is the place to hack. But that's
another story.
[ go multi-user, but gingerly]
Restart the old client, then try the new one.
This process took me about 45 minutes in all - a great saving over setup.
But I had thought about it for several days before hand.
James Davenport
jhd at uk.ac.bath.maths
------------------------------
Date: Mon, 25 Jan 88 00:37:42 EST
From: mcgrew at topaz.rutgers.edu (Charles)
Subject: Re: Adding a node to a server-based system (2)
You didn't necessarily screw up. If there is space on the disk (or disks)
for new clients to go on (a spare partition, or whatever), all you need to
do is edit your /etc/nd.local to set aside root and swap space there - it
doesn't have to be next to or near the other client (see 'adding a client'
in the administrator's manual for how to initialize the client space).
(The man page for nd will help, a little.)
If you haven't got space on the disk set aside for this, then your job is
messier. You'll have to backup a partition, run diag and alter the
parttition table (to set aside the space for the client's root and swap),
remake the file system for the file system you snarfed and restore it (do
all this single user, of course). Then adjust nd.local and set up the
client as 'normal'. (Hints: use /usr/etc/setup.files/copy_client, and
then mount the ndlX partition as /mnt, cd /mnt/dev, and
MAKEDEV std nd0 ndp0 win0 win1 win2 pty0 pty1 pty2 bwtwo
plus any other devices you need, have a look at /dev/MAKEDEV for this.)
Its gory, but this will save you having to completely rerunning setup and
restoring all partitions.
In general, when we get a new server (we've got 8 or so now), we decide up
front how many clients we want on it (usually 10), and set aside the
space, regardless of what clients we have at hand at the time. Having
extra client partitions around comes in very handy when a server goes
seriously bad - we can boot the bad server as a client, mount its disks
and work on them with a complete unix environment at hand.
Hope this helps,
Charles
------------------------------
Date: Fri, 22 Jan 88 15:19:28 EST
From: mnetor!utzoo!henry at uunet.uu.net
Subject: Re: Maximum disk space limitation?
> Sun specifications list the 3/260 as only being able to handle 1 gigabyte
> of disk space, and a 3/280 at 2 gigabytes... What's the limitation here?
My guess would be that these are either the largest configurations that
Sun thought worth supporting, or the largest that would fit in the box
with the disk drives Sun prefers. This is yet another case of a problem
that constantly angers me in Sun configuration documentation: no attempt
is made to explain the reasons behind the rules, which means you cannot
tell whether what you want is (a) impossible, (b) awkward, (c) beyond what
Sun is willing to support, (d) infeasible with the hardware available when
the manual was written, or merely (e) something Sun never thought about.
I recognize the usefulness of cookbook rules for the unsophisticated users
(although most of *them* probably find the Sun manuals unreadable
anyway!), but personally I thoroughly dislike the Mama-knows-best attitude
that excludes any mention of the principles behind the rules.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
------------------------------
Date: Sat, 23 Jan 88 21:58:52 EST
From: allegra!phri!roy at ucbvax.berkeley.edu (Roy Smith)
Subject: Re: Two ND servers on one cable
We've got 2 3/160's and 13 3/50's being ND served from 2 3/180's, roughly
half the clients on each server. We don't see any particular problem.
We're typically running at about 20% capacity on the wire (as shown by
traffic), with maybe a couple of collisions per second max. You must have
some other problem.
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Fri, 22 Jan 88 19:36:45 EST
From: hirai at swarthmore.edu (Eiji "A.G." Hirai)
Subject: Re: Problems (bug) with SunOS 3.4
I use an alias in my .cshrc to "wipe" away those annoying pseudo-tty's.
Don't use it on nodes that still have "real" users on them though, or else
their valid utmp entry gets wiped too.
alias wipe 'rsh \!* "(echo -n > /etc/utmp)"'
-a.g. hirai
swarthmore college
[[ In most cases, that's a little too severe. --wnl ]]
------------------------------
Date: Fri, 22 Jan 88 14:28:31 PST
From: Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Re: ping bug
>We have noticed the same behavior. It seems that if more that one PING is
>outstanding, that is, if more than one ICMP ECHO packet has been
>transmitted without receiving the corresponding ECHO REPLY packet, then
>when one ECHO REPLY does arrive, it satisfies all outstanding ECHOs and
>ping erroneously reports all systems as 'alive'.
In the documentation accompanying the 3.5 release, there is mention that a
ping bug similar to this has been fixed; your bug sounds like a slightly
different manifestation of what was fixed, so your bug is probably gone as
well.
SunOS 3.5 is not being automaticly shipped to all service-contract
customers; it is being shipped with all new systems, and will be shipped
to any service- contract site that requests it. I haven't installed mine
yet (it just came in this morning), so I can't tell you much more than
what's in the accompanying documentation.
-Brent
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
{lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704
capmkt!brent@{tis.llnl.gov,cogsci.berkeley.edu} Phone: 415/540-6400
------------------------------
>From csrobe at icase.arpa Fri Jan 29 14:56:58 1988
Date: Fri, 29 Jan 88 15:56:43 EST
From: csrobe at icase.arpa (Charles S. Roberson)
To: sun-spots at rice.edu
Subject: Re: FIG (was: MacDraw and/or Macpaint for Sun)
After I saw wnl's pointer to fig, I decided to check it out for myself.
We took a look at it and it is definitely much better than Graphedit! It
moves easily and has a nice interface. However there are a few facilities
that we would like to use that it doesn't have. Namely:
Multiple fonts
Stacking objects
Filling/Shading
Line thickness
Rotating text
Before we, perhaps, attempt to add any of them, has anyone made any
extensions to fig? Fig is, by far, the best MacClone software I have seen
yet, (well, MacClone is probably a bit strong, but it does have all the
basic ideas of MacDraw), however, without the above abilities, we are not
sure if it is good enough to replace our *old* Mac and MacDraft/MacDraw.
The version of fig that I ftp'd was 1.3 and dated 1985.
cheers,
-c
Chip Roberson ARPANET: csrobe at icase.arpa
1105 London Company Way BITNET: $csrobe at wmmvs.bitnet
Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe
[[ The author is Supoj Sutanthavibul <supoj at sally.utexas.edu>. He told me
that he is working on a new version which will hopefully be available in a
few weeks. I don't know how responsive he is to new ideas, but you might
want to try suggesting a few anyway. --wnl ]]
------------------------------
Date: Sun, 24 Jan 88 19:36:27 PST
From: Van Jacobson <van at lbl-csam.arpa>
Subject: new version of tcpdump available
There's a new version of tcpdump (v1.17) available for anonymous ftp from
internet host lbl-rtsg.arpa (128.3.254.68), compressed tar file
tcpdump.tar.Z. There are no major changes but several bug fixes and a
couple of new flags. In addition to the tcpdump update, a couple of new
trace analysis awk scripts have been added.
This version was compiled -fswitch so it should work on Sun-3s without a
68881. And no, the source still isn't available (but will be soon I
hope).
- Van
------------------------------
Date: Fri, 22 Jan 88 19:04:23 EST
From: dupuy at columbia.edu (Alexander Dupuy)
Subject: FBIOGTYPE ioctl bug and Sun video enable/disable program
Here's a little program which you can use to turn a Sun video display on
and off. It's especially useful if you ran screenblank, but it died or is
behaving erratically. You can also use it to find out the type of a
framebuffer.
Unfortunately, the FBIOGTYPE ioctl in SunOS 3.4 (and maybe others - it
doesn't seem to be used by any programs at all) has a bug which causes it
not to return the fb_type field, and as a result, the other fields are all
off by one in the structure. I worked around this, and screen attempts to
intuit the framebuffer type from its size and number of colormap entries.
Since I don't have any Sun-1 or Sun-4 color displays, it doesn't guess
those right (yet).
I am cc'ing a copy of this to sun!bugs as a bug report for the FBIOGTYPE
ioctl, and am placing this in the public domain. If Sun wants to include
this minor program in any future releases, they are free to do so.
@alex
arpanet: dupuy at columbia.edu
uucp: ...!rutgers!columbia!dupuy
[[ Available in the archives as "sun-source/screen.shar". It can be
retrieved via anonymous FTP from the host "titan.rice.edu" or via the
archive server with "send sun-source screen.shar". For more information
about the archive server, send a mail message containing the word "help"
to the address "archive-server at rice.edu". --wnl ]]
------------------------------
Date: Fri, 22 Jan 88 11:08:51 PST
From: telesoft!souza at sdcsvax.ucsd.edu (Steve Souza @eldest)
Subject: 3.2 vs. 3.4 `time' command
In some timing tests recently done on Sun3s running 3.2 and 3.4 we've
found large discrepancies in the "average shared memory" and "unshared
data space" statistics reported by the C-shell `time' command.
In summary, it appears that the memory usage reported by the 3.4 version
of `time' is much larger that the amount reported by the 3.2 version for
execution of the same program under similar conditions. The difference
has been anywhere from 2 to 10 times greater for version 3.4. Here are
the results of some typical Unix commands:
__________
"ps aux"
3.2: 0.7u 4.1s 0:06 76% 6+9k 20+1io 0pf+0w
3.4: 0.9u 1.6s 0:04 58% 48+72k 35+3io 0pf+0w
"nroff -man /usr/man/man1/csh.1"
3.2: 67.2u 0.9s 1:16 88% 2+9k 40+46io 0pf+0w
3.4: 69.0u 3.0s 1:45 68% 16+72k 41+47io 0pf+0w
"cc -O test.c"
3.2: 0.8u 1.5s 0:06 36% 4+4k 130+38io 26pf+0w
3.4: 0.9u 1.1s 0:06 31% 32+32k 107+43io 5pf+0w
__________
The machines involved were both Sun3 160s with 16MB of memory.
Why these numbers differ so drastically? The only clue we found was a
note about a bug fix in 3.4 for the memory device driver ("Release 3.4
Manual for the Sun Workstation", p111). Assuming the method of stat
calculation in csh has remained the same between releases, do any of you
"in-the-know" kernel hackers out there know of any changes?
Other ideas?
Many thanks,
Steve Souza sdcsvax!telesoft!souza, telesoft!souza at sdcsvax
TELESOFT Inc., San Diego, CA (619)457-2700 x277
------------------------------
Date: Fri, 22 Jan 88 16:01:26 CST
From: "Patrick M. Landry" <pml%pmlsun at USL.CSNET>
Subject: Calentool doesn't know about leap years
I have a copy of calentool off of the 1987 SUG tape but it has a problem.
It doesn't know about leap years. Two questions:
1. Has anyone fixed calentool?
2. Does anyone have an alternative?
Thanks
---patrick---
pml at usl.usl.edu
ut-sally!usl!pml
------------------------------
Date: Fri, 22 Jan 88 10:07:18 EST
From: im4u!rutgers!rochester!srs!matt at ut-sally.UUCP
Subject: Bug in C compiler
We have had a bug in our main signal analysis tool for well over a year.
Occasionally, and apparently w/o any regularity, one of the graphs (a
raster display of FFTs of an input signal) would produce what looked like
garbage, but tended to follow the basic trend of the input data.
Recompiling the tool sometimes changed the frequency of occurance and with
the latest changes, it tended to occur quite often. Well, I have finally
tracked it down to a compiler problem and this bug will bother us no
more...
Release: Sun OS 3.2
Systems: Sun3, Sun2
Comment: The following program outputs (erroneously) 0xff00 for the
second call to screwit(). Basically, the compiler fails to
clear the upper half of "d7" before adding it into "a".
"a" can be a signed or unsigned short. If "a" is an int
(long), it appears to work correctly.
#include <stdio.h>
main()
{
register short d7;
unsigned char b = 0;
d7 = 0x00ff;
screwit(&b);
d7 = 0xffff;
screwit(&b);
}
screwit(b)
register unsigned char *b;
{
register unsigned char d7;
register unsigned short a = 0;
d7 = *b;
a += (unsigned short) d7;
printf("C: 0x%04x\n", a);
}
UUCP: {allegra,rutgers,ames}!rochester!srs!matt Matt Goheen
"First the pants, THEN the shoes." S.R. Systems
------------------------------
Date: 22 Jan 88 10:53:30 GMT
From: unido!tb at uunet.uu.net (Tb)
Subject: Problems with Suns
Hi everybody,
We have some problems with our SUNs, perhaps someone outhere can help us :
1. Since we upgraded to SunOS3.4, our SUNs only use 512 Byte tcp-packets.
This was not the case under SunOS3.2. Is there any reason for that ?
If not how can it be fixed ?
2. We never managed to get talk and ftp running on diskless clients.
Normally those exit with "bind:cannot assign requested adress".
Strange enough ftp SOMETIMES (don't know exactly when) works.
3. We recently bought a 3/280 with a Rimfire hard-disk-controller.
Though the documentation stated that the SUN setup program should work
with the Rimfire controller, we didn't manage to get it running (though
we made the appropriate changes to setup.config setuphardware.file).
Did anyone outhere got setup running with the Rimfire controller ? If
so, what where the changes you made to the setup files ?
4. How can I get eye and this Mandelbrot graphic demo from SUN. (As
I'm in Europe I'm not able to ftp this from somewhere. Mail is to
expansive, so the only remainder would be a tape or bitnet-mail. Can
anyone help ?)
Any help would be greatly appreciated.
Thanx in advance
Torsten Beyer
Michael Kuschke
Torsten Beyer uucp : ...uunet!unido!tb
University of Dortmund tb at unido.uucp
-IRB-
P.O.Box 500500 bitnet : tb at unido.bitnet
D-4600 Dortmund 50
West-Germany
------------------------------
Date: 22 Jan 88 17:42:01 GMT
From: lj at spdcc.com (Len Jacobs)
Subject: Sun monitor behaving strangely?
Does anyone have any experience with a Sun 3 monitor behaving strangely,
waving and acting as though the tube may be on its last legs? Any
comments would be appreciated.
Thanks
Len Jacobs
{harvard,linus,ihnp4}!spdcc!lj
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list