I upgraded my home server from Debian stretch to buster recently, which is something I normally do once we’re frozen: this is a system that was first installed in 1999 and has a lot of complicated stuff on it, and while I try to keep it as cleanly-maintained as I can it still often runs into some interesting problems. Things went largely OK this time round, although there were a few snags of various degrees of severity, some of which weren’t Debian’s fault.
etckeeper made it much more comfortable to make non-trivial
configuration file changes without fearing that I was going to lose information.
apt full-upgradefailed part-way through with “dependency problems prevent processing triggers for desktop-file-utils” for what didn’t seem like a particularly good reason;
dpkg --configure -asorted it out and I was able to resume the upgrade from there. I think I’ve seen a report of this somewhere recently as it rang a bell, though I haven’t yet found it.
I had a number of truly annoying configuration file resolutions to perform. There’s not much to be done about that except try to gradually move things to
.ddirectories where available, and other such strategies to minimise the local differences I’m maintaining.
I had an old backup disk that had failed some time ago but was still plugged in and occasionally generating ATA errors. These made some parts of the upgrade excruciatingly slow, so as soon as I got to a point where I had to reboot anyway I took the opportunity to open up the case and unplug it.
I hit #919621 “lvm2: Update unexpectedly activates system ID check, bypassing impossible”. Fortunately I noticed the problem before rebooting due to warning messages from various things, and I adjusted my LVM configuration to set a system ID matching the one in my volume group. Unfortunately I forgot to run
update-initramfs -uafter doing so, and so I ended up having to use
break=premounton the kernel command line and fix things up in the same way in the initramfs until I could update it properly. I’m not sure what the right fix for this is, although it probably only affects some rather old VGs; I created mine in 2004.
I ran into #924881 “postgresql: buster upgrade breaks older postgresql (9.6) and newer postgresql (11) is also inoperative” (in fact a bug in
ssl-cert). It was correct to reject the snakeoil certificate, but the upgrade failure mode was pretty graceless and it would have been helpful for something to notice the situation and prompt me to regenerate the certificate.
My networking wasn’t happy after the upgrade; I ended up with some missing addresses, which I’m prepared to believe was the fault of my very old and badly-organised
/etc/network/interfacesfile, so I rearranged it to follow what seems to be the modern best practice of handling multiple addresses on an interface by just having one
ifacestanza per address using the same interface name, rather than
pre-up ip addr addlines or alias interfaces or anything like that. After that, the interface sometimes refused to come up at all with “ADDRCONF(NETDEV_UP): eth0: link is not ready” messages. Some web-searching and grepping of the kernel source led me to the idea that listing
inetstanzas for a given interface name was likely to be helpful, and so it proved: I now have an
/etc/network/interfacesthat both works and is much easier to read.
I had to do some manual steps to get Icinga Web 2 authentication working again: I followed the upstream directions to upgrade the database schema, and I had to run
a2enmod php7.3manually since the previous enablement of
php7.0wasn’t carried over. (I’m not completely sure if the first step was required, but the second certainly was.)
Other than that, everything seems to be working well now.