Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn't return any data!

["Fajar A. Nugraha" <fajar@xxxxxxxxx>]

On Thu, Dec 31, 2009 at 1:01 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote:

> root@grp-01-23-02:/var/lib/xen/images# fdisk -l $LOOP
>
> Disk /dev/loop0: 128.8 GB, 128849018880 bytes
> 255 heads, 63 sectors/track, 15665 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0x000438c1
>
>     Device Boot      Start         End      Blocks   Id  System
> /dev/loop0p1   *           1       15634   125580073+  8e  Linux LVM
> /dev/loop0p2           15635       15665      249007+   5  Extended
> /dev/loop0p5           15635       15665      248976   83  Linux

This is just wrong. In sooo many levels. The active partition is LVM?
/boot is on logical partition? Come on ...
grub/grub2 PROBABLY won't care about it if you install them on MBR,
but it won't work if you install them on the boot sector (/dev/vda5),
or use other bootloaders (like syslinux/extlinux), or use pygrub.
/boot needs to be active, primary partition.

It's probably not your fault though (I think I got similar results
with opensuse), so if that's the default layout you got when
installing the OS you should file a bug to your distro (Ubuntu?).

At this point it's probably easiest to just create another virtual
disk with one primary partition, and copy the contents of the original
/boot there. It's A LOT easier compared to messing up with existing
partition table. Your domU config should then look something like this

disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w",
"tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ]

Don't forget to umount all the disk images after these tests (umount,
kpartx -dv, losetup -d). Forgetting that can lead to data corruption.

-- 
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users