From: Colin Watson Date: Thu, 13 Jun 2019 09:30:40 +0000 (+0100) Subject: Buster upgrade X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~cjwatson/git?a=commitdiff_plain;h=0ff79cdf25a7cc2874d55805f853ecf4650d3cd1;p=blog.git Buster upgrade --- diff --git a/content/buster-upgrade.md b/content/buster-upgrade.md new file mode 100644 index 00000000..95275357 --- /dev/null +++ b/content/buster-upgrade.md @@ -0,0 +1,77 @@ +Title: Buster upgrade +Slug: buster-upgrade +Date: 2019-05-05 01:10:48 +0100 +Category: debian +Tags: debian, planet-debian, planet-ubuntu + +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. + +As ever, `etckeeper` made it much more comfortable to make non-trivial +configuration file changes without fearing that I was going to lose +information. + + * The first `apt full-upgrade` failed 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 -a` sorted + 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 `.d` directories 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"](https://bugs.debian.org/919621). 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 -u` after doing so, and so I ended up having to use + `break=premount` on 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"](https://bugs.debian.org/924881) (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/interfaces` file, 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 `iface` stanza per + address using the same interface name, rather than `pre-up ip addr add` + lines 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 `inet6` stanzas before + `inet` stanzas for a given interface name was likely to be helpful, and + so it proved: I now have an `/etc/network/interfaces` that 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](https://icinga.com/docs/icingaweb2/latest/doc/80-Upgrading/#upgrading-pgsql-db), + and I had to run `a2enmod php7.3` manually since the previous enablement + of `php7.0` wasn'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.