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