Can you temporarily connect it to your network with an ethernet cable? That would help if you need to load firmware for the wifi card onto the laptop. Or just copy any error messages into your favourite search engine.

One of the first things to know with any UNIX variant such as Linux is that man pages are the first place to go when you have problems. Whenever you see a recommendation to use a command you are not familiar with you should always start by reading the man page for it to see what it will do. Man itself has a man page (enter man man to see it).

Also try:

echo $PATH
su
echo $PATH
exit # or press control-d
su -
echo $PATH

Trying things out is a good way to learn how Linux works under the hood.

I've just fixed a bug in the above script (I had a do missing) and tested it after replacing "starfish -d duration" with "sleep 5". So it might work now.

The first thing I'd try is to boot a live DVD/USB, mount the SSD and scp everything I want to save to another system (plugging in an ethernet cable if necessary). Then mount the nVME drive and save anything I wanted or what might show what went wrong.

Then I would check the data looks OK on the destination system. After that I'd be happy to start trying to repair the broken system.

I'm still getting them. On two different systems (one Devuan ascii, one openSUSE Leap 42.3).

I also tried echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org     | openssl x509 > wwwdevuanorg.cert, that gets different screen output:

On devuan:

$ echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org \
>     | openssl x509 > wwwdevuanorg.cert
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = www.devuan.org
verify return:1
DONE

On openSUSE:

echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org     | openssl x509 > wwwdevuanorg.cert
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
DONE
chris@vega:~/primo/progs> ll wwwdevuanorg.cert*
-rw-r--r-- 1 chris users 2025 Nov  4 16:57 wwwdevuanorg.cert

Though the certificates downloaded were identical on both systems.

I doubt it's cached, the openSUSE box isn't used for web browsing so has probably never downloaded the certificate before I first tried yesterday.

But on a web server I can log on to via ssh (I do some of the admin on it) wget is happy:

$ wget 'https://www.devuan.org/get-devuan'
--2022-11-04 17:04:43--  https://www.devuan.org/get-devuan
Resolving www.devuan.org (www.devuan.org)... 54.36.142.179, 2001:41d0:8:732b::3624:8eb3
Connecting to www.devuan.org (www.devuan.org)|54.36.142.179|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25326 (25K) [text/html]
Saving to: ‘get-devuan’

get-devuan                              100%[============================================================================>]  24.73K  --.-KB/s    in 0.005s  

2022-11-04 17:04:44 (4.50 MB/s) - ‘get-devuan’ saved [25326/25326]

And:

$ echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org     | openssl x509 > wwwdevuanorg.cert
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = www.devuan.org
verify return:1
DONE

And the cert appears to be the same too.

I'm now wondering if my ISP is caching something. Have you any ideas?

From experience the most likely explanation is that you misspelt it yesterday. I've learnt to take a hard look at what I typed if I get that error.

Have you still got the screen output? Or does your command history show you what you really typed?

If it's not that could your PATH have been altered to not include /usr/bin?

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.