Red Hat Bugzilla – Bug 130561
udev doesn't create raid devices (early enough?)
Last modified: 2007-11-30 17:10:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
On systems whose root devices are on (logical volumes on) raid 1
devices, generating initrd with UDEV_INITRD="yes", raid devices are
not available at the time linuxrc attempts to raidautorun them.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Run mkinitrd with any raid device active, having UDEV_INITRD=yes
Actual Results: raidautorun says the raid device is not available
Expected Results: it should be available
I'm seeing this too. Gets as far as "Loading ext3.ko module"
raidautorun: failed to open /dev/md0: 2
Creating root device
Mounting root filesystem
mount: error 6 mounting ext3
mount: error 2 mounting none
Switching to new root
switchroot: mount failed: 22
umount /initrd/dev failed: 2
kernel panic: Attempted to kill init!
My root is raid 5 instead of raid 1 as above, but same idea. Didn't
try turning off UDEV_INITRD (didn't know about udev.conf) but revert
to 4.0.6 and remake initrd and it works.
Fixed in mkinitrd 4.1.4.
Now we check for if the device exists and if not, nash will create it
before trying to do the raidautorun.
Tested 4.1.4, and it does indeed fix the problem for me.
I've just had problem with this on an FC3 machine. mkinitrd-4.1.18-2.
Actually, two problems.
First was that SCSI devices are detected asynchroniously, second was
that udev seems to be working asynchroniously. Quick and dirty
workaround was adding "sleep 10" after "insmod /lib/sym53c8xx.ko"
line, and another "sleep 10" after "/sbin/udevstart" in init script
(inside initrd image).
Without the "sleep" lines, init script would simply load the modules,
and execute udevstart withoug waiting for things be initialized
properly. When raidautorun is called, the devices are not yet
detected, so it fails to initialize RAID1 device that holds physical
volume (under LVM) with root partition on it.
I've asked about this on Linux kernel mailing list (LKML). I got
answer that this should be delt within init script that is generated
by mkinitrd. In short, PCI is hot-pluggable, and everything on it is
asynchronious. When driver loads, it starts asynchroniously searching
for devices, which sometimes can take long time. Making assumption
that things are synchronious (as mkinitrd seems to be making) is
simply wrong. It takes about 5 seconds for sym53c8xx driver to detect
disk devices on my dual SCSI card (integragted into motherboard) after
it is loaded. One person replied that FreeBSD is waiting 15 seconds
for SCSI buses to initialize. Linux dosn't waste time waiting, nor
init script does.
I guess with most devices and drivers this race condition that exists
in mkinitrd generated init script won't be hit (drivers are fast
enough in detecting the hardware). But the race condition exists, and
can be a problem on certain hardware configurations.
The fix made in 4.1.4 dosn't seem to affect this case. The problem
here is not non-existing device node, the problem is that SCSI driver
is slow in detecting disks. Should this bug be reopened?
From your description, it doesn't look like the same bug at all, it
just happens to have a similar symptom. So, open a new bug instead of
hijacking this one ;-)