Comment 19 for bug 1540401

------- Comment From <email address hidden> 2016-02-04 16:52 EDT-------
Hi @mathieu-tl

(In reply to comment #44)
> This isn't obvious to reproduce. So far, I haven't had the system fail to
> boot or fail to mount all partitions. I have been testing *without*
> multipath-tools 0.4.9-3ubuntu7.8; so not using multipathd in the initramfs.

> My test system is indeed a ppc64el qemu VM using spapr-vscsi.

I could reproduce the problem in that scenario by using break=multipath in the kernel cmdline
(which forces LVM udev rules to run before multipath discovery).

> I suppose it may be that I'm using a partitioning that happens to work?

I'd expect it to fail in any case with LVM on top of multipath devices,
and LVM scan/volume activation happening before multipath discory
(root cause: LVM locking an individual path before multipath takes it).

> Could you please add the output of: sudo dmsetup ls --tree -o blkdevname

Sure.

qemu-kvm guest w/ ibm-vscsi:

ubuntu@mauricfo4:~$ sudo dmsetup ls --tree -o blkdevname
[sudo] password for ubuntu:
mpath0-part2 <dm-2> (252:2)
??mpath0 <dm-0> (252:0)
?? <sdb> (8:16)
?? <sda> (8:0)
mpath0-part1 <dm-1> (252:1)
??mpath0 <dm-0> (252:0)
?? <sdb> (8:16)
?? <sda> (8:0)
mauricfo4--vg-swap_1 <dm-5> (252:5)
??mpath0-part3 <dm-3> (252:3)
??mpath0 <dm-0> (252:0)
?? <sdb> (8:16)
?? <sda> (8:0)
mauricfo4--vg-root <dm-4> (252:4)
??mpath0-part3 <dm-3> (252:3)
??mpath0 <dm-0> (252:0)
?? <sdb> (8:16)
?? <sda> (8:0)

powervm lpar w/ ibmvfc:

root@biglp1:~# dmsetup ls --tree -o blkdevname
mpath0-part2 <dm-6> (252:6)
??mpath0 <dm-0> (252:0)
?? <sdz> (65:144)
?? <sdu> (65:64)
?? <sdp> (8:240)
?? <sdk> (8:160)
?? <sdf> (8:80)
?? <sda> (8:0)
mpath2 <dm-2> (252:2)
?? <sdab> (65:176)
?? <sdw> (65:96)
?? <sdr> (65:16)
?? <sdm> (8:192)
?? <sdh> (8:112)
?? <sdc> (8:32)
mpath0-part1 <dm-5> (252:5)
??mpath0 <dm-0> (252:0)
?? <sdz> (65:144)
?? <sdu> (65:64)
?? <sdp> (8:240)
?? <sdk> (8:160)
?? <sdf> (8:80)
?? <sda> (8:0)
mpath1 <dm-1> (252:1)
?? <sdaa> (65:160)
?? <sdv> (65:80)
?? <sdq> (65:0)
?? <sdl> (8:176)
?? <sdg> (8:96)
?? <sdb> (8:16)
biglp1--vg-root <dm-8> (252:8)
??mpath0-part3 <dm-7> (252:7)
??mpath0 <dm-0> (252:0)
?? <sdz> (65:144)
?? <sdu> (65:64)
?? <sdp> (8:240)
?? <sdk> (8:160)
?? <sdf> (8:80)
?? <sda> (8:0)
mpath4 <dm-4> (252:4)
?? <sdad> (65:208)
?? <sdy> (65:128)
?? <sdt> (65:48)
?? <sdo> (8:224)
?? <sdj> (8:144)
?? <sde> (8:64)
biglp1--vg-swap_1 <dm-9> (252:9)
??mpath0-part3 <dm-7> (252:7)
??mpath0 <dm-0> (252:0)
?? <sdz> (65:144)
?? <sdu> (65:64)
?? <sdp> (8:240)
?? <sdk> (8:160)
?? <sdf> (8:80)
?? <sda> (8:0)
mpath3 <dm-3> (252:3)
?? <sdac> (65:192)
?? <sdx> (65:112)
?? <sds> (65:32)
?? <sdn> (8:208)
?? <sdi> (8:128)
?? <sdd> (8:48)

------- Comment From <email address hidden> 2016-02-04 16:53 EDT-------
@mathieu-tl

(In reply to comment #45)
> > My test system is indeed a ppc64el qemu VM using spapr-vscsi.
>
> I could reproduce the problem in that scenario by using break=multipath in
> the kernel cmdline
> (which forces LVM udev rules to run before multipath discovery).

Correction: break=pre-multipath