Hi all, for the past year Unraid worked perfectly fine with my AMD hardware (B550 and 5800X). I really wanted to get HW transcoding without using a GPU so I decided to migrate to a Z790 DDR4 and an Intel i5 13500. Everything worked fine after the hardware migration but as soon as I start using my jellyfin to watch things, I get crashes. I really tried hard to figure out whats causing the issue but I can only see maybe some realtek nic timeouts and possibly memory failure. I've ran memtest and got 3 passes so im not sure whats going on.

I'm including my syslog here to anyone that might be able to help me.

syslog.txt

Attach Diagnostics ZIP to your NEXT post in this thread.

Thanks for taking a look at my post, Here is my Diagnostics ZIP file

server-diagnostics-20250406-1353.zip

Why were you running a correcting parity check, and why did it have parity sync errors to correct?

 

Have you ever had zero parity errors? That is the only acceptable result.

 

Apr  6 13:31:23 Server kernel: BTRFS warning (device loop2): csum failed root 3610 ino 3259 off 1077248 csum 0xaf0ea063 expected csum 0x0903e211 mirror 1

btrfs csum errors are usually bad RAM. Only saw this one, and it is in the docker.img vdisk so maybe left over from your old system.

 

But that plus my questions about parity sync errors make me suspect RAM.

 

I didn't run it manually, but it must've been my scheduled parity check at the beginning of the month.

I suspect it must be a bad processor/motherboard since this ram came from my AMD system and it ran perfectly there.

I've ran memtest and it never found anything though. with 3 passes. Unless there are different parameters I need to run, I just boot up memtest and let it do its thing without touching it.

About that btrfs scum error, could you please point me to the right direction to fix that? or will the parity check/correction do that it self?

1 minute ago, Aiden0rchad said:

my scheduled parity check

should be noncorrecting. You don't want it to go off on its own changing parity when there is some other problem going on.

I see! I always thought that parity checks are error correcting if they don't match up. Would it be best remove the parity drives, format them then add them back?

 

Sorry for my ignorance, still starting out in this homelab journey.

5 minutes ago, Aiden0rchad said:

my scheduled parity check at the beginning of the month.

Apr  6 13:31:14 Server kernel: mdcmd (37): check correct
Apr  6 13:31:14 Server kernel: md: recovery thread: check P Q ...

Obviously not the beginning of the month

2 minutes ago, Aiden0rchad said:

remove the parity drives, format them

Parity has no filesystem so pointless to format them. Many people have made serious mistakes because they don't understand what format means.

 

Scheduled parity checks should be non-correcting because if it turns out you do have parity errors, there might be something else that is causing that, and you don't want to overwrite good parity with bad.

 

Before doing anything else, we need to establish that you can get to exactly zero parity errors.

 

Is that correcting parity check still running?

Makes perfect sense. Thank you for the info.

 

Nope, I let the machine stay dead after getting this crash 5 times.

 

should I let this parity check run? how do I make it "correcting"?

Edited April 7, 20251 yr by Aiden0rchad

Boot in SAFE mode, disable Docker and VM Manager in Settings.

 

Run a correcting parity check to fix those parity errors. Post diagnostics when it completes.

 

DO NOT reboot.

 

Then, run a non-correcting parity check to confirm no parity errors remain. Either way, post new diagnostics when it completes

Just an update @trurl

This might be the cause of the issue. Looks like it might be due to a loose or bad cable on one of my SSD drives. From inspection the wire is a bit too short and tugging on it a bit.
 

Just finished with the correcting parity check. Here are the results:

1stCorrection_server-diagnostics-20250408-0313.zip

How many sync errors did you get?

 

Go ahead with the noncorrecting parity check.

88 errors, like the one in the image above

On 4/7/2025 at 12:58 AM, Aiden0rchad said:

Just an update @trurl
 

 

88 errors in the beginning of a parity check may just be from unclean shutdown.

Apr  6 20:56:28 Server emhttpd: unclean shutdown detected

 

23 hours ago, trurl said:

88 errors in the beginning of a parity check may just be from unclean shutdown.

Apr  6 20:56:28 Server emhttpd: unclean shutdown detected

 

You are correct, most likely it came from an unclean shutdown since I had weird issues from my display when I was first booting up my server after the migration which forced me to force it to turn off.

 

Here is the last parity check without correction 

nocorrection_server-diagnostics-20250409-1143.zip

Were there any parity sync errors remaining?

Not at all, stayed at 0 error after correcting them.

I feel like I might be good to go, reboot and give it whirl?

👍

Just giving you an update, the crash happened again and I decided to chatGPT the heck out of it.

When I went to the brass tacks with all the errors, it found that there was corruption happening in my "docker.img" file. I recommended me to wipe it and reinstall all the docker images I had. 

Another thing that it recommended me to do was to scrub my "btrfs" so that I did.

So far running it in all its paces has no crashes now.

@trurl Thank you for your help and teaching me about parity correction and scanning information.