The scenario
You just downloaded the Fedora Workstation ISO and burned it to a USB drive. The laptop you are installing it on contains years of personal documents, or you are setting up a new machine that will travel to coffee shops and airports. You know plain disk storage is a liability. If the drive drops out of the bag or gets seized at a border, the data is readable by anyone with a USB adapter. You need full disk encryption, but the installer screen has a dozen options and you want to make sure you are doing it right the first time.
What LUKS actually does under the hood
LUKS stands for Linux Unified Key Setup. It is not a filesystem. It is a block device mapping layer that sits between the raw disk and whatever filesystem you choose. Think of it as a secure vault door bolted onto your hard drive. The installer writes a LUKS header to the beginning of the partition. That header contains the cryptographic metadata, the key slots, and the cipher configuration. When you type your passphrase at boot, the kernel uses cryptsetup to unlock the header, derive the master key, and create a decrypted block device at /dev/mapper/fedora-root. The filesystem then mounts on top of that decrypted device.
Fedora defaults to LUKS2. LUKS2 supports larger headers, multiple key slots with different key types, and better support for modern ciphers like AES-XTS and Argon2 for key derivation. The installer handles all the heavy lifting. You do not need to run manual cryptsetup commands during a standard desktop installation. The Anaconda installer partitions the disk, formats the LUKS container, and configures the initramfs to prompt for the passphrase before mounting the root filesystem.
Convention aside: Always back up the LUKS header after installation. The header contains everything needed to decrypt the drive. If the first few megabytes of the disk get corrupted, the data is unrecoverable without a header backup. Fedora does not automate this step for you. Run the backup command immediately after your first successful boot.
Enabling encryption during installation
The process happens entirely within the graphical installer. You do not need to drop to a terminal or use the advanced partitioning screen unless you are building a custom layout.
Boot the Fedora installation media and wait for the desktop environment to load. Double-click the installation icon on the desktop. The installer will detect your hardware and present the main configuration dashboard. Click the Installation Destination tile. You will see a list of detected storage devices. Select the drive you want to install to. The installer will automatically propose a standard partition layout with /boot, /boot/efi, and / (root).
Look for the Encrypt checkbox near the bottom of the destination screen. Check it. A passphrase prompt will appear immediately. Enter a strong passphrase. Type it again to confirm. Click Done. The installer will now mark the root partition for LUKS encryption. If you are using a laptop with a separate home partition, you can choose to encrypt that as well, but encrypting the root partition is the baseline requirement for full disk protection.
Click Begin Installation. The installer will format the partitions, create the LUKS containers, and write the filesystems. This step takes longer than an unencrypted install because the disk must be securely formatted and the cryptographic structures initialized. Once the progress bar finishes, click Reboot. Remove the installation media when prompted. The system will restart and immediately present a black screen with a text prompt asking for your passphrase. Type it carefully and press Enter. The boot process will continue normally.
Convention aside: The initramfs image contains the cryptsetup binary and the necessary kernel modules. If you ever rebuild the initramfs manually, the system will automatically regenerate the LUKS unlock scripts. You do not need to manually edit dracut configuration files for standard desktop setups. Trust the package manager to handle initramfs rebuilds after kernel updates.
Verifying the encrypted volume
After the first boot completes, you should verify that the disk is actually encrypted and that the system is reading from the decrypted mapper device. Open a terminal and run the following command to inspect the block device layout.
Here is how to check whether the root filesystem is sitting on top of a LUKS mapper device.
lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT,SIZE # WHY: Shows the block device tree, filesystem types, and mount points in one view
grep -E "crypt|mapper" /proc/mounts # WHY: Confirms the kernel is mounting a decrypted cryptographic device
You will see an entry like nvme0n1p3 with TYPE=part and FSTYPE=crypto_LUKS. Below it, you will see fedora-root or luks-<uuid> with TYPE=crypt and FSTYPE=xfs (or btrfs depending on your edition). The mount point will be /. This confirms the chain is correct. The raw partition is encrypted, the mapper device is decrypted, and the filesystem is mounted.
You can also inspect the LUKS header directly to verify the version and cipher. This is useful if you ever need to document the encryption parameters for compliance or recovery.
Here is how to read the LUKS metadata without unlocking the drive.
sudo cryptsetup luksDump /dev/nvme0n1p3 | head -20 # WHY: Dumps the LUKS header metadata to verify version, cipher, and key slots
Look for LUKS version: 2 and Cipher name: aes-xts-plain64. These are the Fedora defaults. The output will also show Keyslots: 1, meaning one passphrase is registered. You can add more key slots later if you need to share access or add a hardware token.
Check the boot logs to ensure the unlock service completed without warnings. The system records every successful and failed unlock attempt in the journal.
Here is how to review the cryptsetup boot logs for errors or warnings.
journalctl -xeu systemd-cryptsetup@fedora\x2droot.service # WHY: Filters the journal for the specific LUKS unlock unit and shows explanatory text
Run journalctl first. Read the actual error before guessing.
Managing keys and troubleshooting
Encryption adds a single point of failure: the passphrase. If you forget it, the data is gone. There is no backdoor. Microsoft account recovery does not apply here. The kernel will not guess your password. If you mistype the passphrase three times, the boot process will drop you into an emergency shell. You can retry by typing ctrl+D or exit. Do not panic. The system is waiting for the correct key.
Another common issue is header corruption. SSDs occasionally remap bad blocks, and a power loss during a write can damage the first megabyte of the disk. If the system fails to unlock the drive and prints Device /dev/nvme0n1p3 is not a valid LUKS device, the header is likely damaged. You will need a live USB and a header backup to recover.
Here is how to restore a corrupted LUKS header from a backup file.
sudo cryptsetup luksHeaderRestore /dev/nvme0n1p3 --header-backup-file /path/to/luks-header-backup.img # WHY: Overwrites the damaged header with a known-good copy to restore decryption capability
Always keep the header backup on a separate physical drive or encrypted USB stick. Storing it on the same disk defeats the purpose. Run sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file ~/luks-header-backup.img immediately after installation and store it safely.
You might also want to add a secondary key slot for convenience or hardware token integration. LUKS2 supports up to 32 key slots. Adding a second passphrase is straightforward and does not affect the existing master key.
Here is how to add a new passphrase to an existing LUKS container.
sudo cryptsetup luksAddKey /dev/nvme0n1p3 # WHY: Prompts for an existing passphrase, then asks for a new one to register in a fresh slot
You will be asked to type the current passphrase first. This proves you have authorized access. Then you will type the new passphrase twice. The command will return silently on success. Verify the new slot appeared by running cryptsetup luksDump again. You will see Keyslots: 2.
Convention aside: SELinux does not interfere with LUKS. The encryption happens at the block layer, before the filesystem is mounted and before SELinux policies are applied. You can enable strict SELinux enforcement alongside full disk encryption without conflict. Edit /etc/ configuration files for your services, never /usr/lib/. The package manager controls the latter.
Snapshot the system before the upgrade. Future-you will thank you.
When to use LUKS versus alternatives
Use LUKS when you need transparent, kernel-level encryption for a laptop or desktop that travels or stores sensitive personal data. Use file-level encryption like gpg or age when you only need to protect specific documents and want to share them across different operating systems. Use cloud provider disk encryption when you are running a virtual machine and the hypervisor already handles volume encryption at the infrastructure level. Skip encryption entirely when you are deploying a headless server in a physically secured data center where disk theft is not a threat model. Trust the package manager for updates, but trust your passphrase for access.