You checked the box, but do you know what it did?
You installed Fedora on a laptop and checked the "Encrypt my data" box because every security guide says you should. Now you are sitting at the boot prompt typing a passphrase, and you wonder if you just slowed down your system or if this is actually protecting your files. Or maybe you installed Fedora six months ago without encryption, and now you are traveling with sensitive work documents. You need to understand how LUKS works, how to verify the encryption is active, and how to add a keyfile so you stop typing the same password twice during boot.
What's actually happening
LUKS stands for Linux Unified Key Setup. It is a disk encryption standard that encrypts the entire block device. When you enable encryption, Fedora creates a LUKS container on your partition. Inside that container, the installer places your volume group and logical volumes, or your Btrfs subvolumes. The encryption happens at the block layer. The filesystem never sees unencrypted data.
Think of LUKS as a heavy steel safe. The disk is the safe. The passphrase is the combination. When you boot, systemd asks for the combination. Once unlocked, the operating system sees a normal block device and mounts the filesystem. If someone removes the drive while the computer is off and connects it to another machine, they cannot read anything. The drive looks like random static. There is no filesystem, no files, no metadata. Just entropy.
Fedora uses LUKS2 by default. LUKS2 improves key management, supports multiple key types natively, and offers better performance with modern algorithms. You do not need to configure LUKS2 manually. Anaconda handles this automatically. If you encrypt a drive manually later, always specify the LUKS2 type to get the modern header format.
Run lsblk first. If the mapper device is missing, the encryption layer failed to unlock.
Enabling encryption during installation
The safest time to enable encryption is during installation. Anaconda partitions the disk, creates the LUKS header, and sets up the volume manager inside the encrypted container. This avoids the risk of misaligning partitions or corrupting headers.
Boot the Fedora installation media and start the installer. Navigate to Installation Destination and select your target disk. Under Storage Configuration, choose Custom or Automatic. Both options support encryption. Check the box labeled Encrypt my data. Set a strong passphrase when prompted. This passphrase is required at every boot. Complete the rest of the installation normally.
Anaconda creates a LUKS2 container on the selected partition. It then initializes LVM or Btrfs inside the unlocked mapper device. The boot partition remains unencrypted by default to ensure GRUB can load the kernel without complex configuration. This is a standard trade-off. The kernel and initramfs are small and rarely contain sensitive user data. The root volume, home directory, and swap are fully encrypted.
Trust the installer. Manual partitioning errors can leave you with an unbootable system.
Adding a keyfile to avoid double prompts
Systemd may ask for the passphrase twice during early boot. This happens when you have two encrypted volumes that require the same passphrase, such as an encrypted root volume and an encrypted swap or resume volume. The keyfile trick solves this by storing a copy of the key inside the initramfs. When the root volume unlocks, the initramfs loads and uses the keyfile to unlock the second volume automatically. You type the passphrase once, and the rest happens in the background.
Here's how to generate a keyfile and add it to your LUKS volume.
# Generate a random keyfile. 512 bytes is sufficient for LUKS2 security.
sudo dd if=/dev/urandom of=/etc/luks-keyfile bs=512 count=8
# Restrict permissions. Only root can read this file.
# If other users can read the keyfile, encryption is useless.
sudo chmod 400 /etc/luks-keyfile
# Add the keyfile as a second key to the LUKS header.
# You will be asked for your existing passphrase to authorize this operation.
# This creates a new keyslot that accepts the keyfile.
sudo cryptsetup luksAddKey /dev/mapper/fedora_luks /etc/luks-keyfile
The keyfile must be referenced in /etc/crypttab so systemd knows to use it. The entry tells systemd to unlock the device using the keyfile stored in the initramfs.
Here's the crypttab entry format. Replace the UUID with your actual device UUID.
# /etc/crypttab entry.
# Format: name device keyfile options
# The name matches the device mapper name you want to create.
# The device is the LUKS partition. Always use UUID, never /dev/sdX.
# The keyfile path points to the file inside the initramfs.
# The luks option tells systemd to use LUKS.
fedora_luks UUID=your-uuid-here /etc/luks-keyfile luks
After editing /etc/crypttab, you must rebuild the initramfs. The keyfile lives on the root filesystem. The initramfs is a compressed cpio archive that loads before the root filesystem mounts. If you do not rebuild the initramfs, the keyfile is not available during early boot, and systemd will still prompt for the passphrase.
Here's how to rebuild the initramfs and verify the keyfile is included.
# Rebuild the initramfs to include the keyfile.
# Without this step, the keyfile stays on the root filesystem
# and cannot be read before the root filesystem is mounted.
sudo dracut --force
# Verify the keyfile is present in the new initramfs.
# If the file is missing, dracut failed to copy it.
lsinitrd | grep luks-keyfile
Reboot before you debug. If the keyfile is missing from initramfs, you will drop to an emergency shell.
Encrypting a secondary disk after installation
You can encrypt additional drives after installation. This is useful for external drives or secondary internal disks that store sensitive data. The process involves formatting the device with LUKS, opening the volume, and creating a filesystem inside the unlocked mapper device.
Here's how to encrypt a secondary disk. Verify the device path carefully. This command destroys all data on the target device.
# WARNING: This command destroys all data on /dev/sdb.
# Use the correct device path. Verify with lsblk first.
# The --type luks2 flag ensures you get the modern header format.
sudo cryptsetup luksFormat --type luks2 /dev/sdb
# Open the encrypted volume and give it a mapper name.
# You will be prompted for the passphrase.
sudo cryptsetup open /dev/sdb my_data
# Create a filesystem inside the unlocked mapper device.
# The filesystem lives inside the LUKS container.
sudo mkfs.ext4 /dev/mapper/my_data
To mount the drive automatically on boot, add entries to /etc/crypttab and /etc/fstab. Use UUIDs for both files. Device names like /dev/sdb change when you add USB drives. UUIDs are stable.
Use blkid to find the UUID of the LUKS device and the filesystem. The UUID in /etc/crypttab is the LUKS UUID. The UUID in /etc/fstab is the filesystem UUID inside the mapper device.
Trust the UUID. Device names lie.
Verifying your setup
After installation or configuration changes, verify that encryption is active and configured correctly. The cryptsetup luksDump command shows the LUKS header details, including the version, cipher, and active key slots. The lsblk command shows the device mapper tree and mount points.
Here's how to check the LUKS header and verify key slots.
# Check the LUKS header to see key slots and version.
# Look for 'Keyslots' to confirm multiple keys exist.
# If you added a keyfile, you should see two active slots.
sudo cryptsetup luksDump /dev/nvme0n1p2 | grep -A 5 Keyslots
# Verify the device mapper node is active and mapped correctly.
# The FSTYPE column should show crypto_LUKS for the partition
# and ext4 or btrfs for the mapper device.
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT
If you see crypto_LUKS in the FSTYPE column for the partition, encryption is active. If the mapper device is mounted, the volume is unlocked. If the mapper device is missing, the encryption layer failed to unlock. Check journalctl -xe for errors. SELinux denials can sometimes block access to keyfiles. Read the setroubleshoot messages in the journal before disabling SELinux.
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls
You lose the passphrase. LUKS supports multiple keys. You can add a keyfile as a backup. If you lose all keys, the data is unrecoverable. There is no backdoor. The encryption is mathematically secure. Store your passphrase in a password manager or write it down and keep it in a safe place.
Device names change. /dev/sda can become /dev/sdb when you plug in a USB drive. Always use UUIDs in /etc/crypttab and /etc/fstab. Use blkid to find the UUID. If you clone a disk, the UUID changes. You must update the configuration files. If you do not, the system will fail to mount the drive.
Performance overhead is minimal on modern hardware. CPUs with AES-NI hardware acceleration handle encryption and decryption with negligible impact. You will not notice a slowdown in daily use. Benchmarks show less than 5% overhead on encrypted volumes compared to unencrypted ones.
Error messages appear when configuration is wrong. Error: Device /dev/sda2 is not a valid LUKS device. means you are trying to open a partition that was not formatted with LUKS. Check the partition type. Failed to unlock /dev/mapper/... in the journal means the passphrase was wrong or the keyfile is missing. Check the UUID in /etc/crypttab. Check the permissions on the keyfile.
Snapshot the system before the upgrade. Future-you will thank you.
When to use encryption
Use LUKS encryption when the device can be physically stolen, such as a laptop or external drive. Use unencrypted storage when performance is the absolute priority and the device never leaves a secure data center. Use a keyfile in initramfs when you have a separate swap or resume volume that requires the same passphrase and you want to avoid typing twice. Use a separate passphrase for the keyfile when you want the convenience of a keyfile but the security of a human-memorized password for the primary unlock. Stay on the default installer settings if you are unsure. The installer creates a secure configuration that works for 99% of users.