check out man cryptsetup

I'm using forums.debian.net... it seems available but different. (I haven't noticed before that the header includes "Debian Fish and Animal Emporium", whatever that means.)

EDIT: apparently an April 1 joke that was so hilarious for the admins that it has remained. "Fun" is something subjective, obviously.

I'm more puzzled by your statement "don't want to open a debate" than anything. But I agree that using elogind or not is not really something worth debating.

Fair enough. Old thread, but since it's yours...

It used to be that the user running Xorg has to be owner of the associated tty, i.e. /dev/tty7 in your case. How does it compare with  /dev/tty2 permissions in the working use case?

Though I don't know anything about sddm or KDE.

Perhaps the DHCP options are on the ipv4 settings tab?

Was that "bad signature" for SHA256SUMS.txt.gpg?

Perhaps you need to refresh your pgp store?

gpg --keyserver keyserver.ubuntu.com --refresh-keys rrq@rrq.au

The sha256sum should be 722af7905595d9a1417f48f783d43dd40fe7da7a2e1d7998a8ea47df2d26941b
otherwise the download had errors.

EDIT: yes, fsmithred beat me to it

EDIT 2: concerns with the installers can be reported to the virtual project "devuan-installer"

@deutschem: I have assumed that you have 1) an iscsi server correctly set up and running, and 2) set up the client with the required configuration regarding targets and identities. Are those assumptions correct? To me it looks like the client (initiator) cannot connect to a server.

I'd suggest you don't worry about the rc?.d/ links too much; they only come into play at boot and shutdown.

Hmm I think you may need to enable iscid as well, as the /etc/rcS.d/K01iscsid may cause it to be stopped inadvertently on boot. By enabling it, it will be started on boot even with the "on demand" set up, but otherwise it might get killed by init. It should really have kill links only in 0 and 6; (looks like the debian developer is less read-in on sysvinit than could be expected).

You seem to have a mix of sources; e.g.
    docker-ce is not a package in either daedalus or excalibur;
    iptables=1.8.9-2 is in daedalus;
    libxtables12=1.8.11-2 is in excalibur

It's quite easy to mix sources.list points from anywhere, and usually doing so ends up with confusion about packages and what is where and why.

The whole idea behind a debian (and devuan) "release" is to offer a collection of software that works together. There is no promise that packages of different releases, or "foreign packages" for that matter, work together.

Not sure it'll make a difference, but the normal sequence is:
   to run "apt-get update" first, because that updates the local meta information to be current.
   thereafter you run "apt-get upgrade" to bring existing packages up-to-date as much as possible.
  finally you run "apt-get dist-upgrade" to also handle changing dependencies of new package versions, which may involve both removing and installing packages.

Does udev detect the device and install associated modules? What's in /sys/class/net/
What's in your latest boot dmesg?

I'm not sure what you take issue with... perhaps just that documentation on the web is old?

Otherwise I think one of the confusing aspects of ALSA configuration changes is that in general any program that use the audio system will end up loading an instantiating a configuration structure internally only once, when it starts. Therefore, such programs need restart after a change to the configuration source files, which include the user's .asoundrc file.

Though, a program may of course have been made to reload the configuration, and in that case such a program will do so as programmed and then rebuild the internal configuration structure from that on file.

I would suggest that old and bad documentation can only be remedied by writing new and better documentation; grumbling about what's existing and discussing it's badness is just waste of time.