Isn't pipwire something to be run by the (local desktop) user?

That's good. Just fill the forum with generated crap... much better than the mind-authored.
not.

It sometimes helps to run

apt-get update

to update your local meta files.

TL;DR; apt asks for particular versions of packages and it does not ask for "whatever is current right now" (as one might think it would do). The meta files tell "slices" of versions across packages that have been tested and shown to work together. Sometimes one would want apt to run "update" automatically upon install of packages, but I guess that would add code "unnecessarily"; anyone who wants update to be part of installing would simply do that themselves.

Sometimes though it's a neworking problem, or that the target server has a transient problem.

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.