Since about 2018 or 2019, I have been using the Fedora upgrade tool (here’s a link to my backup) to upgrade my fleet of computers to new versions of Fedora, normally skipping a version at a time, and having settled on odd numbered versions (as a matter of convenience to take advantage of Fedora’s roughly year long life cycle) since about Fedora 15.
In December 2023, I blogged about upgrading my fleet of five computers — all of which I still have and are still running — from Fedora 37 and 38 to Fedora 39. This included two baremetal installs, which proved to be the most difficult. So, despite the title above, I want to underline that the upgrade tool makes upgrading a breeze, even when there are issues, which are usually trivial, and, usually not difficult to resolve … admittedly, if one has a bit of experience! 🙁
As I recall, the upgrade cycle at the end of 2024 from Fedora 39 to Fedora 41 was rather unremarkable. Meaning, I have no recollection of the experience beyond that it happened, especially given the evidence of having just spent the last year using Fedora 41!
The release of Fedora 43 came around a few weeks ago, and I embarked on the upgrades on a sunday afternoon at the very beginning of November, 2025, and was finished and writing up this blog post by the Tuesday evening a couple of days later.
To begin, I looked up my post from December 2023 as a reference throughout the process, and was constantly referring to the following commands, performed as root:
dnf upgrade --refresh
dnf system-upgrade download --releasever=43
dnf system-upgrade rebootDespite the experience largely being a breeze and relatively unremarkable, I had three distinct problems of note over three systems on the upgrades.
Problem #1: Download of new version blocked by existing packages
On my desktop and later on one of my laptops, I received what was to me cryptic errors about some packages on my systems, which were listed, which somehow blocked the upgrade. Looking around on the internet but before even finding a solution, I recalled that I could add “—allowerasing” to the end of the
dnf system-upgrade download –releasever=43
command to start downloading the packages; this allowed the system upgrades themselves to proceed “like a breeze”. Well, sort of, but not quite.
For what it’s worth, www.debugpoint.com (here is my archive) mentions this workaround.
And here is a screenshot from my desktop post-upgrade, but before I started dealing with Problem #2:
Problem #2: Gnome Extensions causing system to freeze:
According to my recollection, which of course is subjective at this point, one of the points highlighted as a positive in the transition from Gnome 2 to Gnome 3 — in the Fedora world, beginning with Fedora 15 in May, 2011 — was that Gnome 3 was designed to be extensible. (Looking back, this may well have been a concession on the part of the Gnome developers since the code, being open source, naturally lends itself to such, at least in the short term.) This way it allowed both the Gnome developers to present the desktop environment according to their vision, and allow users to modify it to behave as they pleased. From this, for instance, the Cinnamon Desktop, initially really just a heavily extended variant of Gnome 3, was born.
Unfortunately, what has really occurred in my experience — including during this upgrade cycle — is that with just about every upgrade comes breakage of many Gnome 3 extensions; and from this, for instance, the Cinnamon Desktop finally forking itself away from Gnome 3 due to the extensive work they had to do with each release to maintain their extensions and their functionality. As such, I have had many Gnome extensions over the years — which I have gotten directly from extensions.gnome.org to boot! — that have come and gone simply because maintainers could not devote the time to update them for each release. This is doubly frustrating, because:
- on the one hand, I would love Gnome to have some kind of pathway such as stable APIs or whatnot that would keep extensions alive instead of having to be (sometimes massively) rewritten with every release of Gnome, and,
- on the other hand, you get what you pay for, which in my case, is a wonderful operating system for which I paid nothing more than the internet connection to download it, and if I don’t like what I get, I can always change desktop environments — there are several!
To wit, on my desktop, existing and active extensions made the system freeze, usually within roughly 15 minutes or thereabouts: The mouse would not work, they keyboard would not work, the screen would freeze, the time and date display would freeze, and I could not ssh into the machine from another machine. After the third or fourth hard reboot requiring powering down with the power button and after about a day, I noticed a notification window come up after a reboot, saying that there were extensions that needed to be updated; I proceeded with this, and the problem was solved.
Problem #3: Deprecation of X11 would cause systems to not boot into a graphical desktop
On my webserver — the host of this blog! (and which is in my bedroom, not colocated in some datacenter or some virtual machine in a cloud service — I use Fedora Workstation (graphical) instead of the server edition. This is simply because at its core, both editions are essentially the same operating system, and at the time that I installed the current instance, I hadn’t ever used the server edition. Of course, each has different subsets of packages and different settings in their default installations, but at their core, they are the same OS, a few “dnf install” commands and settings away from each other. And, while I indeed normally treat it and administer it as a headless server, there have been a small handful of occasions over the years during which my significantly-less-than-expert abilities have allowed me to do things with it using the graphical desktop that I would have had more difficulty doing on the command line.
At this point I should say that usually, one should do backups before proceeding with the upgrades, a practice that with one exception I don’t normally do.
However, I did do so with my webserver, which is also a passive backup for my data from my other computers … which is a bit out of date, although I expect / hope not substantially.
So I asked my brother to do a backup to his network, which just required a manual differential update, since we had already set up cron jobs to do so:
The next day, I started doing things like dnf updates and then the upgrade. Whaddya know, I got a couple of messages from my brother while I was upgrading. He sent me some screenshots:
My brother has an alert on my website to detect downtime. I told him that I was aware, because I had manually disconnected the external hard drive with the static parts of my website.
Then a few minutes later, I got another message from him:
I responded to him again saying well of course, but I’m still in the process of doing the upgrades!
I went through the upgrade, which seemed to work. Yet, upon the reboot after the upgrade, I got the following screen:
Oddly, it stopped during the reboot. However, I managed to ssh into the machine, as well as check to see if it was able to serve web pages. Both worked.
In the meantime, I also got ambitious and started upgrading one of my laptops. Again, once I’d done the “–allowerasing” addition to the download command (above), and the system went through with the upgrade, I got the following screen:
Fortunately, I was able to ssh into the laptop.
But I was wondering what was going on, especially since both machines appeared to stop at different times — although, I suppose, the webserver had a few other services to start, but that’s beyond what I actually checked.
So I tried to ask on the internet, and the first suggestion I found was on the Fedora discussion boards (somehow I can’t seem to create a proper PDF of it …) suggesting that I modify a shadow file:
This did not work for me.
Another suggestion I found elsewhere was to check what failed, so as root on my server I entered:
systemctl –failed (that’s two dashes, wordpress decided to combine them!)
and I got the following information:
This seemed to tell me that there were issues with starting up the graphical display. I suspected that this could be the same problem I was having on my laptop.
Again on the Fedora project’s discussion boards, I came across the following advice:
The advice was to edit the /etc/gdm/custom.conf file by commenting the line “WalandEnable=false”
With this I remembered that on my webserver and one of my laptops, the windowing system was X.org for historical reasons related to my brother helping me a lot with these systems, and, until recently, X.org was easier for him to remotely help administer those systems if he needed to use the desktop. Alas, X.org has been deprecated in Fedora Workstation Edition using Gnome (here’s my archive), although one can still use it elsewhere in other editions and spins.
Well once the WaylandEnable=false line was commented out, that solved my problem easily on both my webserver, and on the laptop that was affected.
Note about desktop on abovementioned laptop:
Curiously, the laptop’s wallpaper wasn’t changed. In fact, it still has the wallpaper from its original install of Fedora 36 when it was new!
(Maybe I should check the settings to see if something was set to permanent on the wallpapers when it was initially formatted when purchased new. Maybe.)
And yes, on my desktop, my other laptop, and my webserver, which all have the Workstation Edition, the wallpapers upgraded to the Space Shuttle design for Fedora 43. Only the VPN server, which is the Server Edition, doesn’t have any wallpaper at all.
The “Breezy” systems:
And the other two systems I have? Upgrading them was a breeze — an old PIII 3.4 something or other I found in a building slated to be demolished in 2016, now running Fedora Server edition, and currently used as a VPN gate and soon as a backup server, and a 2015 laptop that I still use regularly, including for teleconferencing and videos. Both upgraded like a breeze and without saying boo.
Now for another year of Fedora goodness!