The daedalus ISO offers a menu of alternative boot methods; does "start the desired distro" start with presenting that menu?

The ISO is further a hybrid ISO with 3 separate boot equipments that cater for different use cases: whether the media is presented as a harddisk or a cdrom and whether the boot loading is by legacy or UEFI bios. Which use case does Ventoy present?

Evidently Ventoy is able to start a kernel (which kernel?) and unpack the preamble.gz of the daedalus ISO. Then the init script of that fails to find the partition.

For sure, that init script could be improved to scan for image files and loop-back mount that for loading the actual installer (initrd.gz) and also for again, later presenting the ISO as block device for that installer. Is anyone up for assisting with making such script improvement?

E.g. at the emergency shell, install the loopback module with max_part=16, then mount the partition containing ISOs, then loopback mount daedalus as isofs (might need to load the module first), then unpack its /boot/isolinux/initrd.gz onto /target. After that it's just a matter of switching to /target as root filesystem (though with certain environment passed on)... You can inspect the current /init script of preamble.gz or at the emergency shell prompt to get an idea.

I guess you mistakenly copied his ".asoundrc" and replaced "hw" with "plughw"... that's not what to do.
Rather you should use my (last) suggested ".asoundrc" to make sure the right card is selected for audio output. Then use "aplay -D plughw ..." for playing, because that PCM has audio format translations to map any input format into the format "hw" needs. ("plughw" channels audio to/from "hw" as its slave PCM)

EDIT: I'm not good at guessing and confused myself about "amixer" vs "aplay". There is no "plughw" CTL, and one would rather use amixer with the "hw" CTL. I.e., playback to "plughw" with mixer controls for "hw"

I was wrong and too sloppy to actually test my suggestion.
It should really say

defaults.pcm.card 1
defaults.ctl.card 1

There is the tool qasconfig that presents the raw current ALSA configuration. I find it somewhat useful on occation (even if I don't fully understand it), but it in particular tells the configuration effect  of changes to ~/.asoundrc.

EDIT: corrected to say qasconfig as it should have been.

That'd raise the firewall regardless of the administration command, i.e. both "start" and "stop", which might not be ideal.

And, for dnsmasq, remember youl'll need to configure its upstream as it otherwise would want to use /etc/resolv.conf.

Why the hell do you all insist on filling the forum with repetitions of previous posts.. in full or in parts. Are you all pre-schoolers? Do you think people can't read and remeber for a few seconds?

I don't know whether ventoy keeps the ISO as a partition, and if not, you have more thorny path ahead of you. Basically you'll need to ensure the ISO partition is appropriately labelled DEVUAN501.

Technically it would be possible to patch a ventoy ISO copy (as file image) to be legacy bios bootable without the preamble stage, but UEFI boot requires the preamble and the ISO as a duly labelled partition.

The paths

/path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/e8b658bc0b30120109470ac5b20c8be088f56b9024a49285c76d41d8694e2ce2

et al are all compressed Packages files, i.e. so called "digests", and evidently that "tool" can't handle them.

There are a number of systemd* binary packages (thus originating with systemd source) even in daedalus; perhaps that's what's reported in distrowatch ... check which ones at https://pkginfo.devuan.org/systemd*

fwiw, on the subject of "full posting", I'm totally with Alex; I tried once or twice to make "you kids" aware of its disruptiveness for the reader, but had as much luck as Alex.

But as we know, kiddies do what kiddies do, and simple things like showing consideration  e.g. for people needing screenreaders, or just generally finding the useless repetition bothersome, appears to be outside of the attention span.

You could try updating xserver-xorg-core and xserver-common from daedalus-proposed-updates. That might resolve the VT switching issue.

Thus, add to sources.list:

deb http://deb.devuan.org/merged daedalus-proposed-updates main
deb-src http://deb.devuan.org/merged daedalus-proposed-updates main

Then run (as root)

# apt-get update
# apt-get install --no-install-recommends -t daedalus-proposed-updates xserver-xorg-core ]xserver-common

It might be that the script has "/usr/bin/python" as interpreter, which might not exist on your Devuan system.

(any file in that directory)

That pinning makes packages from daedalus-proposed-updates only installable on demand. Eg.

# apt-get install --no-install-recommends -t daedalus-proposed-updates \
    xserver-xorg-core xserver-common