[3907] in Release_7.7_team
Different Solaris update miniroot
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jul 3 22:54:44 2003
Date: Thu, 3 Jul 2003 22:54:41 -0400
Message-Id: <200307040254.h642sfLp026286@error-messages.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Short form: the update miniroot for Solaris has changed in the dev
cell, in order to work around the problem with hardware installed at
8.3. Before the public release, we need people to test dev cell
updates from 9.1 to 9.2 on various different kinds of Sun hardware to
make sure that the new miniroot volume works. Please help out if you
are able to.
Long form: miki thinks our update problem is not related to the dad
134 device (in particular, her test machine demonstrated the failure
even though the dad device was set to 136) and that it is related to
having devices in /etc/name_to_major which aren't appropriate for the
hardware. Or something. At any rate, the current stopgap solution is
to switch from a Solaris 9 update miniroot to a Solaris 8 update
miniroot.
In the long run, it actually does make sense to use an update miniroot
matching the version you're updating from, rather than the version
you're updating to. That way you can just copy in the
/etc/name_to_major from the root. It does mean we need two different
update miniroots, though (one if you're updating from 9.1 to 9.2,
another if you're doing a 9.2 patch release--assuming we ever do a
miniroot patch release, of course).
