Enlarge an Ubuntu partition with fdisk without losing data

You have resized a disk or now have unallocated space after an Ubuntu data partition? For this space to become usable, two distinct operations are necessary: modifying the partition entry in the table, and then resizing the ext4 filesystem it contains. fdisk only does the first; resize2fs comes next.

The title “without losing data” does not constitute a guarantee. The safety of this operation relies on a properly tested backup, the certain identification of the correct disk, and the exact preservation of the starting sector of the partition. A target error or a modified start can render the data inaccessible. If a check does not match what is described here, stop before any writing.

Check that your partition fits the case in question

This process concerns a classic Linux data partition, formatted in ext4, non-root, non-LVM, unencrypted, and outside of software RAID mdraid. The unallocated space must be immediately after the partition to be enlarged. The partition must not be a logical partition located within an extended MBR partition. Finally, it must be unmounted for the operation: do not attempt to bypass a kernel refusal because it is in use.

Start by reading the organization of devices and filesystems:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Locate the parent disk, the part type entry that interests you, its format, and its mount point. An intermediate layer, an LVM logical volume, encryption, or RAID means you are not acting directly on a classic ext4 partition: stop and follow the procedure of this layer. To distinguish a data partition from a mounted root partition, also check the mounts:

findmnt

In the examples of this article, /dev/sdX designates the entire disk, to be replaced by the name actually identified, such as a device on your system. /dev/sdXN designates the partition of that disk, with its actual number. These are placeholders, not paths to copy as they are. Do not confuse the parent disk and the partition: fdisk will receive the former, while resize2fs will target the latter.

Examine the table and limits of the identified disk:

sudo fdisk -l /dev/sdX

Replace /dev/sdX with the confirmed disk from the previous step. Locate the table type (gpt or dos, i.e., MBR), the number of the target partition, its start sector (“Start”), its end (“End”), and its type. The free space should start just after the end of the partition and continue without any other partition interposing. If the space is before the partition, if it is occupied, if the disk is already fully allocated, or if you cannot establish these limits with certainty, do not use this method. If the identification of the disk remains uncertain, first redo the checks presented in this guide to prepare a partition without erasing the wrong disk. If it is the disk itself that needs to be enlarged, this preliminary operation takes place in the environment that provides it; it is not detailed here.

Also stop if the target is the mounted root, if the filesystem is not ext4, or if you have a logical/extended MBR partition, LVM, LUKS, mdraid, Btrfs, or XFS. These cases fall under another layer or procedure. Never move the beginning of the partition to reclaim space located before it.

Backup data and note parameters

Before touching the table, make a complete backup of the data on a separate medium, then verify it by actual reading or restoration. A backup file of the table does not replace this backup of files. Plan a maintenance window and the possibility of a controlled restart if the kernel cannot immediately reread the table.

You can save a record of the table in a location writable by your shell:

sudo sfdisk -d /dev/sdX > backup-table-sdX.sfdisk

Replace /dev/sdX and the name backup-table-sdX.sfdisk with those of the confirmed disk. Ensure that the resulting file is present, readable, and not empty, that it describes the correct disk, and then keep a copy away from the manipulated disk. The redirection > is executed by the calling shell: sudo does not automatically give write rights to the destination folder. Do not consider this dump as an improvised restoration method.

Note the exact parameters of the target partition outside your session: number, Start sector, End sector, type, and GPT or MBR table. Compare them to the output of the previous command and the interactive display described below. The starting sector is the critical reference: it must remain identical, without shift, after re-creating the entry. Also check that the planned extension will not overlap any other partition.

If your system uses partition or filesystem identifiers, note them before the operation:

blkid

blkid displays the UUID values of the filesystem and, depending on the device, the PARTUUID of the partition. Then compare these values to the references used by the mounts or boot. Deleting and then recreating an entry may alter its PARTUUID; do not assume it will remain stable. If you do not know which references are in use or how to handle a difference, stop before writing. The same applies if the data backup has not been tested, if the table dump is missing or inconsistent, or if the number, type, or start are uncertain.

Recreate the entry in fdisk without moving its beginning

The operation in fdisk concerns the partition table, not the ext4 content. The documentation of fdisk describes the manipulation of GPT and MBR tables as well as the partition information to control. Open the tool on the already identified parent disk:

sudo fdisk /dev/sdX

Replace the placeholder with the entire disk, not with the partition name. In the interactive interface, progress only after understanding each display:

• Enter p to display the table. Locate again the target partition, its number, its type, and its starting sector. They must match your notes.
• The deletion of the entry with d concerns only the target partition. If the tool asks for a number, choose the one you verified; do not guess and do not delete any other entry.
• With n, create the replacement entry. Keep the same number and enter exactly the same starting sector as noted. Choose an end located further in the contiguous free space, without exceeding the disk or overlapping another partition. Take into account fdisk‘s proposed alignment; if it implies a different start or if you do not understand the warning, do not proceed.
• Verify that the original partition type is preserved. Display the table again with p and compare it to your notes: same number, same type, same Start, new expected end, and all other entries intact.

Do not validate writing with w unless every value matches and you understand the displayed messages. Otherwise, quit without writing and resume the diagnosis. If fdisk indicates an ext4 signature and offers to delete it, refuse: do not delete this signature. A warning, an unexpected dialogue, or a numbering inconsistency is a reason to stop, not an invitation to try random responses.

After writing, the table describes a larger partition, but ext4 still retains its initial size. The second operation will be necessary for the filesystem to use the added space.

Have the kernel reread the table

Ask the kernel to reread the table of the concerned disk:

sudo partprobe /dev/sdX

Always use the confirmed parent disk. A return without error from partprobe is not enough to prove that the new size is actually recognized. Reread the table and verify the size presented by the kernel:

sudo fdisk -l /dev/sdX
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

The starting sector must remain unchanged, the new end must stay within the intended limits, and lsblk should display the new size on the target partition, without anomalies on other entries. If the kernel does not reload the table, do not run resize2fs. Postpone the operation; if your environment allows, arrange a restart within a controlled window, then check the table and recognized size again before any ext4 extension. If rereading fails for a mounted root, stop: this case does not fall under this tutorial.

Extend ext4 and check the result

When the kernel correctly sees the enlarged partition and its starting sector is identical to the recorded value, you can extend the ext4 filesystem:

sudo resize2fs /dev/sdXN

Replace /dev/sdXN with the exact name of the ext4 partition, with its real number — not by the parent disk. resize2fs extends ext2/3/4 within the existing container; it does not modify the partition table. Its order of execution comes after the enlargement and successful rereading of this table, as indicated in the documentation of resize2fs. A partition start recreated at a different sector can expose the filesystem to total loss: do not use this command if the start does not match exactly.

Wait for the end of the command and check that it reports no errors. Then check the filesystems and identifiers:

lsblk -f
blkid

The target must still appear as ext4, with the expected identifiers or with any difference in UUID/PARTUUID understood and addressed. If any PARTUUID references have changed, do not bring the system back online before verifying and correcting, according to your environment, the relevant mount or boot references. Do not assume that a reference will remain valid after recreating the entry.

To check the usable space on a mounted filesystem, use:

df -hT

After remounting according to the procedure specific to your environment, the line for the concerned partition should indicate the ext4 type and an increased usable capacity. If the partition is not mounted, its absence in df is normal and does not demonstrate a failure. Keep in mind the distinction: a larger table does not mean that ext4 is as well until resize2fs has completed.

Errors and situations that require stopping

Do not proceed further if you cannot identify the disk, if the first sector is unknown or different, if a backup has not been verified, if the space is not contiguous after the partition, or if another partition is at risk of being overlapped. Also stop in case of an ext4 signature warning, a changing type, an incomprehensible fdisk dialogue, or kernel reread failure.

An error from resize2fs, a size that does not match that of the table, or an unexpected UUID/PARTUUID identifier also requires suspending bringing the system back online and reviewing the situation. Do not proceed with random formatting, improvisational repairs, or further table modifications. If you fall outside the simple ext4 case described here, use the documentation corresponding to the actual layer instead of adapting this sequence.

Key Takeaways

For this ext4 data partition only, proceed in this order: tested backup, identification and recording of parameters, extension of the entry with the same starting sector, confirmed reread by the kernel, then extension of ext4 with resize2fs. Any uncertainty regarding the disk, sectors, identifiers, or expected outcome is sufficient reason not to write the table.