[26261] in Athena Bugs
Re: Linux-Athena installer improperly created partitions
daemon@ATHENA.MIT.EDU (andrew m. boardman)
Wed Dec 22 14:22:58 2004
Date: Wed, 22 Dec 2004 10:51:41 -0500
Message-Id: <200412221551.iBMFpfIa024554@pothole.mit.edu>
From: "andrew m. boardman" <amb@mit.edu>
To: kchen@mit.edu
In-reply-to: <41C0EA12.60800@mit.edu> (message from Kevin Chen on Wed, 15 Dec
2004 20:51:14 -0500)
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
>After not doing anything at "Installing RPMs" for about 15 minutes, we
>rebooted.
This, unfortunately, is a fact of life. At this point, the installation
needs to scan the RPM headers for the entire release (to build a
dependency tree), and given the size of the release and a potentially
slow network and/or CPU, it can take quite a while; 15 minutes is
definitely not unheard-of, and I've seen it take hours. What sort of
machine was this?
>Unsure whether this was related to the version 5 image, I again used the
>version 5 CD, but specified tae-kwon-leap.mit.edu and
>/linux/rhlinux4.img. This gave a bunch of AFS errors and the system
>automatically rebooted.
Yeah, that's pretty much just doomed. It won't have gotten far enough to
hurt anything, though.
[The old Windows partition is gone, but the installer hasn't overwritten
the relevant part of the disk, instead creating linux partitions after it.]
That's really poor. Do you have any idea what the partition number and
numerical partition type was before the install, and can you tell me what
you recreated it as? (In an ideal easily-debuggable world, the output of
"sfdisk -d -uS /dev/hda" (or whatever disk applies) and the contents of
/proc/partitions and /tmp/partitioning.old would be handy in figuring out
what went wrong.)
>Also, the installer seems to have created an insufficient number of
>partitions. /dev/hda5 is swap, /dev/had6 looks like AFS cache, and
>/dev/hda7 looks like root, but there's no /boot partition. (My guesses
>here are based on the number of blocks in the partitions.)
Your partition IDs are correct, but this behaviour is actually correct as
well. Boot partitions are only created for standalone (full-disk)
installs, and that only for consistency among cluster machines. Given
modern hardware and boot loaders, there's not a lot of point in them
otherwise.
I'll do more testing with the 4.99a installer and some scenarios like
this. (New code for the version 5 CD is otherwise done, but the most
likely thing right now seems to be changes in the way partitions are
registered by the kernel, which has the potential to be really poor...)
My apologies for the delay in getting back to you on this.
