Bug 197547 - multi-path devices not brought up early enough during boot
multi-path devices not brought up early enough during boot
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-07-03 19:18 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-02 11:40:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2006-07-03 19:18:31 EDT
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
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):

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:

Expected results:

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.
Comment 1 Peter Jones 2006-07-13 11:36:43 EDT
Why are you using dm-multipath here?

Actually, why are you using device-mapper here at all?
Comment 2 Alexandre Oliva 2006-07-13 13:10:42 EDT
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.
Comment 3 Peter Jones 2006-07-13 13:16:33 EDT
Well, that config simply isn't right.  Whatever is doing that is where the bug is.
Comment 4 Alexandre Oliva 2006-07-14 17:09:30 EDT
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.
Comment 5 Alexandre Oliva 2006-07-15 05:14:22 EDT
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.
Comment 6 Alexandre Oliva 2006-07-28 16:57:51 EDT
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.
Comment 7 Peter Jones 2006-08-02 11:40:47 EDT
Root on multipath works fine for me in the current builds.

Note You need to log in before you can comment on or make changes to this bug.