Resize LVM Root Partition Without Reinstalling Linux (September 2026)

Running out of space on your root partition is one of the most frustrating problems a Linux user can face. The good news is that if you set up LVM during installation, you can grow your root filesystem on the fly without wiping the disk or reinstalling your operating system.

In this guide, I will walk you through exactly how to resize an LVM root partition without reinstalling Linux. I have used these same steps on Ubuntu, Debian, CentOS, and Fedora servers, and they work whether you have unused space sitting inside your volume group or you have just expanded a virtual disk in VMware, Hyper-V, KVM, or VirtualBox.

I will also cover the trickier scenario of shrinking a root partition, which requires a Live CD, plus troubleshooting for the errors I see most often on Reddit and Ask Ubuntu. By the end, you will have a complete command reference you can apply to any LVM-based Linux system.

What Is LVM and Why It Matters?

LVM, or Logical Volume Manager, is a storage abstraction layer built into the Linux kernel. It sits between your physical disks and your filesystems, letting you carve up, grow, and move storage without being locked into fixed partition sizes.

Without LVM, resizing a partition means working directly with the partition table on the disk. That is risky, inflexible, and often requires booting from external media. With LVM, you can extend a logical volume while the system is running, then resize the filesystem on top of it in seconds.

This flexibility is exactly why most modern installers, including the Ubuntu installer, default to LVM when you choose the “use entire disk with LVM” option. It also explains why the Ubuntu installer famously leaves roughly half your disk unallocated inside the volume group, ready for you to claim later.

Understanding the PV, VG, and LV Layers

Before running a single command, it helps to understand the three layers LVM uses. I have seen countless admins get confused because they try to resize the wrong layer.

Physical Volume (PV): This is the base layer. A PV is a whole disk or a partition, like /dev/sda3, that has been initialized for LVM with pvcreate. You can inspect PVs with pvdisplay or pvs.

Volume Group (VG): One or more PVs are pooled together into a VG. Think of the VG as a bucket of storage. On Ubuntu, the default VG is usually named ubuntu-vg. You check it with vgdisplay or vgs.

Logical Volume (LV): The VG is carved into LVs, which behave like virtual partitions. Your root filesystem typically lives on an LV named something like ubuntu-lv, mapped to /dev/mapper/ubuntu--vg-ubuntu--lv. You inspect LVs with lvdisplay or lvs.

The resizing workflow always flows through these layers in order. To grow the root filesystem, you first make sure the VG has free space, then you extend the LV with lvextend, and finally you grow the filesystem itself with resize2fs.

Prerequisites and Safety Precautions

Resizing an LVM root partition is safe when done correctly, but a typo in a device path can destroy data. I treat every resize operation as if it could fail, because sometimes it does. Here is the safety checklist I follow before touching any partition.

1. Take a backup of critical data. LVM online extends rarely cause data loss, but shrinking and partition table edits absolutely can. If you are working on a VM, shut it down and take a snapshot or clone first. On bare metal, copy important files to external storage.

2. Confirm you are actually using LVM. Not every Linux install uses LVM. Run lsblk and look for entries under lvm or names like ubuntu--vg-ubuntu--lv. If you only see plain partitions like /dev/sda1 with no mapper device, you are not on LVM and these steps will not apply.

3. Have a Live USB or rescue media ready. If anything locks you out of the root filesystem, you will need to boot from external media to fix it. The Ubuntu install USB, SystemRescue, or a GParted Live image all work.

4. Check filesystem health first. Run df -hT to confirm your filesystem type. Most root partitions are ext4. Then, if you can unmount or boot to a rescue environment, run e2fsck -f /dev/mapper/ubuntu--vg-ubuntu--lv to repair any existing errors before resizing.

5. Never shrink a mounted filesystem. Extending ext4 can be done online while mounted. Shrinking ext4 requires the filesystem to be unmounted, which for the root partition means booting from a Live CD. This is the single biggest difference between the two operations.

How to Check Current Disk Usage and Free Space?

The first thing I do on any resize job is gather information. You need to know how much space the filesystem currently uses, how much room is left in the VG, and where the physical storage lives.

Start with df -h. This shows you mounted filesystems and their usage. Look for the line mounted at /, which is your root partition. If it is at 95% or higher, you need to act soon.

Next, run vgdisplay to see how much free space exists inside the volume group. Look for the line that reads Free PE / Size. If you see free extents here, you can extend the LV immediately without touching the disk or partition table at all. This is the easiest scenario and the one most Ubuntu users hit first.

Run lsblk to see the full storage tree. This command shows you the relationship between the physical disk, the partition, the PV, the VG, the LV, and the mount point all in one view. It is the single most useful command for understanding your layout.

Finally, lvdisplay shows the current size of your logical volumes and pvdisplay shows how much space each physical volume contributes. Together, these four commands give you a complete picture before you change anything.

How to Resize an LVM Root Partition Without Reinstalling Linux?

This method covers the most common scenario: you have free space sitting unused inside your volume group and you want to give it to the root logical volume. This is purely an online operation, no reboot, no Live CD, no partition table changes.

Step 1: Confirm free space in the volume group. Run sudo vgdisplay and read the Free PE / Size line. If it shows something like Free PE / Size 1024 / 4.00 GiB, you have 4 GiB ready to allocate. If Free PE is zero, skip to Method 2 below.

Step 2: Extend the logical volume. Use the lvextend command to grow the LV. To add all available free space to root, run:

sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

To add a specific amount instead, for example 10 GiB, use:

sudo lvextend -L +10G /dev/mapper/ubuntu--vg-ubuntu--lv

Make sure the device path matches your actual LV, which you can confirm with lvdisplay. On Ubuntu the default name is usually /dev/mapper/ubuntu--vg-ubuntu--lv.

Step 3: Resize the filesystem on top of the LV. Extending the LV does not automatically grow the filesystem. For ext4, run:

sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

If you omit a size argument, resize2fs grows the filesystem to fill the entire LV. On modern kernels, ext4 supports online resizing, so you can run this while root is mounted and in use. If you are using XFS instead of ext4, use xfs_growfs / rather than resize2fs.

Step 4: Verify the new size. Run df -h again and check the root line. The total size and available space should reflect the increase. That is the entire process for the default free space scenario.

Method 2: Extending After Expanding the Virtual or Physical Disk

If your volume group has zero free space, you need to add storage first. On a virtual machine, that means expanding the virtual disk in your hypervisor. On physical hardware, it means adding a new disk or growing a RAID array. The two most common paths are resizing the existing partition and adding a brand new PV.

Scenario A: Expanding an existing partition. After you grow the virtual disk in VMware, Hyper-V, KVM, or VirtualBox, the extra space appears as unallocated space at the end of the disk. First, rescan the disk so the kernel sees the new size. On a VM you can often do this with:

echo 1 | sudo tee /sys/class/block/sda/device/rescan

Next, grow the partition itself. I prefer cfdisk for its visual interface, but growpart works well in scripts. With cfdisk /dev/sda, select the LVM partition, choose Resize, and write the changes. Then tell LVM about the new size with:

sudo pvresize /dev/sda3

Replace /dev/sda3 with your actual partition. After pvresize, vgdisplay will show new free space in the VG. From here, you repeat Steps 2 through 4 from Method 1: lvextend then resize2fs.

Scenario B: Adding a new physical volume. If you added a brand new disk, initialize it as a PV and add it to the existing VG:

sudo pvcreate /dev/sdb
sudo vgextend ubuntu-vg /dev/sdb

Now the VG has more free space, and you extend the LV and filesystem exactly as before. This approach avoids partition table edits entirely, which makes it the safer option on production servers.

One important note for VM users: if you have snapshots on the disk, the hypervisor may refuse to let you expand it. Delete the snapshots first, expand the disk, then recreate snapshots afterward. I have seen this trip up countless VMware and Hyper-V admins.

How to Shrink an LVM Root Partition (Requires Live CD)

Shrinking is fundamentally different from extending. Ext4 does not support online shrinking, so you cannot reduce a mounted root filesystem. You must boot from a Live CD or rescue media. There is no shortcut here, and attempting to shrink a mounted filesystem will corrupt it.

Step 1: Boot from a Live USB. Use the Ubuntu install media, SystemRescue, or GParted Live. Boot into the live environment without mounting the system disk.

Step 2: Activate the volume group. The live environment needs to see your LVM structures. Run:

sudo vgchange -a y

Then confirm the LV with lvdisplay so you know the exact device path.

Step 3: Check the filesystem. You must run a filesystem check before resizing. Run:

sudo e2fsck -f /dev/mapper/ubuntu--vg-ubuntu--lv

Step 4: Reduce the filesystem first, then the LV. Order matters here. First shrink the filesystem to a target size smaller than what you want the final LV to be:

sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv 20G

Then shrink the logical volume to match, setting it slightly larger than the filesystem:

sudo lvreduce -L 22G /dev/mapper/ubuntu--vg-ubuntu--lv

Step 5: Grow the filesystem back to fill the LV. Run resize2fs without a size argument so the filesystem uses all available space in the now smaller LV:

sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

Step 6: Reboot and verify. Remove the Live USB and boot normally. Run df -h to confirm the new root size. The free space you freed up now sits inside the VG, available for other LVs.

Verifying the Resize

I always run three verification commands after any resize operation. df -h confirms the filesystem sees the new size from the user perspective. lvdisplay confirms the logical volume matches. vgdisplay shows whether any free space remains in the volume group.

If df -h shows the old size but lvdisplay shows the new size, it means you extended the LV but forgot to run resize2fs. That is the most common mistake I see, and the fix is simply running resize2fs now.

If the numbers between lsblk and df -h look slightly different, that is normal. lsblk reports the block device size, while df -h reports the filesystem size after accounting for reserved blocks and overhead.

Troubleshooting Common LVM Resize Errors

Over years of resizing partitions on Linux servers, I have run into the same handful of errors repeatedly. Here is how to fix each one.

Error: “No space left on device” during pvresize or lvextend. This happens when the root partition is completely full and LVM cannot write to its metadata area. Free up a small amount of space first by deleting log files or clearing the package cache with sudo apt clean. Once a few megabytes are free, retry the command.

Error: resize2fs reports “Filesystem is mounted” when shrinking. This is expected behavior. Ext4 cannot shrink online. You must boot from a Live CD, as described in the shrinking section above.

Error: “PV resize did not pick up the new disk size.” This usually means the kernel did not rescan the disk after you expanded it in the hypervisor. Reboot the VM, or trigger a rescan manually. Also verify you deleted any VM snapshots, since snapshots can prevent disk expansion in VMware and Hyper-V.

Error: lvextend says “Insufficient free space” even though you expanded the disk. You grew the disk but forgot to grow the partition and run pvresize. LVM only knows about space inside PVs, so run pvresize /dev/sda3 after expanding the partition, then check vgdisplay again.

Error: resize2fs fails with “bad magic number in superblock.” The filesystem is damaged or you pointed resize2fs at the wrong device. Run e2fsck -f on the device first. If that fails, you may need to restore from backup, which is why I always recommend taking a snapshot before resizing.

Confusion: df -h and lsblk show different sizes after resizing. This is normal and not an error. lsblk shows the block device size, df -h shows the filesystem size. If both reflect roughly the expected value, the resize succeeded.

Frequently Asked Questions

Conclusion

Learning how to resize an LVM root partition without reinstalling Linux saves you hours of downtime and eliminates the risk of a full OS reinstall. The core workflow is the same in every scenario: confirm free space in the VG, extend the LV with lvextend, and grow the filesystem with resize2fs.

If you started with the Ubuntu installer defaults, you likely have free space waiting inside your volume group right now, and claiming it takes under a minute. If you need more room than that, expand the virtual disk, run pvresize, and repeat the same two commands.

The only operation that requires extra effort is shrinking, because ext4 does not shrink online. For that, boot from a Live CD, shrink the filesystem first with resize2fs, then reduce the LV with lvreduce. With the commands in this guide and a backup in hand, you can handle any LVM resize scenario on any modern Linux distribution.