Tell Linux a Partition Has a New Size with `resizepart`

You will update the Linux kernel's view of one partition boundary with `resizepart`, using an exact length in 512-byte sectors. The command does not edit a partition table and does not resize a filesystem. That distinction is the safety boundary for the whole procedure.

Allow about fifteen minutes if you already know the intended partition length. You need the `util-linux` package, the correct disk and partition number, and a maintenance window if the device is mounted or used by a service. The examples use the distro binary at `/usr/bin/resizepart`, from util-linux 2.39.3. Check your own path before copying a version-sensitive result: this machine also has a separate Homebrew util-linux 2.42.4 binary earlier in one user's `PATH`.

1. Confirm the command and its version

Start with read-only checks. Use the absolute path when you want the Ubuntu package described by this guide:

$ command -v /usr/bin/resizepart
/usr/bin/resizepart
$ /usr/bin/resizepart --version
resizepart from util-linux 2.39.3
$ /usr/bin/resizepart --help
Usage:
 resizepart <disk device> <partition number> <length>

The installed manual documents only three positional parameters: the disk device, the partition number, and the new length. The available options are `-h`/`--help` and `-V`/`--version`. There is no option here for choosing bytes, megabytes or a filesystem.

2. Identify the disk and partition number

Inspect the device tree without changing it:

$ lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME   PATH         SIZE TYPE FSTYPE MOUNTPOINTS
sda    /dev/sda     100G disk
|-sda1 /dev/sda1     32G part ext4   /
+-sda2 /dev/sda2     68G part LVM2_member

Replace the illustrative values with the output from your machine. The first argument to `resizepart` is the whole disk, such as `/dev/sda`, not the partition path `/dev/sda2`. The second argument is the numeric partition number, so the example for `/dev/sda2` uses `2`.

Do not guess when names are ambiguous. NVMe devices use names such as `/dev/nvme0n1` with partitions such as `/dev/nvme0n1p3`, but the partition number passed to `resizepart` is still `3`. Recheck the model, serial or mount point with your normal inventory tools before proceeding.

3. Work out the length in sectors

The length argument is not a byte count. The manual defines it as the new partition length in 512-byte sectors. If your storage documentation gives a byte count, divide it by 512 and use an integer result. For example, 64 GiB is `134217728` sectors because 64 x 1024 x 1024 x 1024 / 512 equals that value.

Prefer a sector value supplied by the partitioning plan or recovery record. Do not infer the new end from a rounded human-readable value shown by a graphical tool. A one-sector mistake can leave the boundary different from the intended layout, and a value that is too small can make existing data inaccessible.

If you need to record the current kernel size for comparison, use a read-only block-device query available on your system, for example:

$ blockdev --getsz /dev/sda2
67108864

This prints the current length in 512-byte sectors. Save the old value before changing anything. It is the simplest recovery reference if you discover that the new boundary was entered incorrectly.

4. Check the destructive boundary before running it

Resizing a partition is not the same as resizing its filesystem. For an expansion, the filesystem normally needs its own filesystem-specific expansion operation afterwards. For a shrink, the filesystem must be safely shrunk first, using its own documented procedure, and the partition must not be made smaller than the filesystem data. `resizepart` performs neither operation.

Before the command, stop or quiesce services that are writing the affected storage where your storage layout requires it. A mounted root or data filesystem may have additional constraints. Use the ordinary account for the inspection commands above; use elevated privileges only for the state-changing command:

$ sudo /usr/bin/resizepart /dev/sda 2 134217728

The command normally produces no success message. The useful signal is a zero exit status:

$ printf '%s\n' "$?"
0

Run that check immediately after `resizepart`. If it prints a non-zero value, keep the error text and do not assume that the kernel accepted the requested length.

5. Verify the kernel view and finish the storage task

Read the sector count again:

$ blockdev --getsz /dev/sda2
134217728

If the value is unchanged, investigate the command's error and the device state. If it matches the requested length, the kernel has accepted the new boundary. That still does not prove that the partition table on disk, a device-mapper layer, or the filesystem has been updated. Check the complete stack using the tools appropriate to your layout, then perform the filesystem operation separately if an expansion or shrink is part of the maintenance plan.

Keep the original sector value and the command transcript with the change record. If you entered the wrong value but have not performed a filesystem operation, the immediate correction is to run `resizepart` again with the saved intended value, after checking the device and partition one more time. Do not use a guessed value as an undo operation, and do not attempt a shrink until the filesystem has been dealt with safely.

Common traps

• Using bytes: the length is in 512-byte sectors, not bytes or human-readable units.
• Passing the partition as the device: pass `/dev/sda` and a separate number such as `2`, not `/dev/sda2` as the first argument.
• Expecting partition editing: the command tells the kernel the new size; it does not manipulate partitions on the block device.
• Stopping after a zero status: verify the resulting sector count, then handle the filesystem and any storage layer separately.
• Running the wrong binary: `command -v resizepart` can find a different installation. Use an explicit path when the package version matters.