Unless you took a backup I guess it's not relevant anymore but if it happens again you can narrow down files last changed around some timestamp like so: find /var -mmin +4 -mmin -5
Given your requirements, absolutely I'd also recommend against Bazzite and CachyOS, at least today.
Debian stable. Enable security updates by unattended-upgrades and you can basically go over a year without manually updating (aside from the occasional reboot to activate the newer kernel).
Then if you're not already into containers, I propose learning about rootless Podman and using that to run your arr stack services. For example using docker-compose and/or systemd services.
If you don't mind going a little bit more of the beaten track, then I also encourage you to check out Alpine Linux. Their wiki explains how to install it with a read-only root filesystem which it sounds like you'd like. But since it's early and a commitment, maybe save this adventure for later.
Arch has a like 10x more update churn than Debian or sth and is not stable in the same sense.
For a more hands-on system, or something offline, Arch is still great.
journalctl -xb-1 i believe gives it for last boot (if it even gets that far?)
Also dmesg.
And just in general, to see recently changed logfiles to look at after a reboot: sudo find /var/log -mmin -3 for files modified within last 3 minutes for example.
I'm not sure about your CPU but I've had times when similar issues play out differently on different distros (I guess due to differences in kernel buikdconf, modules, or drivers) so while it's a long-shot you could give that a go.
Try also the LTS and Zen kernel flavors.
I'd try Arch, Debian, Fedora (or perhaps some other rpm-based alternative that doesnt deprecate so quickly)
Like someone else said, anyone who hasn't had your exact issue will need logs and details to give more helpful advice.
SWIM has a sizable aged library - wouldn't be surprising with sqlite db corruptions by now - and absolutely no issues smoothly upgrading amd migrating to 10.11. Had sweaty upgrades a few times over the years but this was not one of them.
Good question and without looking closer or verifying I'd guess it actually doesn't.
Usually such things happen because at some point someone had an issue with accessing a hardware device or something and this became the "fix" perhaps because udev was confusing.
If someone cares enough about it, tidying up loose flatpak packaging ends like that is often appreciated and a great way to contribute.
In general for consumer routers, Broadcom-based ones like the one posted require a lot of work and hacking to port and maintain. If they’re even working with OpenWRT at all it can be quite dicey and troblesome if you are not very lucky.
In comparison, Mediatek-based models tend to be better supported and smoother sailing.
I haven’t seen much of Qualcomm but I’d guess they fall somewhere closer to Broadcom.
So no, I don’t think it’s a good pick. If OP got it handed down for free it might be worth a shot but I would buy something else if the purpose is to run OpenWRT or any Linux or BSD on it.
Source: Installed OpenWRT on many different devices over the years, including one with the same chipset
I have a hard time imagining a less rewarding user-facing software to be maintainer of. That’s probably why there isn’t one.
Thousands of hours and being blamed for dozens of people softbricking their PCs (which they now probably lack the USB route to recover from) - all because writing an ISO to USB and rebooting is too much friction?
Depending on how demanding those games are, perhaps they could still be run in VMs, just without physical GPU at all? Then you can passthrough USB controllers or attach USB devices just for the input and audio.
I guess you probably want third "management monitor" for this where you run virt-manager.
I'm guessing a "thin client" setup might not make sense here, but otherwise if you have some laptops around to use as "terminals viewers" that could also work I guess. I guess you would just do Steam Link remote play if this is just for Steam gaming though.
This gives a little bit of credence to the theory of an old installation taking precedence.
Are there other EFI partitions around? Try booting explicitly from each one and see if you get different results
Are there old bootloaders or entries from no longer existing installations lingering around on yor EFI drive? Move them from a live env to a backup or just delete them if you are confident.
How about NVRAM? It's a way for the OS to configure boot straight to your mobo; separate from any disks attached. It doesn't look like it to me but perhaps it is possible your mobo is still trying to load stale OS from NVRAM config and your newest installation didnt touch it? Manually overriding boot in BIOS like above should root out this possibility.
Just to root out the x-y factor, could you elaborate on your goals and how you wish to use it? I think "multi-seat" is a bit of a fuzzy term at this point and perhaps other solutions than what it's typically referring to is more appropriate for your use-case.
I haven't set up a single-GPU classic multiseat myself but a cursory reading from Debian wiki and Arch wiki Talk say it should be possible. There is mention of Xephyr, which QubesOS is using to do something similar with their "GUI domain". Maybe looking at that can be useful for you.
Two other things to consider could be VM with PCI-passthrough of the GPU (this does require a second GPU or an APU/iGPU in order to still have graphics on the host OS), or running secondary X servers with TigerVNC that you can then run fullscreen using vncviewer. The latter scales very well on a single GPU and works great for usual desktop/browser/dev but I'd be curious about gaming performance.
Unless you took a backup I guess it's not relevant anymore but if it happens again you can narrow down files last changed around some timestamp like so:
find /var -mmin +4 -mmin -5