You upgraded and the system broke
You ran the release upgrade command, the machine rebooted, and the desktop environment crashes on login. Or the boot process hangs at a black screen with a blinking cursor. Or NetworkManager refuses to start and you are left without internet. You need to restore a working state without wiping your configuration or losing your files. Fedora does not ship with a single undo button for a full system upgrade. The recovery path depends on what artifacts the upgrade process left behind.
What actually changed under the hood
A system upgrade replaces core libraries, kernel modules, systemd units, and service configurations. When a new package introduces a regression, drops a deprecated dependency, or conflicts with a third-party driver, the system state becomes inconsistent. The package manager applies the new files, but the running services and loaded kernel modules still expect the old behavior. Fedora keeps transaction history in DNF and maintains multiple kernel versions in /boot. If you are on Btrfs, the filesystem may also contain read-only snapshots of the root subvolume. The rollback method you choose must match the layer where the breakage occurred.
Reboot before you debug. Half the time the symptom is gone once the old kernel loads.
Roll back the kernel first
Start with the boot menu. Fedora ships three kernel versions by default. The newest one is usually the source of the problem. Older kernels remain in /boot so you can boot into a known-good state while you investigate.
Here is how to check which kernels are currently installed and identify the problematic version.
rpm -q kernel
# Lists every kernel package currently on disk
# The output shows version numbers like 6.8.5-200.fc40.x86_64
# Note the highest version. That is the one that just booted.
Reboot the machine. Hold the Shift key immediately after POST to interrupt the automatic boot timer. The GRUB menu appears. Use the arrow keys to select the second entry, which corresponds to the previous kernel version. Press Enter to boot. If the system starts normally, the new kernel or a new kernel module is the culprit.
Here is how to remove the broken kernel and prevent GRUB from offering it again.
sudo dnf remove kernel-<bad-version>
# Removes the specific kernel package and its modules
# DNF automatically cleans up orphaned dependencies
# GRUB will regenerate its config on the next boot
Fedora's package manager tracks kernel versions separately from the rest of the system. Removing a kernel does not touch user packages or configuration files. It only deletes the vmlinuz image, the initramfs archive, and the kernel modules in /usr/lib/modules. If you rely on proprietary drivers like NVIDIA, you will need to reinstall them after booting the older kernel. The driver package is tied to the kernel version. Mismatched modules cause immediate black screens.
Run dnf autoremove after the removal. It clears out leftover kernel headers and debuginfo packages that no longer match your active kernel.
Keep the second-newest kernel installed. It is your safety net for the next upgrade cycle.
Restore a Btrfs snapshot
Fedora Workstation uses Btrfs by default. The filesystem supports atomic subvolume snapshots. If you created a snapshot before upgrading, or if Snapper is configured to take automatic snapshots, you can roll back the entire root filesystem to a previous point in time.
Here is how to list available snapshots and identify the one taken before the upgrade.
snapper list
# Shows all snapshots in the root configuration
# Look for the number with a description like "before-upgrade"
# Note the ID column. You will need it for the rollback command.
Snapper stores snapshots in the /.snapshots subvolume. Each snapshot is a read-only copy of the root filesystem at a specific moment. Rolling back swaps the active @ subvolume with the snapshot subvolume. The old root becomes a new snapshot, and the snapshot becomes your active system.
Here is how to perform the rollback and restore the previous filesystem state.
sudo snapper rollback <snapshot-number>
# Swaps the current root subvolume with the chosen snapshot
# Creates a new snapshot of the broken state for safety
# Updates the Btrfs default subvolume pointer for the next boot
After the command completes, reboot. The system will mount the older subvolume as /. Your files, packages, and configurations return to the state they were in when the snapshot was taken.
Btrfs rollbacks restore /etc as well. If you modified configuration files after taking the snapshot, those changes disappear. Snapper does not merge /etc files. It replaces them entirely. If you need to preserve custom settings, copy them to a separate directory before running the rollback. The /etc directory is for user modifications. Files in /usr/lib/ ship with packages and are overwritten by DNF. Never edit /usr/lib/ directly.
Check the default subvolume after reboot. Btrfs uses a default subvolume pointer to decide what mounts at /. If the pointer is misaligned, the boot process will drop you into an emergency shell.
Run btrfs subvolume get-default / to verify the active subvolume ID matches your expectation.
Trust the filesystem snapshot. Manual file edits drift, snapshots stay consistent.
Undo DNF transactions
If the issue stems from a specific package upgrade rather than the kernel or the entire filesystem, DNF transaction history provides a surgical rollback. DNF records every install, upgrade, remove, and downgrade in a SQLite database. You can undo individual transactions or roll back to a specific point in time.
Here is how to view recent package manager activity and locate the transaction that introduced the regression.
dnf history
# Displays a table of recent transactions
# Columns show ID, Command Line, Date and Time, and Altered
# Look for the ID that corresponds to your upgrade or package install.
DNF keeps the old package files in the cache directory under /var/cache/dnf. If the cache is still populated, or if the older package versions are available in the configured repositories, you can reverse the transaction.
Here is how to undo a specific transaction and restore the previous package versions.
sudo dnf history undo <id>
# Reverses the package changes from the specified transaction
# Downloads older RPMs from the cache or remote repositories
# Restores configuration files to their pre-upgrade state
If you want to revert multiple transactions at once, use the rollback command. It walks backward through the history log and restores the system to the state it was in before the specified ID.
Here is how to roll back all changes since a specific transaction ID.
sudo dnf history rollback <id>
# Undoes every transaction that occurred after the given ID
# Effectively reverts a partial or full system upgrade
# Requires cached packages or accessible repository metadata
DNF will refuse to proceed if it cannot locate the older package files. The error message will explicitly state which RPMs are missing from the cache. You can force DNF to refresh the repository metadata and try again, but if the older Fedora release has reached end of life, the mirrors will no longer host the packages. In that case, you must rely on a Btrfs snapshot or a clean reinstall.
Run dnf clean all only after you have confirmed the rollback succeeded. Clearing the cache removes the safety net for future undo operations.
Check the transaction log before you guess. DNF history shows exactly what changed.
Verify the system state
A rollback is not complete until you confirm the services are running and the logs are clean. The boot process may succeed, but background services can still fail silently.
Here is how to inspect the journal for recent failures and verify critical units.
journalctl -xeu NetworkManager.service
# Shows recent log lines for the specified systemd unit
# The x flag adds explanatory text for common failures
# The e flag jumps to the end of the journal output
Check the kernel version and module status. Mismatched modules cause immediate hardware failures.
Here is how to confirm the active kernel matches the loaded modules.
uname -r
# Prints the running kernel version string
# Compare this output with the rpm -q kernel list
# They must match exactly. A mismatch indicates a partial boot.
Verify that SELinux is enforcing and not throwing denials. A rollback can restore older policy files that conflict with newer binaries.
Here is how to check for SELinux access denials in the journal.
journalctl -t setroubleshoot
# Filters journal entries for SELinux troubleshooting messages
# Shows one-line summaries of denied operations
# Read these before disabling the security module entirely.
If the logs are clean and the services are active, the rollback succeeded. If you see repeated failures, the issue likely lies in configuration drift or a missing dependency. Address those before attempting another upgrade.
Run systemctl status on any failing unit. Read the actual error before guessing.
Common failure modes and exact errors
Rollbacks fail when the underlying assumptions are wrong. The most common mistakes involve missing caches, misaligned subvolumes, and ignored security contexts.
The dnf history undo command will refuse to proceed and print Error: Cannot undo transaction: package <name> is not available. The package manager cannot find the older RPM in the cache or the repository. You must either restore the cache from a backup, switch the repository metadata to the older Fedora release, or abandon the DNF rollback in favor of a Btrfs snapshot.
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name or a deprecated key. Btrfs rollbacks restore /etc/NetworkManager/ exactly as it was. If you renamed an interface after the snapshot, the old config will fail. Edit the connection profile and update the interface name.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A rollback can restore older file contexts that do not match the new binary layout. Run restorecon -Rv / to relabel the filesystem. The command walks the directory tree and applies the correct security contexts from the policy database.
Btrfs subvolume swaps can leave the default pointer misaligned. If the boot process drops you into a btrfs rescue shell, the root subvolume is not mounted correctly. Check the mount options in /etc/fstab. The subvol=@ parameter must point to the active subvolume. If you manually moved subvolumes, update the fstab entry and run btrfs subvolume set-default <id> /.
Fedora's release cadence is six months. The N-2 release goes end of life when N+1 ships. Plan upgrades on that cycle. Attempting to roll back to an EOL release will fail because the mirrors no longer host the packages.
Snapshot the system before the upgrade. Future-you will thank you.
Choose your rollback path
Use the GRUB menu to boot the previous kernel when the new kernel or a kernel module causes a black screen or hardware failure. Use a Btrfs snapshot when you need to restore the entire filesystem state, including /etc and user data, to a known-good point in time. Use DNF transaction history when a specific package upgrade introduced a regression and the older RPMs are still cached or available in the repository. Use a clean reinstall when the system is unbootable, no snapshots exist, and the package cache is empty. Stay on the upstream Workstation defaults if you only deviate from the configuration occasionally.