The upgrade scenario
You are sitting at your desk. Fedora 41 has been running smoothly for six months. The release calendar shows Fedora 42 is out, and your current release is approaching end of life. You want to move to the new version without wiping your home directory or reinstalling your dotfiles. You open a terminal and type sudo dnf upgrade. The package manager updates everything, but the release version stays at 41. You need a different command to cross the release boundary.
What the upgrade process actually does
Fedora treats major version jumps as a complete transaction, not a series of incremental patches. The dnf upgrade command only updates packages within the current release stream. It respects the repository metadata pinned to Fedora 41. When you cross to Fedora 42, the package manager must swap the entire repository configuration, resolve dependencies against a new set of packages, and replace core system libraries that might be in use.
Think of it like replacing the foundation of a house while people are still living inside. You cannot just swap the bricks one by one. You need a staged approach. First, you gather all the new materials and verify they fit. Then, you schedule a maintenance window to actually swap the foundation. The dnf system-upgrade plugin follows this exact pattern. It separates the download and dependency resolution phase from the actual installation phase. This keeps your system usable while the new packages are fetched, and it ensures the transaction completes atomically during the next boot.
Fedora's release cadence is six months. The N-2 release goes end of life when N+1 ships. Plan upgrades on that cycle to avoid running unsupported software. The dnf upgrade --refresh command is your normal weekly maintenance tool. dnf system-upgrade is exclusively for crossing major Fedora releases. They are different commands with different transaction scopes. Do not conflate them.
Run a full backup before you start. A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can.
Running the in-place upgrade
The upgrade happens in two distinct steps. You download the new packages first. Then you trigger the reboot that applies them. Run the download command from a clean terminal. Close your graphical applications to avoid file locks. The package manager will stage everything in /var/cache/dnf before touching your running system.
Here is how to fetch the Fedora 42 packages and prepare the transaction.
sudo dnf system-upgrade download --releasever=42
# --releasever=42 tells dnf to switch repository metadata to the 42 stream
# system-upgrade download resolves dependencies and stages packages in /var/cache
# The command will prompt for confirmation before consuming bandwidth
# If interrupted, run the same command again to resume the download
The package manager will calculate the transaction size. It might take several minutes to resolve dependencies if you have third-party repositories enabled. Once the download finishes, the packages sit in the cache. Your system is still running Fedora 41. You can continue working until you are ready to commit.
When you are ready to apply the upgrade, run the reboot command. This command does not just restart your machine. It mounts the new packages as the target root filesystem and schedules the transaction to run during the boot process. The dracut initramfs will handle the package replacement before systemd starts your user sessions.
Here is how to trigger the staged upgrade and restart.
sudo dnf system-upgrade reboot
# This command hands control to dracut and systemd for the next boot
# The upgrade transaction runs before your graphical session starts
# Do not interrupt the process once the progress bar appears
# The system will automatically roll back if a critical dependency fails
The machine will reboot. You will see a text-mode progress bar showing package replacements. The process can take anywhere from ten to forty minutes depending on your disk speed and package count. Do not force shutdown. The transaction manager will roll back automatically if it detects a critical failure, but an interrupted power cycle can corrupt the package database.
Trust the package manager. Manual file edits drift, snapshots stay.
Verifying the new release
Once the system finishes the transaction, it will drop you to the login screen or boot directly into your desktop. Do not assume the upgrade succeeded just because the machine turned on. Check the kernel version and the release metadata. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. The upgrade process respects this boundary, but post-upgrade drift can still occur if you manually patched system files in the past.
Here is how to confirm you are running the correct Fedora release.
cat /etc/fedora-release
# This file contains the human-readable release string
uname -r
# This shows the running kernel version, which should match the 42 stream
dnf repolist enabled
# This confirms your active repositories are now pointing to Fedora 42
# If repos still show 41, run dnf upgrade --refresh to force a metadata pull
You should see Fedora Linux 42 in the release file. The kernel version will likely be a 6.x series with a higher patch number than your previous installation. The repository list should show fedora and updates streams without the old version suffix. If the repository list still shows 41, the metadata swap failed. Run sudo dnf upgrade --refresh to force a metadata pull, then check again.
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and error messages
Third-party repositories are the most common cause of failed upgrades. RPM Fusion, Flatpak remotes, and custom COPR repositories often lag behind the official Fedora release cycle. If you attempt the upgrade with an incompatible third-party repo enabled, the dependency resolver will abort.
The dnf system-upgrade download command will refuse to proceed and print the following error:
Error: Transaction test error: package foo-1.0 conflicts with bar-2.0
The conflict is intentional. The resolver cannot satisfy dependencies across two different release streams simultaneously. Disable the problematic repository before running the download command again. You can temporarily disable a repo with sudo dnf config-manager --set-disabled <repo-name>.
Another frequent issue involves SELinux relabeling. After a major version jump, file contexts might drift. The system will automatically trigger a relabel on the next boot. You will see Relabeling in progress... on the console. This can take a long time on large drives. Do not skip it. A skipped relabel will cause permission denials across the desktop environment and break service startups. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux.
If you see [FAILED] Failed to start graphical-session.target after the reboot, your display manager configuration might reference a deprecated service. Check the journal for the actual failure reason. Run journalctl -xeu graphical-session.target to isolate the unit. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Most display manager issues resolve after a fresh login or a quick sudo dnf distro-sync to align package versions.
Run journalctl first. Read the actual error before guessing.
Choosing your upgrade path
Use dnf system-upgrade when you want to preserve your existing configuration, home directory, and installed packages while crossing a major release boundary. Use a clean installation when your current system has accumulated years of manual edits, broken third-party repositories, or custom kernel patches that conflict with the new release. Use dnf upgrade --refresh when you only need to update packages within the current Fedora release cycle. Stay on the upstream Workstation stream if you only deviate from the defaults occasionally and want the longest supported lifecycle.