The scenario
You installed Fedora six months ago and allocated 50GB to the root partition, assuming that would be enough. Now dnf upgrade fails with No space left on device, or your build directory fills up instantly. Alternatively, you see a massive "Unallocated" block in GParted right next to your root partition, but the slider is grayed out. You need to move boundaries, but the disk layout feels locked. You are staring at a system where the physical storage exists, but the operating system cannot reach it.
What is actually happening
A disk has layers of abstraction. The partition table defines slices of the disk. The filesystem lives inside a slice and manages files. On Fedora, there is often a third layer: LVM (Logical Volume Manager). LVM sits between the partition and the filesystem, providing flexibility.
Resizing requires touching every layer in the correct order. If you expand the partition but forget the filesystem, the filesystem ignores the new space. If you expand the filesystem but forget the partition, the filesystem claims blocks that the kernel does not assign to it, which causes corruption.
The order depends on the direction. To grow, expand the outer layer first, then the inner layer. The partition grows, then LVM grows, then the filesystem grows. To shrink, reverse the order. Shrink the filesystem first, then LVM, then the partition. If you shrink the partition before the filesystem, you truncate the filesystem metadata and lose data.
Check your storage stack
Fedora Workstation and Server installations use LVM by default. If your system uses LVM, you resize logical volumes, not partitions. Running parted on the physical disk will not help if the root filesystem lives on a logical volume inside a volume group.
Run this command to see the stack. Look for lvm in the FSTYPE column or dm- device names.
# lsblk shows the block device tree with filesystem types and mount points
# -f adds filesystem details; -o selects columns for a clean view
lsblk -f -o NAME,FSTYPE,MOUNTPOINT,SIZE
If you see lvm or /dev/mapper/fedora-root, your system uses LVM. Follow the LVM procedure. If you see xfs or ext4 directly on /dev/sda2 or /dev/nvme0n1p2, you are using direct partitions. Follow the direct partition procedure.
Expand with LVM
LVM is the standard on Fedora. The workflow involves three steps: expand the physical partition, tell the physical volume about the new space, and extend the logical volume with the filesystem.
Here is how to expand the root logical volume to use all available free space. This assumes you have already freed space by shrinking a neighbor partition or adding a disk.
# parted resizes the partition table entry; 100% extends the partition to the disk end
# Replace /dev/sda and 2 with your disk and partition number
sudo parted /dev/sda resizepart 2 100%
# pvresize updates the LVM physical volume metadata to recognize the new partition size
# This makes the extra space available to the volume group without moving data
sudo pvresize /dev/sda2
# lvextend grows the logical volume and automatically resizes the filesystem with -r
# +100%FREE uses all remaining free space in the volume group
# Replace /dev/fedora/root with your logical volume path
sudo lvextend -l +100%FREE -r /dev/fedora/root
The -r flag in lvextend is a time-saver. It runs xfs_growfs or resize2fs automatically after extending the volume. You do not need to run a separate filesystem command.
Verify the result. The mount point should show the new size.
# df -h displays filesystem usage in human-readable units
# Compare the Size column against the expected total
df -h /
Snapshot the system before you shrink. Future-you will thank you.
Expand without LVM
If your system does not use LVM, you resize the partition and then the filesystem directly. Fedora defaults to XFS for root and home partitions. XFS supports online growth but does not support shrinking. Ext4 supports both growth and shrinking, but shrinking requires an unmounted filesystem.
Here is how to grow an XFS partition. XFS can grow while mounted, so you do not need a Live USB.
# parted extends the partition to fill the available space on the disk
# 100% sets the end boundary to the last sector of the disk
sudo parted /dev/sda resizepart 2 100%
# xfs_growfs expands the XFS filesystem to fill the underlying block device
# It detects the new partition size automatically when you pass the mount point
sudo xfs_growfs /
If you are using ext4, the command changes. resize2fs handles ext4.
# parted extends the partition boundary
sudo parted /dev/sda resizepart 2 100%
# resize2fs grows the ext4 filesystem to fill the partition
# Without a size argument, it expands to the maximum size of the block device
sudo resize2fs /dev/sda2
Run df -h to confirm. If the size did not change, check lsblk to ensure the partition actually grew. If the partition grew but df did not, the filesystem resize command failed or was skipped.
Trust the package manager. Manual file edits drift, snapshots stay.
Shrinking partitions
Shrinking is riskier than growing. You must reduce the filesystem first, then the partition. If you reduce the partition first, you destroy the filesystem structure at the edge.
XFS cannot shrink. If you have an XFS partition that is too large, you must back up the data, delete the partition, create a smaller one, format it, and restore the data. There is no in-place shrink for XFS. This is a design choice to keep XFS fast and simple.
Ext4 can shrink, but the filesystem must be unmounted. You cannot unmount the root partition on a running system. You must boot from a Fedora Live USB to shrink root or home partitions.
Here is the procedure for shrinking an ext4 partition from a Live USB.
# Unmount the filesystem; this is impossible for root on a running system
sudo umount /dev/sda2
# resize2fs shrinks the filesystem to the specified size
# The filesystem must be smaller than the partition before you shrink the partition
sudo resize2fs /dev/sda2 20G
# parted shrinks the partition table entry to match the new filesystem size
# The end position must not exceed the filesystem size
sudo parted /dev/sda resizepart 2 20G
After shrinking, run e2fsck -f /dev/sda2 to verify filesystem integrity before remounting. A botched shrink can leave you with an unmountable filesystem. Run this from a backup VM first if you can.
Common errors
You will encounter specific errors if the order is wrong or the tool arguments are incorrect.
xfs_growfs: /dev/mapper/fedora-root is not a mounted XFS filesystem
This error appears when you pass a device path to xfs_growfs instead of a mount point, or when the filesystem is not XFS. xfs_growfs expects a mount point like / or /home. If you are on LVM, the device path is /dev/mapper/..., but xfs_growfs still wants the mount point. Run xfs_growfs / instead.
resize2fs: The filesystem is mounted read-only
This happens when you try to resize a mounted ext4 filesystem that is locked or in a failed state. Unmount the filesystem or reboot into a Live environment. resize2fs requires write access to modify the superblock and block groups.
parted: Invalid argument
This error occurs when parted cannot apply the resize, often because the requested end position overlaps with another partition or falls inside the filesystem data. Check lsblk to ensure there is free space adjacent to the partition. You cannot resize into occupied space.
Run journalctl -xe after a resize operation if the system behaves oddly. The logs will show if the kernel detected a partition table mismatch or if the filesystem reported errors during the resize.
Decision matrix
Use GParted when you prefer a visual interface and are resizing non-root partitions on a running system. Use parted and xfs_growfs when you are on a headless server or need to script the expansion of an XFS root partition. Use lvextend when your system uses LVM, which is the default for most Fedora Workstation and Server installations. Use a Live USB when you must shrink a partition or modify the root partition boundaries, since the kernel cannot resize the partition it is currently executing from. Use ext4 when you anticipate needing to shrink partitions in the future. Use XFS when you want maximum performance and only need to grow partitions.
Reboot before you debug. Half the time the symptom is gone.