Red Hat Bugzilla – Bug 197547
multi-path devices not brought up early enough during boot
Last modified: 2007-11-30 17:11:36 EST
Description of problem: The raid 1 devices that are brought up after a reboot do not include the raid 1 members in external USB disks, now mapped to devicemapper long names. This is a similar symptom to bug 193206, but with a very different cause. init contains: echo "Loading usb-storage.ko module" insmod /lib/usb-storage.ko echo Waiting for driver initialization. stabilized --interval 1500 /proc/bus/usb/devices [...] echo Making device-mapper control node mkdmnod mkblkdevs [...] Adding dm map "SMaxtor_OneTouch_Y4237Z9E_" rmparts sda dm create SMaxtor_OneTouch_Y4237Z9E_ --uuid mpath-SMaxtor_OneTouch_Y4237Z9E_ 0 320171008 multipath 0 0 1 1 round-robin 0 1 1 8:0 1000 dm partadd SMaxtor_OneTouch_Y4237Z9E_ raidautorun /dev/md7 echo Scanning logical volumes lvm vgscan --ignorelockingfailure [...] and dmesg says: SCSI device sda: 320171008 512-byte hdwr sectors (163928 MB) sda: Write Protect is off sda: Mode Sense: 1c 00 00 00 sda: assuming drive cache: write through sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 > sda4 sd 0:0:0:0: Attached scsi disk sda PM: Adding info for No Bus:target0:0:1 PM: Removing info for No Bus:target0:0:1 PM: Adding info for No Bus:target0:0:2 PM: Removing info for No Bus:target0:0:2 PM: Adding info for No Bus:target0:0:3 PM: Removing info for No Bus:target0:0:3 PM: Adding info for No Bus:target0:0:4 PM: Removing info for No Bus:target0:0:4 PM: Adding info for No Bus:target0:0:5 PM: Removing info for No Bus:target0:0:5 PM: Adding info for No Bus:target0:0:6 PM: Removing info for No Bus:target0:0:6 PM: Adding info for No Bus:target0:0:7 PM: Removing info for No Bus:target0:0:7 usb-storage: device scan complete md: raid1 personality registered for level 1 device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com device-mapper: multipath: version 1.0.4 loaded device-mapper: multipath round-robin: version 1.0.0 loaded md: Autodetecting RAID arrays. md: could not open unknown-block(8,5). md: could not open unknown-block(8,6). md: could not open unknown-block(8,7). md: could not open unknown-block(8,8). md: could not open unknown-block(8,9). md: autorun ... md: considering hda9 ... md: adding hda9 ... md: hda8 has different UUID to hda9 md: hda7 has different UUID to hda9 md: hda6 has different UUID to hda9 md: hda5 has different UUID to hda9 md: created md9 md: bind<hda9> md: running: <hda9> raid1: raid set md9 active with 1 out of 2 mirrors md: considering hda8 ... [...] Version-Release number of selected component (if applicable): mkinitrd-5.0.46-1 device-mapper-1.02.07-1.0 How reproducible: Every time Steps to Reproduce: 1.Set up RAID 1 to an external USB disk 2.Try to have it brought up on boot Actual results: Can't Expected results: Should Additional info: I'm pretty sure this has to do with the dm mapping of /dev/sda* to device mapper devices. It even stops mdadm from adding the devices to the raid devices I have, I now have to use the device mapper nodes to accomplish this, otherwise mdadm complains that the devices are busy.
Why are you using dm-multipath here? Actually, why are you using device-mapper here at all?
I wish I knew... Someone apparently decided that device-mapper was the way to go for external disks. Now all external disks go through this (pointless?) exercise, breaking all sorts of stuff. See bug 197548 for one.
Well, that config simply isn't right. Whatever is doing that is where the bug is.
FWIW, simply closing a bug just because it's not in your component doesn't sound right. It's much better to reassign to your best guess as to where the problem might actually be. As it turns out, it appears that the problem is already fixed, so leaving it closed is just fine in this case.
I'm afraid something ought to be done about this bug in mkinitrd. The current set up is useless if device-mapper-multipath is installed. That's what causes device-mapper devices to be created for disks not set as in use very early in the boot. If you ever need to replace a raid device, you won't get a chance to add the raid device as the partition itself, you'll have to use the device-mapper node, but then mkinitrd will try to get such a device node set up at boot time, and AFAICT not the underlying device, and then things don't quite work. Maybe this can be fixed by arranging for device-mapper-multipath's udev rules to not introduce such (pointless?) dm nodes, but otherwise it will take some mkinitrd work to fix the current broken situation.
It was a bug in device-mapper-multipath config file, after all, but it still appears to be the case that, if your root depends on an actual multi-path device, it won't work, so I'm changing the bug accordingly.
Root on multipath works fine for me in the current builds.