You cannot skip versions
You are running Fedora 40. Fedora 42 just shipped with the kernel and desktop features you need. You open a terminal and try to jump straight to the new release. The package manager refuses. You want to skip the intermediate version to save time and avoid a second reboot. The short answer is that you cannot skip versions. Fedora requires sequential upgrades. Here is why the constraint exists, how to navigate it safely, and what happens if you try to force a jump.
What is actually happening
dnf system-upgrade does not perform a live migration across multiple releases. It calculates a single atomic transaction that replaces every package on your system with the version from the immediate next release. The transaction relies on metadata that only exists for adjacent releases. When you request a jump from 40 to 42, the resolver cannot find a valid dependency chain. It does not know which intermediate libraries, configuration schema changes, or systemd unit modifications happened in 41. Skipping a release leaves orphaned dependencies and broken configuration paths.
Think of it like upgrading a database schema. You cannot jump from version 1 to version 3 without running the migration scripts for version 2. The intermediate steps rewrite tables and update indexes. Fedora works the same way. Package maintainers ship transition scripts, library soname bumps, and configuration file updates that assume you are coming from the previous release. The upgrade process reads a state file that tracks the last successful release. It only knows how to step forward by one.
Convention aside: dnf upgrade --refresh is your weekly maintenance command. It pulls updates within the same release. dnf system-upgrade is strictly for crossing release boundaries. They share a name but operate on completely different metadata streams. Do not mix them.
The upgrade environment runs inside a modified initramfs. dracut injects the dnf-system-upgrade module into the boot image. When you trigger the reboot, the system drops to a minimal rootfs, mounts your real filesystem read-only, and applies the downloaded RPMs. This environment is built for a single release boundary. It does not contain the logic to chain multiple transactions. Forcing a skip breaks the atomic guarantee.
Run the intermediate upgrade first. The package manager will not calculate a safe path until you are on the adjacent release.
The fix
You need to run the upgrade twice. First, move to the intermediate release. Then, move to your target release. The process is identical both times. You must complete the first cycle fully before starting the second. A partial transaction leaves your system in an unbootable state.
Snapshot the system before the upgrade. Future-you will thank you.
Convention aside: Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Back up /etc/ before the reboot. The upgrade process will prompt you to keep or replace modified files. Third-party repositories often lock to a specific Fedora version. Disable them before starting the first cycle. Re-enable them after the final reboot.
Here is how to download the transaction for the next release and prepare the reboot.
sudo dnf system-upgrade download --releasever=41 # Calculates the package transaction for Fedora 41
# --releasever points dnf to the correct metadata repository
# The resolver checks for conflicts and downloads every required RPM
sudo dnf system-upgrade reboot # Hands control to dracut and begins the live upgrade
# The system drops to a minimal environment and applies the transaction
# Do not interrupt power or close the lid during this phase
The machine will restart automatically. The screen will show a progress bar as the package manager applies the RPMs. Wait for the login prompt. Do not assume the upgrade is complete just because the desktop appears. The transaction finishes in the background.
Here is how to verify the intermediate release is active before starting the second cycle.
cat /etc/fedora-release # Confirms the intermediate release is active
rpm -q fedora-release # Returns the exact version package installed
dnf repolist # Shows that the repository metadata points to the new release
Once the output confirms you are on Fedora 41, run the second cycle. The commands are the same, only the version number changes.
sudo dnf system-upgrade download --releasever=42 # Fetches the next transaction
# The resolver now sees a valid adjacent release and builds the dependency tree
sudo dnf system-upgrade reboot # Applies the final upgrade cycle
# The system reboots into the target release
Verify it worked
Log in after the second reboot. Check the kernel version, the release package, and the service state. A successful upgrade leaves all core services running and the new release string in place.
Here is how to confirm the target release is active and the services are healthy.
uname -r # Shows the new kernel version shipped with the target release
rpm -q fedora-release # Returns the exact version package installed
systemctl status --no-pager | grep loaded # Shows how many units are active
journalctl -xeu systemd-journald # Checks for post-upgrade service failures
Convention aside: 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. Use it to scan for red FAILED lines. If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name.
Run journalctl -xe first. Read the actual error before guessing.
Common pitfalls and what the error looks like
Attempting to skip a release triggers a hard failure. The package manager cannot resolve the dependency tree across a missing release boundary. You will see a transaction error that stops the download immediately.
Error: No matching releasever found
Error: Cannot find a valid baseurl for repo: fedora
The resolver gives up because the metadata for the skipped release does not exist in the current repository configuration. Forcing the command with --skip-broken or --best will not work. The missing packages are not broken. They are simply not part of a valid upgrade path. The dependency graph requires every intermediate step.
Another common issue is leftover third-party repositories. RPM Fusion, Flatpak remotes, or custom YUM repos often lock to a specific Fedora version. When you cross a release boundary, those repositories stop providing valid metadata. The upgrade transaction fails with a GPG key error or a missing package error. Disable third-party repos before starting the first cycle. Re-enable them after the final reboot.
Convention aside: SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A skipped upgrade often leaves context labels out of sync. Run restorecon -Rv / if services refuse to start after the reboot.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use dnf system-upgrade when you need to preserve your current configuration and user data across releases. Use a live ISO installation when the system is heavily customized or the upgrade transaction fails repeatedly. Use a container or virtual machine when you want to test the new release before touching your main hardware. Stay on the current release when your workload is stable and the new features do not justify the maintenance window.