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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]