Bug 1892573

Description of problem:
A fresh installation of RHVH 4.4.2 on an external FC disk fails to boot in the first reboot after Anaconda.

After switching to the real root, the /boot partition fails to mount and the boot process is then stuck forever after failing to start the kdump service.

We made it to boot by using the multipath device instead of the UUID in /etc/fstab for the /boot and /boot/efi filesystems.

If we interrupt the boot process with 'rd.break=pre-pivot', we correctly see the multipath device with 4 healthy paths. Running blkid displays the UUID of the /boot filesystem duplicated for every path.


Version-Release number of selected component (if applicable):
RHVH 4.4.2 (RHVH-4.4-20200722.1-RHVH-x86_64-dvd1.iso)

How reproducible:
It has to be a race condition, because a 10% of the boots using the UUID succeed. The customer has to install dozens of new servers and it happens in all of them.

Steps to Reproduce:
1. Install RHVH 4.4.2 on a FC disk. In Anaconda select the multipath device.
2. Reboot

Actual results:

~~~
[ TIME ] Timed out waiting for device dev-mapper-rhvh\x2dswap.device.
[DEPEND] Dependency failed for Resume from hibernation using device /dev/mapper/rhvh-swap.

[FAILED] Failed to mount /boot.
See 'systemctl status boot.mount' for details.
[DEPEND] Dependency failed for /boot/efi.
[DEPEND] Dependency failed for Local File Systems.

[FAILED] Failed to start Crash recovery kernel arming.
~~~

Expected results:
A system booting without problems.


Additional info:
- We tried to add the options 'x-systemd.device-timeout=0,x-systemd.mount-timeout=0' to /etc/fstab but the mount process hung forever.
- Storage array is NetApp in C-Mode
- HBA using driver qla2xxx: Fibre Channel [0c04]: QLogic Corp. ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter [1077:2261] (rev 01)