Sorry for the delay on this.
Here's the patch addressing most of Steve's directions (comment #13).
I'll submit the remaining changes shortly.
Patch description:
> - 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
Now kpartx.rules creates the /dev/disk/by-uuid/multipath-<UUID> symlink for that.
Theoretically (I read somewhere), the symlinks in 'by-uuid' should be *UUID-based*, and not strictly *only the UUID string*.
So, either a 'multipath-' prefix or '-multipath' suffix would do it.
I opted for a prefix so not to confuse scripts with expressions like "/dev/disk/by-uuid/[[:uuid-chars:]]*" (don't strictly match the entire string) to think that the '-multipath' suffix is part of the UUID.
> - the fstab and bootloader should be configured to refer to this symlink, not the non-unique UUID
I'll submit the installer changes for the fstab shortly.
After some thinking and attempts, I opted not to require changes to the bootloader, but rather to keep it contained in multipath-tools-boot.
Ideally, it'd be nice to install new scripts (wrappers?) to /etc/grub.d with multipath-tools-boot, but it's not easy to wrap/re-use 10_linux and 30_os-prober currently.
Anyway, it requires just a simple change to /etc/grub.d/{10_linux,30_os-prober}, but would still require a change to non-multipath stuff.
I thought this would be a more simplistic and multipath-tools contained option:
Change the ROOT parameter in the initramfs from '/dev/disk/by-uuid/<UUID>' to '/dev/disk/by-uuid/multipath-<UUID>', thus relying on the new symlink; short and simple.
I added a failure_hook, so if wait-for-root can't find the root device (due to this change or *any other* multipath problem), the user will descriptively know that, and get a shell.
> 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.
I'll submit the event-driven assembly changes shortly too.
That's optional (and builds on-top of this change) - things already work really fine with the patch as it is.
Hi Mathieu and Steve,
Sorry for the delay on this.
Here's the patch addressing most of Steve's directions (comment #13).
I'll submit the remaining changes shortly.
Patch description:
> - 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
Now kpartx.rules creates the /dev/disk/ by-uuid/ multipath- <UUID> symlink for that.
Theoretically (I read somewhere), the symlinks in 'by-uuid' should be *UUID-based*, and not strictly *only the UUID string*. by-uuid/ [[:uuid- chars:] ]*" (don't strictly match the entire string) to think that the '-multipath' suffix is part of the UUID.
So, either a 'multipath-' prefix or '-multipath' suffix would do it.
I opted for a prefix so not to confuse scripts with expressions like "/dev/disk/
> - the fstab and bootloader should be configured to refer to this symlink, not the non-unique UUID
I'll submit the installer changes for the fstab shortly.
After some thinking and attempts, I opted not to require changes to the bootloader, but rather to keep it contained in multipath- tools-boot.
Ideally, it'd be nice to install new scripts (wrappers?) to /etc/grub.d with multipath- tools-boot, but it's not easy to wrap/re-use 10_linux and 30_os-prober currently. d/{10_linux, 30_os-prober} , but would still require a change to non-multipath stuff.
Anyway, it requires just a simple change to /etc/grub.
I thought this would be a more simplistic and multipath-tools contained option: by-uuid/ <UUID>' to '/dev/disk/ by-uuid/ multipath- <UUID>' , thus relying on the new symlink; short and simple.
Change the ROOT parameter in the initramfs from '/dev/disk/
I added a failure_hook, so if wait-for-root can't find the root device (due to this change or *any other* multipath problem), the user will descriptively know that, and get a shell.
> 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.
I'll submit the event-driven assembly changes shortly too.
That's optional (and builds on-top of this change) - things already work really fine with the patch as it is.