| Previous | INDEX | Next |
| Installing Arch Linux on a Macbook Pro (mid-2009) | Raspberry PI upgrade 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.
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.
| Previous | INDEX | Next |
| Installing Arch Linux on a Macbook Pro (mid-2009) | Raspberry PI upgrade to Debian 11 (bullseye) |
