[3400] in Release_7.7_team
Solaris and Irix release
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Tue Jul 16 04:15:41 2002
Message-Id: <200207160815.EAA08235@hodge-podge.mit.edu>
To: release-team@MIT.EDU
cc: ops@MIT.EDU
Date: Tue, 16 Jul 2002 04:15:36 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
The Solaris and Irix release happened tonight, as you're
probably aware. I spent the evening monitoring the update to make sure
everything went smoothly.
The Irix release happened with no issues; all the machines in
4-035 (the only remaining cluster containing SGIs) are now running
9.1.11.
The Solaris update had 2 issues of note and one slight cosmetic
bug (which should also affect Irix, although I didn't see it there).
The two issues of note:
1.) The free space checks were not being done in update_ws on
Solaris. I noticed this when I came across an Ultra 5 in m12-182 that
had lost mid-update due to filling /usr. Greg and I patched update_ws
at around 2:30am. It's possible that some number of crufty private
machines got toasted in the 4.5 hours prior to that, although I'm still
unaware of any specific instances, and there was only one cluster
machine affected, which I've reinstalled.
2.) I observed reasonably early that Sun Blade 100s with USB zip
drives connected to them will fail to update, apparently because the
booted 9.0 kernel sees the root disk as c0t0d0, but the booted miniroot
sees the USB zip as c0t0d0 and the root disk at c1t0d0. You can work
past this by tweaking vfstab on the constructed miniroot, which I did
for the ~10 cluster machines that this affected. I'm not sure if there
are any private machines configured with USB zip drives. If there are,
the easiest workaround is probably to disconnect the zip drive and
reboot (the machine will be sitting at a single user shell, booted off
the miniroot but having failed to mount /).
miki: This is something we should probably fix, although I'm not
sure how best to do so. There's a USB zip drive in my office somewhere
(it may be on one of Camilla's machines) that you can borrow if you
don't otherwise have access to one.
The cosmetic problem that I noted on Solaris but which exists for
Solaris and Irix is this: the new reactivate that runs out of cron runs
"detach -clean -a" 9 out of 10 times it runs; this fails to detach the
system packs, which are attached by root, which is of course always in
the passwd file. The 1 out of 10 reactivates that do detach the system
packs will allow the new ones to be attached, allowing the update to
proceed. This has the affect of delaying machines' updates by at most
10 reactivates after UPDATE_TIME. This isn't a big deal, but is
something we should probably consider fixing in the future.
Machines are still updating but I'm heading home now, since
I've dealt with all the issues I noted walking around campus.
Garry
