^ Thanks Geoff, sterling work you're doing.

Probably. I've used it myself and it is actively developed by Gentoo & Alpine Linux. But to use the Alpine init script you would have to use /sbin/openrc-init rather than just the service manager, which might not be the best idea for a production machine.

I've just run the systemd unit file through sysd2v and it generated this sysvinit script:

#!/bin/sh
# Generated by sysd2v v0.3  --  http://www.trek.eu.org/devel/sysd2v
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
    set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides:       thermald dbus-org.freedesktop.thermald
# Required-Start: $remote_fs
# Required-Stop:  $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Description:    Thermal Daemon Service
### END INIT INFO
DAEMON=/usr/sbin/thermald
DAEMON_ARGS="--no-daemon --dbus-enable"
PIDFILE=/var/run/thermald-sysd2v.pid
START_ARGS="--background --make-pidfile"

^ Place that in /etc/init.d/thermald and enable the service to autostart thermald at boot.

What is the CPU? How does the utility fail? What actually happens when you try to use it? Are you sure you need it with beowulf's newer kernel? The overheating problem might be fixed for that.

Have you seen thermald? It only offers a systemd unit file for autostarting but I'm sure we could hack something together for sysvinit if you want.

Alpine Linux have an OpenRC init script but you would have to switch to /sbin/openrc-init as PID1: https://git.alpinelinux.org/aports/tree … mald.initd

There is also linux-cpupower but that's command line only, the cpupower-gui package is only available in chimera/ceres.

I meant to just run my posted command directly rather than modifying the startup script.

It all works now, posting this connected via wefe

If deleting the plain-text password line in /etc/wefe/saved/* is too much trouble then perhaps consider using chmod 600 to prevent non-root users from reading the file.

There are only two drivers for wpa_supplicant(8).

Did you switch to TTY4 or check the install log to see if there were more error messages?

At a guess you have a disk with a GUID partition table but no BIOS boot partition to hold GRUB's core.img for a non-UEFI system.

Can we see

# parted --list

^ You can run that from any live ISO image.

I've removed the statically-linked version, I can't get it to build under Meson and it's a potential security risk anyway.

The mksh package provides two statically linked versions using musl & klibc, both of which are better than glibc (which has problems with static linking) and Thorsten is a *much* better maintainer than I so use that if you need a KornShell for rescue & recovery purposes.

The loksh package is derived from OpenBSD's KornShell implementation and so is audited and maintained by their devs.

It is very slightly "lighter" than mksh and also a tiny bit faster but it lacks support for here strings (here documents still work though). In respect of the original KornShell, that is significantly faster (it is the fastest of all the Bourne shells by some margin) but the ksh93 version in ASCII & beowulf is very old and has quite a few bugs — the new 2020 version in chimera/ceres fixes most of these and is under heavy development.

All three KornShell implementations are actively developed and maintained.

EDIT: loksh is the only one with bash-style PS1 support though, which I like.

I think you should have continued this in the old thread rather than start a new one about essentially the same issue.

So have you tried installing the libqt5gui5:armhf package?

v6.7.1-1 is now available, upstream has included the lolibc subproject in the release tarball so I don't have to hack it in like I did for v6.7-1. I've also moved libncurses6 to the Recommends list because it is now an optional dependency.

I've decided to drop the loksh-static package, I can't get it to build and it's a potential security risk if I miss an update for the embedded libraries.

I forgot to mention but there are no ASCII packages because Meson builds aren't supported by that release's debhelper version. Sorry.

Note that you can make the command speak English by using

# LC_ALL=C apt purge network-manager{,-gnome}

Well that's just stupid, even the GNOME desktop doesn't list network-manager-gnome as a dependency...

Why use wicd? An ethernet connection just needs two lines in /etc/network/interfaces (or four if you don't want to use DHCP).

Anyway, disable NM with

# update-rc.d network-manager disable

I think that must have been the development branch, v2.04 was only released in July last year.

I don't think it would be sensible to use a bootloader from one of the development branches in the stable installer.