So, starting on 2020-01-31 I upgraded the "vicki" host (physical: Supermicro PDSMi) from: Debian GNU/Linux 9.11 (stretch) x86_64 to: Debian GNU/Linux 10.2 (buster) x86_64 vicki is the host that's the occasional* host that hosts the balug Virtual Machine (VM) - that VM hosts most all things: BALUG.org SF-LUG.org (excepting list(s)) BerkeleyLUG.com (and excepting DNS slaves thereof)

*occasional - vicki mostly hosts the BALUG VM when it's not otherwise being hosted on its nominal host (which is much quieter and has significantly more RAM, but alas, is a laptop, and semi-regularly ventures out or is otherwise unavailable for hosting the balug VM - hence the VM typically live migrates first to vicki on such occasions, and then back again when the nominal host is available again). The (rather loud, and power hungry) vicki hosts spends most of its time powered off when it's not hosting the balug VM.

And the upgrade ... mostly was done live and went mostly quite smoothly. Here are the slight bits that took a little more/additional attention:

apt[-get] autoremove - After the upgrade, apt[-get] was suggesting using autoremove to remove a bunch of "no longer needed" stuff. I reviewed the list, most of it was fine/routine (e.g. lots of libraries - which would otherwise remain if that dependent upon them also remained), ... but some bits of it weren't, e.g. bridge-utils (notably at least, I sometimes use brctl, and it may also be used by ifup/ifdown and friends, and/or libvirt). There may have been a small number of packages other than that, which autoremove would've defaulted to removing, but which I opted to retain. After suitably adjusting the status of those (so apt[-get] would show them as explicitly requested rather than just brought in to satisfy some dependency(/ies), proceeded fine with the autoremove (with --purge - the relevant pre-upgrade backups were done, so no need to otherwise explicitly retain configs for packages being removed).

libvirt - live migration from of VM from Debian GNU/Linux 9.11 (stretch) x86_64 to: Debian GNU/Linux 10.2 (buster) x86_64 worked fine, but trying to live migrate back failed. Found and corrected issue to allow backwards compatibility to Stretch, from the (hand maintained for human(s)) logs: To allow live migration back to Debian 9.x without apparmor, in file /etc/libvirt/qemu.conf changed: security_driver = "selinux" to: #security_driver = "selinux" ##### security_driver = "none" ##### and restarted libvirtd I did end up rebooting the VM after making that change though. Although the live migration to Buster had added the different security bit, I wasn't able to quickly and easily determine a way to live remove that. But the balug VM was long overdue for a reboot anyway (not on latest security kernel update, likewise older libraries/binaries still in process RAM from long-running daemon processes, etc.), so rebooted, as the expedient way to both address that and the apparmor bit that Buster had dragged into the running VM. Was then able to live migrate back to Stretch without issue.

That was basically it, no other issues of note bumped into (did review the install and release notes documentation, did first cover relevant items from there - most notably network device names - and having covered that first avoided any surprises on that).