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

Yes, and one thing that is confusing with ALSA is that programs typically loads the sound configuration only once, early during startup. Therefore such a change to the configuration only takes effect for programs that are started after the change.

There is a way to make a configuration have a dynamic part, to be automatically reloaded upon every sink (or source) creation instead, but then we are entering a deeper level of understanding of ALSA configuration structure and elements which most people rather wish to avoid.

Hmm I have a /.cache with two sub directories

drwx------  2 root root 4096 Jun 17 01:15 mesa_shader_cache
drwx------ 52 root root 4096 Jun 17 01:15 mesa_shader_cache_db

and then some directory tree down to pairs of files. All of that created and modified at that one time. Presumably mine belongs to some "mesa" package.

slower than what?

What do you get from rfkill  ? (you might need to install it).

@rwall, add some double-quotes, and make that line 17 be

if [ ! -e "${RC_SVCDIR}/softlevel" ]; then

and then you won't have that problem (at least).

(I assume "freer" is a misspelling)

I can't replicate the problem, but an access timeout may have many reasons.
Does the "same thing" happen every time?

How about we leave this thread here (without me actually closing it) as there is no value in adding opinions here one way or the other. If I get inspired I'll weed it and retain the technical matters for later.