Story / scenario opener
You bought a new drive, booted the Fedora installer, and the default partitioning screen offered you a single monolithic partition. You know you want flexibility. You want to resize your root filesystem without wiping your home directory. You want to add another disk later and pool the space together. The installer gives you a Custom button, but clicking it opens a screen full of mount points, filesystem types, and LVM checkboxes that feel like a test rather than a setup wizard.
What's actually happening
LVM stands for Logical Volume Manager. It sits between your physical disks and your filesystems. Think of it as a storage abstraction layer. Instead of carving your disk into fixed-size partitions at the factory, you tell the system to treat the raw disk as a pool of free space. You carve logical volumes out of that pool whenever you need them. If you run out of room on your root volume, you can shrink your swap volume or add a second physical disk to the pool and expand the root volume without rebooting or touching your data.
The architecture uses three layers. The Physical Volume lives on the raw disk. The installer writes a small metadata header to the first sector so the kernel knows the disk belongs to LVM. The Volume Group aggregates one or more physical volumes into a single addressable pool. The Logical Volume is a slice of that pool. The kernel exposes each logical volume as a block device under /dev/mapper/. Your filesystem formats that block device and mounts it at a directory path.
The metadata layer tracks where every block lives. LVM stores this metadata in the physical volume headers and in a central configuration directory. The device mapper kernel module translates logical addresses to physical disk sectors on the fly. You never interact with /dev/sda2 again. You interact with /dev/fedora/root. The abstraction handles the mapping.
Convention aside: Config files for LVM live in /etc/lvm/. The daemon reads them on startup. Never edit files in /usr/lib/lvm/. Those ship with the package and get overwritten on updates. Stick to /etc/ for any custom caching or filtering rules.
Reboot before you debug. Half the time the symptom is gone.
The fix or how-to
Start the Fedora installation and reach the storage configuration screen. Click I will configure partitioning to drop into the manual layout editor. Click Done to enter the mount point assignment interface.
Select your target disk from the device list. Click the plus button to add a new mount point. Set the mount point to /. Leave the filesystem type as xfs. Check the box that says Create as LVM. The installer will automatically create the underlying physical volume and volume group. Name the volume group fedora if you want to match the default convention, or pick something descriptive like storage-pool.
Add a second mount point for swap. Set the mount point to swap. Keep the LVM checkbox enabled. The installer will allocate a logical volume sized to your system RAM by default. Adjust the size if you plan to use hibernation. Hibernation requires swap equal to or larger than your physical RAM.
If you want a separate home directory, add a third mount point at /home. Set the filesystem to xfs and enable LVM. Leave the remaining space in the volume group unallocated. You can carve out new logical volumes later when you need them. Unallocated space in the volume group is your safety margin.
Click Done to return to the summary screen. Review the layout. Confirm the changes to begin the installation. The installer will format the logical volumes and copy the base system files. The process takes longer than a default install because LVM writes metadata to every physical volume and builds the device mapper nodes.
Convention aside: dnf upgrade --refresh is your normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them when maintaining your new LVM setup.
Here's how to verify the physical volumes and volume groups after the first boot.
sudo pvs
# Shows physical disks, their size, and which volume group claims them
sudo vgs
# Shows volume group names, total capacity, and free space
sudo lvs
# Shows logical volumes, their mount points, and current usage
You will see output mapping your disk to the volume group, and the volume group to the logical volumes. The paths will look like /dev/fedora/root instead of /dev/sda2. The /dev/mapper/ symlink handles the translation for you. The output confirms the metadata is readable and the device nodes exist.
Run journalctl first. Read the actual error before guessing.
Verify it worked
Run a quick check to ensure the filesystem is mounted correctly and the LVM metadata is healthy. The kernel must recognize the device mapper paths and mount them at boot.
Here's how to confirm the root filesystem is mounted from the logical volume and check for metadata warnings.
df -hT /
# Confirms the filesystem type is xfs and the device is /dev/mapper/fedora-root
sudo lvm pvck /dev/sda
# Validates the physical volume metadata without modifying anything
sudo lvm vgck fedora
# Validates the volume group metadata and checks for consistency
The df output should show xfs as the type and /dev/mapper/fedora-root as the source. The pvck and vgck commands return nothing if everything is clean. They print warnings or errors if the metadata is corrupted. A clean run means the volume group is consistent and the logical volumes are properly mapped.
Convention aside: journalctl -xe reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Use it when LVM operations fail silently.
Snapshot the system before the upgrade. Future-you will thank you.
Common pitfalls and what the error looks like
Running out of space in the volume group is the most common issue. You will see this error when trying to create a new logical volume or extend an existing one.
Insufficient free space in volume group "fedora": 512.00 MiB required, 0 free
The volume group is full. You need to add another physical disk or shrink an existing logical volume. Shrinking xfs is not supported. You must back up the data, delete the logical volume, create a smaller one, and restore the data. Extending is safe and reversible. Fedora defaults to xfs for root partitions because it handles large files and concurrent writes efficiently. The tradeoff is that you can only grow it online.
Here's how to add a second disk and expand the root logical volume without downtime.
sudo pvcreate /dev/nvme1n1
# Initializes the new disk for LVM use and writes metadata to the first sector
sudo vgextend fedora /dev/nvme1n1
# Adds the new physical volume to the existing volume group pool
sudo lvextend -l +100%FREE /dev/fedora/root
# Expands the root logical volume to consume all newly available space
sudo xfs_growfs /
# Resizes the xfs filesystem to fill the expanded logical volume
Notice the -l +100%FREE flag. It tells LVM to use every available block in the volume group. The xfs_growfs command runs online. You do not need to unmount the root filesystem. The filesystem expands instantly. If you used ext4 instead, you would run resize2fs and the process would work the same way. The command name changes, not the mechanism.
Another common trap is editing the wrong configuration directory. LVM reads /etc/lvm/lvm.conf for runtime settings. If you place custom filters or cache rules in /usr/lib/lvm/, the package manager will overwrite them on the next update. Always work in /etc/.
If the boot process hangs on a storage device, check the kernel logs for LVM activation failures.
[FAILED] Failed to activate one or more LVM2 logical volumes.
This usually means the physical volume is missing, the disk UUID changed, or the initramfs lacks the LVM drivers. Rebuild the initramfs with sudo dracut --force and reboot. The initramfs will regenerate the device tree and include the correct LVM activation scripts. The boot process will resume normally.
Convention aside: systemctl status <unit> shows recent log lines AND state in one view. Always check status before restart. If lvm2-activation.service is failing, the status output will point directly to the missing physical volume.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use LVM when you need to resize filesystems dynamically or pool multiple physical disks into a single storage space. Use Btrfs subvolumes when you want built-in snapshots, compression, and copy-on-write semantics without a separate volume manager. Use standard partitions when you are installing on a single drive and never plan to change the layout. Use ZFS when you need enterprise-grade data integrity, hardware RAID replacement, and advanced caching tiers. Stay on the default Anaconda layout if you only deviate from the defaults occasionally.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.