Hi group, I''m sure this has been discussed numerous times, but I would like some pointers on troubleshooting the resizing of a DomU built on an image file (not LVM). To add another 20GB, I tried running the following, as root: dd if=/dev/zero bs=1M count=20480 >> img_file.img 20480+0 records in 20480+0 records out 21474836480 bytes (21 GB) copied, 1578.68 s, 13.6 MB/s /sbin/resize2fs img_file.img resize2fs 1.40.4 (31-Dec-2007) /sbin/resize2fs: Bad magic number in super-block while trying to open img_file.img Couldn''t find valid filesystem superblock. Also, this command fails: /sbin/e2fsck -f img_file.img I have several DomUs running and are very stable. However, the e2fsck fails on all of them. What am I doing wrong? Thanks for any help you can provide, -Harold _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Nov 03, 2008 at 10:50:06PM -0500, Harold A. Giménez Ch. wrote:> Also, this command fails: > /sbin/e2fsck -f img_file.img > > I have several DomUs running and are very stable. However, the e2fsck fails > on all of them. What am I doing wrong?What does fdisk -l img_file.img return? Rainer _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks for the suggestion. "Partition 2 has different physical/logical
endings" doesn''t sound too great...
Here''s the output of the fdisk:
$/sbin/fdisk -l img-file.img
You must set cylinders.
You can do this from the extra functions menu.
Disk img-file.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000abe34
Device Boot Start End Blocks Id System
img-file.img1 * 1 25 200781 83 Linux
img-file.img2 26 7832 62709727+ 8e Linux LVM
Partition 2 has different physical/logical endings:
phys=(1023, 254, 63) logical=(7831, 254, 63)
On Tue, Nov 4, 2008 at 2:42 AM, Rainer Sokoll <rainer@sokoll.com> wrote:
> On Mon, Nov 03, 2008 at 10:50:06PM -0500, Harold A. Giménez Ch. wrote:
>
> > Also, this command fails:
> > /sbin/e2fsck -f img_file.img
> >
> > I have several DomUs running and are very stable. However, the e2fsck
> fails
> > on all of them. What am I doing wrong?
>
> What does fdisk -l img_file.img return?
>
> Rainer
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On Tue, Nov 04, 2008 at 08:56:47AM -0500, Harold A. Giménez Ch. wrote:> Thanks for the suggestion. "Partition 2 has different physical/logical > endings" doesn''t sound too great...Do not worry about that. It''s fine.> Device Boot Start End Blocks Id System > img-file.img1 * 1 25 200781 83 Linux > img-file.img2 26 7832 62709727+ 8e Linux LVMYou see that your image contains one partition and one LVM. That is why e2fsck complains - it needs a file system, not a disk. (If I am wrong, please sombedy correct me) Rainer _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks Rainer, that makes sense. How would I go about resizing the LVM? The PV you mention is simply the /boot partition, and the LVM in there is where / is mounted. The objective would be to expand the LVM. How would I go about that? Thanks again, -H On Tue, Nov 4, 2008 at 9:41 AM, Rainer Sokoll <rainer@sokoll.com> wrote:> On Tue, Nov 04, 2008 at 08:56:47AM -0500, Harold A. Giménez Ch. wrote: > > > Thanks for the suggestion. "Partition 2 has different physical/logical > > endings" doesn''t sound too great... > > Do not worry about that. It''s fine. > > > Device Boot Start End Blocks Id > System > > img-file.img1 * 1 25 200781 83 Linux > > img-file.img2 26 7832 62709727+ 8e Linux LVM > > You see that your image contains one partition and one LVM. That is why > e2fsck complains - it needs a file system, not a disk. > (If I am wrong, please sombedy correct me) > > Rainer > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Harold A. Giménez Ch. wrote:> Thanks Rainer, that makes sense. > How would I go about resizing the LVM? The PV you mention is simply > the /boot partition, and the LVM in there is where / is mounted. The > objective would be to expand the LVM. How would I go about that? >There are several ways to do this but they all amount to the same in the end. If you use fdisk on the file you can delete the second partition and add it with the same start point and the default end point so that the partition now fills the disk. Generally speaking it''s now easiest to do the remainder of the resizing in the guest. First, run "pvresize /dev/xvda2" (or whatever device the disk is mapped to). This should grow the volume group to which this belongs and you can now do "vgdisplay /dev/VolGroup00" (or whatever the volume group is called) and you''ll see you have some free physical extents. Now you can increase the size of the logical volume you want to grow with "lvextend -L +<n> /dev/VolGroup00/LogVol01" where "<n>" is the number of extents you want to grow it by and which is no more than the number of free extents reported by vgdisplay. And now, finally, you can grow the file system: "resize2fs /dev/VolGroup00/LogVol01". That''s all assuming you have a Red Hat/Fedora style DomU and it''s reasonably new. If it''s different or it''s older some things will be different: the main thing is that resize2fs used to be ext2online and took the mount point as parameter. There are manual pages for all the commands I mentioned and it''s worth reading them. And backing stuff up, just in case. jch _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Nov 3, 2008 at 10:50 PM, Harold A. Giménez Ch. <harold.gimenez@gmail.com> wrote:> Hi group, > > I''m sure this has been discussed numerous times, but I would like some > pointers on troubleshooting the resizing of a DomU built on an image file > (not LVM). > > To add another 20GB, I tried running the following, as root: > > dd if=/dev/zero bs=1M count=20480 >> img_file.img > 20480+0 records in > 20480+0 records out > 21474836480 bytes (21 GB) copied, 1578.68 s, 13.6 MB/s > /sbin/resize2fs img_file.img > resize2fs 1.40.4 (31-Dec-2007) > /sbin/resize2fs: Bad magic number in super-block while trying to open > img_file.img > Couldn''t find valid filesystem superblock. > > Also, this command fails: > /sbin/e2fsck -f img_file.img > > I have several DomUs running and are very stable. However, the e2fsck fails > on all of them. What am I doing wrong? >Based on the discussion below, I now understand your original problem and, if only for the sake of the community, I''ll explain the disk image file in a general sense. You are working with a disk image file, which contains partitions on it. If they were in fact ext3 partitions, you would need to make them available to the system with a the kpartx command (I usually pass it -av then the disk image). Then they would show up in /dev/mapper/<something like diskimage-name1 diskimage-name2, etc. for each partition that kpartx detected). Then you could work with those partitions a bit, but to work with them like they are more like a block device, it would be better to use the losetup command. losetup will associate the disk image file with a loop device (/dev/loopN, where N is the next available loop). You can then run fdisk, parted, and other disk-related commands on the /dev/loopN device. Making the loop partitions available and working with them would be the same ideas as above, run kpartx -av on the /dev/loopN device and then look in /dev/mapper for the loopNpX device nodes. Note that if you had been working with a partition image (also sometimes referred to as a file system image) then you intuition of working with it as a file system/partitition would have worked if it was a ext3 partition or similar. The answers below seem good and are more specific to the problem at hand and when working with LVM partitions etc. Hope that helps. ( Examples can be found all over the internet and in the Running Xen book ;) ) Cheers, Todd -- Todd Deshane http://todddeshane.net http://runningxen.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Reiner, John, Todd, and others, Thanks for all the info. It is invaluable. I still have not achieved my goal, but I''d like to battle with this for a bit. I think you have provided enough information to play around with. I''ll post back further questions if I have any. Thanks again, -Harold On Tue, Nov 4, 2008 at 12:30 PM, Todd Deshane <deshantm@gmail.com> wrote:> On Mon, Nov 3, 2008 at 10:50 PM, Harold A. Giménez Ch. > <harold.gimenez@gmail.com> wrote: > > Hi group, > > > > I''m sure this has been discussed numerous times, but I would like some > > pointers on troubleshooting the resizing of a DomU built on an image file > > (not LVM). > > > > To add another 20GB, I tried running the following, as root: > > > > dd if=/dev/zero bs=1M count=20480 >> img_file.img > > 20480+0 records in > > 20480+0 records out > > 21474836480 bytes (21 GB) copied, 1578.68 s, 13.6 MB/s > > /sbin/resize2fs img_file.img > > resize2fs 1.40.4 (31-Dec-2007) > > /sbin/resize2fs: Bad magic number in super-block while trying to open > > img_file.img > > Couldn''t find valid filesystem superblock. > > > > Also, this command fails: > > /sbin/e2fsck -f img_file.img > > > > I have several DomUs running and are very stable. However, the e2fsck > fails > > on all of them. What am I doing wrong? > > > > Based on the discussion below, I now understand your original problem and, > if only for the sake of the community, I''ll explain the disk image file in > a > general sense. > > You are working with a disk image file, which contains partitions on it. If > they > were in fact ext3 partitions, you would need to make them available to the > system with a the kpartx command (I usually pass it -av then the disk > image). > Then they would show up in /dev/mapper/<something like diskimage-name1 > diskimage-name2, etc. for each partition that kpartx detected). Then you > could work with those partitions a bit, but to work with them like they are > more like a block device, it would be better to use the losetup command. > losetup will associate the disk image file with a loop device (/dev/loopN, > where N is the next available loop). You can then run fdisk, parted, > and other disk-related commands on the /dev/loopN device. > Making the loop partitions available and working with them would be the > same ideas as above, run kpartx -av on the /dev/loopN device and then > look in /dev/mapper for the loopNpX device nodes. > > Note that if you had been working with a partition image (also sometimes > referred to as a file system image) then you intuition of working with it > as a file system/partitition would have worked if it was a ext3 partition > or similar. > > The answers below seem good and are more specific to the problem > at hand and when working with LVM partitions etc. > > Hope that helps. > ( Examples can be found all over the internet and in the Running Xen book > ;) ) > > Cheers, > Todd > > -- > Todd Deshane > http://todddeshane.net > http://runningxen.com >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users