This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours
Bug 745335 - pygrub cannot start F16 PV guests (GPT partition) under Xen 4.1.1
pygrub cannot start F16 PV guests (GPT partition) under Xen 4.1.1
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Xen Maintainance List
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 746602
  Show dependency treegraph
 
Reported: 2011-10-11 23:26 EDT by Konrad Rzeszutek Wilk
Modified: 2011-10-24 23:44 EDT (History)
7 users (show)

See Also:
Fixed In Version: xen-4.1.1-8.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 746602 (view as bug list)
Environment:
Last Closed: 2011-10-24 23:44:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
improved GPT support in pygrub (3.14 KB, patch)
2011-10-13 16:02 EDT, Michael Young
no flags Details | Diff

  None (edit)
Description Konrad Rzeszutek Wilk 2011-10-11 23:26:59 EDT
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:
Comment 1 Konrad Rzeszutek Wilk 2011-10-12 10:13:36 EDT
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.
Comment 2 Michael Young 2011-10-12 10:21:26 EDT
(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.
Comment 3 Michael Young 2011-10-13 16:02:51 EDT
Created attachment 528095 [details]
improved GPT support in pygrub

Try the attached patch to pygrub and GrubConf.py .
Comment 4 Konrad Rzeszutek Wilk 2011-10-14 13:47:06 EDT
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?
Comment 5 Michael Young 2011-10-14 14:18:31 EDT
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.
Comment 6 Michael Young 2011-10-14 14:22:02 EDT
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.
Comment 7 Konrad Rzeszutek Wilk 2011-10-14 15:04:22 EDT
[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}'
Comment 8 Konrad Rzeszutek Wilk 2011-10-14 15:18:19 EDT
Adding in this extra piece:

   if self.commands.has_key(com):
                if arg.strip() == "${saved_entry}":
                    arg = "0"

seems to have done it
Comment 9 Fedora Update System 2011-10-14 18:16:57 EDT
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
Comment 10 Michael Young 2011-10-14 19:44:27 EDT
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.
Comment 11 Fedora Update System 2011-10-15 10:33:34 EDT
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).
Comment 12 Pasi Karkkainen 2011-10-15 12:52:53 EDT
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.
Comment 13 Pasi Karkkainen 2011-10-16 07:17:34 EDT
I can confirm xen-4.1.1-8.fc16 works with GPT partitioned domU disks. I added karma aswell.
Comment 14 Konrad Rzeszutek Wilk 2011-10-17 11:05:47 EDT
Done. Left feedback (+1)
Comment 15 Pasi Karkkainen 2011-10-22 09:13:28 EDT
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
Comment 16 Fedora Update System 2011-10-24 23:44:40 EDT
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.

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