Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have followed many of the tutorials that pretty much all say the same thing which is basically:

  1. Stop the instance
  2. Detach the volume
  3. Create a snapshot of the volume
  4. Create a bigger volume from the snapshot
  5. Attach the new volume to the instance
  6. Start the instance back up
  7. Run resize2fs /dev/xxx

However, step 7 is where the problems start happening. In any case running resize2fs always tells me that it is already xxxxx blocks big and does nothing, even with -f passed. So I start to continue with tutorials which all basically say the same thing and that is:

  1. Delete all partitons
  2. Recreate them back to what they were except with the bigger sizes
  3. Reboot the instance and run resize2fs

(I have tried these steps both from the live instance and by attaching the volume to another instance and running the commands there) The main problem is that the instance won't start back up again and the system error log provided in the AWS console doesn't provide any errors. (it does however stop at the grub bootloader which to me indicates that it doesn't like the partitions(yes, the boot flag was toggled on the partition with no affect)) The other thing that happens regardless of what changes I make to the partitions is that the instance that the volume is attached to says that the partition has an invalid magic number and the super-block is corrupt. However, if I make no changes and reattach the volume, the instance runs without a problem.

Can anybody shed some light on what I could be doing wrong?


Edit

On my new volume of 20GB with the 6GB image,df -h says:

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvde1            5.8G  877M  4.7G  16% /
tmpfs                 836M     0  836M   0% /dev/shm 

And fdisk -l /dev/xvde says:

Disk /dev/xvde: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x7d833f39

    Device Boot      Start         End      Blocks   Id  System
/dev/xvde1               1         766     6144000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/xvde2             766         784      146432   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.

Also, sudo resize2fs /dev/xvde1 says:

resize2fs 1.41.12 (17-May-2010)
The filesystem is already 1536000 blocks long.  Nothing to do!
share|improve this question

migrated from stackoverflow.com Oct 2 '12 at 7:08

This question came from our site for professional and enthusiast programmers.

    
Is the root partition the only one you have on that volume? –  Decado Oct 2 '12 at 8:00
    
This particular image has xvde1 as the root partition and xvde2 as the swap –  nathanjosiah Oct 2 '12 at 18:10
    
Try removing the swap partition, then resize2fs –  Decado Oct 5 '12 at 5:47
    
I tried that, it still tells me that it is already as big as it can get. –  nathanjosiah Oct 6 '12 at 6:24
2  
A different approach might be to create a blank EBS volume (not from a snapshot), attach it to your instance, partition it, format the partition, and copy over the data. –  cyberx86 Oct 22 '12 at 16:45

3 Answers 3

up vote 0 down vote accepted
+50

I would take the safer route. And it looks like you are already doing things about as complicated. Attach the old volume to an instance launched with Amazon Linux or Ubuntu or whatever you are comfortable using. Mount it read/only. Then, create a new volume of the larger size you need. Attach it to the same instance at another device letter. Format it using the same label (or same UUID if your fstab mounts by UUID ... no real need for that in AWS but that is no assurance it isn't being done). Mount it read-write. Copy the file tree from the old volume to the new volume. You can use cp or rsync for that.

You may need to take other steps to make it bootable if you are not using PVGRUB "bootloader kernels" to load your real kernel from the volume.

Be sure to make a snapshot of the old volume before this, and a snapshot of the new volume after this.

share|improve this answer

Basically the problem here is that you're tring to increase the size of the filesystem to fill up the partition, yet the partition hasn't actually increased in size.

The trick here will be to mount a snapshot of the volume onto a different instance as, say /dev/xdf. Then use parted or fdisk to remove the swap partition at /dev/xdf2.

parted /dev/xdf
rm 2

Then you can resize the other partition to fill the disk

parted /dev/xdf
resize 1

Then use the default for starting partition and an appropriate number for ending position. Then recreate the swap partition. Then if you run resize2fs /dev/sdf it should increase the size of the partition. Then unmount that disk and use it as the root volume of a new instance.

share|improve this answer
    
As I have stated in my original question, I have already done that a hundred different ways. Every time it corrupts the drive and is unable to start again. However, I tried it again just to see and got the same result. resize2fs /dev/xvdj resize2fs 1.41.12 (17-May-2010) resize2fs: Bad magic number in super-block while trying to open /dev/xvdj Couldn't find valid filesystem superblock., If it helps I am using a ext4 FS –  nathanjosiah Oct 9 '12 at 16:20
    
Okay, could you do an fdisk -l after you resize the partition. That sounds like the start sector of the root partition changed. So with parted, specify the start sector with "1s". –  Decado Oct 9 '12 at 17:18
    
I cannot use parted because I am using an ext4 FS. –  nathanjosiah Oct 9 '12 at 17:33
    
Okay, so how does the fdisk output look after you resized the partitions using whatever tool it was you used to resize the partitions? –  Decado Oct 9 '12 at 17:34
    
Identical start points, further end points, bigger sizes –  nathanjosiah Oct 9 '12 at 17:35

Well, really the problem is you're using a poor AMI that sets up a swap partition. Amazon virtual machines do not need swap partitions and the tutorials you have been following assume your EBS volume is not partitioned. I'd recommend starting with an Ubuntu AMI from Alestic.com or using an Amazon Linux AMI.

If you must continue to use the AMI you are using then what you need to do is delete the swap partition and resize the ext4 partition with fdisk and then you can resize the file system. Doing that is fairly long and complicated and scary and I've never done it so I won't explain how to do it. You can find instructions via Google if you dare.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.