You upgraded and the system broke
You ran dnf system-upgrade to move to the latest Fedora release. The system rebooted, but your desktop environment refuses to load, or your proprietary GPU driver silently fails. You need to go back to the previous release. The short answer is that Fedora does not support full system downgrades. The longer answer explains why the project makes that choice and gives you four practical paths to recover your system.
What is actually happening under the hood
Fedora follows a forward-only release model. Every six months, the project ships a new version with updated kernels, glibc, systemd, and thousands of dependent packages. When you upgrade, the package manager replaces shared libraries, updates kernel ABIs, and applies new SELinux policy modules. The RPM database records the current state of every file on the system, but it does not keep a reversible history of every change. Reversing a full upgrade would require tracking which configuration files were modified, which libraries were swapped, and which systemd units were replaced. That level of state tracking introduces too much complexity and too many failure points. Think of it like baking a cake. You can add ingredients and bake it forward. You cannot unmix the batter and separate the eggs from the flour after the oven cycle finishes. Fedora accepts that trade-off to keep the package manager fast and the system stable.
Run journalctl -xe first. Read the actual error before guessing.
The recovery paths
You still have options. The right path depends on what broke and whether you prepared for this moment.
Roll back a single package
If the upgrade itself worked but one specific application is misbehaving, you can target that package directly. The dnf tool keeps a local history of installed versions and can fetch older builds from the archives if they are still available. Remember that dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them.
Here is how to check which versions of a package are available in your cache and repositories.
# List all cached and repository versions of the package
dnf list --showduplicates firefox
# Identify the exact version string you want to revert to
# Copy the full name including architecture, for example firefox-121.0-1.fc40.x86_64
Once you have the version string, you can force the package manager to install it.
# Replace the current version with the older build
sudo dnf install firefox-121.0-1.fc40.x86_64
# Add --skip-broken if dnf aborts due to a single missing dependency
# This flag tells dnf to proceed with the rest of the transaction instead of failing entirely
If you prefer a simpler syntax, dnf downgrade automatically finds the previous version in the repository metadata.
# Automatically resolve and install the previous repository version
sudo dnf downgrade firefox
# This command checks the repository history and picks the version immediately before the current one
# It will refuse to run if the older version has been purged from the mirrors
Boot an older kernel
Kernel updates are the most common cause of boot failures and hardware regressions. Fedora retains the previous two kernel packages by default. You do not need to uninstall the new kernel to use the old one.
Here is how to verify which kernels are currently installed on your system.
# Query the rpm database for installed kernel packages
rpm -q kernel --qf '%{VERSION}-%{RELEASE}.%{ARCH}\n'
# The output lists every kernel version currently present in /boot
# Pick the version that worked before the upgrade
Set the working kernel as the default boot entry so you do not have to press a key every time the machine starts.
# Point grubby to the specific vmlinuz file for the older kernel
sudo grubby --set-default /boot/vmlinuz-6.8.5-301.fc40.x86_64
# This updates the GRUB configuration and sets the default boot index
# Reboot immediately to test the older kernel in a clean environment
Restore a Btrfs snapshot
Fedora uses Btrfs as the default root filesystem. The copy-on-write design allows instant snapshots of the entire root subvolume. If you installed a snapshot manager before running the upgrade, you can revert the entire system to a known-good state.
Here is how to list your existing snapshots and identify the pre-upgrade point.
# Display all snapper snapshots with their creation timestamps
sudo snapper list
# Look for the snapshot created right before you ran dnf system-upgrade
# Note the numeric ID in the first column
Apply the rollback command to restore the root filesystem to that snapshot.
# Revert the root subvolume to snapshot number 5
sudo snapper rollback 5
# This command creates a new snapshot of the current state and swaps the read-write pointer
# The next reboot will mount the older snapshot as the active root filesystem
Perform a clean reinstall
When the upgrade touched core libraries, SELinux policies, or systemd units, and you do not have a snapshot, a fresh install is the only reliable path backward. Fedora keeps older release ISOs in the public archive.
Back up your user data before touching the disk.
# Mirror your home directory to an external drive or separate partition
rsync -av --exclude='/.cache' /home/username/ /mnt/backup/home-backup/
# The -a flag preserves permissions and timestamps
# The exclude flag prevents copying gigabytes of browser cache and thumbnail data
Boot the older Fedora ISO, select the custom partitioning option, and format only the root and boot partitions. Leave the /home partition untouched if you separated it during the original installation. The installer will restore your documents and configuration files while replacing the system tree.
Snapshot the system before the upgrade. Future-you will thank you.
Verify the rollback
Confirmation depends on which recovery path you chose. For a package rollback, run rpm -q <package> to see the version string. For a kernel change, check uname -r after reboot. For a snapshot rollback, run snapper current to verify the active subvolume ID matches your target. If you modified configuration files during the troubleshooting process, remember that files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Always check systemctl status <unit> before restarting services. The status command shows recent log lines AND state in one view. Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and exact error messages
Downgrade attempts fail when dependency chains break. The package manager will refuse to proceed and print Error: Transaction test error: package python3-3.12.x conflicts with python3-3.13.y. The conflict is intentional. Read the next paragraph before forcing. Forcing a downgrade with --allowerasing or --best disabled will orphan shared libraries and break systemd units that expect newer symbols.
If you try to use snapper on a system that uses XFS or ext4, the command will fail with Error: No snapper configuration found for /. Btrfs snapshots are a filesystem feature, not a universal backup tool. You must have enabled the configuration during installation or manually created it with snapper -c root create-config /.
If the GRUB menu does not appear during boot, your bootloader timeout is set to zero. Hold the Shift key or tap Esc repeatedly during the early boot phase to force the menu to appear. If the boot menu is gone, GRUB rescue is your friend, not your enemy.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can.
When to use each recovery method
Use dnf downgrade when a single application or driver is causing regressions and the rest of the system is stable. Use grubby --set-default when a new kernel breaks hardware support or causes panic loops. Use snapper rollback when you prepared snapshots before the upgrade and need to revert the entire root filesystem instantly. Use a clean reinstall when the upgrade crossed major release boundaries, touched core libraries, and you lack a snapshot. Stay on the upstream Workstation if you only deviate from the defaults occasionally.