Bug 708267 - Fedora 15 cannot install as a DomU, Fails to find hard disk virtual device
Summary: Fedora 15 cannot install as a DomU, Fails to find hard disk virtual device
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
: 718382 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-27 04:48 UTC by Chris Jones
Modified: 2013-01-13 18:34 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
adding 'xen_emul_unplug=never' to the Fedora 15 kernel args as discussed in 718382 provides a workround
Clone Of:
Environment:
Last Closed: 2012-06-06 13:11:51 UTC
Type: ---


Attachments (Terms of Use)

Description Chris Jones 2011-05-27 04:48:00 UTC
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

Comment 1 Chris Lumens 2011-07-06 17:50:04 UTC
*** Bug 718382 has been marked as a duplicate of this bug. ***

Comment 2 Chris Jones 2011-07-07 17:48:16 UTC
    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

Comment 3 Andy Burns 2011-09-24 17:59:38 UTC
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

Comment 4 Andy Burns 2011-09-25 08:08:00 UTC
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

Comment 5 Andy Burns 2011-09-25 14:30:03 UTC
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.

Comment 6 Adam Williamson 2011-09-25 21:10:56 UTC
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.

Comment 7 Pasi Karkkainen 2011-09-26 13:56:05 UTC
Why would Fedora drop Xen domU support, now when Xen dom0 is finally entering Fedora 16 ?

Comment 8 Tim Flink 2011-09-26 16:29:01 UTC
(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.

Comment 9 Adam Williamson 2011-09-26 16:31:01 UTC
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.

Comment 10 Pasi Karkkainen 2011-09-26 16:38:50 UTC
Ok, thanks for the clarifications!

Comment 11 Andy Burns 2011-09-26 16:45:52 UTC
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.

Comment 12 Andrew Jones 2011-10-11 08:08:35 UTC
Don't we just need to get the pv-on-hvm drivers (xen-blkfront, xen-netfront) into the initrd to resolve this?

Comment 13 Ian Campbell 2011-10-11 10:11:41 UTC
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.

Comment 14 Konrad Rzeszutek Wilk 2011-10-11 12:47:31 UTC
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).

Comment 15 Chris Lumens 2011-12-21 18:25:23 UTC
Is this actually an anaconda bug?

Comment 16 Andrew Jones 2011-12-22 13:11:07 UTC
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.

Comment 17 Josh Boyer 2011-12-22 16:06:21 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.