How to Upgrade Fedora to a New Release

Fedora moves fast — a new release drops roughly every six months, and each version receives only about thirteen months of support. Staying current means using dnf system-upgrade, the official in-place upgrade path that downloads the new release, stages it, and applies it on the next reboot entirely outside the running OS. It is reliable, well-tested, and vastly preferable to a fresh install when you want to keep your configuration and data intact.

Before You Start

A failed upgrade mid-stream is painful. Take these precautions seriously before touching a single command.

• Back up your data. Use Timeshift, Btrfs snapshots, or a plain rsync copy to an external drive. No upgrade tool is a substitute for a backup.
• Update the current system fully. Upgrades from a fully-patched base are more reliable than from a partially-updated one.
• Check that you have at least 8 GB free on /. The download cache alone can occupy 3–5 GB, and the upgrade transaction needs working space.
• Know your current version. Fedora only supports skipping one release (e.g., F38 → F40), though upgrading one release at a time is strongly recommended.

Step 1 — Fully Update the Running System

Start clean. Apply every available update, then reboot so the running kernel matches the installed one.

sudo dnf upgrade --refresh -y
sudo reboot

After the reboot, confirm your starting point:

cat /etc/fedora-release
# Example output: Fedora release 39 (Thirty Nine)

Step 2 — Install the DNF System Upgrade Plugin

The plugin ships in the default Fedora repos and may already be installed. This is idempotent — safe to run even if it is present.

sudo dnf install dnf-plugin-system-upgrade -y

Step 3 — Handle Third-Party and Non-Default Repositories

This is the step most guides gloss over. Enabled third-party repos (RPM Fusion, Visual Studio Code, Google Chrome, etc.) are a leading cause of upgrade failures because they may not yet carry packages for the new Fedora version at the time you upgrade.

Option A — Disable them temporarily (recommended)

List all enabled repos, then disable the non-Fedora ones for the duration of the upgrade:

dnf repolist enabled

sudo dnf config-manager --disable rpmfusion-free rpmfusion-nonfree \
  rpmfusion-free-updates rpmfusion-nonfree-updates
# Repeat for any other third-party repos you see in the list

Re-enable them after a successful upgrade as described in Step 7.

Option B — Use --allowerasing and --skip-broken

If you leave repos enabled, add these flags to the download command in Step 4. DNF will remove packages it cannot satisfy rather than aborting, which is acceptable but can surprise you post-upgrade. Option A is cleaner.

Step 4 — Download the New Release

Replace 40 with the target Fedora version number. Check the current stable release at fedoraproject.org before running this.

sudo dnf system-upgrade download --releasever=40 -y

DNF resolves the full transaction, downloads all required RPMs into /var/lib/dnf/system-upgrade/, and verifies their GPG signatures. Depending on your connection and how many packages are installed, this can take anywhere from five minutes to over an hour. The command is safe to cancel and re-run — it resumes partial downloads.

If DNF reports dependency conflicts it cannot resolve, add --allowerasing:

sudo dnf system-upgrade download --releasever=40 --allowerasing -y

Read the list of packages marked for removal before accepting. A handful of obsolete packages being dropped is normal; dozens of core packages disappearing is a warning sign — investigate before proceeding.

Step 5 — Trigger the Upgrade Reboot

This command tells systemd to boot into the upgrade target on the next startup. It queues a special system-upgrade.target unit and immediately reboots the machine.

sudo dnf system-upgrade reboot

The system reboots, Plymouth shows a progress screen while DNF applies the transaction in a minimal environment, and then the machine reboots a second time into the fully upgraded OS. On a mid-range SSD this second phase typically takes 10–20 minutes; spinning-disk systems can take 40+ minutes. Do not power off the machine during this phase.

Step 6 — Verify the Upgrade

After login, confirm the new release:

cat /etc/fedora-release
hostnamectl | grep "Operating System"
uname -r

Check for any packages that were not upgraded (typically packages installed from local RPMs or repos that were offline):

sudo dnf distro-sync --refresh

distro-sync resets the versions of all installed packages to exactly what the now-active repos specify. Run it after every in-place upgrade — it catches stragglers and resolves version mismatches that upgrade alone can miss.

Step 7 — Post-Upgrade Cleanup

Re-enable and update third-party repositories

Re-enable the repos you disabled in Step 3. For RPM Fusion, the cleanest approach is to re-install the release packages so the repo files point at the correct new release:

sudo dnf install \
  "https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm" \
  "https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm"

For other repos you disabled manually:

sudo dnf config-manager --enable rpmfusion-free rpmfusion-nonfree \
  rpmfusion-free-updates rpmfusion-nonfree-updates

Remove obsolete packages

Packages that have no counterpart in the new release accumulate over time. Review and optionally remove them:

sudo dnf repoquery --unsatisfied
sudo dnf autoremove

autoremove only removes packages that were installed as dependencies and are no longer required. Review its output before confirming — occasionally it will propose removing something you installed intentionally that lost its reverse dependency.

Clear the DNF upgrade cache

The staged RPMs in /var/lib/dnf/system-upgrade/ are no longer needed and can be several gigabytes:

sudo dnf clean all

Check for leftover .rpmnew and .rpmsave files

When RPM cannot safely overwrite a config file you have modified, it leaves a .rpmnew (the package default) or .rpmsave (your old file, renamed) alongside the original. Review these and merge changes as needed:

sudo find /etc /usr -name '*.rpmnew' -o -name '*.rpmsave' 2>/dev/null

Troubleshooting

"Error: Transaction check error" during download

Usually a conflict from a third-party package. Identify the offending package in the error output, remove it, and re-run the download step. You can reinstall it from the third-party repo after the upgrade.

System boots into the old release after the upgrade reboot

The upgrade may not have been triggered correctly, or a prior dnf system-upgrade reboot was interrupted. Check systemd's upgrade status and journal:

sudo journalctl -b -1 -u dnf-system-upgrade

If the upgrade phase never ran, you can safely re-run sudo dnf system-upgrade reboot provided the download cache is still intact.

Plymouth progress screen freezes

This is usually a display driver or Wayland compositor issue with the upgrade environment, not an actual freeze. If the disk activity light is still active, the upgrade is still running. Wait at least 60 minutes before considering a hard reboot. If you must hard-reboot, the system may be in an inconsistent state — boot from a Fedora live image and run dnf system-upgrade download again from a chroot.

Packages installed from Copr or local RPMs remain at old version

Copr repositories are version-specific. After the upgrade, visit your active Copr repo pages, update the repo file to point at the new Fedora version, and run dnf distro-sync again.