Aganan

Hi JorgeB, thanks for the reply. So I've got 32gb split 4x 8gb. I've booted Unraid with individual 8gb sticks and am still getting Call Trace errors. Would this photo (sorry, not sure why I didn't take a screenshot. Very very tired) indicate that the hardware issue is with my CPU?

I may have spoken too soon, went into one of the containers to change the settings as I only seeing the port number and not the whole IP address on the docker page and it crashed Unraid. Took a picture of the monitor attached to the Unraid tower. When I rebooted, the container was completely removed from my docker page. Went to reinstall the container and it auto-started. Worried it would crash again, I tried to go into the container settings but didn't have enough time unchange the edit I made before it crashed again. This time a Call trace error. 1st Crash 2nd Crash

Update. I ran the server for 48hrs in safe mode. Did a couple of backups from my PC to Unraid. I also played some media files hosted on Unraid just so it wasn't sitting there doing nothing. Experienced no issues at all. Decided to reboot Unraid with services and docker enabled and turned on one docker container at a time spaced out over long intervals. Had plans with the family, sleep, etc. Couldn't sit next to Unraid all day. Everything so far has been stable. No trace errors. I have avoided turning on the Satisfactory Dedicated Server so far. But plan to do so once I've confirmed some stability with all the other containers up and running. I did get a hardware error again and have attached a syslog and diagnostics. Is the ACHP/BIOS error and the mce Hardware error the same thing? Apologies, I have no idea how to read these logs. How do I view the mcelog? Thanks again for the help. apollo-diagnostics-20241104-2017.zip apollo-syslog-20241104-1117.zip

Hi JorgeB, thanks for the advice. I'll go ahead and do as you recommended and post the findings here. Hi mathomas3, thanks for the reply. I decided to change out the PSU entirely. Originally it was a 750W. Now I have a different PSU at 1000W in the system. Booting to Unraid isn't an issue, unless you're suggesting I try migrating the system to a different CPU, MOBO, RAM etc which I can do. When I was troubleshooting previously, I would boot up into Unraid and immediately go and disable the Docker service as I was convinced one of the containers was causing Call Traces. Hard to say so with certainty after seeing the hardware error in the log. The mobo, CPU, ram in the system currently are over 10 years old, so it could just be their time. I also thought maybe it was the Satisfactory dedicated server container in docker causing issues but I had that running for almost a whole day yesterday. Then I went to update a password in Vaultwarden and got another Call Trace error. I have the system in Safe Mode currently doing a Parity Check. I got a 3 day weekend ahead, so I'll turn docker services back on Monday and turn on individual containers one by one and see what happens. I'll try this as well if need be. Thanks again.

Hi all, hoping someone can help. Came home to a powered-off server. I troubleshooted the following, PSU checked out fine. Tested server with alternate PSUs. I removed the battery on the mobo to clear bios. The original USB memory stick seemed faulty from the dirty power off, I'm not sure tbh if that was the cause of the USB memory card acting up but it has since been replaced. Backup of Unraid installed on new USB memory stick. Once I got Unraid back up and running, it would start crashing, getting Call Trace errors up the wazoo. I'm not sure why all of a sudden it started happening. I recently installed the Satisfactory dedicated server in Docker which may have been the cause/catalyst, though that docker app ran fine for a few days with zero issues. I was on macvlan but followed the instructions in the 6.12.4 release notes and switched to ipvlan. I still got call trace errors. tinkered further with docker and network settings. Currently, my network settings are: Docker Settings: ipvlan Settings > Network Settings > eth0 > Enable Bonding = No. Settings > Network Settings > eth0 > Enable Bridging = Yes. Settings > Docker > Host access to custom networks = Disabled I also deleted the docker image file, and reinstalled all dockers apps again on a new image. I had a bit of stability for almost a day but then noticed a mce: [Hardware Error]: Machine check events logged, but I was unable to figure out how to investigate further. A little later on another call trace. Many dirty power offs and powering on back to Unraid to try and solve the issue but unfortunately, I'm still getting call trace errors which forces me to do another dirty power off. Lost count now. I ran a memtest overnight and completed over 4 passes, zero errors. I've exhausted my ideas to further troubleshoot, hence why I'm here. I have attached some images and diagnostics which I got immediately after powering up from another crash. Any help is much appreciated. apollo-diagnostics-20241101-1700.zip

Apologies for the late reply, but I just wanted to say thank you for your help and guidance.

I just noticed my new 8TB drive has 2.97TB already on the drive. /facepalm. This is undoubtedly from the Data-Rebuild back when I was on 6.11.2 Does this mean that even though Unraid is telling me a Data-Rebuild is in progress, whats really happening is just a Parity Sync? The new drive is getting a lot of writes and very few reads, so it appears to be a Data-Rebuild. But why would that be necessary if Unraid can see that the 2.7TB content is already on the drive?

Following my previous post, I was no longer able to access my server after a while just leaving the server as is. I attached a monitor and took this photo. I'm not sure why this happened. I guess Unraid didn't like having the drive assigned but the array stopped for a long period of time. I did a hard shut down and booted up the server again. Thankfully I was able to log back into the server. Due to the crash, I decided it was best to just go ahead and start the array and let the Parity-Sync and/or Data-Rebuild happen. When I started the array, I'm able to see the new 8TB drives FS, Size, Used, Free and View it's contents. However the Array appears to be doing a Data Rebuild and not just a Parity-Sync. I was hoping that Unraid would recognize that I had already done a Data Rebuild back on 6.11.2 but I guess this is not the case.

Hi again, sorry for the late reply. Different timezones. Apologies, I made a mistake. The drive is mountable and I've reassigned it to the array as shown in the image. But I haven't started the array yet because it's telling me if I do that, then it will Parity-Sync and/or Data-Rebuild. I already did a Data Rebuild previously on 6.11.2 though, so trying to avoid that process again if possible. Happy to do it again ofcourse if need be. Am I correct to assume if I Start the array now, then Unraid will recognize I already did the Data-Rebuild previously and there won't be another Data-Rebuild on the drive? Here is the top and bottom screen shots of the Main. Thanks again.

Thank you for the prompt reply. I stopped the array, unassigned and started the array but the drive didn't mount. Please see attached diags. I got a notification saying Disk 5 in error state. No device identification. I stopped the array and now have the option to do a data drive rebuild on the 8TB drive. (I have not done this yet.) Appreciate any further help you can provide. Thanks. apollo-diagnostics-20230414-2002.zip

I have a similar issue. I was previously running 6.11.2 and replaced a date drive. 6TB to 8TB. I followed the Unraid "Replace a Data Drive guide" The rebuild of the data drive completed with out error and I got the notification that Disk 5 had returned to normal operation. However the new drive (8TB) was showing the "Unmountable: Unsupported partition layout." Message. The 8TB hdd is brand new and I didn't bother with a format or pre-clear prior. I should also note that all my data drives connect to Unraid via a SAS controller. But I'm only using the SAS controller to populate my system with more drives as my mobo only has 4 SATA connectors which are being used by my 2 Parity drives and my 2 Cache drives. The SAS controller is not running it's own Raid. I have never had an issue with Unraid and using the the SAS controller to attach my data drives. After researching on the Unraid forums, I discovered the "Unmountable: Unsupported partition layout." Message is a bug with 6.11.2 and I should upgrade the OS. I upgraded to the most recent version at the time of this post which is 6.11.5, however the "Unmountable: Unsupported partition layout." message persists. I have tried rebooting & shutdown / power on. Stopping the array. Unassigning the new drive from the array and setting it to no device (like in the "Replace a Data Drive guide") and rebooting. I hoped this would allow me to then reassign the new drive back and a disk rebuild would initiate. However after rebooting, the array has already started with the new drive re-assigned. "Unmountable: Unsupported partition layout." message persists. I have tried connecting the new drive via SATA directly to my motherboard and connecting 1 of my cache drives to the SAS controller. After doing this, they both are recognised by Unraid as per usual but the new drive still has the "Unmountable: Unsupported partition layout." message. Finally, I also tried to assigh back the original 6TB drive. However Unraid now says I can't put that drive back into the array because it is smaller than the drive it is now replacing which is the new 8TB drive... In the Main Tab, Under Array Operation, it gives me the option to Format the new 8TB drive. However I have read that Formatting is never part of the Data Rebuild process and so I dare not touch it. Any help / guidance would be greatly appreciated. Thanks. apollo-diagnostics-20230414-1902.zip