Comment 20 for bug 1429327

Revision history for this message
Mauricio Faria de Oliveira (mfo) wrote : Re: ISST-LTE: system drops to initramfs after install on multipath disk

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