TerminalOrangutang

Haven't gotten to the point of having any VMs or docker containers or other stuff installed - it has a single array with all three disks with one share (and no files). That's it. I do believe it's a hardware problem with the motherboard/CPU, I'm just trying to see if I can nail it down specifically.

This is a good example of a failure profile - somewhere between the end of syslog.previous (the last entry of which is April 7, 17:37) - and the beginning of syslog (April 8, 08:02) the system became fully unresponsive and totally locked up. (It was probably somewhere after 0200 on April 8, since I was logged into the console and adjusting settings at about midnight.) I power cycled at about ~0800, which started the new syslog entry. The system fully booted again, and I was able to login (as you can see at 08:03:12) but locked up after only a few seconds and became totally unresponsive again. When it does this, it's not just the webUI that becomes unresponsive but the console, as well. syslog syslog-previous tower-diagnostics-20250407-1023.zip

Having been in a tech support role in my past life, I'll try to be as coherent as I can be without (I think) having easy access to useful logs. I've built a little custom box specifically to use as a NAS. These are the parts: Topton N18 motherboard with an Intel N150 CPU (https://www.aliexpress.com/item/1005007287947062.html), 16GB Patriot Signature DDR SODIMM 2x Patriot P320 512GB NVME drives (for cache) 3x 12TB Seagate Ironwolf drives (for storage) I also had a pair of Kingston DT101 G2 USB keys (8 and 32GB) lying around which I used irregularly, but I also specifically bought a Samsung BAR Plus USB key that I saw recommended somewhere along here (even though it's USB 3 and 64GB). I installed Unraid on the Samsung BAR, put everything together, and turned on the box. Unraid kicked off the boot process (no-GUI). The first boot reached "Triggering udev events" before it just hung there, indefinitely. The second boot reached "Starting emhttpd" before it hung there. I went through several more boot cycles, but the furthest that it ever got was to reach the "Tower login:" mark (which it reached only once), at which point it crashed after about 15 seconds. The blinking _ cursor would stop and the webGUI would become entirely unresponsive. As any good technician would do I went back and started from scratch: I removed all devices and booted just the USB key, CPU, motherboard, and RAM, and ran memtests. Left memtest running all night; no issues reported with the SODIMM. Booting in those conditions I could reach the webGUI, (which had no errors) about two times out of three; the third time, it would normally fail to start the emhttpd. I re-added the hard disks, and was able to boot into the webGUI and build a 3-disk array. It did its parity thing (the entire thing was up for about ~18 hours). Re-adding the NVME drives meant it would not boot again. I put each NVME drive in a different PC individually, validated them, and swapped them for a known-good NVME drive in the NAS. The system resumed crashing inconsistently with any combination of NVME drives possible. Removed the NVME drives; the system booted back up and reached the dashboard, and the array came up successfully. Again this only consistently boots about two times out of three. TLDR: I suspect that the culprit here is the motherboard/CPU - something is not very stable, and I wonder if it's the PCIe controller that is flaking out somehow. 1. Has anyone else successfully used a N18 or other similar N150 motherboard under similar conditions? Any known problems? I did search and saw some people complaining the system was maybe underpowered, but nothing exactly like this. 2. Is there a good way to extract more diagnostic data from Unraid? The Boot Issues and Capturing Diagnostic Information mostly seem related to either diagnosing a bad USB key or a failing webGUI where the underlying system is still up and reachable using SSH. In most of the cases I seem to be experiencing the entire system crashes without any ability to access it at all.