Description of problem: I have an existing domU domain that worked on FC5. When I upgraded to FC6test2 and pointed the domain config file at the new kernel, I got this panic when I tried to boot domU: <snip> XENBUS: Device with no driver: device/vbd/768 XENBUS: Device with no driver: device/vbd/832 XENBUS: Device with no driver: device/vif/0 Red Hat nash version 5.1.2 starting Mounting proc filesystem Mounting sysfs filesystem Creating /dev Creating initial device nodes Setting up hotplug. Creating block device nodes. Loading scsi_mod.ko module SCSI subsystem initialized Loading sd_mod.ko module Loading libata.ko module Loading ata_piix.ko module Loading jbd.ko module Loading ext3.ko module Loading dm-mod.ko module device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel Loading dm-mirror.ko module Loading dm-zero.ko module Loading dm-snapshot.ko module Making device-mapper control node Scanning logical volumes Reading all physical volumes. This may take a while... No volume groups found Activating logical volumes Volume group "VolGroup00" not found Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /proc/bus/usb ERROR unmounting old /proc/bus/usb: No such file or directory forcing unmount of /proc/bus/usb unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! Version-Release number of selected component (if applicable): kernel-xen-2.6.17-1.2517.fc6 How reproducible: Always Steps to Reproduce: 1. Using attached config file, xm create rpath2 Actual results: See above Expected results: Booting
Created attachment 133817 [details] xen config file
The problem was that the initrd for the xen kernel didn't contain the backend block device driver, xenblk. However, there is another, timing-related, issue (I have hyperthreading and SMP enabled, by the way, in case that's relevant), because the workaround below worked for me only *some* of the time. mkinitrd --omit-scsi-modules --preload=xenblk /boot/myinitrd.img `uname -r` domU now boots up about half the time - the other half the times I get a panic.
forgot to reassign bug owner
FYI -- you can have mkinitrd pull in xenblk automatically with 'alias scsi_hostadapter xenblk'. I do agree that there seems to be some timing related race still going on there, although I only hit it like 1 in every 30-ish boots making it a bit hard to pin down :-/ It looks like the driver init for xenblk is async, thus allowing us to return from the module probe before all of the xenbus stuff is (necessarily) complete. So we might end up just needing to go with the "wait for it to stabliize" stuff like we do for root on usb :(
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora!
I'm not seeing this any more.