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)
RHVH QE can't reproduce this issue both on automation and manual testing, could you please provide more detail steps? Test version: RHVH-4.4-20200930.0-RHVH-x86_64-dvd1.iso Test steps: 1. Install RHVH-4.4-20200930.0-RHVH-x86_64-dvd1.iso on FC machine via anaconda. 2. Select the FC disk as boot device. 3. Finish the installation. 4. Reboot and login RHVH. Test result: RHVH can boot from FC lun.
The issue is not reproducible anymore in 4.4.5 latest builds consuming new kernel.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Red Hat Virtualization security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1189
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days