[6954] in testers
Re: prevert.mit.edu: failed Linux 9.4 update
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri May 6 18:07:17 2005
Date: Fri, 6 May 2005 18:07:05 -0400
Message-Id: <200505062207.j46M75oH023092@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
CC: "andrew m. boardman" <amb@MIT.EDU>, testers@MIT.EDU
In-reply-to: <200505042119.j44LJJDF005569@pyramids.mit.edu>
> I don't know why anaconda upgrades wouldn't run into the same
> problem, partly because I don't know what's cleaning out /dev.
I have some more information about this:
* /etc/rc.sysinit runs /sbin/start_udev, which mounts a tmpfs
filesystem onto /dev, thus effectively clearing it out. This
mount does not show up in the output of "mount", but does show up
(along with the sysfs mount and a few other things) in
/proc/mounts.
* start_udev then runs udevstart, which iterates over /sys and
creates devices for everything currently existing.
We apparently have license to do whatever we want to /dev after the
update, since (a) it won't have any effect on the system post-reboot,
and (b) it's pretty screwed to start with. I suggest we use rpm2cpio
to extract the contents of the RHEL3 dev RPM back into /dev (without
installing it in the RPM database), and then re-run lilo. I think
this will also fix our mouse problems, although I worry about systems
which use /dev/mouse and don't have it pointing at a psaux device. We
could handle that by writing a variant of the fix-mouse-psaux script,
but I think I'll wait for an example case first.
An alternative to re-extracting the RHEL3 dev RPM would be to run
udevstart ourselves. But this might not as accurately reflect the
pre-update state of the /dev tree (thus perhaps frustrating
fix-mouse-psaux), and might fail altogether if Linux 2.4 doesn't have
sysfs support or if RHEL3 isn't using it.
