WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

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

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.

-Gerry


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

<Prev in Thread] Current Thread [Next in Thread>