[4654] in testers
Re: Ken Raeburn: Solaris athena-9.0 beta update
daemon@ATHENA.MIT.EDU (Tom Yu)
Tue May 22 21:23:26 2001
Date: Tue, 22 May 2001 21:23:16 -0400 (EDT)
Message-Id: <200105230123.VAA09879@saint-elmos-fire.mit.edu>
To: Michal N Lusztig <miki@mit.edu>
CC: testers@mit.edu
In-reply-to: "[4632] in testers"
From: Tom Yu <tlyu@MIT.EDU>
>>>>> "miki" == Michal N Lusztig <miki@MIT.EDU> writes:
miki> I will try to summarize the problems experienced by Abbey and
miki> Ken in updating their machines.
miki> a. In the first stage of the update, a miniroot(based on
miki> Solaris8) is installed on the swap device. That miniroot has an
miki> /etc/name_to_major which specifies that the ide device is 136.
miki> b. When the machine boots the swap device, if by any chance
miki> the ide device was not 136, the machine fails to come up.
My impression was that the kernel device drivers read
/etc/name_to_major to determine which major number mappings to use;
these must be in sync with the device nodes in /devices, which was the
problem here: Ken's machine had the miniroot /devices entries for the
IDE disk devices having major numbers of 134, while the miniroot's
/etc/name_to_major listed the major number of the dad device as 136.
miki> c. Most of the times, the ide device of the machine to update
miki> is 136 so we have no problem. The exceptions I have seen were
miki> Abbey's and Ken's machine. I have no idea why they were
miki> different. (In the past we were copying the /etc/name_to_major
miki> from the machine to be updated into the miniroot
miki> /etc/name_to_major. This is no more possible because the
miki> miniroot is Solaris8 and the machine to update is Solaris7)
I believe that any private Ultra 5 or 10 workstation installed with
8.3 or earlier will have "dad 134" in /etc/name_to_major. I also
noticed that it didn't seem possible to run drvconfig at all (even
with the "-r" flag) with the system booted to the miniroot in
single-user mode. It kept complaining about di_init, which I believe
is related to the devinfo pseudo-device. Additionally, during the
update process, various package installation operations reported
errors relating to "di_init". It turns out that on my Ultra 10 (which
I have yet to update), devinfo gets major device number 10 in
/etc/name_to_major, while I think it's 88 on the miniroot's copy of
/etc/name_to_major. I haven't check this on Ken's machine, though.
miki> 1. How to fix a machine that got in this stage :
miki> boot net the machine in single user mode (or boot cdrom -s)
miki> mount the root partition and see what is the number for the ide device
miki> mount the swap partition; edit /etc/name_to_major to fix the
miki> number of the ide device to be the number of the ide device on
miki> the root.
miki> halt the machine
miki> at PROM OK setenv boot-device disk
miki> boot disk:b
miki> 2. We need to introduce in the setup-swap-boot a check for the
miki> number of the ide disk on the machine that is going to be
miki> updated and after that edit the name_to_major file on the swap
miki> partition to have the right number.
I'm not convinced that this is the correct solution. What appears to
be the central problem is that the device nodes in /devices on the
miniroot are getting created using the old root partition's copy of
/etc/name_to_major, meaning that these device nodes won't match the
miniroot's copy of name_to_major, which (presumably) comes from the
Solaris 8 CD or something suchlike.
I believe that the right thing to do would be to completely replace
/etc/name_to_major on the root partition of the machine being updated
prior to building the miniroot. Probably drvconfig and devlinks
should be run immediately afterward to avoid getting the machine's
root partition into an unbootable state. The subsequent run of
drvconfig while building the miniroot should then create a miniroot
with name_to_major and /devices being consistent.
What is not obvious is whether the right thing will happen with the
devinfo pseudo-device if this proposed procedure is followed. I don't
know if changing the /etc/name_to_major mapping for devinfo will cause
drvconfig to break horribly. This may need some experimentation.
Additionally, I don't know the original logic behind not doing a
wholesale update of /etc/name_to_major on private workstations.
Digging through archives reveals that only public workstations had
their /etc/name_to_major files force-updated. I suspect it may have
to do with potential private workstation customizations that change
name_to_major, but it seems problematic to ask private workstation
owners to have to jump through lots of hoops just to have a
non-mangled name_to_major file. It would be nice to have a
well-tested automated solution to this problem before 9.0 finishes
beta.
---Tom
