vmtests.test_multipath_lvm.Centos70TestMultipathLvm failing in curtin-vmtest-devel-amd64

Can you attach the artifacts for this test? the logs/* contents would be helpful to see the install and boot serial-console log files.

Attaching logs.

Looks like a poor assumption was made around device-mapper numbering:

[ 89.840658] cloud-init[955]: drwxr-xr-x 2 root root 120 Oct 6 05:27 .
[ 89.841893] cloud-init[955]: drwxr-xr-x 17 root root 3920 Oct 6 05:27 ..
[ 89.843098] cloud-init[955]: crw------- 1 root root 10, 236 Oct 6 05:26 control
[ 89.844469] cloud-init[955]: lrwxrwxrwx 1 root root 7 Oct 6 05:27 mpatha -> ../dm-1
[ 89.854995] cloud-init[955]: lrwxrwxrwx 1 root root 7 Oct 6 05:27 mpatha-part1 -> ../dm-2
[ 89.860959] cloud-init[955]: lrwxrwxrwx 1 root root 7 Oct 6 05:27 mpatha-part2 -> ../dm-3
[ 89.863047] cloud-init[955]: + sleep 5
[ 94.864004] cloud-init[955]: + ls -al /sys/class/block/dm-0/holders/
[ 94.869368] cloud-init[955]: ls: cannot access '/sys/class/block/dm-0/holders/': No such file or directory

99 out of 100 times, mpatha would be dm-0 since we're creating the *first* device mapper on a clean system; however; sometimes we don't get dm-0.

So the fix here is for this script to read the dm-X name from the /dev/mapper/mpatha link so we can show the holders tree for that device (that there are no LVM holders against the mpath devices as we're creating a "buried" lvm on top of multipath devices for curtin to ensure it can wipe clean.

This bug is fixed with commit c696c8d1 to curtin on branch master.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=c696c8d1

This bug is believed to be fixed in curtin in version 21.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.