So in the last 10 days my home server has insta-rebooted twice.

I wouldn't even know if I wasn't at home and on the Internet at the moment (as my DNS is in a container) and then didn't notice parity rebuilding.
 

Is there a way to identify (some log?) possible crash reason?

 

Note this is a server I have for... decades, with several upgrades over the years (currently using rather modern hardware) and no hardware change for months. It used to run pretty stable.

 

So how could UNRAID's linux backbone (or UNRAID itself) help me identify the issue?

 

The syslog in the standard diagnostics is the RAM version that starts afresh every time the system is booted.  You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to the problem.  The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field and log to to a share instead.
 

A follow up, so this is not left pending whatever.
(although I am still evaluating if it got resolved)
Detailed description follows, you may skip to the final paragraph!

 

I enabled to mirror the log to USB. Nothing showed up (I mean to help identify, not nothing at all). It just stopped on its tracks and restarted.

 

This was one of the things that people in IT know IT SUCKS (I am in IT for decades) and can be really anything. CPU, RAM, mobo, PSU, peripherals, firmware, OS.
You really need almost a... duplicate system in spares, to be able to resolve this.

 

The problem was really even worse because since BEFORE the issue, I had another issue, that was not too serious when server was not self rebooting.
My system actually could freeze BEFORE booting the USB! So now with the self reboots it could (in >50% of cases), just stay forever in the first couple of text lines after UEFI init! (in "press F10 to setup")
When starting the system, it initiated the two HBA cards (probably - I had no feedback but probably did) and other things, before attempting to boot (like all BIOS/UEFI do).
When it was to freeze (and I let it), it didn't even go into the UEFI settings, though this took several seconds before happening. If I was fast, I could go to UEFI.
As I said this was definitely an issue, but when my system was stable (and since this is a home setup), well... OK, I chose to ignore it for now.
Though it didn't happen in the (a bit distant) past. With same hardware.

So, back to the main issue.
I did a RAM test, it didn't fail. I could more or less eliminate the RAM factor.

I checked temps, even on stress, it was a bit hot but well below serious (after all it uses a single fan AIO and the CPU is not a power house... R5 5600G).
Then OS got eliminated, as .14 came out, so I "changed" that too.
But OS was out of the picture a couple of days before anyway. You see, I found my system frozen (not rebooted) on UNRAID login screen. This in my (not huge but ok-ish) Linux experience, shows hardware issue, not OS.

So... when I switched to .14, I also played a bit with UEFI settings. Nothing seemed to improve things and I can say they were even marginally worse (to reach an actual boot).
I thought of switching from UEFI boot, to legacy. I noticed it didn't change a thing either BUT (hint) also noticed that my USB stick only showed as UEFI boot. Note, I don't mean it was ignored in legacy (i.e. say that no boot device is available). It actually seemed to ignore legacy boot mode. It seemed to remain in UEFI boot. So I started thinking of the firmware.
I had the latest (which was actually a couple of months old). So I put in the stick all the UEFI images from latest and back until the one that got my CPU supported. In fact until the next one, as the manufacturer strongly advised to use that because of a bug in previous. I went directly to that. No go, because I noticed that my two HBA cards didn't show up. Note, they MIGHT work, I don't know, but they didn't show in UEFI so that I couldn't diagnose them if needed. That was important.
Next version though, they showed up ok. I set all settings similar to the ones I already had... but noticed something important...
My USB stick showed up twice, both as UEFI and normal! Big change. I immediately switch to legacy mode, selected the stick in its non-UEFI mode and voilà the before-rare blue menu and timer showed up! Actually twice, as I had to reboot again because in older firmware enabling VM on CPU was hideously hidden, and I forgot to enable it. So, two times in a row, I could again "easily" boot.
After that, I manually started a parity check and my system hasn't rebooted or frozen for 24 hours. Which the last few days was very rare.

So: In mobos, don't update firmware if you don't have a reason to and everything already works. This SEEMS to have been my issue.
I am still curious what in the firmware was so bad that made things actually worsen by the day. Technically speaking, a problem should exist or not exist, especially in firmware.
Not start with not having it, then have it sometimes, then more and more.
I hope my actual firmware chip is not messed up and I just "refreshed" it for a while. I hope it was just a bug of the newer firmware versions esp. for my scenario (maybe it just happens with people having two PCIe HBA + a PCIe 10Gbit NIC... who knows).

 

Edited December 2, 20241 yr by NLS