Red Hat Bugzilla – Bug 201764
Existing domain fails to find root device, panics
Last modified: 2008-08-02 19:40:36 EDT
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:
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 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:
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):
Steps to Reproduce:
1. Using attached config file, xm create rpath2
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
forgot to reassign bug owner
FYI -- you can have mkinitrd pull in xenblk automatically with 'alias
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 :(
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.
I am CC'ing myself to this bug, however this version of Fedora is no longer
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.