Some people may want to be able to move a disk to another slot and still have the system to boot.

Thanks. esp the note about email; (your email got filtered as spam... it reminded me I need to set up my real email address here since google filters rather than forwards some emails that it judges to be spam)

Anyhow, it shows that the second partition on the /dev/sde drive holds an iso9660 filesystem. Presumably the Ventoy iso. (It seems the UEFI bios reorders the drive partitions so that the EFI partition counts as the first one, not mounted)

It's the "load modules" step that requires the media to be mounted for the Chimaera ISO. Though if the network works with the initial modules you can complete an installation without access to the media provided you don't need to set up the target partition as, say, ext4 as part of that installation. The Daedalus ISO boot up requires access to the media at an earlier point and it fails when that media is missing.

One could imagine that the second /dev/sde partition indeed would be the target iso file in some virtual loop-back mounting done by Ventoy software "behind" the kernel, but then this would be the same for Daedalus.

You gave me the Ventoy version (96) on email so I can experiment with it myself.

That is interesting. Would you be able to make that ventoy stick image available to me?

If I remember right, the partitioning step needs modules from the media to set up ext4 partitions.

Could you when the partitioning step starts make a detour by using Ctrl-Alt-F2 to enter shell, and there type "mount" to see what is mounted... what is the output of that?

EDIT: also, what does blkid print for /dev/sdg1 ... Have you tried labelling that "Ventoy" ?
there may be an exfatlabel utility for that or tune.exfat.

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".