Gmail wrote:
Hello. I'm running the 'testing' release. I found that once I upgrade
to the 2.6.18 kernel my box wouldn't boot.
[...]
What appears to be happening is that while the kernel starts to boot, it
seems to change the drive letter of the disk containing the / partition
to /dev/hde. I'm not entirely clear about the boot process, but I
believe this happens when the initrd partition is mounted.
I believe a tech tip published in the recent Linux Journal (issue 153,
January 2007) by Nicholas Petreley (LJ Editor) describes the problem
you're seeing. It is apparently to do with the order in which initrd
loads disk storage device drivers, which determines the actual device
names allocated to the discovered devices.
Here's a link to what seems to be the same article :
http://delivery.acm.org/10.1145/1200000/1194965/9452.html?key1=1194965&key2=8641060711&coll=&dl=GUIDE&CFID=15151515&CFTOKEN=6184618
"Modify initrd to Make 3ware RAID the First Serial Device"
(there didn't seem to be a web copy of the article at the LJ website)
Relevant extract:
=============================< cut >==============================
"Ubuntu (and probably other distributions) do not necessarily respect
your BIOS settings [regarding which device is the root/boot device].
For example, I have an ASUS M2N32 WS Professional motherboard, which
includes a PCI-X slot for the 3ware 9550SX-4LP RAID card. I can set the
BIOS to make this card the first device. However, if I add a SATA
drive, the Ubuntu initrd will see the onboard SATA as the first SCSI
device on the system, in spite of the BIOS settings.
There may be a kernel boot parameter to override this behavior, but I
haven't found one that works. Regardless, I like the following solution
if for no other reason than it teaches one how to extract, modify an
Ubuntu initrd and then reassemble it for use.
Here's why the Ubuntu initrd defies the BIOS settings .... The following
line, which discovers storage controllers, happens to discover the
NVIDIA SATA first:
/sbin/udevplug -s -Bpci -Iclass=0x01*
You can force this script to find the 3ware controller first by adding a
line that explicitly loads the 3ware module before this line
/sbin/modprobe 3w-9xxx
This forces the script to discover the 3ware RAID card first and assign
it as /dev/sda before udevplug discovers the rest of the PCI storage
controllers .... The trick here is that you need to unpack the default
initrd file that comes with Ubuntu, modify this script, and then repack
it and use it instead of the default initrd.
Here's one way to do that ..."
=============================< cut >==============================
This stuff has apparently changed in "recent" kernels (which would
explain why you saw the problem when you upgraded from Sarge to Etch).
Interestingly, apparently the Fedora technique of labeling disk
partitions, and then mounting them by their labels, provides a nice
solution to the device order discovery & naming problem.
We are certainly going to have to find a good way round this sort of
silliness before Linux can be ready for the masses.
Good luck.
(And sorry if I'm completely off-target here)
Nick Boyce