Comment 10 for bug 1429327

To illustrate the problem more clearly:

> The 'multipath' command is run *before* the disks over FC show up.
> It must wait for them to settle.

> There's a wait for SCSI devices already, but it is not enough in this case.
(it actually doesn't work because scsi_wait_scan was removed from the kernel years ago.)

 ...
 Loading, please wait...
 starting version 219
 ...
 Begin: Running /scripts/local-top ...
 Begin: Loading multipath modules ...
 ...
 Begin: Waiting for scsi storage ... done.
 Begin: Discovering multipaths ...
 ...
 [ 4.088476] scsi host2: Emulex LPe12000 PCIe Fibre Channel Adapter on PCI bus 50 device 01 irq 506
 ...
 [ 7.472269] scsi 2:0:0:1: Direct-Access IBM 2810XIV 10.2 PQ: 0 ANSI: 5
 [ 7.473301] sd 2:0:0:1: Attached scsi generic sg2 type 0
 [ 7.473542] sd 2:0:0:1: [sdb] 67108864 512-byte logical blocks: (34.3 GB/32.0 GiB)
 ...

In this example, sdb is not considered by the multipath command (Discovering multipaths ...).

Another problem arising from this: a root filesystem that should be mounted on a multipath device is actually mounted on one of its single-path devices.

Explanation: the root filesystem is specified by-UUID (root=UUID=...), and the /dev/disk/by-uuid symlink will point to the last detected single-path device w/ the matching UUID.
Had the disks been detected before the multipath command ran, the symlink would be updated to point to the multipath device (higher link priority, in kpartx udev rules).