I am surprised to hear that! Afaik they all need to mount the media, and ventoy doesn't offer it as mountable. Perhaps you could provide me with a such loaded USB with, say, chimaera, to investigate?

EDIT: the installer may well start and bring up a dialog, but it fails after a couple of dialogs when it comes to the step that needs to mount the media. That step essentially uses blkid to find the mountable devices. When using a ventoy boot, the ISO is merely a file somewhere in the first partition.

Well, there are a couple of graphical tools to mismanage network configurations with, and there is the traditional ifupdown that uses /etc/network/interfaces as its control file.
Guess which I'm using

If your router is set up to provide network settings via DHCP, then you would configure it such for ifupdown. See man interfaces. Otheriwse you need to configure manually, either directly as you did, or by editing the configuration ... for ifupdown it's /etc/network/interfaces, and for gui tools they typically offer their own editing dialogs for manual editing of their configuration files.

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.