You need to cross the release boundary
You are running Fedora 40. The release notes for Fedora 42 are out. You want the new kernel, the updated desktop environment, and the latest development tools. You run sudo dnf upgrade and the terminal tells you there is nothing to do. The release version is pinned. You cannot move forward with a standard upgrade command.
This is the moment for dnf system-upgrade. It is the standard tool for moving between Fedora releases without reinstalling. It downloads the entire new system state while your current system is running, then applies the changes during a dedicated offline reboot phase. This approach avoids the dependency conflicts that plague in-place live upgrades. A botched upgrade can leave you unable to boot. Snapshot the system before the upgrade. Future-you will thank you.
What is actually happening
DNF manages packages by resolving a dependency graph. When you update packages within a release, the graph changes incrementally. Libraries get patched. Binaries get replaced. The system stays consistent because the changes are small and tested together.
When you cross releases, the graph changes massively. Libraries get renamed. APIs change. Packages get split or merged. Conflicts appear. If you try to apply these changes one by one while the system is running, you risk a "half-upgraded" state where package A is new but package B is old, and they conflict. The system can become unstable or fail to boot.
dnf system-upgrade handles this by downloading the entire new state first. It builds a transaction that replaces the old state with the new state in one atomic operation. Think of it like swapping the engine of a car while the car is off, rather than trying to swap parts while the engine is running. The command downloads everything, verifies GPG signatures, and stages the changes. Then it reboots into a special upgrade environment to apply the changes. This environment isolates the upgrade process from the running system. If the upgrade fails, the system rolls back to the previous state automatically.
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.
Run dnf upgrade --refresh before you start. A partially updated base causes conflicts during the release transition.
Prepare the current system
Before you touch the upgrade process, ensure your current system is healthy. Update all packages to the latest versions available for your current release. This minimizes the number of changes the upgrade transaction has to handle.
# Fully update the current system to the latest state of the current release
sudo dnf upgrade --refresh
# --refresh forces dnf to ignore cached metadata and fetch the latest package list from the repos
# This ensures you are starting from a known-good baseline before crossing the release boundary
Check for third-party repositories. RPM Fusion, Flatpak remotes, and custom YUM repos can interfere with the upgrade. Some third-party packages may not have equivalents in the new release. DNF will warn you about conflicts. You can disable problematic repos temporarily or use the --allowerasing flag with caution.
Verify that you have enough disk space. The download phase stores all new packages in the cache. A typical upgrade requires 1 to 5 GB of free space, depending on the number of installed packages.
# Check available disk space on the root partition
df -h /
# Ensure at least 5 GB is free to accommodate the package cache and temporary files
Install the upgrade plugin
The dnf-plugin-system-upgrade package provides the system-upgrade command. It is usually pre-installed on Fedora Workstation, but minimal Server installs or custom spins may lack it.
# Install the plugin if it is missing
sudo dnf install dnf-plugin-system-upgrade
# The plugin adds the system-upgrade subcommand to dnf
# It is often pre-installed on Workstation but missing on minimal Server installs
Download the new release
The upgrade process happens in two steps. First, you download the packages. Second, you reboot to apply them. This separation lets you review the transaction and cancel if something looks wrong.
Replace 42 with the target Fedora version. You can only upgrade to the next immediate release or the one after that. Fedora's release cadence is 6 months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle.
# Download packages for the target release without applying them
sudo dnf system-upgrade download --releasever=42
# --releasever=42 tells dnf to resolve dependencies against the Fedora 42 repository metadata
# DNF will calculate the full transaction, download all required packages, and verify signatures
DNF will display a transaction summary. It lists every package to be installed, updated, removed, and downgraded. Review this list carefully. If you see unexpected removals, cancel the command and investigate.
If DNF stops with a conflict error, you may need to allow erasing packages. This tells DNF it can remove packages to resolve conflicts. Use this flag only when you understand which packages will be removed. It might remove a driver or a tool you rely on.
# Download packages and allow DNF to remove conflicting packages if necessary
sudo dnf system-upgrade download --releasever=42 --allowerasing
# --allowerasing lets dnf remove packages that conflict with the new release
# Review the output carefully to ensure no critical software is being dropped
Check the transaction summary before confirming. DNF will list every package to be installed, updated, and removed.
Trigger the upgrade reboot
Once the download completes, trigger the reboot. The system will restart into a special upgrade environment. This environment mounts the root filesystem in a way that allows the package manager to replace core system files safely.
# Reboot into the upgrade environment to apply the downloaded packages
sudo dnf system-upgrade reboot
# This triggers a reboot into a special upgrade environment
# The system will not boot normally until the transaction completes
# Do not interrupt the process. Power loss during this phase can corrupt the filesystem
The machine will reboot. You will see a progress bar or a text-based installation screen. The upgrade typically takes 10 to 30 minutes. The system will reboot a second time automatically when the transaction finishes.
If the upgrade fails, the system will roll back to the previous state. You will boot into your old Fedora release. Check the logs to understand the failure.
SELinux might trigger a relabeling on the first boot after the upgrade. This takes time. Don't panic if the system hangs for a few minutes after the upgrade reboot. The relabeling is normal and ensures security contexts are correct for the new packages.
Verify the upgrade
After the second reboot, log in and verify the system state. Check the release version and the kernel version.
# Confirm the OS version matches the target release
cat /etc/os-release
# Look for VERSION_ID="42" in the output
# This file defines the OS identity and is updated by the upgrade transaction
# Check the kernel version to ensure the new kernel is running
uname -r
# The kernel version should match the latest kernel package for the new release
# If you see an old kernel version, you may need to reboot again or select the new kernel in GRUB
Clean up the upgrade cache. The downloaded packages and temporary files are no longer needed.
# Remove the upgrade cache and temporary files
sudo dnf system-upgrade clean
# Removes the downloaded packages and the temporary upgrade environment files to reclaim disk space
# This step is safe to run immediately after a successful upgrade
# Remove obsolete packages that are no longer required by any installed package
sudo dnf autoremove
# Review the output before accepting. This may remove old kernels or orphaned dependencies
# Old kernels accumulate over time and can consume significant disk space
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and errors
Third-party repositories are the most common source of failure. If you have RPM Fusion or other custom repos enabled, DNF might try to pull packages from them that do not exist in the new release. This causes dependency resolution errors.
You may see an error like this:
Error: Transaction test error: package python3-3.12.x conflicts with python3-3.13.y
The conflict is intentional. Python versions are split across releases. DNF cannot upgrade Python incrementally. You must use dnf system-upgrade to handle this transition. If you see this error during a standard dnf upgrade, switch to system-upgrade.
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. Check /etc/NetworkManager/ for stale configuration files. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
SELinux denials can appear after an upgrade if a new package introduces a service that SELinux does not recognize yet. Check the logs for denials.
# Check for SELinux denials in the journal
journalctl -t setroubleshoot
# SELinux denials show up in journalctl -t setroubleshoot with a one-line summary
# Read those before disabling SELinux. Most denials are false positives or require a simple policy module
journalctl -xe reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
Immutable variants: Silverblue and Kinoite
Fedora Silverblue and Kinoite use an immutable base. You cannot modify the system packages with DNF. Instead, you use rpm-ostree to switch to a new image. The upgrade process is atomic and rollback-safe.
# Rebase to the new Fedora release image
sudo rpm-ostree rebase fedora:fedora/42/x86_64/silverblue
# rpm-ostree rebase downloads the new OSTree commit and stages it as the next boot deployment
# Replace silverblue with kinoite if you are running that variant
# The command will show a progress bar as it pulls the new image layers
# Reboot to activate the new deployment
sudo systemctl reboot
# The system will boot into the new deployment
# If something goes wrong, you can roll back from the GRUB menu or using rpm-ostree rollback
If the upgrade fails on an immutable system, boot from the previous deployment in GRUB. The previous deployment is preserved until you explicitly remove it.
# Roll back to the previous deployment if the new one is broken
sudo rpm-ostree rollback
# Reverts the boot order to the previous deployment
# This is safe and does not delete the new deployment. You can rebase again later
Trust the package manager. Manual file edits drift, snapshots stay.
When to use which tool
Use dnf system-upgrade when you are on Fedora Workstation or Server and want to preserve your configuration and installed packages across a release boundary. Use rpm-ostree rebase when you are running Fedora Silverblue or Kinoite and need to switch to a new immutable image. Use a fresh installation when your current system has accumulated years of custom patches, broken third-party RPMs, or you want a clean slate without the risk of dependency drift. Stay on the current release if you only need security updates and the new release does not provide a feature you require.