Bug 200953 - xm create fails with "Unable to read filesystem" "Boot loader didn't return any data!"
xm create fails with "Unable to read filesystem" "Boot loader didn't return a...
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Xen Maintainance List
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2006-08-01 15:39 EDT by James Morris
Modified: 2008-02-26 18:14 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-26 18:14:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of xm create (431.63 KB, text/plain)
2006-08-01 16:06 EDT, James Morris
no flags Details

  None (edit)
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.


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