Bug 200953

Summary: xm create fails with "Unable to read filesystem" "Boot loader didn't return any data!"
Product: [Fedora] Fedora Reporter: James Morris <jmorris>
Component: xenAssignee: Xen Maintainance List <xen-maint>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bstein, katzj, rjones
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-26 18:14:59 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
strace of xm create none

Description James Morris 2006-08-01 15:39:06 EDT
Description of problem:

After installing a new domain via xenguest-install.py, using current rawhide,
which appears to complete successfully via vnc, starting the domain fails with:

# xm create -c xt5
Using config file "/etc/xen/xt5".
Traceback (most recent call last):
  File "/usr/bin/pygrub", line 256, in ?
    cf = get_config(file, isconfig)
  File "/usr/bin/pygrub", line 139, in get_config
    raise RuntimeError, "Unable to read filesystem" 
RuntimeError: Unable to read filesystem
Error: Boot loader didn't return any data!

*** This is the output from the install:

XKB extension not present on :1
setsebool:  SELinux is disabled.
sending termination signals...done
sending kill signals...done
disabling swap...
unmounting filesystems...
        /mnt/runtime done
        disabling /dev/loop0
        /proc done
        /dev/pts done
        /sys done
        /tmp/ramfs done
        /mnt/sysimage/boot done
        /mnt/sysimage/proc done
        /mnt/sysimage/sys done
        /mnt/sysimage/dev done
        /mnt/sysimage done
rebooting system
Restarting system.
libvir: Xen Daemon error : GET operation failed: No such domain 3
If your install completed successfully, you can restart your
guest by running 'xm create -c xt5'.

Config file and 'file' output for the disk image:
# Automatically generated xen config file
name = "xt5"
memory = "444"
disk = [ 'file:/opt/xen/xt5-disk,xvda,w' ]
vif = [ 'mac=00:16:3e:20:e9:5f, bridge=xenbr0' ]
uuid = "16129854-8ef8-e246-48be-c347d2ab0d53"

on_reboot   = 'restart'
on_crash    = 'restart'

# file /opt/xen/xt5-disk
/opt/xen/xt5-disk: x86 boot sector; partition 1: ID=0x83, active, starthead 1,
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector
208845, 3984120 sectors, code offset 0x48
Comment 1 Jeremy Katz 2006-08-01 15:46:14 EDT
What's the labeling of /opt/xen/xt5-disk?  Are there any avc's?  
Comment 2 James Morris 2006-08-01 15:51:57 EDT
selinux is disabled, the file was created by the installer.

# ls -laZ /opt/xen/xt5-disk 
-rwxr-xr-x  root root                                  /opt/xen/xt5-disk
Comment 3 Jeremy Katz 2006-08-01 15:58:17 EDT
If you strace things, what happens? 
Comment 4 James Morris 2006-08-01 16:05:23 EDT
(In reply to comment #3)
> If you strace things, what happens? 

I can't see any problem, looks like something internal to pygrub but perhaps not
system related.

See attachement.
Comment 5 James Morris 2006-08-01 16:06:40 EDT
Created attachment 133435 [details]
strace of xm create
Comment 6 Jeremy Katz 2006-08-01 16:13:00 EDT
This means your /boot fs wasn't recognized as being ext[23]
Comment 7 James Morris 2006-08-01 16:22:45 EDT
(In reply to comment #6)
> This means your /boot fs wasn't recognized as being ext[23]

I lomounted it as ext3 just fine:

/opt/xen/xt5-disk on /opt/xen/foo type ext3 (ro,loop=/dev/loop0,offset=32256)

Perhaps a python library bug or missing lib?

Comment 8 Red Hat Bugzilla 2007-07-24 19:56:24 EDT
change QA contact
Comment 9 Chris Lalancette 2007-09-25 08:56:56 EDT
It looks like this bug was filed a long time ago, on FC-5.  Given that FC-5 is
end-of-life, can we close this out, or at least test it on newer Fedora?

Chris Lalancette
Comment 10 Chris Lalancette 2008-02-26 18:14:59 EST
This report targets FC5, which is now end-of-life.

Please re-test against Fedora 7 or later, and if the issue persists, open a new bug.