Re: [Xen-users] [solved] Increase size of file-based diskimage (with MBR, partitions + fs)

[Henrik Holmboe <henrik@xxxxxxxxxx>]

Hello again,

and thanks for your answers. I reviewed the differences in your methods
and mine, and noticed two big differences. One was the way that you
appended extra space at the end of the diskimage, and the second was how
you repartitioned the diskimage afterwards. See below.

Short version: use fdisk instead of sfdisk.

++ 01/10/08 00:54 +0200 - Henrik Holmboe:

[...]

>What I have: a diskimage stored in the fs on dom0. The image is not
>just a filesystem, but contains a full disk presented to the domU. Thus
>it contains an MBR, partition table and a single ext3 filesystem. No 
>LVM is not used in the domU. Both dom0 and domU is Centos 5.2.
>
>What I want to accomplish: increase the size of this diskimage, resize
>the partition and filesystem.

[...]

>Ok, so now on to what I have tried and failed (with a known good image
>as verified above):
>
> # Extend the size of diskimage from 1.5GB to 3GB
>
> > ls -la xvda.img 
> -rw-r--r-- 1 root root 1610612736 Oct  1 00:16 xvda.img
> > dd if=/dev/zero of=xvda.img bs=1 count=1 seek=3G conv=notrunc
> 1+0 records in
> 1+0 records out
> 1 byte (1 B) copied, 0.00506 seconds, 0.2 kB/s
> > ls -la xvda.img
> -rw-r--r-- 1 root root 3221225473 Oct  1 00:25 xvda.img

I noticed that both Franz and used something similar ot

 dd if=/dev/zero of=space.img bs=1 count=1 seek=1536M
 cat space.img >> xvda.img

rather than the method I used above. I have verified that both methods
work similarly and produce the same results.

> # Now rewrite the partition table to span the entire disk, also
> # make sure that the partition is still bootable
>
> > sfdisk -q --no-reread xvda.img << EOF
> ,,,*
> EOF
> > sfdisk -l xvda.img
> Disk xvda.img: 391 cylinders, 255 heads, 63 sectors/track
> Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
>   Device Boot Start     End   #cyls    #blocks   Id  System
>   xvda.img1   *      0+    390     391-   3140707   83  Linux

The solution to the problem was here. I used sfdisk, and when using
fdisk the diskimage is actually bootable. So instead of the above, I did
this

 # Get the number of cylinders (in my case 391)
 sfdisk -l xvda.img

 # Delete the partition, recreate a bigger partition using the same
 # start cylinder, and finally write the partition table. My diskimage
 # only contains a single partition (no swap, no additional filesystem
 # partitions), so the steps in my case were this

 fdisk xvda.img
 # Enter expert mode
 x
 # Specify number of cylinders
 c
 391
 # Return to main menu
 r
 # Delete partition
 d
 # New primary partition, starts on cylinder 1, ends on cylinder 391
 # which is the entire available space
 n
 p
 1
 1
 391
 # Make this partition bootable
 a
 1
 # Write and exit
 w

After this I had to extend the filesystem to span the added space to the
partition. Nothing changed here that affected the result from my initial
procedure, but for completeness sake I will include it here.

 losetup /dev/loop15 xvda.img
 kpartx -a /dev/loop15
 e2fsck -f /dev/mapper/loop15p1
 resize2fs /dev/mapper/loop15p1
 e2fsck -f /dev/mapper/loop15p1
 kpartx -d /dev/loop15
 losetup -d /dev/loop15

The next step would be to see why sfdisk is not working correctly. The
diskimage verified correctly but pygrub couldn't read it. Weird.

Thanks again!

Henrik

-- 
Henrik Holmboe, Stockholm, Sweden
<http://henrik.holmboe.se/contact/>

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