Dist‑upgrade Debian from oldstable to stable

(before LTS support runs out) ∆

I have now dist-upgraded several times, always from (old)stable to stable. Originally written for a Jessie => Stretch upgrade, this text still applies for Buster => Bullseye and likely so on into the future. So just replace "jessie" and "stretch" in this text with your current oldstable/stable release.

Disclaimer: This article is not a complete tutorial, it is simply a set of notes I took down following these instructions.

Today I found out that the debian security team handles oldstable releases only for a year or so, after which the LTS team takes over, which is arguably less secure.
Please see here.

Time to finally dist-upgrade my sturdy kitchenserver, still running on a minimal jessie install!

The release notes for stretch provide copious information on the topic, so that's what I'm going with for now.

According to this, i can use ssh for the upgrade.
However, the computer is sitting in the next room and I can just walk over during reboots and watch the screen. I'd feel a lot less comfortable if that weren't possible.

I have some jessie-backports on my system and one package that is installed locally.
According to the backports FAQ, there's nothing to worry about.
Nevertheless, I booted into the mainline kernel and purged the backported kernel. Now my only backported packages are borgbackup and ffmpeg. Oops, I'm not even using ffmpeg anymore. Purged.
Now purge residual configs also.

Note that the document refered to recommends using apt-get for the upgrade, not aptitude, not apt. I am also recording the upgrading session from now on, as outlined in the same section.

Beware of drama ∆

While 99.9% of the upgrade run smoothly, it's enough to have one outlier to break that experience. For me, it has been postgresql. It requires (or at least recommends) manual migration of databases from one major version to another. The problem is that the binaries for both the old and the new version have to be present for that to succeed, and it happens easily that outdated packages get purged in the upgrade process, requiring me to hunt down the old versions and re-install them.

Step 0: ∆

Change sources: I just removed the jessie-backports section and changed every occurence of jessie to stretch. My /etc/apt/sources.list now looks exactly like this one (only the servers are different).

Step 1: ∆

Minimal upgrade

fail2ban failed.

Rebooting anyway.
My blog still works!
Anyhow, after some searching I found this bug report:

So I had to edit /etc/fail2ban/jail.local to replace [ssh] with [sshd] and [ssh-ddos] with [sshd-ddos]. It fixed the problem.

Step 2: ∆

Full dist-upgrade

Don't walk away, there's quite a few configurations that require your attention and intervention.

Particularly some NGINX configuration under /etc/nginx/sites-enabled requires editing, replacing references to php-7.3 with php-7.4.

Reboot.

Another drama with postgresql.

I'm still on the old kernel. Strange? No, the article tells me what I can do about it.
Another apt-get autoremove --purge, another reboot.
An old kernel version will not show up as "not required anymore" and needs to be purged manually.

Everything still works, no red lights anywhere.