Author: admin

I have been using Fedora Linux since 2008. I would update by re-installation my computers regularly to new versions after end-of-life. Complete, manual re-installs ended in 2018 or 2019 when I started using Fedora’s command line upgrade feature after having observed it in action. Throughout it all, I have sometimes experienced technology change adventures along the way.

I have five active computers, all which were ready to update to Fedora 39 in November, 2023: Three were running on Fedora 37, and two were running Fedora 38. Normally, I try to keep to the same version of Fedora on my fleet of computers — although I will format with the current version of Fedora mid-stream when I format a new or a new to me computer, or a new hard drive or ssd, and try to use a version (that of the majority of computers) until end-of-life, usually roughly 12 to 13 months. I settled on odd numbered versions several years ago, on Fedora 15, by happenstance, and a desire not to be reformatting different computers every six months depending on when their end of life fell.

As such, I proceeded to upgrade my computers.

Since the recommended method of update for Fedora is by the command line DNF upgrade command (here’s my archive), or to use the graphical method in the “Software” “App Store”, I proceeded to upgrade my machines on the command line.

(Note: Some of the screenshots and photos used in this post were created during the various upgrades, while some were re-created ex post facto for the sake of mounting this narrative.)

Webserver: Fedora 37, Workstation Edition, Legacy BIOS (Dell Vostro 420 Series)

First, I updated my home web server using the above-cited DNF upgrade commands (as root; see further down in this post) :

dnf upgrade --refresh
dnf system-upgrade download --releasever=39
dnf system-upgrade reboot

Note that the upgrade plugin was already present on the server, hence my having omitted the step of installing the plugin. Important note, minor in my head although critical to my experience, is that my webserver uses the Workstation Edition, not the Server edition.

All went smoothly, with one small quirk: After the upgrade and later that evening while at a restaurant, I wanted to check my website for something, and it was down. I thought little of it beyond the frustration in the moment. When I got home, I let my brother know in the hopes he might help … but in the process, I saw that the machine’s light in the power button was amber, and I had an idea that there was a software power management issue. I pressed the button, and the machine popped to life; I then went into the power management part of the settings in the gnome settings, and found the “automatic suspend” setting had been turned on to “when idle”.

This was odd. This was an established system I originally installed back in April, 2021, when I upgraded the machine’s mechanical hard drive to an SSD. To be clear, powersaving on idle was *not* a previous setting (ie. the server was always to be on to be a 24/7 webserver, the machine’s only active function, besides its passive function as a backup server), and it appears to have been a change in default settings somewhere around Fedora 38; it appears to be a power saving policy (here’s my archive).

VPN Server: Fedora 38, Server Edition, Legacy BIOS (HP Compaq dc7700 Small Form Factor)

My next upgrade was also fairly simple and straightforward. It was on a machine I found in a building slated for demolition in about 2016, and is a P4-3.4GHz single core machine, which I had been using as a world community grid node for years, but which had been inactive for months, after there having been little work for it for months when WCG moved from IBM to the University of Toronto. (I also suspect that the UofT may have decided to shift most of its tasks to GPUs, which I don’t think the machine possesses, and in any case I did not properly research let alone confirm this, beyond the apparent lack of work units being sent to it.)

A problem I’d been having for years with this machine was that it would not reboot without manual intervention, apparently due to a time error; this suggested a dead bios battery. I tolerated this for years, but this summer I finally installed a new battery in the machine, resolving the issue.

I reformatted the machine with Fedora 38 Server Edition given its age and lack of memory, and I renamed the machine, having some misgivings about its former name. I offered its use to my brother, who uses it as a VPN server for the household here, particularly to simplify assisting our mother in her computer use. I generally leave the machine alone: VPNs are a nebulous thing I don’t understand very much at all; I understand SSH filesystem tunnelling, and the parts between that and VPNs are too nebulous for me to understand.

But to wit: Up to this point I was neglecting the machine, letting my brother deal with it, but as a result the machine would often go unupdated for weeks at a time. In mentioning that I’d embarked upon the process of upgrading my computers all to Fedora 39, I mentioned that I liked to keep my fleet of computers all aligned on the same version of Fedora; I mentioned that at that time, due to new installs, I had two out of five computers on Fedora 38, while the rest were still on Fedora 37. With the comment that I wanted to keep my fleet on the same version, my brother encouraged me to maintain responsibilities for updates and yes indeed to upgrade this machine in particular, to keep it in line with the rest of my computers.

As mentioned, the upgrade went smoothly and with one exception was rather unremarkable: The suspend on idle mentioned earlier was not invoked, which I learned while researching the issue above is a feature not invoked in the Fedora Server Edition (here’s my archive).

Dell XPS 13 Laptop: Fedora 37, Workstation Edition, UEFI

Next, I updated my Dell XPS 13 (note: 2021). Again, this was an easy process with the dnf upgrade command.

One of the items to do in a couple of lists to do after installing Fedora 39, “17 Things to Do After Installing Fedora 39” (here’s my archive) and “Things to do after installing Fedora 39 Workstation” (here’s my archive) was to do firmware updates, using the following commands:

sudo fwupdmgr refresh –force
sudo fwupdmgr get-updates
sudo fwupdmgr update

Which, of course, I did. (There were indeed some firmware updates to be installed.)

Here’s what the process looks like on my XPS13 (Screenshots and photos taken after the fact, on a subsequent series of firmware updates):

At this point, I was invigorated by being able to perform firmware updates on my XPS 13 laptop (which admittedly had not been the first time I had done so under linux, but no matter.)

However, a couple of weeks later, I noticed that an extension wasn’t working: My XP13 has a touchscreen display, and Gnome has an onscreen keyboard that pops up contextually when text is to be entered, occupying a major amount of screen space; I had been using the “disable-touch-osk” extension by sulincix, which stopped working with the upgrade to Fedora 39.

This leads to a gripe I have for the Gnome developers: Stop breaking extensions with each new version of Gnome, or provide *some* kind of stable API or environment or whatever is needed so that the extension developers don’t decide to abandon their extensions because Gnome keeps on shifting so much that they have to work excessively hard every six months just to maintain their extension.

This led to the next two computers I have, which are a 2015 Acer laptop, and a 2014 Dell Inspiron desktop.

Acer Laptop: Fedora 37, Workstation Edition, UEFI — but using Legacy BIOS

I have been having problems using UEFI in my Acer laptop since I received it new in 2015; the Fedora live media would boot up, and I could install Fedora under UEFI; however, it would never boot up afterwards. My only solution seemed to be to use legacy bios. Nonetheless, hope springs eternal, this was the time to try again to install under UEFI.

I should note at this point, as mentioned above, that my home server (2008) and my VPN server (2007) are both rather old computers and pre-date UEFI and use legacy BIOS, while my XPS 13, Acer laptop, and Dell Inspiron desktop, are all UEFI machines. I make these distinctions because of conversations I had in which on the one hand, it was suggested that I perform a baremetal reformat of the Acer laptop in order to sidestep a problem I had been experiencing when I’d allowed the battery to drain completely, forcing a reset to defaults in the BIOS and hence to UEFI boot, making my setup with legacy-BIOS unbootable; on the other hand, I concluded “It’s 2023; it’s absurd not to be using UEFI on UEFI machines.” (Of course, the use of older, legacy machines predating UEFI are a different issue altogether, and for them, said point is moot.)

In addition to this comment about using UEFI, and the potential to have any UEFI firmware upgrades as discussed above, I decided that my Acer laptop needed to receive a baremetal format, given the accumulation of a lot of software on the system that I didn’t use (many though hardly all installed because of a presentation I gave in 2021); I decided that instead of package hunting and manually uninstalling them all — including dependencies that decide not to uninstall — it seemed more efficient and effective to do a clean install.

Fast forward to this round of upgrades, I upgraded the installation using a downloaded Fedora 39 image, and I went through various upgrades and setups, such as Gnome extensions, and some software installations. Suddenly I remembered that I had not changed the boot sequence from legacy bios to UEFI, so … I started over.

Several installation attempts later, including trying Fedora 36 (with an intention of upgrading through to version 39) based on some advice playing around with the various BIOS settings trying to get just “the right” settings, none worked, and I finally resigned to reinstalling yet again under, and continuing to use, legacy BIOS. Sigh.

Before setting up in legacy mode, I had a flash of inspiration: Since I was nonetheless able to boot the live media under UEFI (which I knew wouldn’t otherwise be used afterwards), I attempted a firmware update as per the above. To my mild disappointment, there weren’t any firmware updates for my Acer Laptop:

I continued with the installation under Legacy BIOS mode, and set up the desktop with the various Gnome Extensions, installing software not in the base installation, and customizing settings and the like.

I once again faced a few pet peeves I have about how Fedora is set up (incidentally through Anaconda, but by itself not Anaconda issues, best I can tell):

• A long time ago, for Fedora 21 at the latest, Fedora stopped listing my home city of Montreal in Anaconda. Sigh. (I think I choose New York, which is in the same time zone.)

• Fedora uses sudo by default, which I don’t like: I go by the notion of “Don’t be afraid of root; respect it, but don’t be afraid of it” — when you have to do root-y stuff, log into root, do what you have to do as root, and then sign out of root. (Yes, I am aware of the advantages of sudo, even beyond its convenience and short term elevations of privileges, such as logging of *who* elevated their privileges to do *what*; I just wasn’t taught that way, and on a single user system, I don’t see much value to it; hey maybe that’s just me.) As such, with each new install I perform, I have to, ironically using sudo under my default user account, assign a password to the root account, and then, remove my default account from the wheel group.

First, a password was set for the root user:

Then, after logging into the root account, I edited the /etc/group file (here’s my archive) …

… by removing my user account from the wheel group (highlighted):

• The next thing that irked me was that in Fedora Workstation Edition, it seems that Anaconda no longer has an option (read, without the qualifier “it seems”) to set the hostname during the installation. While I understand that it is a trivial enough thing to set as per the following, under the default régime of the default primary user having sudo privileges … it seems to me that this is the kind of thing that should still be in the system installation part. (As in, I wonder how many new users have “fedora” as their machine name for a significant amount of time if not forever, being unaware that it is (only) a default placeholder name, unaware that it can be changed, and unaware of how to change it.)

Fortunately, this is easily set in the Settings / About menu, *if* you don’t remove your default user from the wheel group, or at least haven’t yet, and therefore still have sudo privileges:

Note that in the above screenshot, the option appears shaded out because since I had already removed the primary user from the wheel group, effectively disabling sudo, my (default user) account did not possess the requisite permissions to edit the hostname.

Changing the hostname on the command line is also not particularly difficult, using the command “hostnamectl set-hostname new-name”

… or, editing the /etc/hostname file, by entering the command “nano /etc/hostname” as the at the command line and as the root user:

Then, once in the /etc/hostname file, enter the host name you want (in the case of my Acer laptop, “reliant”, as in the USS Reliant from Star Trek: The Wrath of Khan movie.)

(More on changing the hostname can be found at the Fedora documentation page (here’s my archive) and techadmin.net (here’s my archive), among many other sites)

And on this install, I noticed that the extension Vertical Overview by Ralthuis, which among other things, allowed for the dock on the Activities page to remain vertical and on the left edge of the screen, instead of on the bottom of the screen, was broken, something I hadn’t noticed when upgrading my XPS13. Note: Check lower down in the section for my desktop.

On this point, I installed a number of Gnome extensions that I like, unfortunately not the one mentioned above, as well as adding apps to the dock, and other optimizations I commonly perform.

After these items, I installed Gnome Evolution, modified the installation’s setup such as pinning apps to the dock, and checked the power management issue listed above. During the install process, I was able to specify that third party repositories could be enabled; after install, I installed the free and non-free repositories from rpmfusion, as well as Rémi’s RPM repository. I transferred my data from the backup I had created earlier onto my laptop. (See next section on my Desktop).

Finally, I had to activate the flathub repository (here’s my archive) in order to be able to install software that I use that is distributed as flatpaks, such as Signal (a secure texting app):

… and then Signal was installed from the Software App:

Minor note: I don’t recall having to enable the flatpak.org repositories before, although I may be wrong.

This leads to my final computer to upgrade, my desktop:

Dell Inspiron: Fedora 38, Workstation Edition; installed Legacy BIOS, Machine UEFI

When I purchased the computer new in 2014, Fedora 21 installed easily under UEFI.

In the summer of 2023, I upgraded the mechanical drive to an SSD, and I had installed Fedora 38 the SSD; the Dell Inspiron had difficulty recognizing Fedora 38 media, so I took an old pre-UEFI computer, inserted the SSD, and installed Fedora on the SSD. I don’t recall if I knew to change to legacy BIOS once I transferred the SSD to the Dell, or after an error or two, I realized the error, and made the change in the setup. The installation worked, although I was slightly irked.

Come time to upgrade to Fedora 39, I performed the command line DNF upgrade covered earlier, dealing with some of the consequences like the power management and idling issue above. Additionnaly, I noticed something else that irked me regarding the power button (changing it from “Suspend” to “Power Off”:

However, in the intervening time I had experienced the UEFI crisis above, so I first performed a backup of my data to my backup folders on my web server, mildly surprised by how much I was behind in my manual backups.

Unfortunately from this point on, my desktop proved to be the most challenging to upgrade properly.

Having downloaded a copy of the install media for Fedora 39 and burned it onto a usb stick, as well as still having the Fedora 38 Server Edition DVD (which I had forgotten was the F38 Server Edition, instead erroneously assuming that I had gone to the trouble of burning the F39 Workstation Edition onto the DVD), and I tried to install Fedora 39 from both media. I tried several settings in the setup menu, to no avail: The motherboard categorically refused to recognize either, simply displaying an error message vaguely communicating a sense that it didn’t like the media. In looking through the internet for pages on the subject, including the Dell website, I was mildly piqued that solutions commonly referenced burning the usb stick using particular software under Windows (to which strictly speaking I have access, but not on the computer in question), and often just assuming that there would be a Windows partition on the computer. Putting aside knee-jerk reactions, I assumed that this would not address the issue since the solutions appeared to assume a conflict with Windows which could not exist on my machine, or that the Fedora media-writing tools were inherently unable to operate correctly.

I gave up for the moment, changed the boot settings back to Legacy BIOS, and used the untouched Legacy BIOS install for roughly a week while dealing with other upgrades and life in general.

After roughly up to a week, I remembered something I’d read a week or two earlier that said that the UEFI shim for Fedora versions 37 and 38 (and I presume, given my experience, Fedora 39 as well), was not working for some motherboards “due to a difficult certification process for this component“, (here’s my archive) and that a workaround was to install Fedora 36, whose shim was known to work, then proceed through the command line upgrades to Fedora 39.

Fedora 36 was downloaded and burned on a usb stick, and the settings in the boot menu were changed back to UEFI. Fedora 36 was installed — successfully! …

… and the updates were performed, after which the command for the version upgrade was performed, to bring it to Fedora 38. However, the system would not reboot on its own; a quick fsck command corrected some “dirty code”, which it corrected, and I changed some boot settings about booting and automatic on at certain dates. Once this was done, the upgrade to Fedora 38 continued:

I again performed a dnf upgrade to Fedora 39, and had to repeat the fsck command in order for the system to properly reboot.

To correct this rebooting issue, an empty file named “fsck” was created in my home directory.

Backups were restored, and work similar to what I’d performed on my Acer laptop were performed regarding sudo, root, renaming of the box, evolution, extensions, pinning apps to the dock, and the like were performed.

After yet another week or so, I noticed that my backups had not fully been transferred, and began transferring the balance. In the process, my computer indicated that it did not have enough space on the hard drive; I suspected that during the previous install that I had not correctly removed the previous install, so I reformatted yet again.

So I repeated the installation and upgrade process, this time ensuring that all space on the drive was reclaimed, and repeated the above processes, both specific to the computer as well as other things generally required as part of the upgrade.

During the initial setup, I discovered an extension that brings back the vertical view: V-Shell (vertical workspaces) by GdH, and it seems to do what I want, although on the desktop there is a setting that brings up the (vertical) dock, workspaces, and app search space over the workspace; comparison with another setup allowed me to find the setting I wanted.

And, to repeat myself: Gnome, do you hear me? Stop breaking extensions!

Now — so far — the computer seems to be working, but as this whole process over a month has shown, I should give it at least a week to find out if there are any other issues.

Final Thoughts

I don’t read the upcoming changes for new versions, nor do I research in advance problems that people have been having. I discover the problems, changes, and challenges along the way, and as such for me Fedora reveals itself as per my usage and discoveries — no doubt leaving a lot hidden to me — not only over its roughly 13 month lifespan, but also over the first few weeks of using it, and, interestingly, over the installation process itself, especially when it’s over several machines of different eras and manufacturers and technologies.

As this round of upgrades in particular has shown, as well as years of using Fedora Linux, using Fedora Linux is an exercise in bleeding edge.

Now, barring unforeseen changes, additions, and the like, I’m looking forward to roughly a year of Fedora 39 goodness!