You are probably right even though that "decision" is obviously not a reason for changing the installation pathname.

The problem you run into is that debian firmware package maintainers have recently decides to install the firmware in a different directory from what the kernel looks in.

It boggles my mind how they could think that that would be a good idea.

You will need some manual hands-on to fix it.

Because the .desktop file uses full pathname.

Possibly you can installl openjdk-8-jdk-headless from ceres first ?

All installer ISO include (on the ISO) all firmware available in the repositories.

Choose the "1 Install" method.

And of course Debain bookworm, which underpins Devuan daedalus, had that major repository change of moving all firmware into the new non-free-firmware section. That change still causes confusion for everyone who whould expect only the traditional repository point changes at an upgrade.

In other words, there need to be a sources.list line naming the non-free-firmware section, e.g. by itself, like:

deb http://deb.devuan.org/merged daedalus non-free-firmware

or together with other sections, for example like

deb http://deb.devuan.org/merged daedalus main contrib non-free-firmware

All Devuan derivatives are likely to have the same issue.

"file manager"?
That's quite a useless piece of software.
It's so much easier to just type commands in a terminal (window).

1. One option is to mount /dev/null onto it, like

sudo mount -obind /dev/null $HOME/.xsession-errors

Though doing this will discard all errors as they occur and that might be too forceful.

2. Another option is to drop a small script into $HOME/bin/logrot.sh, like

#!/bin/sh
#
# This script limits a file to a given number of lines, by moving it
# to a backup name when longer.
#
# $1=filename
# $2=max number of lines (defaults to 1000)

[ -r "$1" ] || exit 1 # The pathname is not readable
[ $(wc -l < $1) -lt ${2:-1000} ] && return 0 # The file is short enough
mv $1 $1.1 && touch $1 # Back it up and leave an empty

and then also add a crontab -e entry like this

37 5 * * * $HOME/bin/logrot.sh $HOME/.xsession-errors 2000

so as to run that script once a day (at 5:37) and then "rotate" the file if it is longer than 2000 lines.

3. Another option is to use something like logrotate and configure that to bother about your $HOME/.xsession-errors

Yeah, the core problem is that the ISO is not available as a mountable partition to the installer, but instead the installer would need to search for it as an image file among the available drives and partitions. It's a whole new use case collective that the installer is (was) not prepared for.

Otoh it's not terribly complicated to add such a search to it; possibly something coming out sooninsh.

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.