Previous INDEX Next
Upgrading to Debian 11 (bullseye) Moving from MBR to GPT and UEFI

Raspberry PI upgrade to Debian 11 (bullseye)

Debian 11 became available for the Raspberry Pi Model B Rev 2 I have. The upgrade was relatively painless, apart from:

Network adapter addressing

At first, I thought this was caused by a renaming of the ethernet device by systemd and hence could be solved by using systemd-networkd, as I had done previously on amber. To that end, I created a file called /etc/systemd/network/ethernet.networks with the following contentst: 

  [Match]
  Name=enx*

  [Network]
  Address=192.168.0.17/24
  Gateway=192.168.0.1
  DNS=192.168.0.4
  Domains=hydrus.org.uk

Then, enable systemd-networkd and systemd-resolved. Also disable the networking.service which handles the old-style /etc/networking/interfaces settings: 

  sudo systemctl enable systemd-networkd
  sudo systemctl enable systemd-resolved
  sudo systemctl disable networking.service

Confidently rebooted and found the Pi was still requesting a DHCP address. After rummaging through /var/log/daemon.log, I tracked down the offending package - connman, some Intel-provided network connection manager. After: 

  sudo apt purge connman

and a reboot, the DHCP problem was solved.

Getting mpd working

Mpd under buster (Debian 10) had been built locally (so as to obtain an up-to-date version), therefore the shared libraries it had been linked with no longer existed on bullseye. The mpd version in ports was now in advance of the local mpd version, so I figured I could just install from ports from now on.

I noted that the configuration file location was /etc/mpd.conf, so as an initial test, I copied the existing local version of mpd.conf to /etc to minimise the number of changes (the local config runs mpd as root). The Android client I use (MALP) worked just fine against the new version of mpd. In the provided configuration file, it recommended against running mpd as root (sensible advice). However, when I copied the local settings to the package configuration file and restarted mpd, the volume control on MALP did not work. Played music though.

At first I thought this might be a permissions issue, so I ensured the mpd user was part of the audio group and tried again. No luck. Eventually, I found that the root user had an .asoundrc file that set the on-board sound card as the default (default is normally 0, i.e. HDMI).

It's contents are as follows: 

  pcm.!default {
    type asym
    playback.pcm {
      type plug
      slave.pcm "output"
    }
    capture.pcm {
      type plug
      slave.pcm "input"
    }
  }

  pcm.output {
    type hw
    card 1
  }

  ctl.!default {
    type hw
    card 1
  }

I copied this .asoundrc file to the mpd user home directory (/var/lib/mpd) and tried again. This worked; MALP had a usable volume control.

I am unclear as to why mpd needs the on-board sound card to be set as the default but as this solution works for me, I'll not investigate further.

Note, another solution (not tested by me) is to set the default sound card globally in /usr/share/alsa/alsa.conf by changing 0 to 1 in these lines: 

  defaults.ctl.card 0
  defaults.pcm.card 0
Previous INDEX Next
Upgrading to Debian 11 (bullseye) Moving from MBR to GPT and UEFI

GNU/Linux Logo