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 sdb1this
~$ 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 filesystemand 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/1000All of this seems to indicate that I can just issue a
sudo resize2fs /dev/sda1and 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/sda1This 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 1before resize2fs can work?
1 Answer
You have to first resize the partition with the following steps:
sudo parted /dev/sdato enter the prompt "(parted)" as the superuserresizepart 1to resize the partition1-0resizes 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:quitto 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.
6