[4655] in testers
Re: Ken Raeburn: Solaris athena-9.0 beta update
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Wed May 23 09:44:58 2001
Message-Id: <200105231344.JAA01819@riff-raff.mit.edu>
To: Tom Yu <tlyu@MIT.EDU>
cc: Michal N Lusztig <miki@MIT.EDU>, testers@MIT.EDU
In-Reply-To: Your message of "Tue, 22 May 2001 21:23:16 EDT."
<200105230123.VAA09879@saint-elmos-fire.mit.edu>
Date: Wed, 23 May 2001 09:44:53 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> 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'm not sure this is the case; I believe we had a similar problem
going from 8.3 to 8.4.
>> 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.
I'm somewhat leery to do this, and I don't believe it will actually
help.
Here's why:
sweet-transvestite.mit.edu# ls -lL /dev/dsk | grep c0t0d0
brw------- 1 root sys 134, 0 Jan 20 1999 c0t0d0s0
brw------- 1 root sys 134, 1 Jan 8 10:17 c0t0d0s1
brw------- 1 root sys 134, 2 Jan 20 1999 c0t0d0s2
brw------- 1 root sys 134, 3 Jan 20 1999 c0t0d0s3
brw------- 1 root sys 134, 4 Jan 20 1999 c0t0d0s4
brw------- 1 root sys 134, 5 Jan 20 1999 c0t0d0s5
brw------- 1 root sys 134, 6 Jan 20 1999 c0t0d0s6
brw------- 1 root sys 134, 7 Jan 20 1999 c0t0d0s7
sweet-transvestite.mit.edu# grep dad /etc/name_to_major
dad 134
sweet-transvestite.mit.edu# mv name_to_major name_to_major.old
sweet-transvestite.mit.edu# mv name_to_major.new name_to_major
sweet-transvestite.mit.edu# grep dad /etc/name_to_major
dad 136
sweet-transvestite.mit.edu# cd /devices/pci@1f,0/pci@1,1/ide@3
sweet-transvestite.mit.edu# rm dad@0,0:*
sweet-transvestite.mit.edu# devfsadm
sweet-transvestite.mit.edu# ls -lL /dev/dsk
total 0
brw------- 1 root sys 134, 0 May 23 09:20 c0t0d0s0
brw------- 1 root sys 134, 1 May 23 09:20 c0t0d0s1
brw------- 1 root sys 134, 2 May 23 09:20 c0t0d0s2
brw------- 1 root sys 134, 3 May 23 09:20 c0t0d0s3
brw------- 1 root sys 134, 4 May 23 09:20 c0t0d0s4
brw------- 1 root sys 134, 5 May 23 09:20 c0t0d0s5
brw------- 1 root sys 134, 6 May 23 09:20 c0t0d0s6
brw------- 1 root sys 134, 7 May 23 09:20 c0t0d0s7
(drvconfig is a hard link to devfsadm; drvconfig, disks, and friends
have been depricated since Solaris 7 and are left around for
compatability)
It would appear that devfsadm is reading the value from the running
kernel; it certainly isn't consulting name_to_major for the information.
So, it might be possible to change the major device number of the root
disk prior to setting up the miniroot, but it appears to require a
reboot and would probably be error prone. The current failure mode of
the update has the saving grace of not taking out the root disk in the
process.
I played around with running devfsadm chrooted to the miniroot, but that
causes devfsadm to coredump thusly:
sweet-transvestite.mit.edu# chroot /var/tmp/miniroot /usr/sbin/devfsadm
libthread panic: _sys_thread_create():alloc_thread returns 0 (no mem) (PID: 23643 LWP 1)
stacktrace:
ff2a3888
ff2ac110
ff3ca668
ff3ca4b0
ff3d31dc
ff3c2984
0
0
Bad system call (core dumped)
which is...disheartening.
We clearly need to put some thought into addressing this problem, but I
don't think the methodology you proposed will work. The method miki
proposed, which "worked" for the 8.3 -> 8.4 update, is a massive kludge
and doesn't address the central problem (the major device number for the
"dad" device changed at some point) but has worked in the past to get us
through an os change.
Ick.
Garry
