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.
echo "Loading usb-storage.ko module"
echo Waiting for driver initialization.
stabilized --interval 1500 /proc/bus/usb/devices
echo Making device-mapper control node
Adding dm map "SMaxtor_OneTouch_Y4237Z9E_"
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_
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: email@example.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: running: <hda9>
raid1: raid set md9 active with 1 out of 2 mirrors
md: considering hda8 ...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Set up RAID 1 to an external USB disk
2.Try to have it brought up on boot
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
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.