You ran out of space on your main partition
You run df -h and see your root or home partition sitting at 98 percent. You just installed a second drive, or maybe you bought a larger SSD and cloned your old system. The operating system sees the new space, but your applications refuse to write to it. You need to push that extra storage into your existing partition without wiping your data or rebooting into a live environment.
What is actually happening under the hood
LVM sits between the physical disk and the filesystem. It creates a virtual pool of storage called a volume group. Inside that pool, you carve out logical volumes. The logical volume is just a block device. The filesystem lives on top of it. When you add a new disk or resize a partition, the physical layer changes first. The volume group learns about the new space. The logical volume stays the same size until you tell it to grow. The filesystem stays the same size until you tell it to grow. You have to resize two layers in order. First the block device, then the filesystem. Skipping one step leaves you with unallocated space that nothing can use.
Think of it like a warehouse. The volume group is the entire building. The logical volume is a rented section of floor space. The filesystem is the shelving system inside that section. If you buy an adjacent warehouse and knock down the wall, you now have more floor space. The shelves do not automatically stretch to fill it. You have to tell the landlord to extend your lease, then you have to rebuild the shelves to match the new dimensions.
Fedora ships with LVM by default on most Workstation and Server installations. The default volume group is usually named fedora or vg_<hostname>. You can check your layout with lsblk or vgs. Never edit files in /usr/lib/lvm/. Those ship with the package. If you need to change LVM behavior, create a drop-in in /etc/lvm/lvm.conf. The package manager will overwrite /usr/lib/ on the next update. Your /etc/ changes survive.
The fix: extending the volume and filesystem
Run these commands to map out your current storage layout before touching anything.
sudo vgs # Shows volume group name, total size, and free space
sudo lvs # Shows logical volume name, size, and filesystem type
df -hT /mount/point # Confirms the current filesystem type and usage
The vgs output tells you how much free space exists in the pool. If it says 0 in the VFree column, you need to add a physical volume first. The lvs output gives you the exact path to your logical volume, usually under /dev/mapper/ or /dev/vg_name/lv_name. The df -hT command confirms whether you are dealing with XFS or ext4. Fedora uses XFS by default for root and home. Older installations or custom setups often use ext4. The resize command changes depending on the filesystem.
Tell LVM to claim the unallocated space from the volume group and attach it to your logical volume.
sudo lvextend -l +100%FREE /dev/mapper/vg_name-lv_name # Uses all unallocated space in the volume group
sudo lvextend -L +50G /dev/mapper/vg_name-lv_name # Alternative: add a fixed amount instead of using everything
The -l +100%FREE flag is the most common choice. It grabs every available megabyte in the volume group. The -L +50G flag gives you precise control when you want to leave room for future snapshots or other volumes. LVM updates the metadata and expands the block device instantly. No reboot is required. The kernel sees the new size immediately.
XFS requires the mount point, not the device path, because it reads the superblock from the mounted filesystem.
sudo xfs_growfs /mount/point # Expands the XFS filesystem to fill the newly enlarged block device
XFS performs this operation online. The filesystem remains mounted and writable during the process. The command reads the current block device size, recalculates the allocation groups, and updates the metadata. It finishes in seconds for most desktop workloads. Large databases or heavily fragmented volumes may take longer. The command prints the old and new block counts when it finishes.
If your partition uses ext4, the command targets the device path directly instead of the mount point.
sudo resize2fs /dev/mapper/vg_name-lv_name # Expands the ext4 filesystem to match the new block device size
The resize2fs utility also works online for ext4. It checks the filesystem, extends the block group descriptors, and updates the superblock. If the filesystem is mounted read-only, you must mount it read-write first. The command prints a progress bar and the final block count.
Run df -h /mount/point and lvs to confirm the sizes match. Check journalctl -xe for any filesystem warnings. Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Run df -hT /mount/point and compare the output to your lvs results. The filesystem size should match the logical volume size within a few megabytes. The difference accounts for filesystem metadata and reserved blocks. Run dmesg | tail -20 to catch any kernel messages about block device resizing. The kernel logs the new capacity when LVM updates the device mapper.
If you are running a database or a service that caches disk geometry, restart the service after the resize. PostgreSQL and MySQL sometimes hold stale size information in memory. A simple systemctl restart postgresql or systemctl restart mysqld clears the cache. Check journalctl -xeu <service> to confirm clean startup.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
The most common mistake is running lvextend and forgetting the filesystem resize. The block device grows, but df shows the exact same usage percentage. The space sits idle until you run xfs_growfs or resize2fs.
XFS cannot shrink. If you accidentally extend a volume and want to reverse it, you must back up the data, reduce the logical volume with lvreduce, and restore the data. The lvreduce command will refuse to run if the filesystem is larger than the target size. It prints lvreduce: Not enough free space in logical volume when you try to shrink past the filesystem boundary.
Running xfs_growfs on an unmounted filesystem fails immediately. XFS requires an active mount point to read the superblock. The error reads xfs_growfs: /mount/point is not a mounted XFS filesystem. Mount the volume first, then run the command.
If your volume group has no free space, lvextend aborts with lvextend: Insufficient free space in volume group. You must add a physical volume first. Run sudo pvcreate /dev/sdX on the new disk, then sudo vgextend vg_name /dev/sdX. The volume group learns about the new storage. You can then run lvextend again.
SELinux denials sometimes appear if you are resizing a volume that hosts a service with strict context requirements. Check journalctl -t setroubleshoot for one-line summaries. Restore contexts with restorecon -Rv /mount/point if the service refuses to start after the resize.
Read the actual error before guessing. Run journalctl -xe first.
When to use LVM versus other storage layouts
Use LVM when you need to resize partitions on the fly without rebooting or unmounting. Use standard partitions when you want a simple layout and never plan to resize volumes. Use btrfs when you want built-in snapshots and subvolumes instead of LVM layers. Stay with the default Fedora layout if you only need occasional storage adjustments.
LVM adds a translation layer. That layer gives you flexibility. It also adds a point of failure. If the LVM metadata gets corrupted, the block devices disappear until you restore the metadata. Keep a backup of your metadata with sudo vgcfgbackup. The backup lives in /etc/lvm/backup/ by default. You can restore it with vgcfgrestore if the primary metadata fails.
btrfs handles snapshots at the filesystem level. LVM handles snapshots at the block level. LVM snapshots require pre-allocated space. btrfs snapshots are copy-on-write and consume space only when blocks change. Choose the tool that matches your backup strategy. Do not mix LVM snapshots with btrfs snapshots on the same volume. The two systems do not coordinate.
Snapshot the system before the upgrade. Future-you will thank you.