multipath discovery failed during install due to md arrays locking individual paths
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
hw-detect (Ubuntu) |
Fix Released
|
Medium
|
Mathieu Trudel-Lapierre |
Bug Description
Similarly to bug 1549504 (for LVM), but this one with LVM on top of md arrays.
During a Xenial installation, some of the multipath devices were not discovered, as individual paths were locked by MD arrays.
The fix is to deactivate MD arrays before multipath discovery (in hw-detect), and activate multipath partitions during partman/init.d (in partman-multipath), so that MD arrays can be re-activated on top of the multipath devices (slightly afterward on partman/
The fix also requires an extra udev rule in the mdadm assembly rules, because the device-mapper devices have no 'add' event (used by the rule for assembly), but only a 'change' event. The rule is required for the initramfs as well (automatically installed w/ the mdadm install triggers), otherwise the rootfs won't be found.
Failure:
~ # multipath -v5
<...>
Feb 22 14:46:02 | mpathb: addmap [0 1115734016 multipath 1 queue_if_no_path 1 alua 2 1 round-robin 0 1 1 8:16 1 round-robin 0 1 1 8:128 1]
Feb 22 14:46:02 | libdevmapper: ioctl/libdm-
Feb 22 14:46:02 | mpathb: domap (0) failure for create/reload map
<...>
Feb 22 14:46:02 | mpathc: addmap [0 1115734016 multipath 1 queue_if_no_path 1 alua 2 1 round-robin 0 1 1 8:32 1 round-robin 0 1 1 8:144 1]
Feb 22 14:46:02 | libdevmapper: ioctl/libdm-
Feb 22 14:46:02 | mpathc: domap (0) failure for create/reload map
<...>
Feb 22 14:46:02 | mpathd: addmap [0 1115734016 multipath 1 queue_if_no_path 1 alua 2 1 round-robin 0 1 1 8:48 1 round-robin 0 1 1 8:160 1]
Feb 22 14:46:02 | libdevmapper: ioctl/libdm-
Feb 22 14:46:02 | mpathd: domap (0) failure for create/reload map
<...>
Feb 22 14:46:02 | mpathe: addmap [0 1115734016 multipath 1 queue_if_no_path 1 alua 2 1 round-robin 0 1 1 8:64 1 round-robin 0 1 1 8:176 1]
Feb 22 14:46:02 | libdevmapper: ioctl/libdm-
Feb 22 14:46:02 | mpathe: domap (0) failure for create/reload map
<...>
Feb 22 14:46:02 | mpathf: addmap [0 1115734016 multipath 1 queue_if_no_path 1 alua 2 1 round-robin 0 1 1 8:80 1 round-robin 0 1 1 8:192 1]
Feb 22 14:46:02 | libdevmapper: ioctl/libdm-
Feb 22 14:46:02 | mpathf: domap (0) failure for create/reload map
~ # dmsetup table | sort
mpatha: 0 1115455488 multipath 0 1 alua 2 1 round-robin 0 1 1 8:0 1 round-robin 0 1 1 8:112 1
mpathg: 0 1115734016 multipath 0 1 alua 2 1 round-robin 0 1 1 8:96 1 round-robin 0 1 1 8:208 1
pkvmci845--vg-root: 0 5351333888 linear 259:2 5555
pkvmci845-
~ # lvm pvdisplay | grep Name
PV Name /dev/md0p3
VG Name pkvmci845-vg
~ # grep ^md /proc/mdstat
md0 : active raid0 sdm1[4] sdl1[3] sdk1[2] sdj1[1] sdi2[0]
After the patch, the md array is on top of the multipath devices, and show up as a LVM PV correctly.
~ # grep ^md /proc/mdstat
md0 : active raid0 dm-9[1] dm-10[2] dm-8[0] dm-11[3] dm-12[4]
~ # lvm vgscan
Reading all physical volumes. This may take a while...
Found volume group "pkvmci845-vg" using metadata type lvm2
~ # lvm vgchange -ay
2 logical volume(s) in volume group "pkvmci845-vg" now active
~ # lvm pvdisplay | grep Name
PV Name /dev/md0p3
VG Name pkvmci845-vg
Related branches
Changed in hw-detect (Ubuntu): | |
importance: | Undecided → Medium |
Changed in hw-detect (Ubuntu): | |
status: | New → Triaged |
assignee: | nobody → Mathieu Trudel-Lapierre (mathieu-tl) |
Hi @mathieu-tl,
Can you check this bug/patches, please?
Thanks!