Description of problem: Fedora 15 does not seem to want to install as a DomU of a RHEL 5.5 Dom0 Fedora 14 can be installed from a DVD, Fedora 15 fails to find the hard disk device. A similar failure seems to occur if you install 14, update to the latest packages and then run preupgrade to update to 15. The upgrade completes but on reboot the disk cannot be found and the reboot drops into dracut. Version-Release number of selected component (if applicable): Fedora 14 -> 15 regression How reproducible: The Dom0 tested is the RHEL 5.5 with latest upgrades. I can create a new virtual machine from a Fedora 14 DVD but not a second from a Fedora 15 DVD. Both startup anaconda but the later cannot find the (virtual) hard disk to install to. The qemu-dm starts on the Dom0 as /usr/lib64/xen/bin/qemu-dm -d 30 -m 960 -boot c -serial pty -vcpus 2 -acpi -usb -k en-us -domain-name Fedora15 -net nic,vlan=1,macaddr=00:16:3e:05:97:aa,model=rtl8139 -net tap,vlan=1,bridge=xenbr0 -vnc 127.0.0.1:30 -vncunused Steps to Reproduce: 1. Download Fedora 15 DVD 2. Use the DVD iso as the CD in a virtual machine 3. Can load installer from the DVD or run media check but install reports 'no device' Actual results: DomU VM stops with nowhere to go. Using the alternate F14 -> preupgrade the boot of F15 ends up in dracut. Expected results: Fedora 15 anaconda session able to see a hard disk or a successful F15 boot ! Additional info: The Dom0 is x86_64 as are both the 14 and 15 DVD iso
*** Bug 718382 has been marked as a duplicate of this bug. ***
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: adding 'xen_emul_unplug=never' to the Fedora 15 kernel args as discussed in 718382 provides a workround
This issue still persists in FC16 (currently using alpha DVD beta DVD will tke anotheer 26 hours to download at present speeds) Workaround fails due to continually repeated "Device reported invalid CHS sector 0" errors
Please consider this bug as an Fedora 16 Beta release blocker [1]. It impacts the release criterion that "The release must boot successfully as a virtual guest in a situation where the virtual host is running a supported Xen implementation". [1] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria
Well ... after more than an hour of udev(?) disc detection errors scrolling past, anaconda eventually started, then in graphics mode, anaconda proceeded to do its own storage detection ... after two more hours it proclaimed that it had seen my 16GB virtual /dev/sda but it was unreadable and requested permission to overwrite anything that might be on there. After a futher 30 minutes it asked the usual timezone/hostname/network/partition questions ... and then re-examined storage devices again ... after another hour confirmation to write the partition table ... after which it seemed to stall permanently.
andy: i'm afraid we're likely going to drop that criterion, as we don't have any grounds for requiring it any more. but this is certainly something we should try and fix for F16. nevertheless proposing as a blocker so we can discuss dropping the criterion.
Why would Fedora drop Xen domU support, now when Xen dom0 is finally entering Fedora 16 ?
(In reply to comment #7) > Why would Fedora drop Xen domU support, now when Xen dom0 is finally entering > Fedora 16 ? There is a difference between dropping support for something and not blocking release for it anymore. At this point, the vote was not to delay beta release more due to lack of DomU support. The beta release criterion for Xen DomU was originally at the request of fedora-infra but since they aren't using Fedora as DomU anymore, there isn't as much of a reason to have a beta release criterion surrounding Xen DomU. As discussed in the 2011-09-26 Fedora QA meeting, Xen DomU is no longer a release criterion for Fedora 16 Beta. As such, this bug was rejected as a blocker for Fedora 16 Beta. It is possible that Xen DomU will be added to the final release criteria. If/when that happens, please re-propose this bug as a blocker for Fedora 16 final.
Discussed at 2011-09-26 QA meeting, functioning as a blocker review meeting. We agreed to drop the Beta criterion "The release must boot successfully as a virtual guest in a situation where the virtual host is running a supported Xen implementation" on the grounds that Fedora no longer has a strong need for Xen to work in order for us to put out a functional Beta release. As I'm getting quite a few contacts on this, let me be clear: this does not mean that 'Fedora doesn't care about Xen' or 'Fedora is dropping Xen support', or anything like that. The release validation process is a very narrow process which exists to ensure the absolute vital things are in place for any Fedora (pre-)release. The release criteria are not an exhaustive list of 'things Fedora supports', but a list of the things that absolutely must function for a Fedora release to be built and released. In the past we had a specific need for Xen functionality as part of our infrastructure processes; now we don't. This does not mean that patches to fix Xen problems won't be accepted, or anything like that. It just means we won't delay the Beta release in order to ensure Xen functionality is in place. (Also note that the release validation process is separate from the feature process; a bug in an Official Feature for a given Fedora release does not constitute a release blocking bug automatically). The criterion may be dropped entirely, or may be moved to Final; we didn't make a decision on that yet. As the Beta criterion is now a dead letter, this bug is rejected as a Beta release blocker.
Ok, thanks for the clarifications!
Thanks, I didn't know there was a QA meeting today or I'd have tagged along, the log for anyone else interested http://meetbot.fedoraproject.org/fedora-meeting/2011-09-26/fedora-meeting.2011-09-26-15.01.log.html FWIW F16 with 3.1.0-rc7 kernel from koji is in reasonably good shape including pci-passthrough.
Don't we just need to get the pv-on-hvm drivers (xen-blkfront, xen-netfront) into the initrd to resolve this?
Chances are that drakut (dracut?) already does that bit correctly since the requirement can be inferred from sysfs in the normal ways. What is usually missing is xen-platform-pci.ko which is the "glue" which enables an HVM guest to see Xen PV devices/xenbus etc. Unfortunately this dependency is indirect and cannot really be expressed in sysfs. The code is only a couple of K so we would recommend compiling it statically into the kernel and in fact patches were recently posted upstream (by Stefano Stabellini) to make this option non-modular. On the other hand I'm not sure how missing xen-platform-pci would cause things to proceed at a snailspace rather than just failing althogether, so perhaps something else is going on.
The patches that Stefano posted is in -next: http://oss.oracle.com/git/?p=kwilk/xen.git;a=shortlog;h=linux-next specifically: 5fbdc10 xen: remove XEN_PLATFORM_PCI config option b17d0b5 xen: XEN_PVHVM depends on PCI And it is queued up for 3.2. I can email the Fedora kernel team to ask them to include those two patches in, but will that for sure fix this bug? (I hate to do the "lets try this" route).
Is this actually an anaconda bug?
It's a kernel config issue, XEN_PLATFORM_PCI was 'm' and needed to be 'y'. It's fixed in later F15 kernels (so an updated F15 works fine), but initial installation from the F15 repo mirrors is still broken. I'm not sure what, if anything, can be done.
(In reply to comment #16) > It's a kernel config issue, XEN_PLATFORM_PCI was 'm' and needed to be 'y'. It's > fixed in later F15 kernels (so an updated F15 works fine), but initial > installation from the F15 repo mirrors is still broken. I'm not sure what, if > anything, can be done. This will probably need to be CLOSED->RAWHIDE because we don't respin install media or repos so F15/F16 won't really be fixed if they don't already work.