Upgrading to Debian 11 (bullseye)

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.

Issues removing obsolete packages

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}
  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:



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.

Long shutdown time

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.


  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.