Comment 21 for bug 1429327

The test-cases performed with the patch:

Install the modified multipath-tools' binary packages; the initramfs is updated with the changes.

Reboot. The system booted successfully; good.
Notice:
- unmodified kernel cmdline
- root filesystem mounted from the 'by-uuid/multipath-<UUID>' symlink
- it points to a device-mapper virtual block device
- the symlink is unique (no other devices claim it).

 $ cat /proc/cmdline
 BOOT_IMAGE=/boot/vmlinux-3.19.0-9-generic root=UUID=7fec6766-3166-4395-982a-555ecce92667 ro

 $ df /
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667 31483800 2374984 27486444 8% /

 $ udevadm info -q path /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667
 /devices/virtual/block/dm-4

 $ ls -1 /run/udev/links/*by-uuid*multipath-7fec6766-3166-4395-982a-555ecce92667
 b252:4

Verify the failure hook.
Reboot with 'break=top,post-multipath'.

 Reduce the wait-for-root timeout for debugging purposes.
 (initramfs) sed 's:\(ARCHDELAY\)=[0-9]\+:\1=10:' -i /scripts/local
 (initramfs) exit

 Check the expected root device:
 (initramfs) cat /proc/cmdline
 BOOT_IMAGE=/boot/vmlinux-3.19.0-9-generic root=UUID=7fec6766-3166-4395-982a-555ecce92667 ro break=top,post-multipath

 Initially, things are alright:

 (initramfs) ls -l /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667
 lrwxrwxrwx 1 10 /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667 -> ../../dm-3

 Now, make things wrong:

 (initramfs) multipath -F
 (initramfs) ls -l /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667
 ls: /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667: No such file or directory

 (initramfs) exit

 ~10 seconds for wait-for-root timeout...

 The informative message is displayed; good; the failure hook is OK.
  ...
  WARNING: the root device is supposed to be a multipath device,
  but it doesn't look like one: it doesn't have a multipath-UUID
  symlink, but it does have a non-multipath (normal) UUID symlink.
  ...

 If you don't try to fix anything and exit, the good and old 'root device not found' message appears, normally.
  ...
  Gave up waiting for root device. Common problems:
  ...
  ALERT! /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667 does not exist. Dropping to a shell!
  ....

Verify the failure hook again, but now let's fix things:

 (repeat steps above)
 ...
 WARNING: the root device is supposed to be a multipath device,
 but it doesn't look like one: it doesn't have a multipath-UUID
 symlink, but it does have a non-multipath (normal) UUID symlink.
 ...

 (initramfs) multipath -v0
 (initramfs) exit

 The initramfs continued on, and the system booted successfully:

 $ cat /proc/cmdline
 BOOT_IMAGE=/boot/vmlinux-3.19.0-9-generic root=UUID=7fec6766-3166-4395-982a-555ecce92667 ro break=top,post-multipath

 $ df /
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667 31483800 2375308 27486120 8% /

 $ udevadm info -q path /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667
 /devices/virtual/block/dm-6

Finally, verify the failure hook again, using the 'TIP (not recommended)' steps.
It boots from the fake symlink (points to underlying/single-path device), so you get the usual errors about device-mapper failing to get the underlying because it's locked (root filesystem mountpoint), plus some "waiting" delays.

 (repeat steps above)
 ...
 WARNING: the root device is supposed to be a multipath device,
 but it doesn't look like one: it doesn't have a multipath-UUID
 symlink, but it does have a non-multipath (normal) UUID symlink.
 ...

 (initramfs) uuid=7fec6766-3166-4395-982a-555ecce92667
 (initramfs) ln -s $uuid /dev/disk/by-uuid/multipath-$uuid && exit

 ...
   Starting LSB: multipath daemon...
 [...] device-mapper: table: 252:4: multipath: error getting device
 [...] device-mapper: table: 252:4: multipath: error getting device
 ...
 A start job is running for dev-mapp...x2dpart3.device (37s / 1min 30s)
 ...

 $ cat /proc/cmdline
 BOOT_IMAGE=/boot/vmlinux-3.19.0-9-generic root=UUID=7fec6766-3166-4395-982a-555ecce92667 ro break=top,post-multipath

 $ df /
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667 31483800 2386948 27474480 8% /

 $ udevadm info -q path /dev/disk/by-uuid/multipath-7fec6766-3166-4395-982a-555ecce92667
 /devices/vio/71000002/host0/target0:0:1/0:0:1:0/block/sdb/sdb2

 $ ls -1 /run/udev/links/*by-uuid*multipath-7fec6766-3166-4395-982a-555ecce92667
 ls: cannot access /run/udev/links/*by-uuid*multipath-7fec6766-3166-4395-982a-555ecce92667: No such file or directory

  (i.e., the fake symlink is expectedly not maintained by udev, which is part of why this is not recommended :)

If you remove the UUID option from GRUB, it doesn't touch anything:

 # GRUB_DISABLE_LINUX_UUID=true update-grub
 ...
 # grep root= /boot/grub/grub.cfg
  linux /boot/vmlinux-3.19.0-9-generic root=/dev/mapper/mpath1-part2 ro
          linux /boot/vmlinux-3.19.0-9-generic root=/dev/mapper/mpath1-part2 ro
          linux /boot/vmlinux-3.19.0-9-generic root=/dev/mapper/mpath1-part2 ro recovery nomodeset
 ...
 # reboot
 ...
 $ cat /proc/cmdline
 BOOT_IMAGE=/boot/vmlinux-3.19.0-9-generic root=/dev/mapper/mpath1-part2 ro

 $ df /
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/mapper/mpath1-part2 31483800 2387108 27474320 8% /

So, I believe these tests cover all the functionality added.
Good to go?