[Bug 1429327] Re: Boot from an unique, stable, multipath-dependent symlink

[Mauricio Faria de Oliveira]

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

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1429327

Title:
  Boot from an unique, stable, multipath-dependent symlink

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1429327/+subscriptions