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.



 

Boot from USB2 port is often more reliable.

 

Attach Diagnostics ZIP to your NEXT post in this thread.

Also setup syslog server

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

Edited April 8, 20251 yr by TerminalOrangutang

1 hour ago, TerminalOrangutang said:

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.

This typically means a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one, including the docker containers. 

39 minutes ago, JorgeB said:

This typically means a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one, including the docker containers. 

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.