[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian switches driver letters preventing boot



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
>
>
>   



Reply to: