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
|
Home