Buster upgrade

diff --git a/content/buster-upgrade.md b/content/buster-upgrade.md
new file mode 100644 (file)
index 0000000..9527535
--- /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.