How to Install Fedora 42 with Full Disk Encryption, Snapshot, and Rollback Support

Fedora Linux 42 is here!

Fedora Workstation 42 debuts with GNOME 48, featuring a refreshed interface, smarter notifications, and smoother animations thanks to triple buffering. The new Anaconda Web UI installer makes setting up Fedora more intuitive than ever, and behind the scenes, performance continues to improve across the board.

This time around, I’m stepping things up.

With Fedora 42, I’ve rethought the setup process from the ground up. Drawing from the simplified method I used in my Arch Linux with Snapshots & Rollback series, this approach trims down complexity while still delivering a stable and reliable system. It’s faster to set up, easier to manage, and works great whether you’re new to Fedora or a seasoned user.

In my previous Fedora 42 guide, I showed how to enable Btrfs snapshots and rollback support using a streamlined method that favored simplicity and speed. It was ideal for users who wanted rollback functionality without dealing with encryption.

If that sounds like what you need, check out this version of the guide without LUKS encryption.

But what if you want all that—plus full disk encryption?

In this updated guide, I’ll walk you through how to install Fedora 42 with full disk encryption, snapshot, and rollback support using Btrfs. You’ll get the best of both worlds: a secure system that’s also easy to restore when things go sideways.

Let’s lock it down, back it up, and roll it back when needed. A smarter, safer Fedora system starts here.

Table of Contents

• 1. Partitions and Subvolumes Layout
• 2. Install Fedora Workstation 42
• 3. Post-Installation Configuration
• 4. Prepare Home for Snapshots and Rollbacks
• 5. Bypass the Additional Passphrase Prompt
  • 5.1 Using a Key File
  • 5.2 Using TPM2
• 6. Set Up Snapper, grub-btrfs, and Btrfs Assistant
• 7. Enable Automatic Timeline Snapshots
• 8. Conclusion
• 9. Watch on YouTube

1. Partitions and Subvolumes Layout

In this setup, I’m installing Fedora 42 on a 128 GiB disk with full LUKS encryption, along with Btrfs snapshots and rollback support. The goal is a secure, efficient system that stays simple to manage—and can easily roll back changes after kernel updates or system configuration tweaks.

This is how the disk partition looks:

NAME         SIZE  FSTYPE        PARTTYPENAMEPARTTYPENAME      MOUNTPOINT
/dev/vda     128G    
├─/dev/vda1    1G  vfat          EFI System        /boot/efi
└─/dev/vda2  127G  btrfs (LUKS)  Linux filesystem  /

• No separate /boot partition: The kernel and initramfs will reside inside the Btrfs root, so when a rollback occurs, the kernel is also rolled back—avoiding mismatches and boot issues.
• No swap partition: Fedora automatically enables SwapOnZRAM at boot, so no separate swap partition is required.

Here are the Btrfs subvolumes I'll create inside the second partition (/dev/vda2), along with their mount points and purposes:

• root → /
  The root filesystem, where Fedora is installed. This is the main subvolume and will be snapshot-enabled.
• home → /home
  User data and configuration files. This subvolume will also be snapshot-enabled, which is why .mozilla is separated below.
• opt → /opt
  Isolates optional or third-party software installations.
• cache → /var/cache
  Avoids bloating system snapshots with package caches.
• gdm → /var/lib/gdm
  Required for GNOME (Workstation Edition). Without this, read-only snapshots may cause login issues.
• libvirt → /var/lib/libvirt
  Isolates virtual machine data (useful if you use KVM/QEMU/libvirt).
• log → /var/log
  Prevents constantly changing log files from filling up snapshot space.
• spool → /var/spool
  Separates queued print jobs or mail data from root.
• tmp → /var/tmp
  Keeps temporary files out of snapshots.
• .mozilla → /home/$USER/.mozilla
  Keeps Firefox data out of /home snapshots, improving rollback speed and stability.

This layout ensures that snapshots stay clean, manageable, and efficient. It also separates volatile or large data directories so they don't interfere with the rollback process.

Optional subvolumes (not created):

• crash → /var/crash
  Only needed if kdump is enabled and you plan to analyze kernel crash dumps.
• www → /var/www
  Useful for isolating web server data, if you're running a website or self-hosted services.
• google-chrome → /home/$USER/.config/google-chrome
  Separating this can keep browser cache and settings out of /home snapshots for cleaner rollbacks.
• BraveSoftware → /home/$USER/.config/BraveSoftware
  Same as above—helps reduce snapshot size and keeps session data isolated.
• .gnupg → /home/$USER/.gnupg
  Useful if you want to exclude GPG keys and trust settings from being affected by rollbacks.
• .ssh → /home/$USER/.ssh
  Keeps your SSH keys and configurations stable and unaffected by snapshot restores.
• .thunderbird → /home/$USER/.thunderbird
  Helps preserve mail client data and cache separately from /home snapshots.

2. Install Fedora Workstation 42

Boot your system using the Fedora 42 Workstation Live installer in UEFI mode.

When the "Welcome to Fedora" window appears, click "Not Now" to skip the initial setup and return to the GNOME desktop.

By default, the Anaconda Web UI installer does not support encrypting the /boot partition, which is required for full LUKS encryption. To enable this feature, we’ll modify two internal configuration files used by the installer and storage stack.

Open the Terminal—you’ll need to make a couple of quick changes to enable full disk encryption.

First, switch to superuser (root) mode:

$ sudo -i

Then, run the following command to enable encryption support:

# sed -i.bkp 's/encryption_support = False/encryption_support = True/' \
    /usr/lib64/python3.*/site-packages/pyanaconda/modules/storage/bootloader/base.py

This change enables the option to encrypt /boot during installation, allowing for full disk encryption.

With /boot encryption support enabled, proceed to launch the Anaconda Web UI installer. Leave the terminal window open for now, as we’ll return to it once the installation is finished.

The redesigned Anaconda Web UI will now appear, offering a more modern and streamlined installation experience. As of now, this web-based interface is only available in Fedora Workstation 42.

On the Welcome screen, choose your preferred language and keyboard layout, then click Next.

On the Installation Method screen, configure how Fedora should be installed — including disk selection and partition layout.

Ensure that the correct installation disk is selected under the Destination section. For example, in this guide, the target disk is vda (/dev/vda). If it is not already selected, click the Change Destination link and choose the appropriate disk.

Since this guide uses a custom disk layout, do not use the default “Use entire disk” option. Click the three-dot menu (⋮) at the top-right corner and select Launch Storage Editor.

A warning will appear indicating that the Storage Editor is an advanced tool and that changes take effect immediately.

Click Launch storage editor to proceed.

In the Storage Editor, begin by creating a new partition table.

⚠️ Warning: This will erase all existing partitions on the selected disk. If you are dual-booting or have existing data, do not proceed with this step.

Since this example uses a blank disk, proceed by clicking the three-dot menu (⋮) and choosing Create partition tab

Click Initialize to confirm.

Now you need to create the required partitions. Click the three-dot menu (⋮) next to the free space and select Create partition.

Create the EFI System Partition (ESP)

• Name: ESP (or any preferred name)
• Mount Point: /boot/efi
• Type: EFI System Partition
• Size: 1 GiB

Click Create to finalize.

Create the Btrfs Partition. Again, click the three-dot menu (⋮) next to the remaining free space and choose Create partition.

• Name: FEDORA (or any name of your choice)
• Mount Point: (Leave empty)
• Type: BTRFS
• Size: Use the remaining available space
• Encryption: LUKS2
• Passphrase: Set a stronger passphrase with higher entropy (password entropy > 60 bits is suggested).

Click Create to continue.

Once the Btrfs volume has been created, begin adding subvolumes as needed.

Click the three-dot menu (⋮) on the line labeled top-level (btrfs subvolume) and select Create subvolume.

Create root subvolume:

• Name: root
• Mount Point: /

Create home subvolume:

Repeat the process:

• Name: home
• Mount Point: /home

Continue creating the remaining subvolumes. Here's a list of the remaining subvolumes you need to create, along with their names and mount points.

NAME       MOUNT POINT
opt        /opt
cache      /var/cache
gdm        /var/lib/gdm
libvirt    /var/lib/libvirt
log        /var/log
spool      /var/spool
tmp        /var/tmp

After creating all the subvolumes, the layout should appear as shown.

Next, click the Return to installation button.

The process may take some time, so please be patient. If everything is set up correctly, the setup screen will display a green check mark, indicating a valid storage layout.

Click Continue to proceed.

Click Next, review your installation summary, and finally click the Install button. The Fedora Workstation 42 installation will now begin.

Once the installation is complete, click the 'Exit to Live Desktop' button. Please do not reboot just yet. Return to the terminal window to complete some post-setup steps.

By default, the GRUB bootloader supports devices encrypted using the PBKDF2 key derivation function only. However, because I chose LUKS2 in the installer, it defaults to Argon2id. Since GRUB does not support Argon2id, we need to change the key derivation function to PBKDF2.

I chose LUKS2 with PBKDF2 over LUKS1 with PBKDF2, even though GRUB and most distro installers primarily support LUKS1. LUKS2 offers a more modern and flexible encryption framework, with better support for future cryptographic advancements. It provides enhanced metadata handling, larger key size options, and improved recovery features. While both LUKS1 and LUKS2 with PBKDF2 use the same key derivation function, LUKS2 ensures a more secure and extensible architecture, making it a better long-term choice for disk encryption. Even though GRUB does not yet support newer KDFs like Argon2id, LUKS2’s design allows for future improvements without sacrificing backward compatibility.

Your current installation is located at /mnt/sysroot.

First, find your LUKS device and save it in a variable. For me, it is /dev/vda2. Yours will be different.

# LUKS_DEVICE="$(cryptsetup status \
    $(grub2-probe --target=device /mnt/sysroot) \
    | grep 'device:' | awk '{print $2}')" \
    ; echo $LUKS_DEVICE

Now, check the current PBKDF being used by your LUKS device:

# cryptsetup luksDump $LUKS_DEVICE | grep -A7 '0: luks2'
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  4
	Memory:     500525

You should see argon2id in the output. We need to change this to pbkdf2.

Run the following command to change the PBKDF to pbkdf2. For PBKDF2, the minimum iteration count is 1000, and the maximum is 4294967295. The more powerful your CPU, the higher the number of iterations you can set. Be mindful that higher iteration counts will result in a longer unlock time during boot.

In this example, I will set the iteration count to 500,000, but you can adjust this value based on your system’s capabilities.

# cryptsetup luksChangeKey ${LUKS_DEVICE} \
    --pbkdf pbkdf2 \
    --pbkdf-force-iterations 500000

You will be prompted for your passphrase three times. The first time will authenticate, and the next two times will set the new passphrase (don’t change it; just use the same passphrase as before).

After the PBKDF has been updated, check again to confirm the change was successful.

# cryptsetup luksDump $LUKS_DEVICE | grep -A7 '0: luks2'
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      pbkdf2
	Hash:       sha256
	Iterations: 500000

You should now see pbkdf2 as the key derivation function, with the iteration count set to 500000.

Next, you need to enable Crypto Disk and Cryptomount. To enable full disk encryption at boot, we need to configure GRUB to load the necessary modules and properly handle the LUKS encryption.

Get the LUKS UUID:

# LUKS_UUID="$(cryptsetup luksUUID ${LUKS_DEVICE})" ; echo $LUKS_UUID

Add the cryptomount command to the GRUB configuration:

# sed -i.bkp "1i cryptomount -u ${LUKS_UUID//-/}" \
    /mnt/sysroot/boot/efi/EFI/fedora/grub.cfg

Enable the required GRUB modules by editing the GRUB configuration file:

# echo 'GRUB_PRELOAD_MODULES="cryptodisk luks"' >> /mnt/sysroot/etc/default/grub

Ensure that cryptodisk is enabled for GRUB:

# echo 'GRUB_ENABLE_CRYPTODISK=y' >> /mnt/sysroot/etc/default/grub

Finally, regenerate the GRUB configuration to apply these changes:

# chroot /mnt/sysroot grub2-mkconfig -o /boot/grub2/grub.cfg

Now that everything is set up, you can reboot your system:

# reboot

Upon reboot, you’ll be prompted for your passphrase twice:

• The first prompt is before GRUB loads.
• The second prompt is before mounting the root filesystem.

Please be patient as the GRUB menu may take up to 15 seconds to appear, depending on your CPU.

Note: When entering the passphrase at the first prompt, there will be no '*' characters displayed. This is normal—just enter your passphrase correctly and press [Enter].

After entering your passphrase correctly, the installation process will continue. You’ll be prompted to set up your username, password, and other preferences.

Once this final step is completed, you'll be logged into Fedora Workstation 42 with the all-new GNOME 48 desktop environment.

3. Post-Installation Configuration

When you boot into Fedora, you might see the following message:

error: ../../grub-core/commands/loadenv.c:216:sparse file not allowed.

This usually happens when the /boot directory is part of a Btrfs subvolume instead of a separate ext4 partition. GRUB tries to read from or write to /boot/grub2/grubenv during boot to store settings like the last-selected kernel, but its Btrfs module is read-only and can’t write to the file—hence the error.

This message is harmless and doesn’t affect Fedora’s performance or stability. Your system will boot and function normally. The only downside is GRUB won’t remember your last boot option, and Fedora’s Hidden GRUB Menu feature may not work as intended.

The grubenv file controls whether the GRUB menu is shown. Normally, Fedora hides the menu unless the last boot failed or you're dual-booting. But if GRUB can’t update grubenv, it can’t show or hide the menu properly.

Since we’re setting up Fedora for snapshot and rollback, we want the GRUB menu to always appear anyway so we can boot from snapshots if needed. So we’ll be disabling Fedora’s Hidden GRUB Menu feature anyway, which means this issue doesn’t really affect us much.

While the error shows up every time you boot and can be a bit annoying, it’s purely visual and has no impact on the system.

To make sure the GRUB menu is always visible, run this command in the terminal:

$ sudo grub2-editenv - unset menu_auto_hide

Check your Btrfs filesystem details:

$ sudo btrfs filesystem show /
Label: 'FEDORA'  uuid: e2adcde7-5739-4c37-beaf-0030cf25c5b5
	Total devices 1 FS bytes used 6.54GiB
	devid    1 size 127.05GiB used 10.02GiB path /dev/mapper/luks-17378d24-d4f9-4877-953a-f2126b17bce4

Your setup should look something like this:

$ lsblk -p /dev/vda
NAME                                                      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
/dev/vda                                                  253:0    0   128G  0 disk  
├─/dev/vda1                                               253:1    0   954M  0 part  /boot/efi
└─/dev/vda2                                               253:2    0 127.1G  0 part  
  └─/dev/mapper/luks-17378d24-d4f9-4877-953a-f2126b17bce4 252:0    0   127G  0 crypt /var/log
                                                                                     /var/spool
                                                                                     /var/tmp
                                                                                     /var/lib/gdm
                                                                                     /var/lib/libvirt
                                                                                     /var/cache
                                                                                     /home
                                                                                     /opt
                                                                                     /

The subvolumes will now appear as follows:

$ sudo btrfs subvolume list /
ID 256 gen 59 top level 5 path root
ID 257 gen 60 top level 5 path home
ID 258 gen 21 top level 5 path opt
ID 259 gen 55 top level 5 path cache
ID 260 gen 51 top level 5 path gdm
ID 261 gen 48 top level 5 path libvirt
ID 262 gen 60 top level 5 path log
ID 263 gen 48 top level 5 path spool
ID 264 gen 58 top level 5 path tmp
ID 265 gen 48 top level 256 path var/lib/machines

The last subvolume, var/lib/machines, is automatically created and used by systemd for managing lightweight containers through systemd-nspawn or portable services. Even if you're not using these features now, having a separate subvolume here allows better separation of system state and makes future containerization easier to manage.

Now, update your system:

$ sudo dnf update

Then, reboot to apply the updates:

$ sudo reboot

4. Prepare Home for Snapshots and Rollbacks

To ensure important user data is preserved when rolling back Snapper snapshots of the home subvolume, it's a good idea to separate certain application directories into their own subvolumes. This way, they remain unaffected by Snapper's undochange or rollback operations.

So, I’ll create a separate Btrfs subvolume for the Firefox configuration directory /home/$USER/.mozilla to prevent its data from being affected when rolling back or undoing snapshots of the home subvolume.

Since the /home/$USER/.mozilla directory already exists, I can't directly create a subvolume with the same name. So I'll first rename the existing directory, create the subvolume, then copy the contents back to ensure everything remains intact.

Run the following commands to move the existing .mozilla data, create the subvolume, and restore everything safely:

$ mv -v ~/.mozilla/ ~/.mozilla-old
$ sudo btrfs subvolume create ~/.mozilla
$ sudo chown -cR $USER:$USER ~/$(ls -A)
$ cp -arv ~/.mozilla-old/. ~/.mozilla/
$ rm -rfv ~/.mozilla-old/
$ sudo restorecon -vRF ~/$(ls -A)

A separate subvolume for the .mozilla directory has been created.

$ sudo btrfs subvolume list /
ID 256 gen 101 top level 5 path root
ID 257 gen 101 top level 5 path home
ID 258 gen 85 top level 5 path opt
ID 259 gen 96 top level 5 path cache
ID 260 gen 97 top level 5 path gdm
ID 261 gen 96 top level 5 path libvirt
ID 262 gen 101 top level 5 path log
ID 263 gen 96 top level 5 path spool
ID 264 gen 101 top level 5 path tmp
ID 265 gen 96 top level 256 path var/lib/machines
ID 266 gen 101 top level 257 path home/madhu/.mozilla

Now your Firefox data is isolated from Snapper snapshots of the home directory. Later in the guide, I’ll set up Snapper configs for both root and home to take full advantage of snapshot and rollback

5. Bypass the Additional Passphrase Prompt

When using full disk encryption, GRUB unlocks the /boot partition by prompting for a passphrase. However, this decryption isn’t passed to the initramfs stage, so the root (/) partition must be unlocked again — requiring the user to enter the passphrase twice.

To streamline the boot process, you can configure automatic unlocking using either a key file or TPM2. This section outlines both methods so you can choose the one that best suits your setup.

5.1 Using a Key File

If you’d like to unlock your LUKS-encrypted volume using a key file, follow this method. Secure Boot is not required.

Switch to the superuser:

$ sudo -i

Get the UUID of your LUKS device:

# LUKS_UUID="$(grub2-probe --target=cryptodisk_uuid /)" ; echo $LUKS_UUID
17378d24-d4f9-4877-953a-f2126b17bce4

Create the key file directory if it doesn’t exist:

# mkdir -v /etc/cryptsetup-keys.d

Generate a 4KiB random key file:

# dd if=/dev/random \
  of=/etc/cryptsetup-keys.d/luks-${LUKS_UUID}.key \
  bs=512 count=8

Restrict the key file’s permissions:

# chmod -c 0400 /etc/cryptsetup-keys.d/luks-${LUKS_UUID}.key

Add the key to an available LUKS key slot:

# cryptsetup luksAddKey \
   --pbkdf pbkdf2 \
   --pbkdf-force-iterations 500000 \
   /dev/disk/by-uuid/${LUKS_UUID} \
   /etc/cryptsetup-keys.d/luks-${LUKS_UUID}.key

Tell dracut to include the key file in the initramfs:

# echo "install_items+=\" /etc/cryptsetup-keys.d/luks-${LUKS_UUID}.key \"" \
 > /etc/dracut.conf.d/cryptodisk.conf

Rebuild the initramfs:

# dracut -vf

Reboot the computer to ensure that everything is working properly:

# reboot

The passphrase should now only be required once, before GRUB.

5.2 Using TPM2

This method leverages your system’s Trusted Platform Module (TPM) to securely unlock the disk. Secure Boot must be enabled.

Switch to the superuser:

$ sudo -i

Verify Secure Boot is active:

# mokutil --sb-state
SecureBoot enabled

Check for TPM support:

# systemd-cryptenroll --tpm2-device=list
PATH        DEVICE      DRIVER 
/dev/tpmrm0 MSFT0101:00 tpm_crb

Save the LUKS UUID to a variable:

# LUKS_UUID="$(grub2-probe --target=cryptodisk_uuid /)" && echo $LUKS_UUID
17378d24-d4f9-4877-953a-f2126b17bce4

Enroll the TPM2 device. When prompted for a passphrase, enter the same LUKS passphrase you set earlier.

# systemd-cryptenroll \
   --wipe-slot=tpm2 \
   --tpm2-device=/dev/tpmrm0 \
   /dev/disk/by-uuid/${LUKS_UUID}

Confirm the TPM key slot:

# systemd-cryptenroll /dev/disk/by-uuid/${LUKS_UUID}
SLOT TYPE    
   0 password
   1 tpm2

Add TPM device info to the kernel boot options:

# grubby --update-kernel=ALL \
 --args="rd.luks.options=tpm2-device=/dev/tpmrm0"

Confirm the boot options were updated:

# grubby --info=DEFAULT
index=0
kernel="/root/boot/vmlinuz-6.14.2-300.fc42.x86_64"
args="ro rootflags=subvol=root rd.luks.uuid=luks-17378d24-d4f9-4877-953a-f2126b17bce4 rhgb quiet $tuned_params rd.luks.options=tpm2-device=/dev/tpmrm0"
root="UUID=e2adcde7-5739-4c37-beaf-0030cf25c5b5"
initrd="/root/boot/initramfs-6.14.2-300.fc42.x86_64.img $tuned_initrd"
title="Fedora Linux (6.14.2-300.fc42.x86_64) 42 (Workstation Edition)"
id="347197e21a7d4bc2b50c1a7675c2a395-6.14.2-300.fc42.x86_64"

Update /etc/crypttab:

# echo "luks-${LUKS_UUID} UUID=${LUKS_UUID} none tpm2-device=/dev/tpmrm0" \
 > /etc/crypttab

Enable TPM module in dracut:

# echo 'add_dracutmodules+=" tpm2-tss "' > /etc/dracut.conf.d/tpm2.conf

Regenerate the GRUB config:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Rebuild initramfs:

# dracut -vf

Reboot:

# reboot

You should now only be prompted once for the LUKS passphrase, before the GRUB menu appears.

6. Set Up Snapper, grub-btrfs, and Btrfs Assistant

To enable robust snapshot and rollback support on Fedora, I’ll install and configure Snapper for managing snapshots, grub-btrfs to integrate snapshots into the GRUB boot menu, and Btrfs Assistant for a simple graphical interface to view and restore snapshots. This setup allows Fedora to automatically create snapshots during package operations, giving you an easy way to undo changes or recover from issues.

Install the necessary packages using DNF:

$ sudo dnf install snapper libdnf5-plugin-actions btrfs-assistant \
    inotify-tools git make

Set Up Automatic Snapshot Creation with DNF. Snapper integrates with DNF through a custom Actions file, which lets you define actions to be run before and after transactions. This is how Snapper creates pre- and post-snapshots automatically during package installs, upgrades, and removals.

Create a new actions file named snapper.actions. Copy everything from sudo to EOF, paste it into your terminal, and press [Enter] to create the file.

$ sudo bash -c "cat > /etc/dnf/libdnf5-plugins/actions.d/snapper.actions" <<'EOF'
# Get snapshot description
pre_transaction::::/usr/bin/sh -c echo\ "tmp.cmd=$(ps\ -o\ command\ --no-headers\ -p\ '${pid}')"

# Creates pre snapshot before the transaction and stores the snapshot number in the "tmp.snapper_pre_number"  variable.
pre_transaction::::/usr/bin/sh -c echo\ "tmp.snapper_pre_number=$(snapper\ create\ -t\ pre\ -c\ number\ -p\ -d\ '${tmp.cmd}')"

# If the variable "tmp.snapper_pre_number" exists, it creates post snapshot after the transaction and removes the variable "tmp.snapper_pre_number".
post_transaction::::/usr/bin/sh -c [\ -n\ "${tmp.snapper_pre_number}"\ ]\ &&\ snapper\ create\ -t\ post\ --pre-number\ "${tmp.snapper_pre_number}"\ -c\ number\ -d\ "${tmp.cmd}"\ ;\ echo\ tmp.snapper_pre_number\ ;\ echo\ tmp.cmd
EOF

Now create Snapper configurations for the root (/) and home (/home) subvolumes:

$ sudo snapper -c root create-config /
$ sudo snapper -c home create-config /home

Verify the configurations:

$ sudo snapper list-configs
Config │ Subvolume
───────┼──────────
home   │ /home
root   │ /

Restore the correct SELinux contexts for the .snapshots directories:

$ sudo restorecon -RFv /.snapshots
$ sudo restorecon -RFv /home/.snapshots

Verify SELinux labels:

$ ls -1dZ /.snapshots /home/.snapshots
system_u:object_r:snapperd_data_t:s0 /home/.snapshots
system_u:object_r:snapperd_data_t:s0 /.snapshots

Enable user access to Snapper and synchronize file ACLs:

$ sudo snapper -c root set-config ALLOW_USERS=$USER SYNC_ACL=yes
$ sudo snapper -c home set-config ALLOW_USERS=$USER SYNC_ACL=yes

This allows your user account to list, view, and manage snapshots without requiring root privileges, and ensures file access permissions (ACLs) are properly synchronized.

Your subvolume layout will now include:

$ sudo btrfs subvolume list /
ID 256 gen 152 top level 5 path root
ID 257 gen 152 top level 5 path home
ID 258 gen 85 top level 5 path opt
ID 259 gen 148 top level 5 path cache
ID 260 gen 142 top level 5 path gdm
ID 261 gen 141 top level 5 path libvirt
ID 262 gen 152 top level 5 path log
ID 263 gen 141 top level 5 path spool
ID 264 gen 148 top level 5 path tmp
ID 265 gen 141 top level 256 path var/lib/machines
ID 266 gen 102 top level 257 path home/madhu/.mozilla
ID 267 gen 152 top level 256 path .snapshots
ID 268 gen 152 top level 257 path home/.snapshots

Prevent updatedb from indexing the .snapshots directories. Indexing is enabled by default and can lead to slowdowns and high memory usage when many snapshots are present.

$ echo 'PRUNENAMES = ".snapshots"' | sudo tee -a /etc/updatedb.conf

You can list snapshots as follows:

$ snapper ls                 # For root
$ snapper -c home ls         # For home

At this point, no snapshots exist. They will be created automatically during package operations or manually when you trigger them.

Next, install and configure grub-btrfs.

The grub-btrfs package allows GRUB to detect and list snapshots in the boot menu, enabling you to boot into a snapshot in read-only mode before deciding to roll back.

Clone the repository:

$ git clone https://github.com/Antynea/grub-btrfs
$ cd grub-btrfs

Apply Fedora-specific changes to the configuration file: Copy the entire block from sed to config, paste it into your terminal, and press [Enter] to update the settings.

$ sed -i.bkp \
  -e '/^#GRUB_BTRFS_SNAPSHOT_KERNEL_PARAMETERS=/a \
GRUB_BTRFS_SNAPSHOT_KERNEL_PARAMETERS="rd.live.overlay.overlayfs=1"' \
  -e '/^#GRUB_BTRFS_GRUB_DIRNAME=/a \
GRUB_BTRFS_GRUB_DIRNAME="/boot/grub2"' \
  -e '/^#GRUB_BTRFS_MKCONFIG=/a \
GRUB_BTRFS_MKCONFIG=/usr/bin/grub2-mkconfig' \
  -e '/^#GRUB_BTRFS_SCRIPT_CHECK=/a \
GRUB_BTRFS_SCRIPT_CHECK=grub2-script-check' \
  config

Install it:

$ sudo make install

You might see a "No snapshots found" message initially. This is expected since no snapshots exist yet.

Enable the service:

$ sudo systemctl enable --now grub-btrfsd.service

Your grub-btrfs setup is now finished. You can safely remove the cloned grub-btrfs directory.

$ cd ..
$ rm -rfv grub-btrfs

With that, all the setup and configuration needed to enable snapshot and rollback support on Fedora 42 is now complete. Snapper is ready to manage your system and home snapshots. GRUB will detect snapshots automatically, and you can restore them easily if something goes wrong. Your system is now snapshot ready.

7. Enable Automatic Timeline Snapshots

Now that everything is set up, you can enable automatic timeline snapshots. With this feature enabled, Snapper automatically creates a snapshot every hour. Once a day, the timeline cleanup algorithm removes older snapshots based on your configuration settings.

By default, timeline snapshots are enabled for both the root and home configurations. However, it's recommended to keep it enabled only for the root and disable it for the home volume to avoid excessive snapshot clutter.

$ sudo snapper -c home set-config TIMELINE_CREATE=no
$ sudo systemctl enable --now snapper-timeline.timer
$ sudo systemctl enable --now snapper-cleanup.timer

These timers are configured to create a snapshot every hour and clean them up once a day. You can adjust this behavior by editing the systemd timer units if you want more or fewer snapshots.

To customize the frequency, edit the timer files located in /usr/lib/systemd/system/ or override them in /etc/systemd/system/. See the Snapper Arch Wiki for examples.

That’s it! From now on, Snapper will automatically create one snapshot every hour and clean them up daily according to the timeline settings.

---

To showcase Snapper's features and real-world applications, I conducted a series of tests. If you're running Fedora in a virtual machine, I highly recommend trying these—or similar scenarios—to see firsthand how Snapper can help you recover from system-breaking changes.

You’ll find the test walkthroughs here: Snapper Tests. Although they were originally performed on Fedora 40, they remain fully applicable to Fedora 42. The only exception is Test #4, which demonstrated a rollback using the GRUB menu.

For a version of Test #4 tailored to this setup, check out this alternative test, where I walk you through performing the rollback using Btrfs Assistant instead.

8. Conclusion

With Fedora 42, you can now take full advantage of modern encryption standards, seamless recovery tools, and a polished GNOME 48 desktop—all while keeping your system secure and resilient. By opting for LUKS2 with PBKDF2, you ensure compatibility with GRUB while benefiting from a more flexible encryption framework. And with methods to bypass the second LUKS passphrase prompt using either a key file or TPM2, you can streamline the boot process without compromising security.

Pairing this setup with Btrfs snapshots and Snapper gives you powerful rollback capabilities that protect against misconfigurations, failed updates, and other system-breaking changes. Whether you’re setting up a secure workstation or just want peace of mind, this guide provides a solid foundation for a reliable and secure Fedora experience.

9. Watch on YouTube