Comment 40 for bug 1429327

@smoser

> Yeah, its been "fun".

Hahah, I do understand the quotes.
Well, it's the way that turned out to be more fruitful to put it. :)

>> Well, I'm not positive the change to root=UUID=multipath- (done via ROOT=)
>> would be well accepted by boot userspace,

> I'm not sure what you mean by "accepted". [snip]

Not a good word for that context.
I meant: something in boot userspace (init scripts & the command they run, et al) didn't like it / failed with that root= parameter in some tests (comment #28)

> Your path *will* work, but will break anyone that doesn't have their root device on multipath.

Yes.
One of the things I couldn't devise clearly is to detect when multipath is really needed for the rootfs.
(that's the reason I added a helpful message about multipath-tools-boot in one of the patches for the initramfs script)

I guess one of the curtin's bugs mention to check for more than 1 device w/ a given WWID..
but Murphy might eventually ensure a condition where all but one paths are down when booting/detecting that (some sort of "degraded SAN" condition, is the term I read somewhere).
In a related aspect, newer multipath-tools introduced "find_multipaths" that does something similar, and for the 1-path case, it relies on the wwids/bindings file to see if that path was known previously.

An option is to use that on initramfs, but also implies the initramfs wwids/bindings file should be always in sync w/ that in the rootfs (which is not always intuitive for users.. regenerate the initramfs on SAN/topology changes).

> One thing I realized yesterday is that whatever solution we come up with for root,
> we also have to use for other mount points on multipath devices.

IIRC the patch for d-i (parman-base.. fstab-something) does that, and I believe that (+ the UUID=multiapath-<uuid>) is what introduced the failure I mentioned in comment #28.

> So, i do like the idea of multipath-<uuid> except for the guaranteed boot failure if
> you install that package and do not have multipath.

I'd suggest not to proceed with that route until that boot error is understood.
I had the impression something really expected an UUID after the UUID= parameter, not really interpreting it as a symlink, but as something to search for in the filesystems' UUID fields in the partitions' data; but I didn't investigate it further by that time.

To rule that out, I wondered about using /root/by-id/multipath-uuid-<uuid>, for example -- or anything that doesn't mean anything more than a symlink, that could hit the UUID interpretation bug I suspected.