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

Re: Should I report a failure to boot?



Alexander E. Patrakov wrote:
Michael Burschik wrote:

Thanks for your offer, but I think my problem is different. The grub
configuration is correct,

If it mentions "root=/dev/hdbX" or "root=/dev/hdfX", it is incorrect.

Thanks for your reply. If this is deprecated, then it is a grub/update-grub bug, since I did not put these entries there myself. However, how am I supposed to know that hdb or hdf are not disk names that have been fixed by udev?


but the kernel names the relevant hard disk
either hdb or hdf, and udev does not prevent the problem.

Udev causes the problem, because it triggers uevents from initramfs, and calls modprobe in response to them. However, it calls modprobe for your IDE controllers in parallel, and, thus, in unpredictable order. This is by design, and will never be fixed - so don't file bugs at udev. BTW, Linux From Scratch has a good page about udev inner working and inherent problems: http://www.linuxfromscratch.org/lfs/view/6.3/chapter07/udev.html

Yes, but this does not really explain why my cdrom is always hda and my hard disk, which is on the same controller, is sometimes hdb and sometimes hdf.

Applications (and in this case, it means grub) are not supposed to use kernel names that are known to be unstable because of random module loading order. They should use persistent names such as:

/dev/disk/by-label/boot
/dev/disk/by-uuid/18032ec0-7d2f-4a3c-b4d3-e248b091da65
/dev/disk/by-id/scsi-S_9QE3W0Z8-part1
/dev/disk/by-id/scsi-SATA_ST3250820AS_9QE3W0Z8-part1
/dev/disk/by-id/ata-ST3250820AS-9QE3W0Z8-part1
/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part1

or persistent names provided by volume management software, e.g. /dev/myvg/debroot (from LVM2). IOW, installing on LVM2 would have prevented the bug. LVM2 names even survive migration from old-style IDE drivers to libata-based ones, without changing a single line in any configuration file.

The bug belongs to whatever component of Debian which wrote (or forgot to update from Sarge) /boot/grub/menu.lst for you. In the case of clean install, this is "debian-installer". In the case of upgrade from Sarge, this may be "grub" (because no other package is allowed to edit the /boot/grub/menu.lst file automatically for you).

I installed Etch and have upgraded to testing. The installed grub is version 0.97-29. Running update-grub does not help.

Regards

Michael Burschik



Reply to: