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

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Thu, Dec 31, 2009 at 01:03:29PM -0500, Gerry Reno wrote:
> Fajar A. Nugraha wrote:
> >On Thu, Dec 31, 2009 at 1:46 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote:
> >  
> >>>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" ]
> >>>
> >>>      
> >>If I do this then maybe I can straighten the original partition table out;
> >>remove the last two partitions and create a primary active partition for
> >>/boot.
> >>    
> >
> >If you want to use a new disk image for /boot, then yes, the disk
> >image only need one small partition. You can still use LVM from the
> >orginal disk -- no need to migrate/copy that.
> >
> >If you want to modify the existing partition table manually, BE
> >CAREFUL. fdisk uses cylinders as unit by default, so you should switch
> >to sectors. Here's an example:
> >
> ># fdisk -l /dev/xvda
> >
> >Disk /dev/xvda: 10.7 GB, 10737418240 bytes
> >255 heads, 63 sectors/track, 1305 cylinders
> >Units = cylinders of 16065 * 512 = 8225280 bytes
> >
> >    Device Boot      Start         End      Blocks   Id  System
> >/dev/xvda1               1        1000     8032468+  8e  Linux LVM
> >/dev/xvda2            1001        1305     2449912+   5  Extended
> >/dev/xvda5   *        1001        1305     2449881   83  Linux
> >
> ># fdisk -lu /dev/xvda
> >
> >Disk /dev/xvda: 10.7 GB, 10737418240 bytes
> >255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
> >Units = sectors of 1 * 512 = 512 bytes
> >
> >    Device Boot      Start         End      Blocks   Id  System
> >/dev/xvda1              63    16064999     8032468+  8e  Linux LVM
> >/dev/xvda2        16065000    20964824     2449912+   5  Extended
> >/dev/xvda5   *    16065063    20964824     2449881   83  Linux
> >
> >Now if you recreate the partition table using cyulinders as unit, the
> >Linux partition will start on the wrong sector. It will be unusable.
> >However if you use sectors as unit (fdisk -u) you can recreate the
> >partition table to be like this
> >
> ># fdisk -lu /dev/xvda
> >
> >Disk /dev/xvda: 10.7 GB, 10737418240 bytes
> >255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
> >Units = sectors of 1 * 512 = 512 bytes
> >
> >    Device Boot      Start         End      Blocks   Id  System
> >/dev/xvda1   *    16065063    20964824     2449881   83  Linux
> >/dev/xvda2              63    16064999     8032468+  8e  Linux LVM
> >
> >Partition table entries are not in disk order
> >
> >pygrub can work with that.
> >
> >  
> 
> The more I thought about this the more I think this is not a distro 
> problem.  It is a pygrub deficiency and pygrub needs to grow the ability 
> to handle these types of partitionings.  KVM has no problem booting 
> these guests.  And even though the partitioning isn't optimal it is 
> still valid.  We can't go asking distros to modify their valid 
> partitioning just to make it 'optimal' for pygrub.
> 

Well you could always run it as Xen HVM fully virtualized guest. 
That would be pretty close to running it as KVM guest.

If you want to run it as Xen PV (paravirtualized) guest, then you need
to have the disk configuration so that pygrub can work.

-- Pasi



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