Bug 201764

Summary: Existing domain fails to find root device, panics
Product: [Fedora] Fedora Reporter: Robin Green <greenrd>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 6CC: bstein, jonstanley, katzj, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-31 14:31:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
xen config file none

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:

<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
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 
panic.
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 
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!
Comment 6 Robin Green 2007-12-31 14:31:06 UTC 
I'm not seeing this any more.