The hard truth about post-install encryption
You installed Fedora on your laptop. You finished the setup, installed your dotfiles, and pushed your first commit. Then you left the laptop unattended at a cafe. You walked back, grabbed it, and realized the drive is unencrypted. Anyone with physical access can pull the SSD and read your SSH keys. You want to encrypt the disk now. You cannot add full disk encryption to a running Fedora system without reinstalling. The only safe path is to back up your data, wipe the disk, and install again with encryption enabled.
Backup before you wipe. A corrupted backup is the only failure that matters.
Why encryption lives at the block layer
Full disk encryption works at the block device level, not the filesystem level. The kernel talks to the disk in blocks. LUKS sits between the kernel and the disk. Every block read or write passes through the LUKS layer for decryption or encryption. If you encrypt after installation, the bootloader needs to change. GRUB needs to read the encrypted partition to load the kernel. The initramfs needs to prompt for the password before mounting root. The partition table itself changes structure. Modifying this chain while the system is running is impossible. Modifying it while the system is stopped requires a live environment and carries extreme risk of breaking the boot chain.
Think of your disk like a house. Full disk encryption locks the front door. You cannot lock the front door while you are standing in the living room. You have to move everything out, lock the door, and move everything back in. File-level encryption is like locking boxes inside the house. You can do that anytime. But if someone breaks the window, they get the boxes. Full disk encryption stops them at the door.
Run lsblk -f to see your current layout. If you see ext4 or xfs directly on a partition, encryption is not active. If you see crypto_LUKS, the partition is encrypted.
The risks of modifying a running root
Some guides suggest using cryptsetup to convert a partition on the fly. This is dangerous on the root filesystem. You are encrypting the partition that contains the kernel, the initramfs, and the bootloader configuration. If the conversion fails halfway, you have an unbootable system. You also need to rebuild the initramfs to include the LUKS hooks. You need to update GRUB to unlock the device. If GRUB cannot read the encrypted device, the system hangs. The risk of data loss is high. The time cost of debugging a broken boot is higher than a clean reinstall.
Fedora uses dracut to build the initial ramdisk. The initramfs contains the drivers and scripts needed to unlock LUKS before the root filesystem mounts. If you encrypt after install, dracut might not include the correct LUKS headers or passphrase handling scripts. The system will drop to an emergency shell. You will see Give root password for maintenance and no way to proceed.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. The bootloader configuration lives in /boot/grub2/. The initramfs lives in /boot/. Both are managed by packages and tools. Manual edits drift and break on updates.
Reboot after every initramfs change. The new kernel needs the new hooks.
The safe path: backup, wipe, reinstall
The fix is a reinstall. This is not a suggestion. This is the only reliable method. The process involves three phases. Backup your data. Boot the installer and enable encryption. Restore your data. Each phase requires care.
Backup your data correctly. A backup you cannot restore is worse than no backup. Use rsync to copy files to an external drive or a different partition. Preserve permissions, ownership, and extended attributes. Exclude virtual filesystems that cannot be backed up.
Here is how to back up your system to an external drive mounted at /mnt/backup.
# Mount the external drive first. Replace /dev/sdX1 with your actual device.
# sudo mount /dev/sdX1 /mnt/backup
# Sync the entire filesystem to the backup location.
# -a preserves permissions, ownership, symlinks, and timestamps.
# -A preserves Access Control Lists.
# -X preserves extended attributes, which SELinux relies on.
# -v shows progress so you know the command is working.
# --exclude skips virtual filesystems that cannot be copied.
rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /mnt/backup/
Verify the backup before you wipe. Check file counts and sizes. Run rsync again with --dry-run to ensure nothing changed.
# Count files in the backup to compare against the source.
# This helps catch silent failures where the destination is empty.
find /mnt/backup -type f | wc -l
# Compare a critical directory to ensure content matches.
diff -rq /etc /mnt/backup/etc
Configure encryption during installation. Boot the Fedora installer from USB. In the installation destination screen, click "Custom" or "I will configure storage" if you need specific mount points. Otherwise, use the automatic layout and check "Encrypt my data". The installer creates a LUKS2 container. LUKS2 is the default format. It supports better key management and integrity protection. Set a strong passphrase. Do not use a simple password. Use a passphrase with high entropy.
Fedora supports automatic unlock using TPM or FIDO2 keys. This reduces the need to type a passphrase on boot. You can bind the LUKS key to the TPM state. If the system boots normally, the TPM releases the key. If the hardware changes, the key is withheld. This is configured via clevis. This is an advanced option. It requires a TPM 2.0 chip. It adds convenience without sacrificing security.
Restore your data after installation. Boot into the new system. Mount the backup. Sync files back. Restore SELinux contexts.
# Sync files back from the backup.
# Use --delete to remove files that existed before but are gone now.
# This ensures the system matches the backup state.
rsync -aAXv --delete /mnt/backup/ /
# Restore SELinux contexts on restored directories.
# Files copied from backup may have wrong labels.
# restorecon relabels files based on the policy.
# -R applies recursively. -v shows changes.
sudo restorecon -Rv /home /etc /var
Check lsblk before you trust. Visual confirmation beats hope.
Verify your encryption setup
After installation, verify that encryption is active and functioning. Check the block device layout. Check the LUKS status. Check the bootloader prompt.
Here is how to verify the encryption layer is present and mapped.
# Show block devices with filesystem types.
# Look for crypto_LUKS on the partition.
# The mapper device should show the filesystem type.
lsblk -f
# Check the status of the LUKS mapping.
# Replace fedora_crypt with your actual mapper name.
# This shows the cipher, key size, and device size.
cryptsetup status /dev/mapper/fedora_crypt
The output of lsblk -f should show a partition with crypto_LUKS. The mapper device should show ext4 or xfs. If you see ext4 directly on the partition, encryption is not active. The output of cryptsetup status should show the active mapping. If this fails, the device is not unlocked or mapped.
Run journalctl -xe to check for errors. The x flag adds explanatory text. The e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Look for LUKS or dm-crypt errors.
Run journalctl first. Read the actual error before guessing.
Common pitfalls and error messages
Encryption setups can fail in subtle ways. GRUB might not prompt. The initramfs might miss modules. The passphrase might be rejected.
If GRUB does not prompt for a password, check Secure Boot. Fedora supports Secure Boot with LUKS, but custom kernels or third-party drivers can break the chain. If you see Failed to load driver, the initramfs is missing the LUKS module. Rebuild the initramfs.
# Rebuild the initramfs for the running kernel.
# --force overwrites the existing image.
# This ensures all hooks and modules are included.
sudo dracut --force
If the system boots but the disk is not encrypted, you missed the checkbox. Run lsblk -f. If you see ext4 directly on the partition, encryption is not active.
If you see [FAILED] Failed to start Cryptography Setup for ... during boot, your LUKS header might be corrupted or the passphrase is wrong. The boot process will drop to an emergency shell. You can try unlocking manually from the shell. If the header is corrupted, you need to restore from backup.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Encryption does not conflict with SELinux. If you see denials after restoring files, run restorecon as shown above.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use full disk encryption vs alternatives
Encryption strategies depend on your threat model and workflow. Choose the method that matches your needs.
Use full disk encryption when you need protection against physical theft and unauthorized access to the entire system. Use LUKS on a separate data partition when you already have an unencrypted system and only need to protect sensitive files without reinstalling. Use file-level encryption tools like gpg or age when you need to encrypt individual files or streams for transfer. Use end-to-end encrypted cloud sync when you need access across devices and trust the sync provider with ciphertext but not plaintext. Stay on an unencrypted system only when the device is in a controlled environment and never leaves your physical possession.
Snapshot the system before the upgrade. Future-you will thank you.