I upgraded my desktop machine, amber, from Debian 10 to 11 recently. The upgrade itself was trouble-free, but I did enounter some difficulties, post-installation.
Attempting to purge obsolete packages with:
# aptitude purge '~o'
produced this undesired outcome:
The following packages will be REMOVED: e2fslibs{p} gcc-8-base{p} libbotan-2-9{p} libcomerr2{p} libevent-2.1-6{p} libffi6{p} libgcc1{p} libjson-c3{p} libtspi1{u} libxfce4ui-1-0{p} libxfconf-0-2{pu} linux-image-4.19.0-17-amd64{p} multiarch-support{p} vdpau-va-driver{p} 0 packages upgraded, 0 newly installed, 14 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 278 MB will be freed. The following packages have unmet dependencies: thunderbird : Depends: libbotan-2-9 but it is not going to be installed Depends: libevent-2.1-6 (>= 2.1.8-stable) but it is not going to be installed Depends: libffi6 (>= 3.0.4) but it is not going to be installed Depends: libjson-c3 (>= 0.11) but it is not going to be installed The following actions will resolve these dependencies: Remove the following packages: 1) thunderbird [1:78.13.0-1~deb10u1 (now)] Accept this solution? [Y/n/q/?]
Refusing this solution caused aptitude
to offer to downgrade
thunderbird 1:78.12 instead. That seemed a less drastic option, but what
was causing this in the first place?
As usual, PEBCAK. It was because I had not read up on the change in
the security line in /etc/apt/sources.list
. I had also
ignored the warning messages from apt when performing updates. [The
idiot remains firmly in charge,] This meant that thunderbird 1:78.13
was the 10 (buster) version. The downgrade installed the 11
(bullseye) release version.
Adding the correct security update line to sources.list
(i.e. this):
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
installed the bullseye 1:78.13 version of thunderbird on the next update (plus a few other security updates).
I'm not sure why/when WOL stopped working. The fix was to add a
01-ethernet.link
file to the directory
/etc/systemd/network
with the following contents:
[Match] OriginalName=enp*s0 [Link] WakeOnLan=magic
The Match
section will match the ethernet adapter in
amber. I don't know why I didn't have to do this in Debian 10.
If I started X, then shutting the system down would result in a 90s
delay, as indicated by this message from systemd
:
A stop job is running for Session 1 of user mark
There's no clue as to what program is responsible for the delay. Looking at the systemd logs with:
journalctl -rb -1
showed no smoking guns. Well, that's not quite true; there were, as it turned out, a couple of red herrings:
gvfs-daemon.service: Killing process 1418 (gdbus) with signal SIGKILL.
and
pulseaudio[1077]: Failed to find a working profile. pulseaudio[1077]: Failed to load module "module-alsa-card" ...
These led me in the wrong direction for a bit. It wasn't until I
read this
discussion that I realised I should be checking processes
started by me, rather that than those started by systemd
.
After logging out of X, ps
revealed that, in addition
to bash
and ps
, audacious
was
still running in the background. Audacious
is the
music player I use. A few experiments showed that if
audacious
was started in the X session, but was not
used to play music, it would survive the X logout. If music was
played, audacious
was killed on X logout.
Audacious
does not respond to the SIGTERM
sent by systemd
, hence the 90s timeout, at which point
systemd
sends SIGKILL
. I suspect this is
a defect in audacious
, although the window manager,
xfce
, might also be involved.