Even then, not so much. I’ve been tugging on those particular wires, and the overall response seems to be, send a reply once, then ghost you until you’ve forgotten that you asked them. They do nothing during that time, and will probably continue to do nothing well after we forget.
I agree. Some of the Linux servers I used to run at work in the early 00’s were 12 to 16 core monsters (for the time) and the kernel didn’t even blink.
I had something similar happen in one of my ESP8266 projects (also running MicroPython). What I wound up doing was, every five wall clock minutes (maybe a bit sooner than that, for your case) I had my firmware do a local_networks = wifi.scan() just to exercise the wifi functionality. If that failed I have the code do gc.collect() followed by sys.exit(1), which causes the 8266 to reboot automatically.
Not being able to select boot order in BIOS suggests something very strange is going on, because it suggests that the BIOS can’t see all the drives. That has to happen before the bootloader can be evoked.
It sounds like GRUB is installed on the WD Black. BIOS -> drives it can see -> boot loader
What was the specific error that the Arch boot attempt threw? How did os-prober work for you?
apk isn’t any more or less than using dpkg by itself, or opkg. As for what I use, I use Arch at home and Ubuntu on my virtual machines (because they’re officially supported by my hosting provider). They work for me. I like them.
That’s understandable. However, pf (OpenBSD’s firewall system) is incredibly logical and easy to use. I never expected to write a fully operational (bloody thing worked the first time I tried it!) firewall ruleset on a two hour flight from scratch.