Description of problem: By default, when running fully-virtualized under Xen, the kernel will try to "unplug" IDE disks and emulated network cards. Dracut however will fail to load the xen-blkfront module in this default mode, leading to a boot failure. If the IDE disk is not unplugged, boot succeeds from the IDE disk, and ultimately the xen-blkfront module is loaded and initialized by udev. Version-Release number of selected component (if applicable): dracut-013-4.fc16.noarch How reproducible: 100% Steps to Reproduce: 1. Install Xen PV guest on RHEL5 (e.g. using virt-install). 2. Change configuration to specify HVM guest: 2a. remove bootloader and vfb lines; 2b. add the following lines at the end: sdl=1 vnc=0 device_model='/usr/lib64/xen/bin/qemu-dm' serial='pty' builder='hvm' acpi=apic=pae=1 kernel='/usr/lib/xen/boot/hvmloader' boot='c' 3. Boot the guest. Actual results: Booting requires adding "xen_emul_unplug=nics" on the grub command line. After boot, /dev/sda and /dev/xvda point to the same disk, which has the potential for data corruption. Expected results: Booting a PV guest as HVM works out of the box. After boot, /dev/sda is not there, and all file system access is done using /dev/xvda. Additional info: Works with RHEL6.
Please: - add "rd.debug=1 rd.shell=1" to the kernel command line - show me the output of dmesg in the dracut shell
Starting from "init=/bin/sh" (and still xen_emul_unplug=nics of course), the following commands bring up /dev/xvda: modprobe xen_platform_pci modprobe xen_blkfront xen_blkfront does not have a dependency on xen_platform_pci in modules.dep, but that's correct because you can issue the two modprobe commands in any order. I think that dracut does attempt to load xen_blkfront because otherwise PV doesn't work either. The solution could be simply to make xen_platform_pci builtin, as it is in RHEL6. If so, please change the component to kernel.
dracut has a xen dracut module, which should do the following: xen-detect RC=$? if [ "$RC" = "1" ] ; then modprobe xenbus_probe_frontend modprobe xen-kbdfront modprobe xen-fbfront modprobe xen-blkfront modprobe xen-netfront modprobe xen-pcifront fi
I see two problems: 1) xen_platform_pci is missing from there. 2) xen-detect is not installed by default on most Xen systems, certainly not on a Fedora minimal install. It's much simpler to check if the contents of /sys/hypervisor/type are "xen\n". 3) Likewise, xen-detect is used by dracut as far as I can tell to detect whether to install the module, but it doesn't work if xen-detect is not present on the system. On the kernel side, xenbus_probe_frontend is builtin, but it is quite useless without xen_platform_pci for fully-virtualized guests. modules.alias is where all Xen support should reside. Assuming xen_platform_pci is loaded and has probed Xen devices (including block devices) it will load the module automatically thanks to lines such as this: alias xen:vbd xen_blkfront To sum up, I think that: 1) of all the modprobes in the module, only xenbus_probe_frontend is useful and xen_platform_pci is missing. The others should be taken care of by modules.alias. 2) Using xen-detect to detect Xen is overkill, and doesn't work anyway on minimal installs. But to solve both at the same time, I think that the solution is to add xen_platform_pci to kernel and remove all Xen cruft from dracut. Just say that dracut requires xenbus_probe_frontend to be builtin, and also xen_platform_pci to be built-in to support Xen fully virtualized guests. xen_platform_pci is 7k of code. In other words, Xen may have a lot of crap in it, but sometimes not that much. :)
I'll try modifying the config tomorrow. If it works, I will change the subject and package (and leave it to you to drop the Xen module from dracut, if you wish).
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
The kernel part is bug 740664, I'll test dracut without the Xen module and post the patch upstream. *** This bug has been marked as a duplicate of bug 740664 ***