How to Install Fedora 42 with Snapshot and Rollback Support

Fedora Linux 42 is here!

Fedora Workstation 42 introduces the sleek new GNOME 48 desktop, a redesigned Anaconda Web UI installer for a more modern setup experience, and performance improvements like triple buffering for smoother animations. You’ll also find smarter notification stacking and a new Well-Being panel to help manage screen time.

In previous releases—Fedora 39, 40, and 41—I published a detailed guide on setting up Btrfs snapshots and rollback support. That method used a robust layout: root as the main volume with manually crafted Btrfs subvolumes for /home, /opt, and more. It worked reliably through Fedora 41 and continues to perform flawlessly on Fedora 42. I truly appreciate all the positive feedback and support from readers.

But with Fedora 42, I’m taking a new approach.

Inspired by the streamlined method I used in my Install Arch Linux with Snapshots & Rollback series, I’ve adopted a much simpler and faster setup for enabling snapshot and rollback support in Fedora 42. This new process cuts down on complexity while maintaining the same rock-solid functionality—perfect for both newcomers and experienced Fedora users.

In this updated guide, I’ll show you how to install Fedora 42 with snapshot and rollback support using a simplified approach that doesn’t sacrifice reliability.

For users who want to set up LUKS encryption, check out the LUKS version of this guide for detailed instructions.

Let’s dive in and build a smarter, safer Fedora system!

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. Set Up Snapper, grub-btrfs, and Btrfs Assistant
• 6. Enable Automatic Timeline Snapshots
• 7. Rollback Using Btrfs Assistant GUI
• 8. Conclusion

1. Partitions and Subvolumes Layout

For this setup, I'm using a 128 GiB disk to install Fedora 42 with Btrfs snapshots and rollback support. The goal is to keep things simple, efficient, and fully rollback-capable—especially when it comes to kernel updates and system configurations.

This is how the disk partition looks:

NAME         SIZE  FSTYPE  PARTTYPENAME      MOUNTPOINT
/dev/vda     128G              
├─/dev/vda1    1G  vfat    EFI System        /boot/efi
└─/dev/vda2  127G  btrfs   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 Workstation 42 Installer in UEFI mode. On the welcome screen, select the Install Fedora button.

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 table.

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

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.

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 and restart your system.

This will begin the final phase of the setup process. Click 'Start Setup' to finish the remaining customization steps, such as creating a user account, setting a password, and more.

After completing the setup, you'll be logged into Fedora Workstation 42, featuring the brand-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: 5f5867f4-1b15-4db8-8e54-0418ea0a7c7b
	Total devices 1 FS bytes used 6.30GiB
	devid    1 size 127.07GiB used 10.02GiB path /dev/vda2

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 /var/tmp
                                      /var/log
                                      /var/spool
                                      /var/lib/libvirt
                                      /var/cache
                                      /var/lib/gdm
                                      /opt
                                      /home
                                      /

The subvolumes will now appear as follows:

$ sudo btrfs subvolume list /
ID 256 gen 56 top level 5 path root
ID 257 gen 57 top level 5 path home
ID 258 gen 21 top level 5 path opt
ID 259 gen 56 top level 5 path cache
ID 260 gen 45 top level 5 path gdm
ID 261 gen 45 top level 5 path libvirt
ID 262 gen 58 top level 5 path log
ID 263 gen 45 top level 5 path spool
ID 264 gen 49 top level 5 path tmp
ID 265 gen 45 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 138 top level 5 path root
ID 257 gen 138 top level 5 path home
ID 258 gen 92 top level 5 path opt
ID 259 gen 133 top level 5 path cache
ID 260 gen 133 top level 5 path gdm
ID 261 gen 125 top level 5 path libvirt
ID 262 gen 138 top level 5 path log
ID 263 gen 125 top level 5 path spool
ID 264 gen 138 top level 5 path tmp
ID 265 gen 125 top level 256 path var/lib/machines
ID 266 gen 138 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. 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 199 top level 5 path root
ID 257 gen 196 top level 5 path home
ID 258 gen 92 top level 5 path opt
ID 259 gen 187 top level 5 path cache
ID 260 gen 181 top level 5 path gdm
ID 261 gen 149 top level 5 path libvirt
ID 262 gen 199 top level 5 path log
ID 263 gen 174 top level 5 path spool
ID 264 gen 187 top level 5 path tmp
ID 265 gen 149 top level 256 path var/lib/machines
ID 266 gen 138 top level 257 path home/madhu/.mozilla
ID 267 gen 199 top level 256 path .snapshots
ID 268 gen 199 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.

6. 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.

7. Rollback Using Btrfs Assistant GUI

Snapper is an incredibly powerful tool for managing and recovering system snapshots with ease.

To explore its capabilities and demonstrate practical use cases, I ran a series of tests. If you’re experimenting in a virtual machine, I highly recommend trying out these tests—or any scenarios you can imagine—to better understand how Snapper can help you recover from system-breaking changes.

You can find those tests here: Snapper Tests. While they were originally conducted on Fedora 40, everything still applies to Fedora 42. The only difference is in Test #4, which involved rolling back from the GRUB menu. I’ll show you how to perform that rollback using Btrfs Assistant instead.

In this demo, I’ll simulate a severe system failure by deleting critical directories and files required for Fedora to function—such as the Linux kernel and initramfs files from /boot, the configuration files in /etc, and the system libraries and modules in /usr.

Before we begin, here’s the current list of available snapshots:

$ snapper ls
# │ Type   │ Pre # │ Date                            │ User │ Cleanup  │ Description │ Userdata
──┼────────┼───────┼─────────────────────────────────┼──────┼──────────┼─────────────┼─────────
0 │ single │       │                                 │ root │          │ current     │
1 │ single │       │ Mon 21 Apr 2025 04:00:09 PM EDT │ root │ timeline │ timeline    │

Now let’s simulate the disaster by deleting the core system files:

$ sudo rm -rvf /boot/{vmlinuz,initramfs}* /etc /usr

At this point, all essential system files have been removed, rendering the system unbootable.

Go ahead and reboot. You’ll find that the system won’t boot successfully and should throw a kernel-related error at startup.

Now, return to the GRUB menu, scroll down, and boot from snapshot #1.

After successfully booting into the snapshot, open a terminal and verify that the kernel and initramfs files are present in the snapshot:

$ sudo ls -1 /boot/{vmlinuz,initramfs}*
/boot/initramfs-0-rescue-c647073f93184f91b4dfd63702ad75ea.img
/boot/initramfs-6.14.0-63.fc42.x86_64.img
/boot/initramfs-6.14.2-300.fc42.x86_64.img
/boot/vmlinuz-0-rescue-c647073f93184f91b4dfd63702ad75ea
/boot/vmlinuz-6.14.0-63.fc42.x86_64
/boot/vmlinuz-6.14.2-300.fc42.x86_64

Now launch the Btrfs Assistant graphical application.

1. Click on the Snapper tab.
2. Switch to the Browse/Restore tab.
3. Ensure that Select target is set to the root subvolume.
4. Choose Snapshot #1.
5. Then click the Restore button.

Then, click Yes to confirm the restoration. When the success message is displayed, click OK and restart your system right away.

After rebooting, your root subvolume will be fully restored and back to a working state.

8. Conclusion

With Fedora 42 now fully set up for snapshots and rollbacks, you’ve got a solid safety net against accidental system changes, failed updates, or broken configurations. Snapper works quietly in the background to create automatic snapshots, and tools like grub-btrfs and Btrfs Assistant give you the power to view, restore, and roll back to any saved state with ease.

Whether you’re experimenting with system tweaks, testing new software, or just want peace of mind, this setup gives you the flexibility and reliability Fedora users deserve.

If you found this guide helpful, feel free to share it—and let me know how it worked for your setup!