Friends, there are thoughts at many levels and many perspectives.
Let's close this thread.

Not sure what you are saying there? Does Ventoy do things in some other way than what I described? Is it different now from before?

And what does "supposedly the same ISO except for branding/sources with the equivalent Debian on it" mean?

The point is that Ventoy does not provide the respetive ISOs as mountable partitions which is what many installers expect and require; they require that the initrd software of the installer is able mount the media.

They are not set up for "browsing" available partitions for directory trees and search for their media as an image file.

Those installers that are complete in their initrd work with Ventoy, because the Ventoy boot loader knows how to browse the Ventoy partition for the selected image file, then it loads the kernel and initrd from the that image file, and boots that kernel. At that point it drops all access details for the image file.

Also those installers work that have initrd software that can mount the Ventoy partition and search for their own media as image file.

In fact the daedalus installer preamble attempts to do that. But requires (if I remember right) firstly that the Ventoy partition is labelled "Ventoy" and secondly that the partition with the image file is an exfat partition. If the preamble then finds the image file it will set up a loop device fo the image file to make it appropriately mountable for the installer proper.

When you copy the image file directly to a drive it is a due mounatble partition for the installer initrd.

Note that the scripts don't do anything at start, so your "# Default-Start:  2 3 4 5" are without effects.

Also, umountroot doesn't actually unmount the root filesystem, but it remounts the filesytem root as read-only, and that should be enough to usually avoid fsck on boot-up.

And, I'm sure you wouldn't want unmounting to be done upon "S s 1", and you should restore the normal "# Default-Stop: 0 6".

It appears you are using runit rather than sysvinit? If that's the case I wonder if you have set up it's start/stop configuration to execute those scripts? I believe it's done differently from the sysvinit setup although many sysvinit scripts may be used with runit.

Don't like yad? Try tcl/tk instead, like e.g.:

#!/bin/sh                                                                       

[ $(id -un) = root ] &&	exec "$@"

[ "$SUDO_ASKPASS" = "$0" ] && exec wish <<EOF                                   
wm title .  {${*%: }}                                                           
pack [entry .pw -show {#} -width 40 \                                           
   -background "#efe60c" -insertwidth 6 -justify center ]                       
bind .pw <Return> { puts -nonewline [.pw get ] ; exit 0; }                      
bind .pw <Escape> { exit 1; }                                                   
focus .pw                                                                       
EOF                                                                             

exec env SUDO_ASKPASS="$0" sudo -A "$@"

That'll use a third of resident and a tenth of virual memory.

I agree it's not the appropriate response. Someone should report it upstream.

@einpoklum, it's a little bit interesting that you on the one hand make your system be part of Devuan's (and thus Debian's) testing/unstable effort and on the other seem annoyed that not all of that software is fully integrated as a stable release environment with "complete organisational branding".

Whilst it's helpful that you unravel misbehaviour, I'd suggest that your annoyance is somewhat misplaced. Rather one would expect you to follow through on the priviiege of partaking in the trialing of testing/unstable software by reporting on the feedback channels set up for that purpose. You have isolated a functional misbehaviour which thus should be reported to the upstream maintainers (those concerned with the functionality rather than packaging).

Also as you probably are aware, Devuan's charter is to reflect Debian sans [identified badness], and there is no additional commitment to software interoperability and completeness. It obviously would have been fun if that software (apt-add-repository) had been designed to automatically slot in a Devuan branding (or arbitrary non-Debian branding) in its principal functionality, but extending that software (either specifically for Devuan or generically in its design) is unrelated to [identified badness] and therefore actually outside the scope of Devuan's charter.

But there's of course nothing wrong in pointing to these kinds of bugs. It's just the matter of following throw with constructive action rather than "whine about it".

That looks well equipped and farily normal. Though  is that only USB 3 ports? Maybe that's a problem for the installer preamble ... I guess your DVD attempt was via a USB drive as well?

If you would have a USB 2 hub it could possibly make a difference; to let the preamble find the ISO and switch into the installer proper.

Alternatively if you could dd the ISO onto an nvme partition to be available there for the preamble's media detection. That would be an option too ... you would boot from the USB stick but let it find the duly labelled nvme partition as its media (for unpacking the installer proper), and when the installer proper has started you could (with immediate Alt-F2 hands-on) guide its media detection to the USB. If you would want that, e.g. to make that nvme partition avaiable for the installation. (If you wish I could give a more detailed step-by-step for this)

Can you provide output of

blkid $USBDEV

where $USBDEV is the device node for that USB; It appears the boot preamble fails to find a duly labelled partition.

Next, if you are somewhat confident with command line, you could try adding EMERG to the boot line (push TAB, then type EMERGE, then  Enter). That will bring you to a busybox shell early in the preamble, where you could investigate things, and especially modprobe any special modules that might be needed for the hardware. When you exit that shell, it will continue with the installation (loading device modules and scanning for the labelled partition).

There's also the variant adding "emerg" in lowercase, which enters the shell late in the preamble sequence (after failing to mount the ISO). At that point it has loaded modules to handle devices, and you might there be able to coax it manually by setting up a loop mount and run unpack by hand... review its /init for inspiration.

... and to continue on the real X discussion; I note that xserver-xorg-core is already a forked package. Though not forked from upstream, but rather a fork of debian's project so as to add the libseat extension that provides the seatd alternative to (e)logind for input device mediation.

which upgrades was that?

Some oldish cards or drives can't deal with GPT partition table but need DOS table.

You could check that by trying again with the first card but then make sure to create a DOS table on it before partitioning. (Use expert mode with activated lowest possible priority level, or perhaps use ctrl-f2 shell and fdisk)

There are also usb sticks that don't support boot setup, but they are rare.