[979] in testers
initial reactions to 7.1 update
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Thu Aug 2 08:54:13 1990
Date: Thu, 2 Aug 90 08:53:45 EDT
From: Ken Raeburn <Raeburn@MIT.Edu>
To: testers@ATHENA.MIT.EDU
(Okay, so I'm a bit behind...)
I've just updated a VAX and an RT to 7.1. Both are providing various
services.
Aside from an initial scare involving lots (hundreds!) of fsck
complaints about a partition providing AFS service on the VAX, things
seem to have gone fairly well.
The message about /site/bin/athena and /site/etc/athena is silly if
neither /site/bin nor /site/etc exist.
The tftp server should be setuid to "default" or "nobody" or some
such, or be run by same from /etc/inetd.conf. I don't see why tftp
should normally be disabled, if netbooting requires it. (Not
something that will get done every day, but it would be convenient to
not have to modify another machine to get a tftp server.)
The line entered for "discuss" service in inetd.conf comes at the end
of the commented-out block of "obsolete services that are not in the
Athena release". Please insert something like "#\n# Extra services\n"
before adding such entries. Better yet, let's change the
"[un]switched" field to support three values, "on", "off", and
"switch". Then services like this can always be put in, and the value
in this field is all that need be changed.
In releases with fully rebuilt, lots of stuff gets recopied to the
workstation needlessly. A particularly silly (but inexpensive)
example I noticed is /bin/true. It was updated, solely because the
modification time had been changed because of the rebuild of the
packs. But what the heck, these machines don't have anything better
to do with their time.
The RT was moderately well-behaved. (Thanks to the recent memory
downgrade, it didn't get a machine check once during the entire
process.)
The "no vice inodes" message in SalvageLog should be preceded by the
date and time.
I seem to have gotten one partition into a state where "vos listvol"
says that there's a volume there that couldn't be attached, but "bos
salvage" can't find it, and "vos zap" won't kill it unless it's
salvaged first. There should be one volume ("disk.prometheus.a")
there.
After convincing myself that the AFS setup on the RT looked okay, I
tried rebooting with "shutdown -r now"; that got a "panic: empty text"
message on the console rather than a reboot. I had to hit
CTRL-ALT-PAUSE to get it to reboot.
Now, to start actually using this release....
