Before You Start: Back Up and Plan for Recovery
A release upgrade rewrites the base operating system. The procedure below is well-tested and usually completes without incident, but "usually" is not a recovery plan. Before you run the first command, make sure you can answer all of the following:
- What is your backup? A current, verified backup of
/etc,/home,/var, and anything else this machine is responsible for. If this is a VM or cloud instance, a fresh snapshot of the disk taken immediately before the upgrade. An untested backup is not a backup — confirm you can actually restore from it before you need to. - What is your recovery plan if it fails? You should be able to answer this in one sentence before you start. "Roll back the VM snapshot," "boot the previous kernel from GRUB," "reinstall from ISO and restore
/etc+/homefrom backup" are all valid answers. "Figure it out when it happens" is not. - How do you reach the console if SSH does not come back? On a remote server, confirm you have a working out-of-band path — IPMI, iDRAC/iLO, the cloud provider's web console, KVM-over-IP, or physical access. Test it before you start. If your only way onto the machine is SSH and the upgrade breaks networking, you are stuck.
- Is now the right time? An upgrade is not an emergency. If this machine is running anything critical, schedule a maintenance window, notify whoever needs to know, and do it when a 30-minute outage (or a longer one, if something goes wrong) is acceptable.
None of this is unique to Fedora — it applies to any in-place OS upgrade on any distribution. Take the few minutes to confirm all four before you begin.
TL;DR
The full upgrade, as five commands:
sudo dnf upgrade --refresh -y
sudo systemctl reboot
sudo dnf system-upgrade download --releasever=44 -y
sudo dnf5 offline reboot -y
cat /etc/fedora-releaseWhy This Matters
In-Place Upgrades Are the Supported Path
Fedora releases roughly every six months and supports each release for about 13 months. Once your release falls out of support, you stop receiving security updates — which is reason enough on its own to keep moving forward. The supported path is an in-place upgrade using the dnf system-upgrade plugin: no reinstall, no media, no data migration. Configuration in /etc, user data in /home, and everything in /var stay where they are; only the OS packages get replaced.
There is no need to step through intermediate releases. The tooling supports jumping directly from one release to the next — and Fedora's policy permits skipping a release as well (e.g. 42 → 44). This guide covers the standard one-release jump: 43 → 44.
Why dnf system-upgrade and Not Just --releasever=44
It is technically possible to run dnf upgrade --releasever=44 on a live system and replace every package without a special reboot. Do not do this. A live cross-release upgrade tries to swap glibc, systemd, the kernel, and every shared library out from under the running processes that are using them. The system frequently survives this, but when it doesn't the failure mode is a half-upgraded machine with no working package manager — exactly the state you cannot recover from without a rescue disk.
The system-upgrade plugin solves this by splitting the work into two phases: a download phase that stages the new packages on the running system without touching anything, and an offline reboot phase that installs them from a minimal early-boot environment where nothing else is running. This is the only safe, supported way to do it.
Every command in this guide is run as a regular user with sudo. If you are still logging in as root, see Adding a New User on Fedora 44+ first.
How the Offline Upgrade Works
The offline upgrade flow has three moving pieces:
dnf system-upgrade downloadresolves the cross-release transaction against the target release's repositories and downloads every package — including every dependency change — into the DNF cache. The running system is not modified.dnf5 offline rebootmarks the staged transaction for execution and reboots into a special early-boot systemd target. At that point the kernel and a tiny userspace are running, but no services, no networking, no shells, and none of the packages being replaced. DNF can swap glibc out from under itself safely because nothing else is using it.- Automatic reboot happens when the offline transaction finishes. The system comes back up running the new release with the new kernel, the new init system, and the new userspace.
On Fedora 41+, dnf is dnf5 — the legacydnf-3 binary is gone. The download phase still uses the historical dnf system-upgrade subcommand, while the reboot/apply phase moved to the new top-level dnf5 offline command set. They operate on the same staged transaction, so the two commands compose cleanly.
Step 1 — Update the Current System
Bring the existing Fedora 43 install fully up to date before attempting the release upgrade. Starting from a current system minimizes the size of the cross-release transaction and avoids package conflicts caused by stale local versions that have already been superseded upstream.
sudo dnf upgrade --refresh -y- upgrade applies all pending package updates from the currently configured (Fedora 43) repositories.
- --refresh forces DNF to re-download repository metadata instead of trusting the cached copy. The default metadata cache lifetime is hours long, and you want to be certain you are starting from the repositories' actual current state — not a snapshot from this morning.
- -y auto-confirms the transaction. Safe to use here because the action is just "catch up on the current release."
If this command pulls in a new kernel, that is expected and fine — the reboot in the next step will land you on it before you start the actual release upgrade.
Step 2 — Reboot
Reboot to make sure the system is in a clean state before something as large as a release upgrade. The upgrade itself will reboot the machine anyway, so this is not adding any meaningful time to the process — and it gives you a known-good baseline if anything goes wrong in the next step.
sudo systemctl rebootTwo specific things this reboot catches:
- A new kernel actually boots. If Step 1 installed a kernel that does not boot on this hardware or VM, you want to discover that now — when you can fall back to the previous kernel in GRUB — not after you have rewritten the rest of the OS on top of it.
- Services come back cleanly. Long-running services sometimes accumulate state that survives a configuration change but not a restart. Catching a broken unit file or a misbehaving service on the existing release is much easier than disentangling it from a release upgrade.
Reboot now even if Step 1 did not install a new kernel. The point is to confirm the existing system comes up cleanly on its own — not to load new code. If it does not come back up, you want to know before you start rewriting the OS.
Step 3 — Download Fedora 44
Stage the Fedora 44 packages for the offline upgrade. This step resolves the entire cross-release transaction — every package that needs to be added, removed, or replaced — and downloads them into the DNF cache. Nothing on the running system is modified yet.
sudo dnf system-upgrade download --releasever=44 -y- system-upgrade download is the plugin subcommand that performs the cross-release dependency solve and downloads the result into a staging area DNF will read back during the offline phase.
- --releasever=44 sets the target release. DNF uses this variable when expanding the
$releaseverplaceholder in.repofiles, so every Fedora repository on the system is pointed at its Fedora 44 mirror for the duration of this command. - -y auto-confirms the staging. The actual upgrade still requires the explicit reboot in the next step, so
-yhere only skips the "download all of this?" prompt.
If the download stops because a third-party repository has not published Fedora 44 packages yet, you have two options: wait for the vendor to catch up, or temporarily disable the repo with --disablerepo=<repo-id> and re-enable it once it publishes. Common offenders are RPM Fusion (usually caught up within a day or two of release) and vendor repos like Microsoft, Docker, or NVIDIA.
This step does not require a reboot afterwards. The staged transaction sits in the DNF cache indefinitely — you can run the download in the morning and apply it that evening if you want to schedule the actual cutover for off-hours.
Step 4 — Reboot and Apply the Upgrade
Trigger the offline transaction. This reboots into the early-boot upgrade environment, installs the staged packages with nothing else running, and then reboots a second time into Fedora 44.
sudo dnf5 offline reboot -y- offline reboot tells
dnf5to enable thesystem-update.targetsystemd target on the next boot and then reboot. When the system comes up into that target, only the bare minimum is running — no networking, no login services, no application stack — and DNF applies the staged transaction in that environment. - -y skips the "are you sure you want to reboot now?" confirmation. The package installation itself is non-interactive.
Do not interrupt the upgrade. Once the offline transaction starts, let it run to completion. The screen will show a Plymouth progress bar as packages are installed; depending on the size of the install and the speed of the disk, this typically takes 5–20 minutes. The system reboots automatically when it is finished. Powering the machine off in the middle of this is the one reliable way to corrupt the install.
If you want to watch the actual log output instead of the Plymouth splash screen, press Esc during the upgrade to drop to the text console. The transaction is logged in real time and will give you a much better idea of where it is in the process.
Step 5 — Verify
Once the system comes back up, log in and confirm you are on Fedora 44.
cat /etc/fedora-releaseThe output should read:
Fedora release 44 (Server Edition)The edition label — Server Edition, Workstation Edition, Cloud Edition, etc. — depends on which spin you originally installed and will not change across a release upgrade.
A couple of additional sanity checks worth running before you consider the upgrade done:
uname -r
sudo systemctl --failed- uname -r confirms you are running a Fedora 44 kernel (the version string will end in
.fc44). - systemctl --failed lists any services that did not start after the upgrade. The output should be empty. If anything shows up, that is where to look first — it is almost always either a third-party package that needs to be reinstalled against the new libraries or a config file in
/etcthat was kept as.rpmsaveand needs to be reconciled with a new.rpmnew.
Additional Notes
Check for Leftover Packages
After a release upgrade, you may have packages installed that are no longer in any enabled Fedora 44 repository — typically things from third-party repos that have not yet published for the new release, or packages that were dropped upstream.
sudo dnf repoquery --extras
sudo dnf repoquery --unsatisfied- --extras lists installed packages that no enabled repository currently provides. These are not broken, but they will not receive updates until the source repo catches up.
- --unsatisfied lists installed packages whose dependencies are no longer met. These are broken and need attention — usually by reinstalling against the new release or removing them.
Reconcile Config File Differences
When RPM installs a new version of a package whose configuration file in /etc has been locally modified, it leaves your edited file in place and writes the new packaged version as a sibling with the .rpmnew suffix. Conversely, if RPM decides it has to replace your file, your old one is preserved as .rpmsave. After a release upgrade, both kinds tend to accumulate and should be reviewed.
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'Diff each pair, merge in whatever you need, and delete the leftover file. Leaving .rpmnew files unreviewed is the most common source of post-upgrade misconfiguration.
Clean Up Old Kernels
The upgrade installs a new Fedora 44 kernel but leaves the last few Fedora 43 kernels in place as a fallback. Once you have confirmed the system is stable on the new kernel, you can let DNF prune them on the normal retention schedule, or remove them explicitly:
sudo dnf remove --oldinstallonlyThis removes every "installonly" package (kernels and a handful of others) except the count configured by installonly_limit in /etc/dnf/dnf.conf — by default, the three most recent.
Refresh the Rescue Kernel (Optional)
Fedora installs ship with a rescue kernel and initramfs in /boot — the entries labeled 0-rescue-*, which GRUB falls back to when none of the regular kernels boot. The rescue image is generated once at install time and is not regenerated by ordinary kernel updates. After a release upgrade it is still the rescue image from your original install — potentially years old, and unlikely to play nicely with your current /etc, drivers, or storage stack.
Check the rescue image's modification time:
stat -c '%y %n' /boot/vmlinuz-*rescue*If the date matches the day this machine was originally installed (often years ago), the rescue image is stale and should be regenerated. First remove the stale rescue files — both the kernel and its initramfs:
sudo rm /boot/vmlinuz-0-rescue-* /boot/initramfs-0-rescue-*Then reinstall kernel-core. The kernel-install scripts notice that no rescue image exists and recreate one as part of the install:
sudo dnf reinstall kernel-core -yRe-run the stat command — the date should now match today:
stat -c '%y %n' /boot/vmlinuz-*rescue*Why bother: if a future kernel update breaks boot — bad out-of-tree driver, broken initramfs, anything — the rescue entry in GRUB is your in-the-box recovery path before you have to reach for a snapshot or rescue ISO. A rescue image that matches your current OS is dramatically more useful than one frozen at the install state.
Sample output of the full sequence on a Fedora 44 host (the date in the first stat is the original install date; the second stat after kernel-core reinstall shows the freshly generated rescue image):
[jbusch@vm01 ~]$ stat -c '%y %n' /boot/vmlinuz-*rescue*
2024-06-03 16:39:14.041247832 -0500 /boot/vmlinuz-0-rescue-c0f2d81387814b059811f23cad88067f
[jbusch@vm01 ~]$ sudo rm /boot/vmlinuz-0-rescue-* /boot/initramfs-0-rescue-*
sudo dnf reinstall kernel-core -y
stat -c '%y %n' /boot/vmlinuz-*rescue*
Updating and loading repositories:
Repositories loaded.
Package Arch Version Repository Size
Reinstalling:
kernel-core x86_64 0:7.0.4-200.fc44 updates 99.1 MiB
replacing kernel-core x86_64 0:7.0.4-200.fc44 updates 99.1 MiB
Transaction Summary:
Reinstalling: 1 package
Replacing: 1 package
Total size of inbound packages is 20 MiB. Need to download 20 MiB.
After this operation, 0 B extra will be used (install 99 MiB, remove 99 MiB).
[1/1] kernel-core-0:7.0.4-200.fc44.x86_64 100% | 29.4 MiB/s | 20.4 MiB | 00m01s
------------------------------------------------------------------------------------------------------------------------
[1/1] Total 100% | 20.6 MiB/s | 20.4 MiB | 00m01s
Running transaction
[1/4] Verify package files 100% | 3.0 B/s | 1.0 B | 00m00s
[2/4] Prepare transaction 100% | 20.0 B/s | 2.0 B | 00m00s
[3/4] Reinstalling kernel-core-0:7.0.4-200.fc44.x86_64 100% | 42.9 MiB/s | 29.6 MiB | 00m01s
[4/4] Removing kernel-core-0:7.0.4-200.fc44.x86_64 100% | 0.0 B/s | 17.0 B | 02m17s
Complete!
2026-05-12 10:23:52.951326430 -0500 /boot/vmlinuz-0-rescue-c0f2d81387814b059811f23cad88067f
[jbusch@vm01 ~]$If the System Does Not Come Back Up
If the machine fails to boot after Step 4, reboot and pick the previous Fedora 43 kernel from the GRUB menu. The old kernel and its initramfs are still present, so you can usually boot back into a working state and investigate from there — most commonly a driver that was not rebuilt against the new kernel (NVIDIA, ZFS, VirtualBox) or a custom initramfs hook.
If you cannot reach a console at all, this is where the snapshot you took before Step 1 earns its keep — roll back and try again with the problematic third-party repo disabled in Step 3.