[2664] in Release_7.7_team
Re: [cfox@MIT.EDU : blank screen during update]
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Sat Mar 24 21:41:07 2001
Date: Sat, 24 Mar 2001 21:40:58 -0500 (EST)
Message-Id: <200103250240.VAA21694@hodge-podge.mit.edu>
From: Garry Zacheiss <zacheiss@MIT.EDU>
To: Garry Zacheiss <zacheiss@mit.edu>
CC: Greg Hudson <ghudson@mit.edu>, release-team@mit.edu
In-reply-to: "[2662] in Release_7.7_team"
Executive summary: I've figured out the problem with afs and the
miniroot, so a miniroot update from 8.3 to 8.4 is an option for us now.
More details:
>> It would surprise me if this wasn't fixable. Is the miniroot being used
>> here the same one we used for the 8.3 -> 8.4 upgrade? What AFS client
>> is being used in it? An upgrade to the 3.6p1 client might help. Have
>> we considered using a memcache for the miniroot afs client? That might
>> also make a difference. Has anyone tried running afsd with -verbose and
>> -debug? That might be enlightening as well.
For the record, the miniroot is the same one that was used for the
8.3 to 8.4 upgrade. It's using the same AFS client we used for 8.2 and
8.3, aka the 3.4a ports 1.67 client for Solaris 2.6.
The problem is that setup-swap-boot is copying /etc/name_to_sysnum
from the base OS install into the miniroot. This is a bad idea; it
worked for the 8.3 to 8.4 upgrade because at the time setup-swap-boot
was run, the miniroot and the base OS install were running the same
version of Solaris. This isn't the case now, since the miniroot is
still based on Solaris 2.6 despite the fact that we're running Solaris
7. As a result, we were installing a name_to_sysnum with the wrong
syscall number for afs, with predictable results.
The miniroot contains a perfectly acceptable name_to_sysnum, so all
we need to do is fail to copy in the wrong version of the file. I'll
submit the patch to source reviewers.
We should decide if we want to proceed with using the miniroot for
the 8.4.20 -> 8.4.21 update.
Garry
