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