Thanks, Nick. This seems to get me part of the way there. I created a modified initrd that does a "modprobe -q hpt366" before it loads the generic ide module. The hpt366 module was already in the initrd image. I modified my /etc/fstab to reflect hda instead of hde for the root drive.
My menu.lst entry says to boot from /dev/hda1 which oddly enough has always worked and is the only configuration that does work. Grub reports a boot from hd(0,0). However, during boot, it seems to indicate that it's trying to get initrd from /dev/hde (now treating hda as if it were hde). It then times out trying to load /scripts/local-top. Eventually I get a rudimentary shell where I can mount the root drive as /dev/hda1. I've tweaked the initrd scripts, but yet it's still alternately treating the root drive as hda and hde. Where is that coming from? Thanks Mark Nick Boyce wrote: > 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]
