As @GlennW noted the kernel package is available in the alpha-20210503 ISO, which I could find from Devuan's backup, but that doesn't include the headers.

Possibly you could get them from the "orginal source" which I think would be
https://www.kernel.org/pub/linux/kernel … .28.tar.xz

.. but then there's the caveat that this might be well a "red herring"....

EDIT: Note that Debian has a couple of patches applied to header files. Though off the top they don't seem to concern graphics.

Hmm that observation suggests it relates to the kernel version?
or is there some apparmor involved?

You might try running

fuser -v /dev/snd/*

to see which if any (other) process "owns" the device.

There is a program and package fbcat for grabbing the frame buffer into ppm format. You'd need to arrange for that to be  available to the installer and run regularly to screenshotting.

E.g., set up a special USB stick that holds that program and has space to hold the succession of snapshots. Then, at the very first dialogue you shift over to VT2 to mount that USB and start the regular repeated snapshotting (example below), and then you shift back to VT1 and continue.  Making a snapshot every 5 seconds gather 12 snapshots a minute, each being (I think) ${number of pixels}x4 bytes in size, typically < 1Mb each. I.e. 1 Gb space handles about an hour of 5-second snapshots.

while sleep 5 ; do fbcat /dev/fb0 > snap-$(date +%s) ; done

Note that this would be for screenshotting the linux frame buffer. The "graphical mode" installers run tthisheir X servers which hold their screen images in memory (without using the linux frame buffer(s)), so screenshotting them is slightly different.

Did you try making /dev/tape a link to /dev/sdc? (though it might well need some API adapter between)

I think debian configures all run-levels 2-5 the same, so you'll need to change one of them, say 3, to boot up without starting a display manager (slim).

There are many ways to do so. For example, you might install sysv-rc-conf and run that in a terminal so as to "untick" the box for slim at run level 3, and then reboot with grub set to use run level 3.

I haven't tried this myself but I believe it's sufficient to avoid slim at boot up.

EDIT: I forgot the m3u ...

find /srv/Audio/CDs -name \*.wav -o -name \*.m3u -print0 | xargs -0 cp -t /media/usb_device

or perhaps

find /srv/Audio/CDs -type f -print0 | xargs -0 cp -t /media/usb_device

@rolfie, if you really want eth0 and wlan0 configurations to be alternatives you might add the lines

pre-up ifdown wlan0 || true

to the eth0 configuration, and

pre-up ifdown eth0 || true

to the wlan0 configuration.

You must also remove the allow-hotplug lines to avoid that the automated management tries to bring them both up on boot and status change. Then bring the right one up manually, or via some software that understands the applicable cabling situation, like for example wicd, connman or network-manager.

Note that any of the latter will compete with your current networking setup, so you will need to clear that out if you use one of them.

Alternatively you take the DIY approach using ethtool and wpa_cli to discover the applicable cabling situation; this approach brings the great joy of further learning situations. (For example that  wlan0 must be brought up at link level without configuration in order to scan for access points and determine its "cabling" options, while eth0 is more physical)

You need to set the default route to be via the wlan0 interface

# ip route replace default via 10.5.5.1 dev wlan0

You also should rather not have localnet routes to 0.0.0.0; it doesn't really matter since the first matching rule (via wlan0) is used shadowing the other but it may bring confusion to the mind of the operator.

EDIT: actually I got confused; those are the "normal" net routes... but you should probably avoid net routes to unconnected interfaces. Remember that when there are multiple routes of same specificity, then the first in the list will be used.

Thanks. That's quite useful. Much of it valid! The script obviously is a "works-for-me" kind of script

The line 36 note is misconceived though as that line actually needs the globbing and word splitting; the other ones are good if not terribly important.

And line 29 should rather include a sed filtering to discard all but the lilne numbers; I'm not sure a while loop will work since bash runs those in sub processes(?); does a history command in the sub change the history list of the parent?

But in any case I'll leave those improvements as exercise.

EDIT: also, the grep at line 29 should rather be grep -nFx "$TABBED" "$HISTFILE" to match the input verbatim (i.e., to avoid that it gets interpreted as a pattern).

afaik you only need the openvpn package; the rest is just some GUI confusion overlay trying to make sure you don't know and understand what you are doing.

Then you need to generate a client key at the server end, and copy the client part to the client end.

And then you need the client configuration file to match up with the service. It's all well documented in man openvpn.

It's both simple and confusing

The FQDN deb.devuan.org is an HTTP mirror collection. The servers in that group are only required to serve HTTP.

If there were several FTP servers it could be useful to craft an ftp.devuan.org mirror collection, and likewise a possible rsync.devuan.org, as well as perhaps even sftp.devuan.org and uucp.devuan.org.

However, only HTTP allows the "HTTP 302 redirect" which tells the client to go elsewhere for package download.

Access for ftp, rsync, etc. requires the server either to house both Devaun and Debian packages themselves, or to have file access proxying. While the latter is not much of a technical challenge it means that any proxied packages would go in and out of the server and thereby doubling the bandwidth loading for them.

The option of housing Debian as well as Devuan is taken up by a couple of servers, typically by them adding Devuan to an already existing Debian mirroring. Then, to provide apt access for Devuan they also have the specially crafted root structure needed to handle the virtual pathnames of the Devuan merged packages.