Hey all,

I swapped out a drive for a larger one last week, and I got about 50% there and then the system hard hung, and now every time I try rebuilding the drive it hard hangs somewhere between an hour and 6 hours into it.dataserver2-safemode-diagnostics-20260620-1810.zip

Once it hard hangs, it will also hard hang on the forced reboot unless I boot into safe mode with no GUI. Any ideas, help, or support appreciated.

Oh and here is a picture of what I saw at the physical terminal while it was hard hung before I physically restarted it.

just happened again while I was in safe mode, rebooted to safe mode again. logs attached.

dataserver2-safemode-diagnostics-20260620-1827.zip

Enable the syslog server and post that after the next crash.

It was enabled for both of these logs

18 minutes ago, LumberJackGeek said:

It was enabled for both of these logs

Post a screenshot of your syslog server settings.

Odd, somehow i must have set it to store in the isos directory, just changed that and increased the number of logs and size:

You must also set the Remote syslog server. If you want it to log to itself just put localhost.

After you actually get it storing syslog where you have it set to store them, you must actually get it from there and zip it to post it. It isn't included in Diagnostics.

4 hours ago, trurl said:

You must also set the Remote syslog server. If you want it to log to itself just put localhost.

It should not be necessary as the mirror to flash option was set and with that the syslog-previous is automatically included in the diagnostics. Having said that the 'mirror to flash' option does put some extra wear on the flash drive so it is best not to leave it set if you are not investigating a current problem.

I am confused because I see syslog.txt and syslog-previous.txt in the diagnostics I shared already?

syslog-previous last timestamp Jun 20 18:08:58

Nothing before that seems likely to indicate problem

syslog first timestamp (reboot) Jun 20 18:22:54

Did hang occur between those timestamps?

Yeah I mean it's literally hanging at the end of the trace. I have replaced my HBA, and all of my power cables to my drives, and it just went down again. I will pull the logs tomorrow and share.

dataserver2-safemode-diagnostics-20260624-1448.zip

Hung again this morning after rebooting recovering from another hang. I rebooted into safe mode and gathered these logs, so the syslog-previous should be from the session that hung. So far I have:

1. Replaced all drive power cables

2. Replaced my HBA

3. Ran memtest, all clear

4. Removed the unassigned devices plugin

Any other recommendations?

7 hours ago, LumberJackGeek said:

I rebooted into safe mode and gathered these logs, so the syslog-previous should be from the session that hung

And that previous session was not in SAFE mode.

Does it still hang in SAFE mode? What if you Disable Docker and VM Manager in Settings?

Correct, that previous session was NOT safe mode, the only time I have hung in safe mode is sometimes when first booting into it after a hang, it will hang again but this has maybe only happened twice. The VM is shut down, but the manager not disabled, is that good enough? And I am running just Plex and tautlli effectively and it still happens.

I ordered a replacement drive to see if it's the drive that I am trying to put in the array, but there are no SMART errors so I had been avoiding, and the drive is 50% more expensive than when I originally paid for it so I wanted to avoid doing this, but I need to test it.

SMART for the invalid disk looks OK, but there has been no extended self-tests on it.

replace the drive, still having the same issues. I keep seeing this in logs:

kernel BUG at drivers/md/unraid.c:1622!

RIP: unraidd+0x12ce/0x13d0 [md_mod] Comm: mdunraidd0

preceded by: mdcmd (36): check → md: recovery thread: recon D4 ...

Any idea what this means or if it's related to my problem?

Post new diagnostics

CRASH-EVIDENCE-unraid-md-bug-20260630.zip

Additionally, I replaced the USB flash drive the OS was booting from today and switched over to an NVMe drive, started recomputing parity and I went down several hours later.

So far I have spent ~$900 replacing hardware trying to fix this issue.

8 hours ago, LumberJackGeek said:

RIP: unraidd+0x12ce/0x13d0 [md_mod] Comm: mdunraidd0

This error is not on the diagnostics posted, but it means the Unraid driver is crashing, and it's almost always a hardware issue, most often bad RAM or a bad CPU.

I see them in the diagnostic, check this file here:

pstore-20260630-202155/dmesg-efi_pstore-178244749403002

RAM has passed a memory check. What can I do to prove in or out CPU? I've seen other posts on these forums with folks being told similar symptoms are hardware, hardware, hardware, and then oh look here's an update that fixes.

I had AI review my logs, completely ack that it could be wrong, but:

But the persisted crash dumps reveal a clear, recurring root cause

Across the saved pstore/crash captures, the same kernel BUG repeats 24 times with an identical signature:

kernel BUG at drivers/md/unraid.c:1622!
Oops: invalid opcode  —  Comm: mdunraidd0  —  RIP: unraidd+0x12ce [md_mod]
md: recovery thread: recon D4 ...

• This is a BUG_ON assertion failing inside Unraid's own proprietary md driver (md_mod), in the mdunraidd0 kernel thread.

• Every occurrence is tied to a parity/reconstruct operation — specifically recon D4 (disk-4 rebuild/sync) appears 60 times in the captures. Disk 4 = sdq (the OOS 24 TB drive).

• This matches the evidence file you already saved: CRASH-EVIDENCE-unraid-md-bug-20260630.zip.