Extend the Ubuntu root partition after expanding the disk

You have increased the size of a virtual disk in the hypervisor, but Ubuntu is not yet using all the space for its root. The disk must first be expanded on the hypervisor side and its new capacity visible in the guest. This process only concerns a root / directly mounted on a simple ext4 partition, followed by contiguous free space.

The partition and the file system are two different layers. The procedure first enlarges the partition entry, then ext4. Only proceed to the next step if the previous checks match your machine.

Identify the ext4 root, disk, and partition

Start by locating the source and type of file system mounted on /, then examine the devices and their relationships:

findmnt -no SOURCE /
findmnt -no FSTYPE /
lsblk

The first command should point to the partition that carries the root; the second should indicate ext4. In lsblk, trace back from this partition to its parent disk. To obtain explicit columns, you can extend the inspection as follows:

lsblk -b -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS,PKNAME,PARTN

Do not deduce the disk name from an example. A root can, for instance, be on /dev/vda2: the disk would then be /dev/vda and the partition number 2. On NVMe, /dev/nvme0n1p2 corresponds to the disk /dev/nvme0n1 and number 2. Always verify these elements in your own outputs.

In the commands below, /dev/sdX is a placeholder for the entire disk, never for a partition. N represents the actual partition number for the root. Replace them before any execution; do not copy these examples as they are.

Then examine the partition table and boundaries on the identified disk. In the following command, replace /dev/sdX with the verified path of the entire disk:

sudo fdisk -l /dev/sdX

fdisk -l is used here to read the table, not to modify it. Compare the disk capacity, partition boundaries, and their order. The available space should be immediately after the root partition, with no other partition in between. The fdisk documentation describes the table information displayed by this tool; this reading does not replace the verification of the actual topology.

Before any writing, perform a dry run diagnosis. Replace the two placeholders with the disk and partition number actually identified:

sudo growpart --dry-run /dev/sdX N

The --dry-run mode reports what the tool would do without modifying the table. It should announce a possible extension of the correct partition in the available contiguous space. The Ubuntu documentation for growpart specifies the disk-partition number syntax and the role of the dry run diagnosis.

Stop if the root goes through LVM, LUKS, or RAID, if the file system is Btrfs or XFS — or is not ext4 — if an extended/logical partition or another layer makes the topology ambiguous, if free space is before the root or not contiguous, or if another partition follows the root. Also stop if the expanded disk is not visible, if the tool is missing, if the diagnosis does not announce the expected extension or returns an error. Do not attempt to circumvent these cases with partition manipulation.

Prepare the change and a rollback

Before the only command of this procedure that writes the partition table, ensure that you have a recoverable backup, that you know how to restore it, and that the inspection outputs are retained. A snapshot is only useful as a rollback if you can actually restore it.

Also confirm access to the machine’s recovery console and the hypervisor, as well as the ability to reboot Ubuntu. Plan a maintenance window: a restart may be necessary if the kernel does not recognize the new partition size hot. If the backup, console access, or reboot possibility are not assured, stop.

Record the current state of the file system and keep the results of findmnt, lsblk, fdisk -l, and the dry run diagnosis for later comparison:

df -hT /

This output is a point of comparison, not proof that the partition and ext4 have already been extended.

Enlarge the partition entry

Proceed only if all the previous checks are compliant, the recoverable backup is ready, and recovery access and rebooting are possible. The following command modifies the partition table. Be sure to replace /dev/sdX and N with the validated disk and number; the first designates the entire disk, the second the root partition.

sudo growpart /dev/sdX N

The expected result is a report of the enlargement of the root partition entry to the available contiguous space. growpart changes the size of the partition, not that of the ext4 file system.

If the command returns an error, reports no enlargement, signals a warning about the table, or seems to target another device, stop. Do not chain with resize2fs and do not attempt to recreate or fix the partition blindly.

Check the size recognized by the kernel

After the operation, confront the table and the devices. Replace /dev/sdX with the identified disk:

lsblk -b -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS,PKNAME,PARTN
sudo fdisk -l /dev/sdX
findmnt -no SOURCE /

The same partition should still carry the root, and its current size, as presented by the kernel in lsblk, should be larger and correspond to the enlarged partition entry. A visible modification in the table is not sufficient if the kernel still exposes the old size.

If the size has not changed, if re-reading the table has failed, if table and kernel do not agree, or if the recognized partition is not the one mounted on /, stop: do not launch resize2fs. If only the hot re-reading is missing while table enlargement is confirmed, plan a controlled reboot using the recovery console. After rebooting, rerun checks of source, type, and size. If the expected size is still not recognized or if booting causes problems, stop and have the machine diagnosed; do not run random commands.

Expand ext4 after confirming the partition

This step is reserved for cases where findmnt still confirms the same ext4 root and where lsblk confirms that its partition actually has the new size. The placeholder /dev/sdXN here designates the full path of the root partition, and not the entire disk. Replace it with the verified source; for NVMe, a partition name notably resembles /dev/nvme0n1p2.

sudo resize2fs /dev/sdXN

The expected result is the extension of the ext4 file system in the now larger partition. The documentation for resize2fs distinguishes this operation from modifying the table: resize2fs does not change the partition. Online resizing depends on kernel and file system support; do not assume it will succeed on any configuration.

Stop if the type is not ext4, if the partition retains its old size, if the source no longer corresponds to the mounted root, or if the command reports an error. Do not unmount / to improvise another procedure; do not execute either shrink or e2fsck on the mounted root. An error calls for appropriate diagnosis, not another random command.

Check usable space

Conclude with checks of the source, type, partition size, and usable space:

findmnt -no SOURCE /
findmnt -no FSTYPE /
lsblk -b -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS,PKNAME,PARTN
df -hT /

To conclude an effective extension, the same root source must be found, type ext4, the new partition size recognized by the kernel, and a greater file system capacity in df -hT /. The partition size and the space reported by df are not identical: ext4 uses part of its capacity for its own structures.

If df has not increased, if the values do not match, or if a command has reported an error, do not declare the operation successful and do not repeat growpart. Keep the outputs for diagnosis. For a non-root ext4 data partition to expand with fdisk, the process differs and this procedure does not apply.

In brief: precisely identify the root, confirm contiguous space and the result of the dry run diagnosis, prepare backup and recovery, then check separately the partition recognized by the kernel and ext4. At the slightest discrepancy, stop before the next step.