I would call it Way Too Many.

tomoyo-tools seems to be to be upstreamed from http://tomoyo.osdn.jp/ (and why that is enabled in debian's standard linux-image is unkown to me). Apparently adding security=none to the boot command should disable this one.

Don't the instructions at https://wiki.winehq.org/Debian work for you?

I suppose, for a 64-bit Devuan beowulf, you will also need the prior

# dpkg --add-architecture i386

so as to enable "multiarch support".

Thereafter it's the usual 3 steps: download and add their key, add their "buster" repository sources.list point and update, and then install their package(s). (Though contrary to those instructions, I would always use --no-install-recommends for installing)

@dice's advice is for registering the connection details for the particular ESSID and WPAKEY.

For a laptop, you might want a slightly more flexible configuration, and to use the wpa_gui to deal with new wireless access points.

First, enter the following at the top of /etc/wpa_supplicant/wpa_supplicant.conf:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
p2p_disabled=1

Secondly, bring down wlan0 (ifdown wlan0) before changing /etc/network/interfaces to have the follwing variant declaration:

auto wlan0
iface wlan0 inet manual
         wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp

You'll note the difference of having a manual stanza with wpa-roam rather than wpa-conf, and a seemingly extra stanza declaring use of a dhcp configuration for a virtual default interface. All that is in support of roaming with dhcp.

Next, install wpagui (that's the package name for the wpa_gui tool) as user management tool for connecting your wireless interface to available acccess point by choice. By virtue of the update_config=1 setting you may save accesspoint settings so wpa_supplicant can find them "automatically" later.

You might also need to re-login the user after ensuring the user is in the netdev group, as per that first configuration line which wpa_supplicant will use for its control sockets.

With that you should be all set. for completeness, the p2p_disabled=1 is needed in order to disable that function which otherwise causes wpa_supplicant to be confused.. I'm not sure about the details.

Firstly, you cannot easily have two interfaces configured for the same network. I.e., if you want eth0 down and wlan0 up, you'd need to do that, in that order:

# ifdown eth0 ; ifup wlan0

Secondly, the gateway for static configuration does the same as your post-up additions to the wlan0 confguration; i.e. remove the post-up lines.

Thirdly, with allow-hotplug rather than auto you declare that networking should be managed via hotplugging, in which case udev will try to configure the nominated interfaces. Both of them if there is a cable, and potentially with a bit of race between them; one first, then the other. Since you have gateway declarations for both configurations, there will be a competition where the first one wins.

Possibly your misapprehension is that you regard the configurations as alternatives while udev will treat them as "complementary" or "conjunctive" and apply them both. Afaict the network management via either allow-hotplug (/lib/udev/net.agent) or auto (/etc/init.d/networking) don't actually detect "presence of cable" to only apply configurations "as per available cabling". Instead it will configure all interfaces that it is set to configure, i.e., both eth0 and wlan0, including the possible race and competition about gateway (aka default route).

The problem with 2 interfaces on the same network is that return traffic will go through the first unless you in addition set up a source based routing rule, so that the kernel has different routing tables for outbound packets depending on what the source IP is. That can be done, but it's not an automatic function in the kernel's networking logic.

... well spotted, thanks.

I got nostalgic today and looked up some serious study music:
https://www.youtube.com/watch?v=y9EA90uF7Ek

Afaik the package repositories are not provided over ftp anywhere; not sure how you got that idea.

The package file access relies on HTTP redirect as means for pulling packages from Devuan the store or the Debian store. The principle is simply that the filename for the package files has a prefix of either pool/DEVUAN or pool/DEBIAN and a server rewrite rule that maps the former into a local access whereas the latter is returned as an HTTP redirect to a deb.debian.org service.

Some release iso mirrors offer different file access protocols such as ftp and rsync for the isos.

Good. So when the start script runs /usr/sbin/anacron it actuallly runs /bin/true which is doing bugger all...

Possibly @fsmithred (who's doing refracta-base) knows something about that redirect but in any case it's wrong for your purpose.

The fix has two options:

The first option would be to change the link by:

sudo ln -sTf anacron.orig.anacron /usr/sbin/anacron

That will undo the redirect, but this then runs the risk of being undone, and the redirect comming back, if the live-config package is updated.

The second option would be to change /etc/init.d/anacron to use /usr/sbin/anacron.orig.anacron as binary; i.e., change start-stop-daemon --start command line to be

start-stop-daemon --start --exec /usr/sbin/anacron.orig.anacron -- $ANACRON_ARGS

The second option is probably a more sticky fix than changing the link, although it probably breaks if the live-config package is uninstalled.

EDIT: btw you might want to "verify" that anacron.orig.anacron is indeed the program by checking

$ md5sum /usr/sbin/anacron.orig.anacron
a16e182008f9105825af2580ab9e5ced  /usr/sbin/anacron.orig.anacron

The warning can be ignored. But I expected to see the output "Anacron 2.3 started on 2021-04-01" after the "transferring control", and not seeing that is peculiar... which architecture do you have?

uname -a

file /usr/sbin/anacron

file $(readlink -f /lib64/ld-linux-x86-64.so.2)

Hmm. obviously your /usr/sbin/anacron dies before it starts, or while it about to start, seemingly at the point where it should allocate memory.

However the "brk(NULL)" which should follow "munmap()" doesn't show up and instead the "exit_group()" showing premature exiting, and that suggests borked linking rather than out of memory; i.e., a technological mismatch with the dynamic libraries rather then a functional error.

Which libc6 do you have?

ls -l /lib*/ld-linux-*

My test showed nothing ...

But I realized that your forced running only resulted in a "Starting..." message, and not like the expected

$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f
[sudo] password for ralph:
Starting /usr/sbin/anacron...
Anacron 2.3 started on 2021-04-01
Will run job `cron.daily'
Will run job `cron.weekly'
Will run job `cron.monthly'
Jobs will be executed sequentially
Job `cron.daily' started
Job `cron.daily' terminated
Job `cron.weekly' started
Job `cron.weekly' terminated
Job `cron.monthly' started
Job `cron.monthly' terminated
Normal exit (3 jobs run)

Which package version do you have?

apt-cache policy anacron |& grep Installed

Is there an anacron running?

pstree -ap | grep -A 3 anacron