Maybe there are some dangling links in some /dev/disk/by-* directory?

Note that those are two quite different machine emulations. You should both add the -serial mon:stdio argument pair so that you can operate the qemu monitor and inspect the emulation. The monitor is then connected to stdin/out of the temrinal where you typed the qemu-system-x86_64 ... command, and you will "wake it up" by the C-A c sequence, which gives you the qemu monitor prompt.

At there, @dice would see, by the info block command, that the emulated hardware includes a disk (hd0), a cdrom (cd0) without media, a floppy reader (fd0) without media and an sd card drive (sd0) without media, whereas @fsmithred would instead not see any hard disk, but cd0 with media and fd0 and sd0 without media.

Going back to to OP case, I am guessing that the hardware seen by that boot is as per @dice, which would mean that the boot USB gets set up as the primary disk rather than as a cdrom (which the live-boot expects).

Yes, that's right.

Basically I suspect that that kernel sees a slightly different device enumeation than the live-boot preparation code expected, and wrote in into the initrd boot procedure.

Well, you should do those commands at the (initramfs) prompt rather.

Normally you'd need root permissions to put scripts there, and it will, if executable, run by cron as root.

However, the PATH is a common cause of issues, see e.g. man 5 crontab.

It's not too hard. You start by copying /usr/bin into a new drectory /A, then make that become /bin by a careful juggle

rm /bin && /usr/bin/mv /A /bin

Thereafter it's a matter of removing from /bin and /usr/bin those that are mentioned differently in the content lists of installed packages. (You must of course also make sure your PATH includes both /usr/bin and /bin)
For example, if living on the edge you would use the following command pipeline

 cat /var/lib/dpkg/info/*.list | \
    grep -E '^(/usr)?/bin/' | \
    sed 's/^/\/usr/;s/^\/usr\/usr//' | \
    xargs -r rm

i.e. from the content lists reduce to the /bin/* and /usr/bin/* pathnames and change each pathname by adding prefix /usr to it but then remove /usr/usr if it becomes that, and then give these pathnames to rm

Then do the similar for /sbin and /usr/sbin (but using /bin/mv).

I haven't looked into unmerging /usr/lib. This might involve something more since there is a cache of pathnames for finding dynamic libraries and you wouldn't want to invalidate that willy nilly.

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.