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.

That device, 054c:094b, does not appear to yet be listed among known devices, but it might work by identifying it explicitly for jmtpfs, i.e. if your mount point is /media/camera you'd use:

jmptfs -d 001,003 /media/camera

Perhaps jmtpfs works for you.