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-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
