Comment 3 for bug 1898758

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.