Description of problem: After installation, RHEV-H can not boot from a mpathed disk who's wwid is given on the kernel cmdline. Version-Release number of selected component (if applicable): rhev-hypervisor7-7.0-20150105.0.1 How reproducible: Always Steps to Reproduce: 1. Install RHEV-H in a VM with a multipathed SATA disk (two SATA disks pointing to the same image file, no caching, same serial) 2. Reboot 3. Actual results: Dracut fails to boot Expected results: RHEV-H boots Additional info:
Exact steps to reproduce: 1. Create a VM with multipathed SATA bus or use a real mpath host 2. Install RHEV-H from comment 1 onto the mpathed disk 3. Reboot
This bug is necessary for RHEV 3.5 RC
Created attachment 976576 [details] virt-manager definition for vm with mpathed disk The xml defintiion can be used to create the vm which can be used to reproduce this bug.
Created attachment 976832 [details] Parts of dracut log from a failed boot This bug seems to be hard to reproduce when rd.debug is set, which undermines that this might be racy (different call time deltas, because of the debug output …). Anyhow, the attachement should illustrate what is happening, dracut is caught in a loop which tries to find the fs labeled Root, but this never appears, because the partitions (which contain the fs) are not discovered (not seen in the logs).
Created attachment 976837 [details] complete log of a failed attempt This logfile is a complete log from a failed attempt
Okay, the issue seems to be in qemu: Sometimes, in rare cases the partition table can not be read from one of the two devices pointing to the same backing file. And booting fails because multipath chosse the device which can not be used for reading as the active device, then booting fails. This happens with the SATA bus, switching to IDE seems to solve it (after the first few tries).
Switching to IDE did not solve the issuem, but switching to raw instead of qcow2 looks promising, for now.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fabian can you still reproduce with fedora 23 qemu?
I can actually not even reproduce it on Fedora 22 anymore.