Why Fedora version upgrades are complicated and painful for me

September 7, 2020

It's September and I still haven't upgraded any of my machines to Fedora 32 (which came out at the end of April). If I delay too much longer, I might run into Fedora 33 coming out and Fedora 31 dropping out of my upgrade path, so I really need to start getting moving on this. But, much like why updating my Fedora kernels is complicated, my Fedora version updates are a drag; complex, time consuming, and periodically painful. So I keep not getting around to it.

(In a normal year, I would have spent a slow afternoon at work to upgrade the work machine, in an environment where having it not work is not completely disruptive, then upgraded the home machine. That's not today's environment; now I'm at home, and my home desktop is also my DSL gateway.)

Normal people have sensible straightforward Fedora upgrade processes. They start the upgrade in one of the official methods, go away for a an hour or three, and it all works. Because my machines run such an unusual and custom set of environments, I don't trust this process and I also don't want to be without either my home desktop or my work desktop for several hours. So the first complication of my upgrades is that I do live upgrades using dnf and during them, I watch dnf's output to see if there are signs of problems with package updates. I can do other things during this, but that's more than an hour where I am basically babysitting the machine while distracting myself every so often. This is a time sink and not a terribly pleasant way to spend my time, but it's probably the least of the upgrade's pain. Doing upgrades in an unofficial way on an unusual system configuration also raises the risks that something will break during them, and I can never completely test this in advance (for example).

(I capture all the dnf output by using script so that I can also look at it later, but there's no good way that I know of to scan through the result the way I could with a more straightforward log file. Something like less will show me the raw output, complete with progress bars being rendered and so on. And my terminal windows only have so much backscroll.)

The next big complication is that I use ZFS on Linux for my home directory and other critical things, and it's of course not integrated with Fedora. This means there's always a risk of something going wrong with my ZFS setup during a Fedora version upgrade. To deal with this, I 'preflight' my Fedora version upgrades extensively on virtual machines (which helps deal with the 'will they work in general' issue). This takes its own set of time and preparation work, and is its own kind of little slog.

Finally, upgrading Fedora sometimes creates problems in my custom desktop environment (or non-environment) that I'll have to then sort out (for example). These range from somewhat modest, such as font rendering issues, to significant, such as sound not working any more. In extreme cases, my desktop environment won't start at all and I get to spend some time sorting things out. This means that I can only start the upgrade on a day when I feel that I have that kind of time left in the day, and I have to be up to dealing with various kinds of irritation about my environment exploding.

There really isn't anything that can be done about all of this, and it's really all a pain that I've set myself up for through my own machine setup choices. So some time, I just have to say that I'm spending this afternoon (or this day) on the work, and get it done (and I'm hoping that writing this entry will help push me forward on it).

(Sometimes I wonder if tracking Fedora Rawhide would make my life easier by spreading this time and effort out over a longer time, instead of concentrating it all in a few days. But Rawhide's potential for serious bugs discourages me. What I really want is a rolling release of 'stable' Fedora, with no big bangs of major releases, but this will probably never exist. There are sensible reasons for distributions to like the idea of major releases, but that's for another entry.)


Comments on this page:

There are a couple of approaches you could take that could reduce your pain.

  • Start tracking the next release at the branch point. Rawhide on your test machines would help catch issues sooner, but it would also expose you to issue that get fixed prior to release. A "safer" way would be to start working out your test machines when we branch the next release from Rawhide. At that point, all of the big changes should have landed (or be close), so you're working with what will be the GA release. We branch ~2 months before GA, so that let's you run your tests more leisurely. (And helps us catch bugs that may bite others)
  • Run an ostree-based variant. Full disclosure: I don't know how well your customizatiions like ZFS would work with this. Using Fedora CoreOS (for servers) or Fedora Silverblue (workstations) would give you the ability to roll back your filesystem to a previous version if there are problems. The downside is that it requires learning a new management paradigm.
  • Run CentOS Linux (or CentOS Stream!) with EPEL packages. This gives you a stable base with more up-to-date userland packages. Of course, if you're choosing Fedora over those options for the base, then this may be a non-starter.

What I really want is a rolling release of 'stable' Fedora, with no big bangs of major releases, but this will probably never exist.

I have a lot of Opinions about this. The short version is that those ideas are, at some level, incompatible. The long version requires me to put more thought into it and may become a blog post at some point.

(I capture all the dnf output by using script so that I can also look at it later, but there's no good way that I know of to scan through the result the way I could with a more straightforward log file. Something like less will show me the raw output, complete with progress bars being rendered and so on. And my terminal windows only have so much backscroll.)

If you can describe your desired experience, I can talk to the DNF team to see if that's something they can put on the roadmap. Feel free to email me (bcotton AT redhat DOT com) if you'd like.

Written on 07 September 2020.
« URL query parameters and how laxness creates de facto requirements on the web
What you should do about extra query parameters on your URLs »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Sep 7 23:50:37 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.