What happens if you put the Toshiba SSD into the Vantec enclosure? If both SSDs run fast in the Plugable enclosure and slow in the Vantec then you might be able to return it as faulty (if it's still in warranty). Or at least scrap it with full justification.

Or better:
aptitude install doas
Check doas works and does everything you need!
aptitude purge sudo
Now check if everything still works. Eg does the menu option to shut down the system need sudo?

I've spend too many years installing software to risk cutting myself off.

That says the file is owned by mysql, has group mysql and can be read and written by user mysql and any user in group mysql. Which all looks OK to me.

The last 4 lines of output say when it was last accessed (ie read), modified (written to), had it's directory entry changed and when it was first created.

Unfortunately the man page for stat is not very clear. But running it against a few files with known characteristics it's fairly easy to work out what it means.

As I said I don't run mariadb, so I was just guessing from the first error message in the log extract. So kudos to rbit.

The interesting part looks to be:

What happens if you invoke the start script manually? Does that produce any interesting messages?

Was mariadb running OK before the upgrade (or is this a new install)?

If it's a new install do you need to do any first time setup steps?

I would *not* use --delete for restoring. It will delete any files on the target that are not in the backup. So you would lose any newly created files.

And I would be very wary of using it when backing up the system. If an important file, such as the kernel, got deleted by mistake and you didn't notice before running a backup you would lose the backup copy of it as well.

Also note it's a very good idea to test restoring things before you need to do it for real.

Checking a bit more:

chris@rigel:~/bin$ host deb.devuan.org
deb.devuan.org is an alias for deb.rr.devuan.org.
deb.rr.devuan.org has address 200.236.31.1
deb.rr.devuan.org has address 125.228.189.120
deb.rr.devuan.org has address 185.178.192.43
deb.rr.devuan.org has address 160.16.137.156
deb.rr.devuan.org has address 195.85.215.180
deb.rr.devuan.org has address 89.174.102.150
deb.rr.devuan.org has address 131.188.12.211
deb.rr.devuan.org has address 185.203.114.135
deb.rr.devuan.org has address 158.69.153.121
deb.rr.devuan.org has address 185.38.15.81
deb.rr.devuan.org has address 95.216.15.86
deb.rr.devuan.org has address 46.4.50.2
deb.rr.devuan.org has address 130.225.254.116
deb.rr.devuan.org has address 141.84.43.19
deb.rr.devuan.org has address 185.183.113.131
deb.rr.devuan.org has address 5.9.122.185
deb.rr.devuan.org has IPv6 address 2a0a:e5c0:2:2:400:c8ff:fe68:bef3
deb.rr.devuan.org has IPv6 address 2001:638:a000:1021:21::1
deb.rr.devuan.org has IPv6 address 2001:4190:801c:1::150
deb.rr.devuan.org has IPv6 address 2001:878:346::116
deb.rr.devuan.org has IPv6 address 2a01:4f9:2a:fa9::2
deb.rr.devuan.org has IPv6 address 2a01:4f8:162:7293::14
deb.rr.devuan.org has IPv6 address 2001:4ca0:4300::1:19
deb.rr.devuan.org has IPv6 address 2001:e42:102:1704:160:16:137:156
deb.rr.devuan.org has IPv6 address 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
deb.rr.devuan.org has IPv6 address 2607:5300:61:95f:7283:11d9:f86:e691
deb.rr.devuan.org has IPv6 address 2801:82:80ff:8000::2
deb.rr.devuan.org has IPv6 address 2a01:9e40::180
deb.rr.devuan.org has IPv6 address 2a02:2a38:1:400:422a:422a:422a:422a

The first line of output is noteworthy.

So if you still have problems try ping deb.rr.devuan.org and see if that works. It's *possible* that just the alias deb.devuan.org was missing from the DNS server you were using.

If that also fails try host deb.devuan.org to see if the alias is there but not deb.rr.devuan.org.

The other thing that could happen is that one or more of the servers the load is shared over was down/inaccessible. This could cause intermittent failures which would be a pain to sort out. Especially if they are only blocked from some IP addresses.

Check your path with echo $PATH (that's the most likely case).

But of course a "dropper" might well try to put things into somewhere in your path where it might get executed without you realising it. You might be better off copying from ~/bin etc every so often, *after checking what you are about to copy is OK*.

On my system la is an alias:

$ alias
alias l='ls -alF'
alias la='ls -A'
alias ll='ls -l'
alias ls='ls --color=auto'

Which is set in .bashrc (I don't know why it doesn't work for you though).

How old is it? I assume it's a desktop, not a laptop.

My first step would be to open the case and vacuum dust, fluff, etc out of it (especially round the CPU cooler). That might stop it over heating. Then check for stuck fans etc. And anything that would obstruct airflow. I had one PC with a decorative grill over the fan inlet, removing the grill cooled the CPU several degrees.

First try ping www.hotspotshield.com If that works your connection to the internet is OK.

The one thing that jumped out from your post was:

Has it previously worked for you? If so on what platforms? And is it still working?

Chris

mkdir /etc/inittab.d as root might get rid of the message.

What is the full text of the message? And what other messages came out at the same time? Those might tell us what is generating the message. Look for it in syslog, dmesg, boot.log etc.

Check running ebegin and eend manually work. Then call them from a small dummy script as a double check.

Look at /lib/rc/sh/supervise-daemon.sh to see if it's changing the PATH anywhere relevant.
Temporarily add echo $PATH to it just before it calls ebegin. Compare with what you get by adding echo $PATH to the start of the script.
If PATH gets changed then work out where it gets changed by adding echo $PATH at suitable places.

If all else fails post the whole of the original version of /lib/rc/sh/supervise-daemon.sh here to let someone who knows shell scripting look at it.

Chris