Bug 200953 - xm create fails with "Unable to read filesystem" "Boot loader didn't return any data!"
Summary: xm create fails with "Unable to read filesystem" "Boot loader didn't return a...
Alias: None
Product: Fedora
Classification: Fedora
Component: xen   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Xen Maintainance List
QA Contact: Martin Jenner
Depends On:
TreeView+ depends on / blocked
Reported: 2006-08-01 19:39 UTC by James Morris
Modified: 2008-02-26 23:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-26 23:14:59 UTC
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 20:06 UTC, James Morris
no flags Details

Description James Morris 2006-08-01 19:39:06 UTC
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 19:46:14 UTC
What's the labeling of /opt/xen/xt5-disk?  Are there any avc's?  

Comment 2 James Morris 2006-08-01 19:51:57 UTC
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 19:58:17 UTC
If you strace things, what happens? 

Comment 4 James Morris 2006-08-01 20:05:23 UTC
(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 20:06:40 UTC
Created attachment 133435 [details]
strace of xm create

Comment 6 Jeremy Katz 2006-08-01 20:13:00 UTC
This means your /boot fs wasn't recognized as being ext[23]

Comment 7 James Morris 2006-08-01 20:22:45 UTC
(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 23:56:24 UTC
change QA contact

Comment 9 Chris Lalancette 2007-09-25 12:56:56 UTC
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 23:14:59 UTC
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.