The official image jellyfin/jellyfin tracks unstable
Huh? That doesn't appear to be the case. jellyfin/jellyfin:latest, which is what they tell you to use in the installation instructions. gives me 10.8.13 which appears to be the latest stable release.
There are newer and unstable versions available in dockerhub as well, but latest doesn't give you those. After all latest is just a tag with no special meaning of itself, it doesn't necessarly give you the most recent build.
Glad to hear that disabling PBO helped, but it does indicate that something may not be entirely healthy with your CPU (or with the way the motherboard is driving it, that also can't be excluded)
For me gravity sync was too heavy and cumbersome. It always failed at copying over the gravity sqlite3 db file consistently because of my slow rpi2 and sd card, a known issue apparently.
I wrote my own script to keep the most important things for me in sync: the DHCP leases, DHCP reservations and local DNS records and CNAMES. It's basically just rsync-ing a couple of files. As for the blocklists: I just manually keep them the same on both piholes, but that's not a big deal because it's mostly static information. My major concern was the pihole bringing DHCP and DNS resolution down on my network if it should fail.
Now with keepalived and my sync script that I run hourly, I can just reboot or temporarily shutdown pihole1 and then pihole2 automatically takes over DNS duties until pihole1 is back. DHCP failover still has to be done manually, but it's just a matter of ticking the box to enable the server on pihole2, and all the leases and reservations will be carried over.
The worst part is to change some things it adds like an extra 4 clicks to the old method.
And then at the final click, it takes you to that control panel screen anyway lol
That's what I do. I do have a small VM that is linked to it in a keepalived cluster with a synchronized configuration that can takeover in case the rpi croaks or in case of a reboot, so that my network doesn't completely die when the rpi is temporarily offline. A lot of services depend on proper DNS resolution being available.
You can use log2ram to mitigate that.
Alternatively, you can even boot a root filesystem residing on an NFS share, but in the case of a rpi hosting the network's DNS and DHCP services, you could end up with a chicken and egg problem.
Maybe a corrupt download/copy of a library… Try a reinstall of say glibc ?
Doesn't explain why it also crashes in an EndeavourOS live image...
Try a day or two of mprime as some others suggested.
That wouldn't necessarily reveal a faulty CPU or firmware. I used to have a 3600x that would sometimes crash on idle at low clocks but would run cinebench or geekbench all day and all night.
I’m pretty sure that it’s not hardware related
Random segfaulting is not something that "just happens" because of an OS misconfiguration, then if the same problem happens on Arch as well as on a clean EndeavourOS live image it convinces me that it is in fact hardware related somehow. As you have already replaced the RAM, my guess is CPU or motherboard issue.
Zen2/B450 is a widely used and well supported configuration on Linux that you normally shouldn't have issues with, but Zen2 CPUs are rather notorious for having fragile memory controllers, and sometimes dodgy AGESA firmware releases that can cause issues on some CPUs. I used to have a 3600X myself that started crashing at idle around a particular firmware release of my motherboard, and it was fixed by a subsequent release.
BTW the fact that it doesn't happen on Debian doesn't necessarily mean that Arch is the culprit. It could just be that Debian is not triggering the fault because of different, perhaps more conservative, compiler optimizations.
As a last ditch effort, you could try resetting your entire UEFI (bios) settings to default, preferably by pulling the CMOS battery.
BTW, is it only GUI applications that are segfaulting? Or other programs as well? Do you have an old spare GPU you can test with?
Again, not all that much user facing, but a lot of under the hood stuff. Reading through the notes, the things that stood out to me: vulkan, direct3d and metal rendering instead of just OpenGL, better HiDPI support including fractional scaling, better concurrency/multi-core support, and bringing the supported development tools up to date.
Mostly the migration to QT6 I think.
Personally, I rather like that they're not doing big changes or redesigns on the user facing side. KDE is pretty damn good as it is and I don't need a whole bag of new-and-shiny breaking my workflow.
To be fair, it would also be highly distruptive if you let the computer run overnight to finish some long running job and Windows decides it's rebootin' time. The point is: the OS shouldn't decide for you to reboot.