Bug 201764 - Existing domain fails to find root device, panics
Summary: Existing domain fails to find root device, panics
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 6
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-08-08 19:07 UTC by Robin Green
Modified: 2008-08-02 23:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-31 14:31:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xen config file (4.85 KB, text/plain)
2006-08-08 19:07 UTC, Robin Green
no flags Details

Description Robin Green 2006-08-08 19:07:30 UTC
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 /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: 
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):

How reproducible:

Steps to Reproduce:
1. Using attached config file, xm create rpath2
Actual results:
See above

Expected results:

Comment 1 Robin Green 2006-08-08 19:07:30 UTC
Created attachment 133817 [details]
xen config file

Comment 2 Robin Green 2006-08-08 22:15:08 UTC
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 

Comment 3 Robin Green 2006-08-08 22:17:47 UTC
forgot to reassign bug owner

Comment 4 Jeremy Katz 2006-08-09 21:25:21 UTC
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 :(

Comment 5 Jon Stanley 2007-12-31 01:24:37 UTC

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!

Comment 6 Robin Green 2007-12-31 14:31:06 UTC
I'm not seeing this any more.

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