Not sure it answers your query, but task-console-productivity pulls in tasksel as dependency, and the following as "recommends":

abook, alsa-utils, apcalc, aspell, aspell-en, bastet, beep, bind9-host, bittornado,
bombardier, brltty, bsdgames, caca-utils, calcurse, cavezofphear, clex, cmatrix,
cowsay, crawl, curl, curseofwar, dialog, dnsutils, dvtm, ed, edbrowse, eject, empire,
entr, espeak, espeak-ng-espeak, espeakup, fbi, fbterm, fetchmail, figlet, fortune-mod,
fortunes-min, freesweep, ftp, gddrescue, gdisk, geoip-bin, ghostscript, gnuchess,
gnupg, gnupg-agent, gnupg2, gpm, greed, hasciicam, htop, iftop, imagemagick, iotop,
irssi, iw, jhead, lftp, links2, lrzsz, man-db, manpages, manpages-dev, matanza, mc,
mcabber, minicom, mlocate, moc, moria, mosh, msmtp, mtr-tiny, multitail, mutt, ncdu,
net-tools, netcat, nethack-console, nfacct, ninvaders, nrss, omega-rpg,
openssh-client, openssh-server, pacman4console, parallel, parted, pciutils, pente,
poppler-utils, procmail, psmisc, radio, rename, rpl, rsync, sc, screen, sox, sudo,
sudoku, taskwarrior, telnet, termsaver, time, tin, tmux, toilet, toilet-fonts,
traceroute, ttyrec, unzip, w3m, wavemon, wget, whois, wireless-tools,
wpasupplicant, yasr, zile, zsh

If /dev/mmcblk0 was the full disk, you can't mount the image file directly. One solution to that would be to use nbd (network block device) where you set up the nbd server to use the image file, and then "install it" to the system with an nbd client, which would create a series of /dev/nbd0p1, /dev/nbd0p2, ... points for the partitions and subsequent file system mounting.

However, I don't think file recognizes the image correctly, but rather that the image is a raw NAND image, which needs to be pulled as such. It's a fair while since I was blistering my eyebrows on that problem, and apart from me having forgotten most of it, the details of the story are probably quite different nowadays anyhow. I can only suggest that you follow up on reading/writing NAND images.

Devuan jessie has 5.6.36+dfsg-0+deb8u1, in jessie-security, so you might be able to install from there.

As far as I can tell, the first rule pair is the right one. However,  it's not possible to rename an interface to an already taken name, and the problem is that the udev rules apply well after both interfaces have gained their kernel names. I.e., both names eth0 and eth1 are in use when the rules apply.

Thus, when udev wants to rename eth0 to eth1, it fails because eth1 is already taken. Then the renaming of eth1 to be eth0 also fails for the same reason.

You may however probably rely on that the interface originally named eth0 by the kernel will be processed first. You could therefore set up the rules to name the secondary interface eth2 rather than eth1. Doing so makes eth0 free for any subsequent renaming of the other interface. In that case you will have the interfaces named as eth0 and eth2 via their mac addresses.

If you insist on having eth0 and eth1 you will need a subsequent renaming to happen. That is not easily done through udev, but I think  the ifrename package would be able to deal with this.

That sounds good. I'll prepare the "translation pack" and email this to your registration email. It involves some 1500 phrases and 17 email templates. Though half or so are for the admin pages, which don't necessarily need translations.

Great work. I've lodged a bug on your behalf. https://bugs.devuan.org//cgi/bugreport.cgi?bug=222

Det låter jättebra. Tack. Låt mig samla ihop underlaget, så skickar jag det till din regestreringsadress (om en dag eller två).

Thanks A full day without takers!
In my mind, "blame" is not central to Anarchism; there are other belief systems for that.
But I agree it's a good point: what would Kropotkin say?

That's a good set of rules for doing no filtering at all, yes

If you don't mind, rather dump the output if iptables-save, just to confirm all the tables. Basically, you shouldn't need any iptables rules, except the masquerading of the outbound traffic on tunY. That one is necessary to allow packets with original source from IP 10.8.x.0/24 (i.e., your server-vpn clients) or 192.168.y.0/24 (your wlanX neighbors), as well as allowing packets from 192.168.x.0/24 (your ethX neighbors) to be forwarded and masqueraded through tunY.

Right. Some random googling suggests https://volumio.org/forum/vcgencmd-comm … html#p6319 to me, but you might have tried that already?

That Ubuntu solution is not right for Devuan.

However they suggest that hdparm -S is ineffective, and maybe that's the first thing to investigate. If it works fine, then the command

# hdparm -S 2 /dev/hda

would make the disk /dev/hda spin down after 10 seconds. Perhaps you can check that to begin with.

If that works, then the resume code path that leads to that (or the similar) command is broken, and we can look at that.
If not, then it's a more difficult problem.

Just to add some motivation:

My assertion is that when you are trolling, you are trolling whether you think so or not; it's not up to you, as a troll, to judge it right or wrong. Further, I believe some people would be too polite to nominate a troll if they thought the troll would see them doing it. They would rather suffer the trolling, and that would dull any edge of this extension.

The troll list is that little bit different from an ignore list in publishing the count, in the hope that it both stimulates people to evaluate the (perhaps) trolling posts more thoughtfully, and triggers self-criticism for the (somewhat) trolling poster.