[Pkg-xen-devel] Bug#745419: Bug#745419: xen-utils-4.1: Pygrub fails to boot from LVM LV when something installed in the volume boot record

[Ian Campbell]

On Mon, 2014-04-21 at 15:43 +0200, Sjors Gielen wrote:
> Package: xen-utils-4.1
> Version: 4.1.4-3+deb7u1
> Severity: important
> 
> When an LVM LV that serves as the root disk for a Xen DomU contains a boot
> loader (or possibly other data) in its volume boot record, pygrub fails to boot
> it, printing "Error: boot loader didn't return any data" before exiting.
> 
> I think this is because of the function "is_disk_image" on line 45 of
> /usr/lib/xen-4.1/bin/pygrub: it should return false on LVM LV's because they
> are not disk images but virtual devices, but it returns true because of certain
> bytes in the first block of 512 bytes being set. This causes
> get_partition_offsets to seek fruitlessly for a partition instead of simply
> returning [0], causing the bootloader not to find the right partition.

I'm afraid I don't follow your logic here. is_disk_image is trying to
determine whether or not the device (be it a virtual device or
otherwise) contains a partition table or not. A device with a partition
table is a "disk image" as in a "full disk image", as opposed to a
device which is unpartitioned and could be used via the "per partition
block device" thing in the block driver.

It seems that your block device does include the DOS MBR/partition table
indicator (the 0x55aa signature at the end of the first sector) and
therefore is considered to be a disk image. But perhaps it doesn't
actually contain a valid partition table? What does "fdisk -l" report
for this device?

Does this still happen with pygrub from a newer Xen? I can see that much
has changed around this area since 4.1.x. If you can reproduce with
something newer then I think your best bet is to report this upstream:
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen

Ian.

> Detailed steps to reproduce:
> We have a domU called blup.kassala.de, it is running Jessie, its root disk is
> a LVM LV at /dev/vpsdisks/blup.kassala.de-disk. The first 512 bytes are null:
> 
> # dd if=/dev/vpsdisks/blup.kassala.de-disk bs=1 count=512 | hexdump -C
> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000200
> 
> "xm create -c blup.kassala.de.cfg" shows the machine boots fine. After boot, we
> log in and "apt-get install grub2". During the installation, we say to install
> the bootloader to /dev/xvda2, the root disk. We then halt the system. The first
> 512 bytes are now non-null:
> 
> # dd if=/dev/vpsdisks/blup.kassala.de-disk bs=1 count=512 | hexdump -C
> 00000000  eb 63 90 00 00 00 00 00  00 00 00 00 00 00 00 00  |.c..............|
> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000050  00 00 00 00 00 00 00 00  00 00 00 80 80 12 46 00  |..............F.|
> 00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
> [snip]
> 00000180  7d e8 2e 00 cd 18 eb fe  47 52 55 42 20 00 47 65  |}.......GRUB .Ge|
> 00000190  6f 6d 00 48 61 72 64 20  44 69 73 6b 00 52 65 61  |om.Hard Disk.Rea|
> 000001a0  64 00 20 45 72 72 6f 72  0d 0a 00 bb 01 00 b4 0e  |d. Error........|
> 000001b0  cd 10 ac 3c 00 75 f4 c3  00 00 00 00 00 00 00 00  |...<.u..........|
> 000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
> 00000200
> 
> We try to boot the DomU again:
> 
> # xm create -c blup.kassala.de.cfg 
> Using config file "./blup.kassala.de.cfg".
> Error: Boot loader didn't return any data!
> 
> We write 512 nullbytes to the disk and retry booting the domU:
> 
> # dd if=/dev/zero of=/dev/vpsdisks/blup.kassala.de-disk bs=1 count=512
> # xm create -c blup.kassala.de.cfg
> 
> The pyGRUB menu appears normally and the machine boots.
> 
> -- System Information:
> Debian Release: 7.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages xen-utils-4.1 depends on:
> ii  e2fslibs          1.42.5-1.1
> ii  libc6             2.13-38+deb7u1
> ii  libgnutls26       2.12.20-8+deb7u1
> ii  libncurses5       5.9-10
> ii  libpci3           1:3.1.9-6
> ii  libtinfo5         5.9-10
> ii  libuuid1          2.20.1-5.3
> ii  libxen-4.1        4.1.4-3+deb7u1
> ii  libxenstore3.0    4.1.4-3+deb7u1
> ii  python            2.7.3-4+deb7u1
> ii  python2.7         2.7.3-6+deb7u2
> ii  xen-utils-common  4.1.4-3+deb7u1
> ii  zlib1g            1:1.2.7.dfsg-13
> 
> Versions of packages xen-utils-4.1 recommends:
> ii  bridge-utils                                   1.5-6
> ii  qemu-keymaps                                   1.1.2+dfsg-6a+deb7u1
> ii  qemu-utils                                     1.1.2+dfsg-6a+deb7u1
> ii  xen-hypervisor-4.1-amd64 [xen-hypervisor-4.1]  4.1.4-3+deb7u1
> 
> Versions of packages xen-utils-4.1 suggests:
> pn  xen-docs-4.1  <none>
> 
> -- no debconf information
> 
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel
>