Fwiw, all devuan 3.1.0 (as well as 3.0.0) ISOs have an EFI partition as well as the CD partition. For example:

% fdisk -l devuan_beowulf_3.1.0_amd64-desktop.iso   
Disk devuan_beowulf_3.1.0_amd64-desktop.iso: 3.7 GiB, 3948937216 bytes, 7712768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5ba9ef0a

Device                                      Boot Start     End Sectors  Size Id Type
devuan_beowulf_3.1.0_amd64-desktop.iso1 *        0 7712767 7712768  3.7G  0 Empty
devuan_beowulf_3.1.0_amd64-desktop.iso2      23636   24531     896  448K ef EFI (FAT-12/16/32)

Technically the blocks of the EFI partition are among the blocks of the CD partition, which in fact spans all blocks of the ISO including the block 0 partition table.

Since the EFI partition needs to be a FAT type file system it cannot be a subdirectory on the CD which needs to be one or the other of the few CD type file systems.

Here's a gratuitous web search result https://www.mycomputertips.co.uk/213
Iit's for Ubuntu but probably works here as well.

The suggestion is to

• determine the label (XXX)  for the "active profile" by looking for that entry in the pulsaudio configuration file

• then edit /etc/pulse/default.pa, to add a line like set-card-profile 1 XXX to it

• and then restart pulsaudio

Probably not ideal for a pointy-clicky minded user.

Sure.  you might then also need to edit /etc/fstab and if there's anything else have captured the old uuid.

Just in parenthesis: hardcoding the uuid is no less hardcoding than hardcoding the partition device name. At some stage in history there was that idea of partition "label" which survives partition resize, move and copy; that could be used as well.

I can imagine at least one scenario where the reported behaviour would be a natural consequence: namely  when there are 2 different IP networks over a single Ethernet (broadcast) network

• the one IP network that includes your Fritz!Box as well as the eth0 interface of Pi4, and

• another IP network for the wlan0 interface of Pi4, visible to Fritz!Box via the wireless router's routing.

• the router bridges the networks into a single Ethernet broadcast network

That setup could explain the observations that an ssh connection targeting the wlan0 interface IP requires the eth0 cable in place, as well as that wlan0 appears for nmap from Fritz!Box but without services if the cable is disconnected.

The issue concerns the return traffic: i.e., the network packets that should go back from sshd to the Fritz!Box IP.

I'm then postulating that your wlan0 configuration does not have any route management, and that therefore Pi4 does not know how to send packets to the Fritz!Box IP unless the eth0 cable is connected.

The eth0 configuration as shown results in both a "network route" for the network of eth0 and (most likely) a "default route" as well through eth0. The wlan0 configuration (not shown) at a guess only resluts in a "network route" for the wlan0 network. Thus, without the cable, the Pi4 does not know where to send IP packets other than those of the wlan0 network.

If that's not your scenarion the issue would probably still be the routing and the way the routing table is manipulated when a cable is disconnected (and connected).

The solution would be to ensure that the routing table is managed appropriately for the 4 different setups: (with or without) * (eth0 or wlan0)

The DHCP set up is done by a dhcp client program, and not "the kernel". That dhcp program is typically run by a network management subsystem.

Which network managment are you using?

What's the output of pgrep -a dhcp ?

Do you have a firewall set up?

Would you mind drop the outputs of two commands:

# ls /sys/class/net
# ip link

That should provide exact information of the link level, and possibly point to where a problem might be.

Yes, "crickets" is a meaningful outcome. The follow-on testing would be

a) try running /usr/sbin/expressvpnd as root (I failed to highlight that before). 

Then b) look into the end of the file /var/log/syslog for traces of that run; esp. if there is anything near a good statement of why it is failing. In particular, if it's an apparmor issue, then it would show up there I think.

Also b2), check whether there might be a dedicated log file for expressvpn in /var/log.

The init script you installed is fine, but there is obviously a problem for the expressvpnd daemon program.

Try running /usr/sbin/expressvpnd from the command line; it may tell you why it fails to start.

Perhaps you are using apparmor restrictively and it needs some permissions set up?

When setting up a bluetooth speaker it got set up as a USB device, and I had to manually chwon /dev/bus/usb/001/002  to me in order gain access to it; maybe you have the same issue?

Yeah, I've read many threads here and still haven't worked out any regular formula for when "advice to search" is administered.

There obviosuly should be a constent rule for it as otherwise any poster might feel left out or fingered; especially those that do search first and don't get any credit for that, as well as those who don't search first and thus suffer an amount of face loss.

I don't use this feature myself, but I have a private stash of useful information. Esp, some "random documentation" that says (far down):

That is, the entry would then look like the following

&%%(diary-float t 4 2) time for my shower

Perhaps that works?

Perhaps this was due to the service pkginfo.devuan.org not being available on ipv6, which now it is.