Comment 14 for bug 1429327

Hi Steve,

> Given that we *know* that the UUID is not unique in the multipath scenario,
> and know this at install time, I think it's wrong for us to configure the system
> to reference filesystems via this non-unique identifier.

I see your point.
Although, I'm not sure it's technically 'wrong' to do that, given that we're relying on an udev feature/thing to handle this (which you know, as an underlying thing, is supposed to work, and actually does).
I guess it's an udev decision/thing to use (sym)link_priority to do this (i.e., the by-uuid symlink to a partition in a multipath disk is assigned a higher priority in kpartx udev rules, and thus the 'active' symlink is that one, until the multipath disk disappears).

> - 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

There's something almost there being done, but not really w/ an UUID; it has the device name and partition number in place:
    /dev/disk/by-id/dm-uuid-part2-mpath-0QEMU<...>HARDDISK<...>serial_one
Maybe a dm-uuid-part-mpath-<UUID> should address what you mean?

> 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.

May you please clarify? I'm not positive I got it.

AFAICT, for event-driven assembly of multipath devices, it takes calling 'multipath' from an udev ruleset, which is no longer possible w/ recent systemd-udev (bug 1431650).

And the real problem in this bug (for which the by-UUID problem is a consequence) is waiting for the SCSI scan to complete, which can't be guaranteed w/ the current scripts, in my understanding.

Given the case where the root fs is on a multipath device, and it is an async-SCSI-scan device (e.g., fibre channel), it's hard to tell when all events/the event of the root fs multipath device is completed. (i.e., udevadm settle is not enough).

Even the 'sleep' work-around doesn't guarantee anything -- it just helps; say, an SCSI scan that takes more than the sleep threshold, on which the root fs was placed at.

This is an interesting problem.. :)