Please read and edit your /etc/iscsi/iscsid.conf

Which package are you talking about here?
I can't anything with "viber" in it.

You sound like you want to do something, so yes: Go for it! Make a debian package and submit it to debian. I'm pretty sure you will get a debian developer sponsoring it. That's also how it gets into the Devuan repository.

My guess would be that the postinst script of xz is buggy; that for some reason it doesn't recognize that the "alternatives" link for lzma already points correcly.

Maybe the script tries to resolve the link value (the pathname "../../usr/bin/xz") itself rather than resolving the link, and it then resolves that relative to "/" (which would be cwd for the postinst script) rather than relative to "/etc/alternatives" (which is where the link resides). Thus it erroneously claims that the resolved value is missing and different from "/usr/bin/xz"... and yet, when the new "alternatives" link get installed, the "alternatives" subsystem translates the given absolute pathname to one that is relative to where the link is set, so it ends up with the same value that it already had.

Remember that the postinst script doesn't "see" those pathnames the way you see them in the error message.

And I'm sure there are other possible stories that could explain how those peculiar log lines come about.

@steve_v: in my mind neither Devuan nor Debian are "distributions". Rather we are organisations of people that provide a means to pull toghether a large number of software packages, that are tested to work together. A "Distribution" is formed by selecting certain packages towards some particular use. So where software implementing a notion of user services exist Devuan will incorporate that if it is in Debian, except of course if it requires systemd.

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.