Fedora’s six-month release cycle makes the jump from one stable version to the next a normal maintenance task, not a rebuild. The standard way to upgrade Fedora 43 or Fedora 42 to Fedora 44 is through DNF, which stages the new release, checks dependency conflicts before reboot, and finishes the switch in an offline environment so your users, packages, and configuration stay in place.
Fedora Linux 44 is now the current stable release after the April 28, 2026 announcement, so Fedora 43 systems can use the normal stable upgrade path. Fedora 42 remains a valid skip-release source during the short post-release grace period, but older releases should move through smaller supported jumps.
Upgrade Fedora 43 or 42 to 44 with DNF
This is Fedora’s standard command-line path for Workstation, Server, and minimal installs. If you run an rpm-ostree edition such as Silverblue, Kinoite, or CoreOS, use the rpm-ostree workflow instead of dnf system-upgrade.
Fedora officially supports upgrading to the next release and skipping one release, so Fedora 43 to 44 and Fedora 42 to 44 are both valid paths. Anything older should move forward in smaller supported steps instead of trying to cross several releases in one jump.
The current Fedora references for this release jump are the offline upgrade documentation, the Fedora Linux 44 release announcement, and the Fedora 44 ChangeSet. Use them to separate the upgrade mechanics from release-specific changes that may affect your hardware, desktop, or installed applications.
Back up important data before any release upgrade. Fedora’s offline installer is reliable, but a major version jump still touches kernels, boot entries, and third-party repositories in one transaction.
Confirm the current Fedora release before you start
Check the current release before you queue the Fedora 44 packages. The value from rpm -E %fedora should show the release you are upgrading from, usually Fedora 43 or Fedora 42, which helps catch a system that was already moved or only partly upgraded. The example output below is from a Fedora 43 system; Fedora 42 should report 42 before the same upgrade command is staged.
rpm -E %fedora
cat /etc/fedora-release43 Fedora release 43 (Forty Three)
Update Fedora before the Fedora 44 upgrade
Bring the source Fedora release fully up to date before you download Fedora 44. Fedora uses this step to deliver newer signing keys, package fixes, and upgrade-related bug fixes ahead of the release jump.
sudo dnf upgrade --refreshThese steps use
sudofor tasks that need root privileges. If your account does not have sudo access yet, either switch to the root account or add a user to sudoers on Fedora before you continue.
Reboot after the update so the current kernel and userspace are in sync before the release transaction is staged.
sudo rebootSpeed up the Fedora 44 package download
The release jump can pull several gigabytes of RPMs, especially on Workstation systems with third-party repositories enabled. If you want faster mirror selection before the big download starts, increase DNF speed on Fedora Linux and then come back to the upgrade.
Confirm the system-upgrade commands are available
Current Fedora releases expose the release-upgrade workflow directly through dnf, so verify the command before you look for older DNF4-era plugin package names.
dnf system-upgrade --helpUsage: dnf5 [GLOBAL OPTIONS] system-upgrade <COMMAND> ... Commands: clean Remove any stored offline transaction and delete cached package files. log Show logs from past offline transactions reboot Prepare the system to perform the offline transaction and reboot to start the transaction. status Show status of the current offline transaction download Download everything needed to upgrade to a new release
Download Fedora 44 packages with DNF
Once the source release is current, stage the Fedora 44 transaction with the target release number. The --releasever=44 flag tells DNF to resolve Fedora 44 packages instead of staying on the current release repositories.
sudo dnf system-upgrade download --releasever=44DNF prints a transaction summary with package counts, download size, and any proposed installs, upgrades, downgrades, or removals. Review that summary closely before you confirm the transaction, especially if the system uses COPR repos, browser repos, RPM Fusion, or other third-party sources.
Relevant output includes:
Transaction Summary: Installing: 66 packages Upgrading: 1944 packages Replacing: 1990 packages Removing: 5 packages Downgrading: 40 packages Total size of inbound packages is 2 GiB. Need to download 2 GiB. After this operation, 126 MiB extra will be used (install 6 GiB, remove 6 GiB). Transaction stored to be performed offline. Run `dnf5 offline reboot` to reboot and run the transaction.
Your package counts will differ, but this summary tells you whether the solver reached a clean Fedora 44 transaction or stopped on dependency conflicts before the reboot stage.
Reboot into the Fedora 44 offline upgrade
After the package download completes, trigger the offline installer and let Fedora finish the release jump during reboot. Save your work first because this command reboots immediately into the queued upgrade environment.
sudo dnf system-upgrade rebootCurrent DNF5 builds ask for a final Is this ok [y/N]: confirmation before the reboot starts. DNF5 also exposes the same queued job through dnf offline status and dnf offline clean, but dnf system-upgrade reboot remains the direct release-upgrade trigger. Keep laptops on external power until Fedora finishes the second reboot into the new release.
Verify Fedora 44 after the upgrade
Once the system comes back up, run the same version checks again so you know both the release string and the Fedora macro have moved forward.
rpm -E %fedora
cat /etc/fedora-release44 Fedora release 44 (Forty Four)
If those checks match Fedora 44, the release jump is complete and you can move on to cleanup, third-party repository checks, and normal package updates.
Clean up after upgrading to Fedora 44
Fedora usually boots cleanly into the new release without extra work, but a short cleanup pass removes the staged transaction data and any packages DNF no longer needs.
Clear cached Fedora 44 upgrade files
Remove the stored offline transaction once you no longer need to inspect it. This clears cached upgrade metadata and leaves less stale data behind for the next major release jump.
sudo dnf system-upgrade cleanRemove unneeded packages after the Fedora 44 upgrade
After the first successful Fedora 44 boot, let DNF remove dependencies that are no longer required. Review the removal list before you confirm it, because a reused system may still carry packages you installed for one-off testing.
sudo dnf autoremoveFedora’s official upgrade documentation also lists optional post-upgrade checks for retired packages, duplicate packages, old signing keys, dangling symlinks, BIOS GRUB installs, and rescue kernels. Use those targeted tasks only when they match your system; the DNF cleanup in this section is the low-risk pass for most desktops and servers.
Refresh third-party Fedora repositories after the upgrade
If you disabled Chrome, COPR, RPM Fusion, or another vendor repository before the upgrade, turn it back on only after it publishes Fedora 44 metadata. RPM Fusion users can compare their repo layout against install RPM Fusion on Fedora Linux, and you can install DNF Automatic on Fedora for routine package updates between major release jumps.
Troubleshoot Fedora 44 upgrade issues
Most failed Fedora upgrades come down to third-party repositories, dependency conflicts, or SELinux fallout after a long-delayed system update. Work through those cases first before you assume the release itself is broken.
Allow DNF to remove conflicting packages during the Fedora 44 download
If DNF stops on dependency conflicts, rerun the download with --allowerasing. This lets DNF remove packages that do not yet have Fedora 44-compatible builds, so read the proposed removals carefully before you approve them.
sudo dnf system-upgrade download --releasever=44 --allowerasingDisable stale third-party repos before retrying the Fedora 44 download
List the current repo IDs first so you disable the exact source that is blocking the solver. The left column is the repo ID that config-manager setopt expects. The sample output is from Fedora 43; Fedora 42 source systems will show Fedora 42 labels.
dnf repo list --allrepo id repo name status copr:copr.fedorainfracloud.org:phracek:PyCharm Copr repo for PyCharm owned by phracek disabled fedora Fedora 43 - x86_64 enabled fedora-cisco-openh264 Fedora 43 openh264 (From Cisco) - x86_64 enabled fedora-cisco-openh264-debuginfo Fedora 43 openh264 (From Cisco) - x86_64 - Debug disabled fedora-cisco-openh264-source Fedora 43 openh264 (From Cisco) - x86_64 - Source disabled fedora-debuginfo Fedora 43 - x86_64 - Debug disabled fedora-source Fedora 43 - Source disabled google-chrome google-chrome disabled rpmfusion-nonfree-nvidia-driver RPM Fusion for Fedora 43 - Nonfree - NVIDIA Driver disabled
Swap in the repo ID you need to turn off, then rerun the download step. Re-enable the repository only after Fedora 44 is working normally and that source has published Fedora 44 content.
sudo dnf config-manager setopt google-chrome.enabled=0Re-sync packages if Fedora 44 boots with dependency errors
If the system boots but package versions are out of step with the enabled Fedora 44 repositories, run a manual sync. This lines up installed packages with the repositories you currently have enabled.
sudo dnf distro-syncRelabel SELinux if the Fedora 44 reboot exposes policy issues
If services start failing with SELinux denials after the upgrade, queue a full relabel for the next boot. Use this only when you have a genuine SELinux labeling problem, not as a first reaction to every package conflict.
sudo fixfiles -B onbootReboot after the command queues the relabel. The next boot can take noticeably longer while Fedora rewrites file labels across the system.
Conclusion
The system is now Fedora 44 with the same users, applications, and configuration still in place, and the remaining work is usually limited to third-party repos and light cleanup. If you want a closer look at status, clean, and log subcommands after the release jump, review the DNF5 system upgrade command on Fedora, and for everyday package work after the upgrade these DNF5 install examples on Fedora are the more useful follow-up.
It looks like in the FAQ, with the question “Can Fedora 41 jump straight to Fedora 44?”, you meant 42 to 44, not 41 to 44.
Good catch, Gio. That should have read Fedora 42 to 44, not 41 to 44. Skipping one release (42 to 44) is supported, but 41 to 44 would cross two releases. The FAQ has been corrected.