2020-04-05
My normal process for upgrading from one Fedora version to another
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).
Why it's very bad for applications to start themselves automatically
Yesterday I was quite grumpy at Microsoft Teams on Linux for automatically starting itself when you logged in (without having you set it to do this), among other things. It may not be obvious why this is such a bad thing, so today I'm going to cover the two levels of why this is a terrible idea (and why it's a worse idea on Linux and other free operating systems).
On the level of an individual application, automatically starting up on login, boot, unsuspend, screen unlock, or whatever is both a resource hit and an intrusion into your work. Merely starting an application (especially a heavyweight Electron based one like Teams) uses up CPU time and power (which may be in limited supply on a laptop running on battery power), and grabs memory memory from other things. For you, the unprompted, unasked for application is an intrusion into bringing up your regular environment; you must stop to dismiss its windows and shut it down, which of course involves waiting for it to start up (most applications can't be shot down immediately from their startup splash screens). You want to get to work but instead the auto-starting application is demanding that you pay attention to it. That's a terrible user experience.
On a collective level, allowing applications to start automatically when they're not asked for is a disaster for the overall system ecology. On my Fedora Linux laptop where Teams did this, there are at least a half a dozen applications that have a plausible claim to be central to work so that they should auto-start just like Teams; off the top of my head there's a mail program (Thunderbird), a browser (Firefox or Chrome), an office suite (LibreOffice), I'm sure I have at least one IDE installed, probably the Zoom client would consider itself that important, and if I had Slack I'm sure that would be on there too. And there are definitely plenty of applications that would like to consider themselves that important.
If even half of these applications decided to autostart like Teams, logging in would be an absolutely terrible experience. If they all opened windows on the desktop, your desktop would be carpeted with unwanted windows and a machine with modest resources might take a minute or more to get them all running (and thrash itself to death) from all of the competing claims for resources. Even if they just created little applets in your system tray, it would still be very bad; your system tray would be taken over by them all and their clutter. And it would still burn a bunch of CPU, power, and so on for things that you didn't want.
Free software and free applications make this worse, because it's much easier to accumulate more applications. You'll probably only purchase so many programs, but free ones can add up far more readily. A commercial, paid office suite is only installed for people who've paid for it, not everyone with Microsoft Windows; meanwhile, most Linux desktops probably have one of the free office suites installed just because.