Comment 17 for bug 1429327

Back to Steve's point (which now I understand more clearly, and looks totally right..) of event-driven multipath assembly.

> - multipath-tools should (if it doesn't already) create a symlink for the device which includes the UUID,
> but is only ever created once multipath is initialized
> - the fstab and bootloader should be configured to refer to this symlink, not the non-unique UUID

> This should address a number of issues with the initramfs,
> including allowing event-driven assembly of the multipath devices instead of the current blocking script approach.

Some observations..

In the context of relying on event-based multipath discovery.. waiting for the
root filesystem device.. and (not?) booting from an underlying device if it were
supposed to be a multipath device.
----------------------------------

I was wondering whether we would need an 'udevadm settle' after wait-for-root
in order to make sure that any /dev/disk/by-uuid symlink (or any other symlink)
pointed to multipath device at that time (i.e., it could point to an underlying
device if udev rules were still being processed and multipath hadn't run yet).

The answer is 'no', because wait-for-root only receives events from the udev
monitor after all udev rules have been processed.

wait-for-root is OK because it uses "udev" as source identifier in this call:
 udev_monitor = udev_monitor_new_from_netlink (udev, "udev");

    udev_monitor_new_from_netlink ()

 [...]
 Valid sources identifiers are "udev" and "kernel".
 [...]
 The "udev" events are sent out after udev has finished its event processing,
 all rules have been processed, and needed device nodes are created.

  https://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-monitor.html

So, it only receives the event that the waited-for /dev/disk/by-uuid symlink
exists after all udev rules are processed, so it implies that the multipath
command called from udev rules finished, and _if successful_, that the symlink
points to the multipath device rather than the underlying device (the former has
greater link_priority).

In summary, it's not possible to guarantee that the multipath command is always
sucessful; therefore, it is reasonable to depend on a symlink that won't exist
if that command fails (as pointed out by Steve);
for example: /dev/disk/by-id/dm-uuid-partX-mpath-WWID

I'm writing a snippet for /etc/grub.d/10_linux to use that idea, and another
one for the installer to modify /target/etc/fstab to a similar intent, so that
the by-id links from multipath-only devices are used rather than by-uuid of
any disk (non-unique UUID).