My normal process for upgrading from one Fedora version to another

April 5, 2020

Sensible people have a normal, relatively standard Fedora configuration and upgrade from one Fedora version to another through one of the straightforward, fully supported methods. Neither of those are true for me, at least for my office and home desktops. The officially supported upgrade methods require taking your machine down for the duration of the upgrade, which is generally hours in my case, and I have an unusual system configuration (which goes beyond how updating Fedora kernels is a complicated affair for me). So I normally follow a much more complicated multi-stage process to upgrade my machines.

The first step is to wait while carefully reading the list of common bugs for the just released Fedora version. I never jump into a new Fedora version right away; I always give it at least a week or two to settle down before I even think about upgrading any of my machines, even unimportant ones. If there are any common bugs that look like they'll affect me, I hold off until they're fixed.

I upgrade my Fedora machines using 'dnf distro-sync', with more or less the process documented in Upgrading Fedora using package manager, because I want to watch over the upgrade process and keep using my machine during it and this is the only form of truly live upgrade that Fedora has. But before I upgrade either of my work or my home desktops, I upgrade a series of less important and generally less complicated other machines.

The first upgrade done is on a virtual machine that's a more or less stock Fedora install (with Cinnamon), generally one installed from scratch with the previous Fedora version. This tells me if the live upgrade process works in general and what sort of things happen on a stock system. After that I upgrade my work laptop, which has a pretty standard Cinnamon based install (although one that has been successively upgraded from Fedora version to Fedora version). If all goes well and I don't run into any problems when I use the new Fedora on my laptop for a while, it's time for the main systems.

Both of my desktops have additional risk factors for an upgrade, in that I use ZFS on Linux and Wireguard. I keep a Fedora virtual machine image with this same general setup, and so my first step in upgrading the main machines is to upgrade it and make sure that the result appears to work. Sometimes this requires manually rebuilding DKMS kernel modules after the 'dnf distro-sync' and other things, which is good to find out in advance. After it upgrades cleanly I will finally upgrade my work machine, sort out anything that's now broken in my non-standard desktop environment, and then at some point upgrade my home machine as well.

I do some extra steps in the actual upgrade process on each important machine (my laptop and my two desktops), and deviate from the standard directions. First, I always download packages separately from doing the actual upgrade:

dnf --downloadonly --releasever=NN --setopt=deltarpom=false distro-sync
dnf --releasever=NN --setopt=deltarpom=false distro-sync

The important thing about this is that it makes the start of the actual upgrade have a predictable timing. Downloading all of the required packages can take an unpredictable amount of time; the last thing I want is for the download to run long and box me in to launching into the upgrade at a bad time. It's also easier to sort out package conflicts in two stages.

I run both the package download and the package upgrade under script to capture all of the output, inside a screen session to try to keep things alive if there is a session problem. I live daringly and do this inside X, but I take a series of precautions. First, I always have several additional already open terminal windows, some of them su'd to root. Second, I have additional text mode root logins (and regular logins) on other virtual terminals. Finally, I generally have some SSH sessions from another machine (such as my laptop), one of which is also attached to the screen session doing the upgrade (with 'screen -x'). All of this is intended to give me access to the system if things go wrong; if I can't open new terminals, or can't now su to root, or the entire X server locks up, or whatever. And in the mean time I keep my normal X environment running so I can do productive work rather than have to sit on my hands for what may be hours.

(My Fedora upgrades are much faster now that I live in the world of SSDs and even NVMe drives, but in the past with HDs they could take three or four hours just to install and upgrade all of the packages.)

Generally everything goes smoothly except sorting out a few package dependency issues (usually solved by removing unimportant old packages) and then making my unusual desktop environment work completely again in the new Fedora. It's actually been a while since I had actual upgrade problems (either in the process as a whole or with individual packages having their postinstall or postuninstall scripts go wrong for some reason).

Written on 05 April 2020.
« Why it's very bad for applications to start themselves automatically
Fedora 31 fumbles DNF modules, package updates edition »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Apr 5 22:26:39 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.