Ok. Strange. Though I'm using a separate netinstall build so I will download the published one and try that.

"VM" is "virtual Machine", i.e. a machine emulator. I use "qemu-system-x86_64" in its default hardware emulation... with an (emulated) ethernet card, so I'll try without that as well. And the ISO is presented as a cdrom but that also shouldn't make a difference.

Yes, excalibur is testing, and there's some inconsistency with its packages so you'll have to not install packages. I.e., after selecting kernel and generic modules collection, then you
     skip both the "configure package manager" and "select and install software" steps, and instead
     continue with
        "select an init system" followed by
        "install the grub boot loader" and finally
        "finish the installation"

Doing all that leads to a very basic intallation with "nano" as editor, and you need to manually set up /etc/apt/sources.list in order to start installaing packages with "apt-get".

.. and I wish there where an https://files.devuan.org/devuan_excalib … README.txt

Hey @zapper, a positive action on this forum would have been to propose the hands-on and/or package list to use from the Devuan repositories in order to have that "minimalistic system".

As you know, there is no single "Devuan System" as Devuan is a repository of packages that includes all Debian packages except those that are or relies on systemd; it is your choice.

Maybe try also with

# Required-Start: $local_fs

as otherwise the root filesystem might still be mounted read-only when the output is attempted.

From that display it appears the headset is paired (and I assume you've marked it trusted). If it's paired, you shuld be able to tickle the "Info" option of the right-click menu, which should bring up a window of this-and-that about that headset including some few "UUIDs" for the audio profiles that it implements (eg "Headset", "Audio Sink" etc).

A connection requires that the computer runs one or more "audio servers" that registers to "bluez" as a handler for some profiles. As you already know pulseaudio has a bluetooth "module" to install to make the pulsaudio process such a server.

I haven't used pulseaudio for many years but if I remember it right, in addition to installing packages I also needed to fiddle with some of its configuration files for the module loading to happen. Afair, there are different fiddlings depending on whether pulseaudio is run as root or as non-root user. It's comprised of both the "registering" of the module to pulseaudio's module register file(s) and then some "authorization" hands-on to its runtime configuration files.

"the job" ?

Any user who is allowed to become root may well be in the input group.

Some tidbits:

1) the user that runs Xorg in vtN must have rw access to both /dev/ttyN and /dev/tty, and (I think) have w access to /dev/tty0 as well. This access is required for Xorg's VT ioctls.

2) further, that user must have rw access to /dev/dri/card0, i.e. the graphics card in use which typically is card0 but could possibly by card1 etc. This access is required for Xorg's graphics ioctls.

3) further, that user probably must have access to /dev/fb0 as well.

4) further, that user must have access to input devices, ether directly or as mediated by either logind0 or seatd. This access is required for Xorg's use of input devices.

4a) the logind0 method for mediating input deices requires access to a system dbus with whatever plethora of environment variables that requires. This typically gets done by using elogind for "session management".

4b) the seatd method for mediating input devices requires acces to the seatd communications socket.

Normally, (1) is typically achieved by the text terminal getty program which makes the logged in use the owner of the associated /dev/ttyN. The other (2-4) are typically achieved by the devices and the user being in the video group.

Apparently your ping channel to Argentina is lossy

With ssh access to remote servers you can obtain time statistics quite easily. E.g.

Download timing:

ssh $remote dd if=/dev/urandom bs=100M count=2 | time cat > /dev/null 

Upload timing:

dd if=/dev/urandom bs=100M count=2 | ssh $remote "time cat > /dev/null" 

That results in time measures for 200 Mib (aka megabytes) plain bulk data transfers.