udev keeps a lock on devices while multipath-tools runs in initramfs

[Mathieu Trudel-Lapierre]

It appears that multipath-tools has issues running its script (detecting multipath devices, then running kpartx to pick up partitions, which in turn will also trigger a new run of udev rules evaluation) because udev may not always be done with settling and evaluating rules by the time the local-top/multipath script gets run.

This happens because some devices take a while to be detected, which also causes the settling to take some time. Before running multipath -v0 or kpartx, which will also trigger udev to do work, we should make sure udev has released the locks it may have on those devices, since multipath will attempt to get an exclusive lock on them too.

This can be easily reproduced in QEMU multipath installs: booting after installation will take a long time, and the resulting boot will not always be started with the multipath device (/dev/mapper/mpath[0-9]+(-part[0-9]+)?) but may instead be using the first single drive it found matching the proper UUID. (see also bug 1429327)

[Mathieu Trudel-Lapierre (cyphermox)]

Solution appears to be running udevadm settle before calling multipath -v0 and kpartx, which appears to have positive results on QEMU, and no adverse effects on systems where the multipath setup is already returning successfully.