or How to tell your Ubuntu AWS server to resize a partition.

Amongst the AWS services we use, we run a number of small EC2 instances that are tightly spec’d (read minimal storage etc) and inevitably as our clients needs evolve we occasionally have to increase the size of the main volume. Sometimes, it’s not the client needs that require the extra space but the needs of the underlying platform, either way the process is nice and simple with a modern EC2 instance that uses EBS volume. So, after snapshotting the server we can follow some simple steps to increase the servers available storage.

WARNING: This should only be done after you’ve made a backup of your server¹

LAST WARNING: If this is all new to you and sounds like magic incantations, then don’t do it — you will probably damager your EC2 instance and take your server down. You’ve been warned.

The three main steps are:

1. Identify the volume that needs more space
2. Use the EC2 section of your AWS Console to increase the volume size
3. Tell Ubuntu to use the space 😃

Identify the Volume

The first step is to identify the volume with the space crunch, luckily this is very easy using the venerable df. Simply ssh into your instance and run df -hT² to get a list of the mounted file systems, their utilisation and types.

ubuntu@ip-10-10-10-101:~$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  475M     0  475M   0% /dev
tmpfs          tmpfs      97M   11M   87M  11% /run
/dev/nvma0b1p1 ext4      7.7G  7.6G   98M  99% /
tmpfs          tmpfs     483M     0  483M   0% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     483M     0  483M   0% /sys/fs/cgroup
tmpfs          tmpfs      97M     0   97M   0% /run/user/1000

The output from df is handy for also getting an understanding of how your Linux server is setup. In our case we want to pay special attention to the Filesystem Size and Use% columns.

First up you can see that root / is mapped to a partition at /dev/nvma0b1p1, it size is 7.7G and its current at 99% utilisation. Yes, that 99% look like our problematic volume 🙃

Remember the path to that partition , you’ll need it later.

Ok, now let’s see where nvma0b1p1 is actually located.

This time we can use lsblk another venerable and easy to use command to see a list of all the block devices. With the addition of a few options we can see mount points, file system types and sizes.

ubuntu@ip-10-10-10-101:~$ sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL

NAME        FSTYPE SIZE MOUNTPOINT LABEL
nvma0b1              8G            
└─nvma0b1p1 ext4     8G /          cloudimg-rootfs

We can clearly see that nvma0b1p1 is a partition on nvma0b1.

A quick ls /dev/ shows us the volume is mapped to /dev/nvma0b1 — check your server to see where your volume is mapped to (it should be in the same location but with your volume name). Remember this volume path for later.

Increase the Volume Size

AWS has a help document on Modifying an EBS Volume which is a good place to start or you can just follow along here.

We saw from in the lsblk command above that the volume nvma0b1 is the actual block storage device for our crowded volume. Unfortunately this doesn’t map to anything in AWS’s Console - but in theory you know which instance needs more storage… right?

So, login to your AWS Console and click on “EC2”, then follow one these two paths:

1

If you only have one server with a single volume attached to it click on “Volumes” in the main navigation column on the left, then click on your volume (it should already selected so you may not need this step). You can skip the next bit

2 or more

If you have several instances and therefore multiple volumes, select EC2 → Instances and then click on the instance you want to work with. If it’s not already showing bring up the Instance Information pane³ and click on the “Description” tab.

In the right-hand column of the Description tab you will see a section listing attached block devices. If it’s a simple instance setup you will probably see something a simple as this:

The block devices like /dev/sda are clickable and reveal more details including the EBS Id which will look something like this vol-0001078ae1ababcd8 . Again this is a link and if you click on it that volume will be selected for you in the Volumes page of the Elastic Block Store section.

3 times the space…

Ok, now that you have your volume selected you can use the Actions menu to Modify Volume. The only value you want to change is size, in our case we only needed a modest increase from 8G to 10G… of course you may need much more.

After you’ve made the change you will need to wait a short amount of time as the volume is optimised.

Shortly⁴ you will see that it’s “State” changes to in-use - completed (100%).

Once that’s done it’s back to ssh

Tell Ubuntu to use that extra space…

Ok, this bit is tricky and could be the reason I don’t publish this article… 😂

The steps in this section are:

1. Confirm that Ubuntu can see that the volume has increased in size
2. Grow the partition to use the extra space
3. Tell Ubuntu to extend the filesystem into the extra space on the partition

Confirm the Volume size

So, we’re going to confirm the volume has grown to the new size by running the lsblk command again.

ubuntu@ip-10-10-10-101:~$ sudo lsblk
NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvma0b1     259:0    0  10G  0 disk 
└─nvma0b1p1 259:1    0   8G  0 part /

You should see your volume has increased to the new size (10G in our case) and you will notice that the partition still shows the original size (8G in our example).

Grow the partition

The next step is to grow the existing partition on the volume you identified earlier. In our case that’s nvma0b1.

We do this with the growpart command:

sudo growpart </YOUR/VOLUME/PATH> 1

So the growpart command needs the path to the volume and a partition number to grow, generally it will be one, if you have more than one you will have to choose the correct number.

So run the growpart substituting your volume path⁵ for the </YOUR/VOLUME/PATH> and you will see output similar to this:

ubuntu@ip-10-10-10-101:~$ sudo growpart /dev/nvma0b1 1
CHANGED: partition=1 start=2048 old: size=16775135 end=16777183 new: size=20969439,end=20971487

Next, lets check that partition thinks it’s the right size by running lsblk again:

ubuntu@ip-10-10-10-101:~$ lsblk
NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvma0b1     259:0    0  10G  0 disk 
└─nvma0b1p1 259:1    0  10G  0 part /

Extend the filesystem

Ok, you’ve made it this far and it’s time to extend the filesystem into that new storage space.

First check you have the path to the volume, our example has the path: /dev/nvma0b1p1 then run sudo resize2fs </YOUR/PARTITION/PATH> replacing </YOUR/PARTITION/PATH> with your partitions path.

And you should see something like this⁶:

sudo resize2fs /dev/nvma0b1p1
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/nvma0b1p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/nvma0b1p1 is now 2621179 (4k) blocks long.

Finally check the filesystem again with df -h to make sure everything is the way you expect it to be.

ubuntu@ip-10-10-10-101:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            475M     0  475M   0% /dev
tmpfs            97M   11M   87M  11% /run
/dev/nvma0b1p1  9.7G  7.6G  2.1G  79% /
tmpfs           483M     0  483M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           483M     0  483M   0% /sys/fs/cgroup
tmpfs            97M     0   97M   0% /run/user/1000

Yay we now have an extra 2G available!!

Hope you found this useful.

Photo by freestocks.org from Pexels