Updating to Fedora 42
So Fedora 0b101010 was released a few days ago as of today and, given both of its short support time for non-current releases and my will to try out the new stuff, I decided it was time to attempt the update myself.
After a decade of pondering whether to try it or not, I finally decided to give this distro a more serious try after realizing it was one of the few that could run on a Secure Boot-only machine I have, and since then I came to grow a bit more fond of Fedora 41. With the new release already available, so came the time to another challenge: cross-release updating.
Full updates when you're not running a rolling release are often a little scary, as you're essentially changing from the "works for me" state into an unknown. But I've done it in several OSes before and it should not be the case that Fedora's way is much different, right? So arming myself with the recommended procedure to update from the command-line, I delved right in.
"Offline upgrading"
The recommended (and perhaps sole official) method outlined by the Fedora Documentation is called, explicitly, Offline upgrading. This was little confusing to me in the beginning since the name makes me think about using external media to supply new files and stuff, but that had nothing to do with it.
Instead, "offline" here means that you only perform the update after all required files have been downloaded to your local disk. This is in contrast with, for example, Alpine Linux's mechanism, which "streams" the new packages straight to their destination with no caching.
As you'll download a hefty amount of data (my update was about 5GiB, thanks, file bloat!), offline indeed seems to be the safe way to go, as you'll only proceed when all packages are stored correctly. The downside of this method is that you cannot do anything with the computer while it's ongoing because the actual package updating happens during a reboot. You'll have to sit and wait.
Step 0: BACK IT UP.
Mandatory stop sign right here, before you even think about beginning. When was the last time you backed up you files? Take your time and do it again - now. Who knows what bizarre stuff might happen during an update process? Better safe than sorry, as they say, only that in this case it might be ten or fifty times better.
While you're at it, remember that not only your user files are worth saving. Got the perfect configuration for that program? Then save its configs too. Dotfiles, /etc/ files - get them all.
Step 1: Refresh your packages
The Fedora documentation recommends that you have a fully up-to-date system before attempting to update it to a new point release. The rationale is that things like developer signing keys and other package manager metadata can change, and through an update in place, these are recorded and stored by the package manager. The command is:
# dnf update --refresh
I think the --refresh bit clears any cache and forces a full re-download of metadata, much like running Arch's pacman -Syyu
Also, if you had any big updates with this command just now, reboot your computer before you proceed. The update won't happen this time just yet. But it's a surefire way to guarantee that all patches get applied in time.
Step 2: Download the new packages
Now finally we've got all the requirements to proceed. Updating from a point release to another is also done via dnf. The command is a little different, though. Since the latest version of Fedora as of this writing is 42, this is where we'll be pointing dnf to:
# dnf system-upgrade download --releasever=42
Despite the syntax difference from an update in place, this "feels" very similar to one. dnf will calculate the size of the install, precheck the transaction and download the files, much as usual. However, at the end of the download, it may catch you off-guard because it will force a system reboot. Don't panic, this is how the offline installation works.
One interesting thing that happened to me at this point, however, was that dnf asked me if I trusted a certain PGP key from the Fedora project that had signed the packages. But wasn't the gathering of new keys and all the whole point of performing Step 1 just now? At any rate, unable to validate that key's veracity through another side channel, I simply accepted it. Not the most secure thing to do, but I guess that was alright.
Step 3: Reboot and install
And now we're in the crux of the update: as part of the system boot process, the downloaded packages are being updated in the local system. And yes, this really is happening as part of boot - you can even see the dmesg timestamps prefixing each updated package.
Sadly, this also means that you can't really do anything during this time. But perhaps you shouldn't anyway; system upgrades are a serious thing, a good sysadmin like you should be devoting attention to them!
Finally, at the end of it, another reboot is forced and voilà; you're running the latest Fedora release!
Comparison to other OSes
Fedora's Offline updating is a tad weird when considering other OSes that I've used and maintained over the years, like Debian, Alpine Linux or FreeBSD. If anything, nobody else differentiates between an Online and an Offline method. The decision to tie the updating process to boot is also uncomfortable to me - it reminds me of the creepy way system updates are applied in Windows right as you're trying to shut down the computer (and you are, you know, usually in a hurry to pack the computer to go somewhere and stuff). Couldn't there be a better way to do this?
Otherwise, the process is simple, and has some parallels to the way you update a FreeBSD system to the latest release:
# freebsd-update fetch install -r $LATEST_RELEASE_VER
# reboot
# freebsd-update install # apply the rest of the core system patches
# pkg upgrade # update the user-installed packages
The Fedora way is insteresting because the source repositories also get updated as you run the update. Unlike in, for example Debian or Alpine, you don't have to manually update the repository URLs by hand before running the update. For example, in Alpine:
# vim /etc/apk/repositories # set to latest Alpine version
# apk -U upgrade
On the other hand, Fedora's method will nuke any other additional repositories you might have set, like COPR or RPMFusion. You have to set them up again if you use any.
Conclusion
Updating Fedora between releases is quite simple, even if a little inconvenient. The documentation is quite clear and the steps are easily reproducible. I still have some work to do after jumping to release 42, like setting back the community repositories, but one thing at a time.
Finally, I could not but notice the following bit in my /etc/os-release now:
Better go get a towel before I try anything new!
Have you upgraded to Fedora 42 already? How was it? Do you do it in another method that doesn't require a reboot? Let me know on Mastodon!
This post is number #59 of my #100DaysToOffload project.
Last updated on 04/21/25