Resize Ubuntu /dev/sda1 partition in VirtualBox VMDK when /dev/sda is already larger

Question

Some time ago I created a VMDK which was mapped to a raw partition on a SSD.

The SSD was a 128GB one, I partitioned it in Windows (the host), made the second partition accessible to Windows (NTFS), and used the first partition to map it into a VMDK.

This first partition has a size of about 48GB.

When I then installed Ubuntu Server in a VM which used that VMDK, I noticed that the size of /dev/sda shown to me was the 128GB, but I created the partition during the Ubuntu installation to be of the size of the first partition, so that /dev/sda1 is of 48GB.

Due to the lack of space on /dev/sda1 (there are 5GB free) I bought another SSD, and decided to stop using raw mappings. I copied the VMDK via the Virtual Media Manager onto the new SSD, so there I now have a VMDK file of aprox. 44GB (don't take it very exactly, it's the MiB vs GiB vs GB issue).

I thn replaced the HDD of the VM with the newly copied VMDK and booted it. It works as expected.

Now I have this:

:~$ cat /proc/partitions
major minor  #blocks  name

  11        0      58100 sr0
   8        0  125034840 sda
   8        1   46873600 sda1
   8       16  488386584 sdb
   8       17  181189085 sdb1

this

~$ sudo fdisk -l
Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000271d1

Device     Boot Start      End  Sectors  Size Id Type
/dev/sda1  *     2048 93749247 93747200 44.7G 83 Linux


Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 59B4B505-C79F-11E3-8F9C-709E29CA19D2

Device     Start       End   Sectors   Size Type
/dev/sdb1     34 362378204 362378171 172.8G Linux filesystem

and this

:/$ df -h
Filesystem       Size  Used Avail Use% Mounted on
udev             7.9G     0  7.9G   0% /dev
tmpfs            1.6G  9.1M  1.6G   1% /run
/dev/sda1         44G   37G  5.1G  88% /
tmpfs            7.9G  1.1M  7.9G   1% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
tmpfs            7.9G     0  7.9G   0% /sys/fs/cgroup
windows-avconv   1.9T  1.8T  103G  95% /home/user/windows-avconv
windows-storage  1.9T  1.8T  103G  95% /home/user/windows-storage
windows-share     50G  101M   50G   1% /home/user/windows
cgmfs            100K     0  100K   0% /run/cgmanager/fs
/dev/sdb1        170G   91G   72G  56% /media/hdd
tmpfs            1.6G     0  1.6G   0% /run/user/1000

All of this seems to indicate that I can just issue a

sudo resize2fs /dev/sda1

and then /dev/sda1 will grow to become 119.2 GiB big without me needing to use VBoxManage modifyhd <absolute path to file> --resize <size in MB>

Am I correct with this assumption?

---

Update: I made a backup copy of the VMDK and issued a

:~$ sudo resize2fs /dev/sda1

This is the result:

resize2fs 1.42.13 (17-May-2015)
The filesystem is already 11718400 (4k) blocks long.  Nothing to do!

Do I need to issue a

sudo growpart /dev/sda 1

before resize2fs can work?

Solution

You have to first resize the partition with the following steps:

1. sudo parted /dev/sda to enter the prompt "(parted)" as the superuser
2. resizepart 1 to resize the partition 1
3. -0 resizes it to the end of the disk. - indicates that it should count from the end of the disk, not the start. This makes -0 the last sector of the disk - which is suitable when you want to make it as big as possible. Step 4:
4. quit to exit parted

The file system meta information needs to indicate the size of disk, and resize2fs updates this. Thus, after expanding, run resize2fs /dev/sda1.

It's highly recommended to do this in either single user mode / recovery mode, or with the file system mounted in read only mode. You can mount it read only by mount -o remount,ro /dev/sda1.

Extending is possible to do with filesystem in RW-mode, but it increases chances of data loss. As this is a VM, and you can easily make a backup, doing it with the volume mounted RW may make sense.

Addendum: run commands as root for desired effect.

Comments

[vidarlo]

You need to extend the partition first, yes. I assume growpart can do this. The traditional way would be to use gparted to extend it, or some other modification utility. The Ancient(TM) way of doing it is deleting the partition, and creatinng it with the same starting point, and a new end.

[Daniel F]

Thanks, this is a headless machine, so no gparted. I'm confused. So does resize2fs resize the usable space inside the partition to be the max space of the partition, and gparted or sudo parted /dev/sda resizepart 1 ???M the actual size of the partition /dev/sda1? I thought the file system was always the size of the partition, am I mistaken here? Is there an option for parted to use the entire /dev/sda?

[vidarlo]

Posted as answer :)

[Daniel F]

Sounds very promising, will do it and give feedback

[Daniel F]

parted: invalid option -- '0' :(

[vidarlo]

Sorry! Tested just now. If you run sudo parted /dev/sda, and in parted do resizepart 1 and enter -0 as size it works :) Just tested here in a VM. I was stupid, and assumed you could pass parameters like that.

[Daniel F]

I did this in single user mode (or recovery, not sure, in single I chose enter to enter maintainence mode). It did warn me that it is mounted as R/W. Is that warning harmless in that mode?

[vidarlo]

It's not harmless, but there's fewer processes doing disk IO, so it's safer. Anyway, extending a disk is not a particularly dangerous operation, as the full filesystem still is there.

[B. Shea]

"Error: Can't have overlapping partitions." when using "-0" I had to remove my ext part+swap partition (it wasn't being used).