[5536] in testers
Re: Solaris 9 update issue
daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Fri Jun 20 04:42:15 2003
Message-Id: <200306200842.EAA30210@athenaphobia.mit.edu>
To: Garry Zacheiss <zacheiss@MIT.EDU>
cc: miki@MIT.EDU, testers@MIT.EDU, larugsi@MIT.EDU
In-Reply-To: Your message of "Tue, 17 Jun 2003 19:06:31 EDT."
<200306172306.h5HN6VUb006518@brad-majors.mit.edu>
Date: Fri, 20 Jun 2003 04:42:07 -0400
From: Mitchell E Berger <mitchb@MIT.EDU>
Hotline got a service request for machines in E53 that failed to take the
update (hume, kant, and condorcet). After some remote debugging with Lou
we found that they were 9.1 Ultra 5s in the early cluster that were installed
at 8.3. We visited the machines this afternoon and salvaged them the same
way Garry did.
These are three more data points suggesting we might want to fix the problem
rather than have it error out. For what it's worth, the three machines also
came back fine with 'dad 134' in /etc/name_to_major.
Mitch
> alexp had his Ultra 5 fail to update to 9.2.7 this morning, and asked me
> to take a look at it. I found it having failed to mount a root
> filesystem off the miniroot, displaying the usual:
>
> INIT: couldn't create /var/adm/utmpx
>
> or whatever the exact wording is.
>
> After playing around with it for a while, I was able to fix the problem
> by booting single user off of the install server, mounting the miniroot
> on /mnt, changing the entry for the dad driver in /mnt/etc/name_to_major
> to 136, and rerunning drvconfig/devlinks/disks to recreate the device
> nodes on the miniroot with major number 136. The update then happened
> and completed uneventfully.
>
> Surprisingly, the machine didn't require attention when it finished the
> update, and booted just fine off of its normal root partition with
> name_to_major containing a "dad 134" entry and corresponding device
> nodes. This implies the miniroot is somehow pickier about the device
> major number than the installed machine, which doesn't make any sense,
> and I'm looking for errors in how I gathered the data.
>
> In the meantime, what this means is that Ultra 5s and 10s that were
> installed at 8.3 or earlier aren't able to update to 9.2. This probably
> isn't the end of the world, but we should either fix it before the
> release happens, or make it not possible for those machines to update
> without a reinstall.
>
> Garry
>
>
