Hello,

Recently, after updating to 7.3.2 and using internal boot, my one of servers became unstable. I looked through the previous syslog and noticed nfs issues, however nothing that would completely shut it down. Note that the server goes completely offline, meaning fans turn off. There's still power to the server as I can see my Google Corals have LED lights on, but nothing is happening with those otherwise.

This was not happening before those two changes (upgrading to latest and internal boot), so if I had to guess, it would be caused by one of the two. I suppose it could be hardware failure of some kind as well.

I've attached my diagnostics. Thanks.

katrinaunraid-diagnostics-20260820-1707.zip

Edited August 20Aug 20 by PuzzlingGerbil
more details

The server shutting down by itself is almost always a hardware issue, but you can enable the syslog server and post that after the next event to see if there's anything starting a shutdown from the Unraid side, make sure to indicate the approximate date/time of shutdown.

Just now, JorgeB said:

The server shutting down by itself is almost always a hardware issue, but you can enable the syslog server and post that after the next event to see if there's anything starting a shutdown from the Unraid side, make sure to indicate the approximate date/time of shutdown.

Hi Jorge, thanks for your help.

I already have had the syslog server configured. I also write syslog to boot as I'm now using internal boot (so that should be in the zip above). Here's my remote syslog, though. The full server crash occurred sometime around 7:56 am, as that's when my uptime monitor stopped being able to ping. There's nothing in the logs showing a planned or forced shutdown unfortunately. My remote syslog server cut out at 7:50 am, as did my syslog write to flash in the diagnostics zip. The last thing in the log is:

Aug 20 07:07:41 KatrinaUnraid kernel: rpc_check_timeout: 54 callbacks suppressed
Aug 20 07:07:41 KatrinaUnraid kernel: nfs: server  not responding, still trying
### [PREVIOUS LINE REPEATED 9 TIMES] ###
Aug 20 07:42:22 KatrinaUnraid kernel: nfs: server  not responding, timed out

It definitely seems to point to hardware, which in that case I hope is the new internal boot drive (since it started to happen once I began using that). Although I'd also think that was strange since Unraid dumps boot into memory.

katrina-unraid-syslog-previous-around-crash.txt

I do see this in my log as well, after I rebooted it of course:

Aug 20 10:27:02 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] Resetting vcs0 for preemption time out
Aug 20 10:27:02 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] dec0:0:hevc[544155] context reset due to GPU hang
Aug 20 10:27:03 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in dec0:0:hevc [544155]
Aug 20 10:27:03 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] GPU error state saved to /sys/class/drm/card0/error
Aug 20 10:27:20 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] Resetting vcs0 for preemption time out
Aug 20 10:27:20 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] dec0:0:hevc[544155] context reset due to GPU hang
Aug 20 10:27:20 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in dec0:0:hevc [544155]
Aug 20 10:27:24 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] Resetting vcs0 for preemption time out
Aug 20 10:27:24 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] dec0:0:hevc[544155] context reset due to GPU hang
Aug 20 10:27:25 KatrinaUnraid kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:4:28fffffd, in dec0:0:hevc [544155]

This would be the built-in graphics on my intel CPU. Not sure if related or not.

12 hours ago, PuzzlingGerbil said:

It definitely seems to point to hardware

Yep

12 hours ago, PuzzlingGerbil said:

which in that case I hope is the new internal boot drive

It seems very unlikely to me that would be the issue; PSU would be my main suspect.

On 8/21/2026 at 6:39 AM, JorgeB said:

Yep

It seems very unlikely to me that would be the issue; PSU would be my main suspect.

Hello again @JorgeB , thank you for your advice and assistance as always.

I replaced the PSU, and for a couple of weeks that seemed to do the trick. However, it just happened again. And once again, there's nothing helpful in syslog-previous (or the remote syslog server). These are the last things in that:

Sep 16 05:41:32 KatrinaUnraid kernel: nfs: server  not responding, timed out
Sep 16 06:58:45 KatrinaUnraid kernel: nfs: server  not responding, still trying
Sep 16 07:07:51 KatrinaUnraid kernel: call_decode: 3 callbacks suppressed
Sep 16 07:07:51 KatrinaUnraid kernel: nfs: server  OK

I think the next suspect is memory or memory leak.

I can see a spike in memory usage on the server (viewed through my separate my home assistant unRAID API integration) for about 4 hours before the crash, and if I zoom out and view more, it looks like a slow but steady increase in memory consumption before a spike and then the system crash. It never gets anywhere near 100% in the attached graph, but maybe something is getting exhausted and causes a near instant shutdown? I'm not sure what would cause a panic that instantly causes an unlogged shutdown other than the PSU, however since the PSU was replaced and the same behavior is happening, it's seeming like it's something else.

I do have another theory related to the internal boot I configured right before this started happening. Could it be the mSATA SSD that I'm using with a USB 3.0 adapter? Perhaps it would stabilize if I used a PCI adapter for the mSATA drive? I'll probably start with this.

Replacing the PSU lowers suspicion of that unit, but it does not isolate the complete power path. The UPS, outlet, AC cable, motherboard, front-panel switch, and PSU cabling remain possible causes.

The original diagnostics and independent syslog do not support a memory-exhaustion event. The post-restart capture had about 50 GiB available memory and no out-of-memory event. The later graph shows correlation, but it does not show exhaustion or identify what allocated the memory.

The internal mSATA boot device is also not the leading suspect. It stayed present, passed SMART, and logged no USB transport or disk-I/O error. I would not move it to a PCI adapter as the first test.

The NFS warnings show that a remote server or network path was unavailable. The same warnings recovered on earlier days. Check whether that NFS server shares the same UPS, outlet, or network equipment.

Network UPS Tools (NUT) is active as the primary UPS monitor. It can request an operating-system shutdown. Please check the UPS event history and NUT event log at the exact failure time. The retained syslog contains no normal shutdown or low-battery sequence, so this path remains unproven.

The logs also contain repeated Intel GPU HEVC video-decode hangs. They are not adjacent to the captured power-off. However, they justify a controlled test with Intel hardware acceleration disabled in Frigate and Plex.

For the next test, please change one item at a time:

1. Record the exact event time, UPS state, fan state, and motherboard LEDs.

2. Check the UPS and NUT history for that time.

3. Update the PRIME H670-PLUS D4 to a supported stable BIOS. Load defaults and disable XMP, overclocking, and undervolting.

4. Run at least four complete offline memory-test passes.

5. Disable Intel GPU media acceleration for longer than the previous failure interval.

6. If it still powers off, test a known-good AC cable, UPS output, and outlet. Inspect the front-panel power switch.

Please post the exact shutdown time, the UPS/NUT history, and a new diagnostic after these controls. Keep the independent syslog enabled.