Description of problem: After installing F16 PV guest under Xen 4.1.1 the extracting of the kernel and initrd.img can't complete. The error throw is: [2011-10-11 22:43:20 12890] DEBUG (XendBootloader:113) Launching bootloader as ['/usr/bin/pygrub', '--output=/var/run/xend/boot/xenbl.27453', '/var/lib/libvirt/images/nfs/F16.img']. [2011-10-11 22:43:20 6427] ERROR (XendBootloader:214) Boot loader didn't return any data! [2011-10-11 22:43:20 6427] ERROR (XendDomainInfo:488) VM start failed Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/lib64/python2.7/site-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 2838, in _initDomain self._configureBootloader() File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 3285, in _configureBootloader bootloader_args, kernel, ramdisk, args) File "/usr/lib64/python2.7/site-packages/xen/xend/XendBootloader.py", line 215, in bootloader raise VmError, msg VmError: Boot loader didn't return any data! [2011-10-11 22:43:20 6427] DEBUG (XendDomainInfo:3071) XendDomainInfo.destroy: domid=18 [2011-10-11 22:43:20 6427] DEBUG (XendDomainInfo:2406) No device model [2011-10-11 22:43:20 6427] DEBUG (XendDomainInfo:2408) Releasing devices [2011-10-11 22:43:20 6427] ERROR (SrvBase:88) Request start failed. Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xen/web/SrvBase.py", line 85, in perform return op_method(op, req) File "/usr/lib64/python2.7/site-packages/xen/xend/server/SrvDomain.py", line 77, in op_start return self.xd.domain_start(self.dom.getName(), paused) File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomain.py", line 1072, in domain_start dominfo.start(is_managed = True) File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/lib64/python2.7/site-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 2838, in _initDomain self._configureBootloader() File "/usr/lib64/python2.7/site-packages/xen/xend/XendDomainInfo.py", line 3285, in _configureBootloader bootloader_args, kernel, ramdisk, args) File "/usr/lib64/python2.7/site-packages/xen/xend/XendBootloader.py", line 215, in bootloader raise VmError, msg VmError: Boot loader didn't return any data! error: Failed to start domain F16 error: POST operation failed: xend_post: error from xen daemon: (xend.err "Boot loader didn't return any data!") To make sure it was not something wrong with the pygrub or SELinux not allowing to read the image file, I installed F15 PV and it successfully booted. Version-Release number of selected component (if applicable): Xen 4.1.1-6.fc16 How reproducible: Every time. I tried to install F16 using the MSDOS partition table, but was unable. Anaconda won't allow me too. Steps to Reproduce: 1. Install F16 Beta with initrd and vmlinuz images from: http://tflink.fedorapeople.org/iso/20111011_preTC1/initrd.img and http://tflink.fedorapeople.org/iso/20111011_preTC1/vmlinuz 2. Let it install (I did the Minimal install) 3. Reboot. Actual results: What I pasted above. Expected results: None of those errors Additional info:
A bit of debugging and I found out that the /boot partition on the image file is not right after the GPT partition: Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB bios_grub 2 2097kB 526MB 524MB ext4 ext4 boot 3 526MB 16.1GB 15.6GB lvm So with this little nasty hack: diff -r 2112db7c68b3 tools/pygrub/src/pygrub --- a/tools/pygrub/src/pygrub Wed Sep 21 17:12:58 2011 +0100 +++ b/tools/pygrub/src/pygrub Wed Oct 12 10:12:31 2011 -0400 @@ -115,6 +115,11 @@ def get_partition_offsets(file): if type == FDISK_PART_GPT: offset = get_fs_offset_gpt(file) + # F16 puts in a 1MB BIOS partition right after the 1st MB so + # the /boot partition is then 2MB offset. + # HACK: Should read parition first. + part_offs.append(offset) + offset = offset + offset # Active partition has 0x80 as the first byte. # If active, prepend to front of list, otherwise append to back. @@ -389,7 +394,8 @@ class Grub: ["/boot/grub/menu.lst", "/boot/grub/grub.conf", "/grub/menu.lst", "/grub/grub.conf"]) + \ map(lambda x: (x,grub.GrubConf.Grub2ConfigFile), - ["/boot/grub/grub.cfg", "/grub/grub.cfg"]) + \ + ["/boot/grub/grub.cfg", "/grub/grub.cfg", + "/grub2/grub.cfg"]) + \ map(lambda x: (x,grub.ExtLinuxConf.ExtLinuxConfigFile), ["/boot/isolinux/isolinux.cfg", "/boot/extlinux.conf"]) I've gotten it to find the /boot partition, but now I get Traceback (most recent call last): File "/usr/bin/pygrub", line 787, in <module> raise RuntimeError, "Unable to find partition containing kernel" RuntimeError: Unable to find partition containing kernel So there is something still amiss.
(In reply to comment #1) > --- a/tools/pygrub/src/pygrub Wed Sep 21 17:12:58 2011 +0100 > +++ b/tools/pygrub/src/pygrub Wed Oct 12 10:12:31 2011 -0400 > @@ -115,6 +115,11 @@ def get_partition_offsets(file): > > if type == FDISK_PART_GPT: > offset = get_fs_offset_gpt(file) > + # F16 puts in a 1MB BIOS partition right after the 1st MB so > + # the /boot partition is then 2MB offset. > + # HACK: Should read parition first. > + part_offs.append(offset) > + offset = offset + offset I haven't read this too carefully but offset = offset + offset looks wrong.
Created attachment 528095 [details] improved GPT support in pygrub Try the attached patch to pygrub and GrubConf.py .
Your patch is much more elegant than mine. With it I get: pygrub /mnt/tmp/F16.img Using <class 'grub.GrubConf.Grub2ConfigFile'> to parse /grub2/grub.cfg Traceback (most recent call last): File "/usr/bin/pygrub", line 790, in <module> raise RuntimeError, "Unable to find partition containing kernel" RuntimeError: Unable to find partition containing kernel You would not by any chance had hit upon this and have some other patch hidden up your sleeve?
That translates as "I have found your grub.cfg file but I don't understand something in it". The best way to debug it is to extract the grub.cfg file from the guest, then run /usr/lib64/python2.7/site-packages/grub/GrubConf.py grub2 grub.cfg and see what it says.
I should have said, run python /usr/lib64/python2.7/site-packages/grub/GrubConf.py grub2 grub.cfg as that file won't run directly.
[root@g-f16-amd64 ~]# python /usr/lib64/python2.7/site-packages/grub/GrubConf.py grub2 /boot/grub2/grub.cfg Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/grub/GrubConf.py", line 459, in <module> g = Grub2ConfigFile(sys.argv[2]) File "/usr/lib64/python2.7/site-packages/grub/GrubConf.py", line 354, in __init__ _GrubConfigFile.__init__(self, fn) File "/usr/lib64/python2.7/site-packages/grub/GrubConf.py", line 174, in __init__ self.parse() File "/usr/lib64/python2.7/site-packages/grub/GrubConf.py", line 427, in parse setattr(self, self.commands[com], arg.strip()) File "/usr/lib64/python2.7/site-packages/grub/GrubConf.py", line 230, in _set_default self._default = int(val) ValueError: invalid literal for int() with base 10: '${saved_entry}'
Adding in this extra piece: if self.commands.has_key(com): if arg.strip() == "${saved_entry}": arg = "0" seems to have done it
xen-4.1.1-8.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/xen-4.1.1-8.fc16
The update mentioned above should fix the pygrub booting issues. It has the earlier patch (with a minor fix) combined with a slight variant on your fix.
Package xen-4.1.1-8.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xen-4.1.1-8.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14369 then log in and leave karma (feedback).
Thanks a lot! Hopefully that pygrub GPT patch will be posted for upstream Xen inclusion. Also there's a workaround in F16 final TC1 (and later) for older Xen versions, such as RHEL5 Xen dom0: You can use "nogpt" boot option for F16 anaconda installer to force creation of old MSDOS partition tables instead of GPT.
I can confirm xen-4.1.1-8.fc16 works with GPT partitioned domU disks. I added karma aswell.
Done. Left feedback (+1)
Update about the anaconda installer "nogpt" boot option workaround. It's actually available in Fedora 16 Final TC2 (Test Compose 2) and later versions, and it allows creating normal MSDOS partition table. more info about the "nogpt" workaround here: https://bugzilla.redhat.com/show_bug.cgi?id=735733
xen-4.1.1-8.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.