@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 Bugs, which is subscribed to 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 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
