Fixing Problems After Debian Bullseye -> Bookworm

First three items are from upgrade of my shack computer.

Item #4 is from upgrade of my main desktop computer.

Item #5 is from my home server. 

Item #6 occurred on both the main desktop computer and the home server.

 

Following an error-free upgrade from debian bullseye to bookworm, I encountered the following problems:

1. Problem: The DejaVu Sans Mono font was no longer available.

Solution: I installed the package fonts-dejavu.

2. Problem: Even though the termName was set to xterm-256color in the ~/.Xresources file, the actual value of TERM in an xterm was "xterm".

Solution: Explicitly export TERM=256-color in the ~/.bashrc file. 

Comment: This looks like a bug; setting termName in the resources file has always worked in the past.

3. Problem: core dumps were no longer written to the current working file. (In fact, it wasn't clear where they were being written.)

Solution: Add the line:

kernel.core_pattern = core

to /etc/sysctl.conf.

Comment: I have been using versions of UNIX since the late 1980s. Every single version until debian bookworm would automatically dump core to the current working directory. This seems to be Yet One More example of the madness of systemd taking everything over. Why debian would change the default behaviour of something on which so many people rely seems ridiculous. But then, so did their decision to support systemd.

4. Problem: autotrash has been removed by the upgrade.

The autotrash website says that the script can be installed with:

 pip install --user autotrash

However, that produces:

 [ZB:bin] pip install --user autotrash
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
   python3-xyz, where xyz is the package you are trying to
   install.
    
   If you wish to install a non-Debian-packaged Python package,
   create a virtual environment using python3 -m venv path/to/venv.
   Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
   sure you have python3-full installed.
    
   If you wish to install a non-Debian packaged Python application,
   it may be easiest to use pipx install xyz, which will manage a
   virtual environment for you. Make sure you have pipx installed.
    
   See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
[ZB:bin]

Solution:

Install the python3-full package. Then execute:

[ZB:~] python3 -m venv ~/.venvs/autotrash
[ZB:~] ~/.venvs/autotrash/bin/python -m pip install autotrash
Collecting autotrash
 Downloading autotrash-0.4.5-py3-none-any.whl (22 kB)
Installing collected packages: autotrash
Successfully installed autotrash-0.4.5
[ZB:~]

Now autotrash can be run as:

 ~/.venvs/autotrash/bin/autotrash

5. Problem: no networking.

This computer uses two ethernet ports: one to my ISP and hence to the Internet; one to my home LAN. On completing the upgrade (without error) and rebooting the machine, neither network was functioning.

The networking was originally configured as part of the process of installing stretch on this machine, probably about six years ago; networking has worked flawlessly since then, until this upgrade.

Solution:

The directory /etc/NetworkManager/system-connections directory contains two files, rather oddly called:

• 'Wired connection enp11s0(eth0).nmconnection'

• 'Wired connection enp12s0(eth1)'
  

The contents of these files are:

Wired connection enp11s0(eth0).nmconnection:

[connection]
id=Wired connection enp11s0(eth0)
uuid=8e308949-5232-47aa-b9b6-8aab6369ec4d
type=ethernet
permissions=

[ethernet]
mac-address-blacklist=

[ipv4]
address1=209.97.232.18/24,209.97.232.1
dns=127.0.0.1;209.97.224.2;209.97.224.3;
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

[proxy]

Wired connection enp12s0(eth1):

[connection]
id=Wired connection enp12s0(eth1)
uuid=251dd901-f8b7-42ee-b568-b15ba565a81b
type=ethernet
permissions=

[ethernet]
mac-address=D8:50:E6:C2:76:03
mac-address-blacklist=

[ipv4]
address1=192.168.0.1/24
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

The fix is to add a MAC address to the first file.

I note that it is odd that this is necessary: as enp12s0 is mapped directly to a particular port by the MAC address, Network Manager should know that enp11s0 should therefore be mapped to the other port. It has worked that way on this machine since stretch, but apparently this behaviour has changed in bookworm.

It took quite a while to figure this out; more details of the flailing around can be found in the threads that start at:

https://lists.debian.org/debian-user/2023/09/msg00024.html and 

https://lists.debian.org/debian-user/2023/09/msg00061.html.

There is also an official response to the issue at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051086,

which I note is remarkably unhelpful (if only because it suggests use of a utility that is not part of debian stable; but it also suggests that the problem is due to kernel timing, which is hard to believe given the discussion in the threads on lists.debian.org -- can a problem that depends on timing of the order of many seconds really be due to a change in kernel timing? -- also, the suggested fix seems less clean than the one I provide above; and, in any case, if a human can figure out which connection goes with which port, Network Manager should have been able to do the same. And Network Manager should in no circumstance have tried to assign two connections to each other, as is described in the first lists.debian.org post; the worst that should have happened is that the connection without a MAC address should have failed, and a useful error message provided).

6. Problem: Errors occur when attempting to connect to remote computers over ssh.

When trying to connect to remote systems over ssh, various error messages would be received. This is a typical such message:

Unable to negotiate with 77.109.148.18 port 22: no matching host key type found. Their offer: ssh-dss,ssh-ed25519

The messages all suggested that ssh was unable to find a common acceptable key type.

It seems that the default types of keys that are deemed acceptable must have changed in bookworm. The easiest fix is simply to restore the old keys types as being acceptable, by adding the following lines to ~/.ssh/config:

PubkeyAcceptedKeyTypes +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-dss

HostKeyAlgorithms +ssh-rsa
HostkeyAlgorithms +ssh-dss