Linux Root Partition: Find It and Grow It Without Rebooting

Updated: 17 October 2026 · Applies to: growpart (cloud-guest-utils 0.33), ext4 (e2fsprogs 1.47.2), XFS (xfsprogs 6.13) and LVM 2.03.31, tested with a Linux 6.12 kernel on Debian 13; the same commands apply to Ubuntu 24.04 and 26.04, AlmaLinux and Rocky Linux 9 and 10

The root partition is the partition that holds the / file system, where Linux itself is installed. After your provider has enlarged the virtual disk, you can grow the root partition and its file system while the server keeps running, with no reboot and no unmount:

sudo growpart /dev/vda 1     # the disk, a space, then the partition number
sudo resize2fs /dev/vda1     # ext4
sudo xfs_growfs /            # XFS (give the mount point)

Use your own disk and partition names from lsblk. If / is on LVM, there are two extra commands (step 4). Take a backup before you change partitions: a wrong disk or partition number can make the server unbootable.

1. Find the root partition

findmnt /
df -hT /
lsblk

findmnt / names the device mounted as / and its file system type. Lab output from our test system, a 1 GiB virtual disk whose root partition was still 597 MiB:

$ findmnt /
TARGET SOURCE     FSTYPE OPTIONS
/      /dev/ubda2 ext4   rw,relatime
$ lsblk /dev/ubda
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
ubda     98:0    0    1G  0 disk
|-ubda1  98:1    0    1M  0 part
`-ubda2  98:2    0  597M  0 part /

Our lab kernel calls the disk ubda; on a VPS it is usually vda or sda, so the root partition is something like /dev/vda1 or /dev/sda2. On an NVMe disk, the partition /dev/nvme0n1p1 belongs to the disk /dev/nvme0n1. If the source looks like /dev/mapper/almalinux-root, root is on LVM. To see every disk and partition, see list all disks, volumes and partitions.

2. Check that Linux sees the bigger disk

In the output above, the disk is already 1 GiB while the partition is not. That is the starting point. fdisk -l warns about it on GPT disks; both lines are normal after a disk was enlarged, and growpart corrects them:

GPT PMBR size mismatch (1228799 != 2097151) will be corrected by write.
The backup GPT table is not on the end of the device.

If lsblk still shows the old disk size:

• virtio disks (vda): the kernel picks up the change by itself and logs a line with new size: (check with sudo dmesg | grep "new size"), according to the virtio_blk driver source.
• SCSI disks (sda): ask the kernel to rescan the disk, as described in Red Hat's storage documentation: echo 1 | sudo tee /sys/block/sda/device/rescan
• If neither shows the new size, the virtual machine may need a full stop and start from its control panel before the disk changes. Ask your provider.

3. Grow the partition, then the file system

1. Install growpart: sudo apt install cloud-guest-utils on Ubuntu and Debian, sudo dnf install cloud-utils-growpart on AlmaLinux, Rocky Linux and RHEL.
2. Preview the change (nothing is written):

   sudo growpart --dry-run /dev/vda 2

3. Grow the partition. Lab output:

   $ sudo growpart /dev/ubda 2
   CHANGED: partition=2 start=4096 old: size=1222656 end=1226751 new: size=2093023 end=2097118

   lsblk now shows the partition at 1022M, but df -h / still shows 571M: the file system has not grown yet.
4. Grow the file system. For ext4 (the default on Ubuntu and Debian), give the partition:

   $ sudo resize2fs /dev/ubda2
   resize2fs 1.47.2 (1-Jan-2025)
   Filesystem at /dev/ubda2 is mounted on /; on-line resizing required
   old_desc_blocks = 1, new_desc_blocks = 1
   The filesystem on /dev/ubda2 is now 261627 (4k) blocks long.

   For XFS (the default on AlmaLinux, Rocky Linux and RHEL), give the mount point:

   $ sudo xfs_growfs /
   ...
   data blocks changed from 152832 to 261627

5. Check: df -hT /. In our lab the ext4 root went from 571M to 990M (72% to 41% used) and the XFS root from 533M to 958M.

Both file systems were the mounted root file system while they grew. A background process kept writing to / throughout, and the checksum of a 15 MB test file was the same afterwards. More detail on XFS: grow an XFS file system with xfs_growfs.

4. Root on LVM

Grow the partition that holds the LVM physical volume, then the physical volume, then the logical volume and its file system in one step (-r):

sudo growpart /dev/vda 3
sudo pvresize /dev/vda3
sudo lvextend -r -l +100%FREE /dev/almalinux/root

Lab output (shortened):

$ sudo pvresize /dev/ubdc3
  Physical volume "/dev/ubdc3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
$ sudo vgs
  VG        #PV #LV #SN Attr   VSize   VFree
  almalinux   1   1   0 wz--n- 820.00m 424.00m
$ sudo lvextend -r -l +100%FREE /dev/almalinux/root
  Size of logical volume almalinux/root changed from 396.00 MiB (99 extents) to 820.00 MiB (205 extents).
...
data blocks changed from 101376 to 209920

If you run lvextend before growpart and pvresize, it only says New size (99 extents) matches existing size (99 extents), because the volume group has no free space yet. On Ubuntu the names are ubuntu-vg and ubuntu-lv (sudo lvs shows yours). For new disks, shrinking and other LVM cases, see extend an LVM volume with lvextend.

When it does not work

• NOCHANGE: partition 2 is size 2093023. it cannot be grown: the partition already ends at the end of the disk, or another partition sits behind it. growpart only grows a partition into free space directly after it.
• The filesystem is already 261627 (4k) blocks long. Nothing to do!: resize2fs found no extra space. Grow the partition first.
• xfs_growfs: / is not a mounted XFS filesystem: in our lab this happened when df named the root device /dev/root, which did not exist (a system that boots without an initramfs). findmnt / still showed the real partition. Creating the link with sudo ln -s /dev/vda2 /dev/root (your partition) let xfs_growfs / run; the link is gone after the next reboot.
• WARNING: MBR/dos partitioned disk is larger than 2TB. Additional space will go unused.: an MBR partition table cannot use more than 2 TiB. Moving to GPT is a bigger job; plan it with a full backup.

A swap partition after the root partition

Some installers put swap behind the root partition (on MBR disks often a logical partition 5 inside an extended partition 2), so growpart answers NOCHANGE. One way out, tested in our lab with the root file system mounted the whole time:

1. Turn the swap off: sudo swapoff /dev/vda5
2. Delete the extended partition, which also removes the swap partition inside it: sudo sfdisk --delete /dev/vda 2. On a disk in use it ends with Re-reading the partition table failed.: Device or resource busy. That is expected.
3. Tell the kernel the partitions are gone: sudo partx -d --nr 5 /dev/vda and sudo partx -d --nr 2 /dev/vda. Without this step growpart failed with FAILED: pt_resize failed.
4. Grow as above: sudo growpart /dev/vda 1, then sudo resize2fs /dev/vda1.
5. Remove the old swap line from /etc/fstab and use a swap file instead: increase swap space with a swap file.

If you would rather not edit partitions on a running system, boot the server into rescue mode first (enable rescue mode in Virtualizor) and use parted.

Cloud images and cloud-init

According to the cloud-init documentation, its growpart and resizefs modules run at every boot and grow the root partition and file system by default. On images that use cloud-init, a reboot would therefore also grow root. The commands above do the same at once, without the reboot.

Other methods for a root partition without LVM: extend an ext4 or XFS root partition without LVM and expand an ext2, ext3, ext4 or XFS root partition.

Official documentation: growpart, resize2fs and xfs_growfs.