New mobo and issues migrating to new hardware


Recommended Posts

Howdy,

 

Recently my ASRock C2750D4I spontaneously bit the dust and I've had nothing but issues trying to get Unraid back to working order since. The replacement mobo I purchased is Supermicro A2SDi-8C+-HLN4F. Some differences came with the setup of this motherboard:

 

  • New memory (Now: 1x Supermicro MEM-DR416L-SL06-ER24 16GB DDR4-2400. Previous: 2x Crucial 8GB DDR3L 1600MT/s PC3-12800 DR x8 ECC UDIMM CT102472BD160B)
  • Mini-SAS to SATA connectors. (2x Cable Matters SFF-8643 to SATA Forward Breakout)

 

When I got the motherboard, there were some roadblocks to get to the point where I am now. Probably not relevant, but to put the current issue in context: Couldn't boot to Unraid (Had to rename the config\EFI- directory to config\EFI), and couldn't establish a network connection (Had to remove ethernet from IPMI and put in another adapter). Once I was able to get to Unraid, I attempted to use the same USB. Things seemed in order until I attempted to start the array. It held at "Starting services..." indefinitely. Researching dug up that I should disable Docker and VM, so I did that. It fixed the array from being unable the start, but that was the start of my current problems.

 

My dataset looked good. I didn't notice any data loss. When opening files, however, I noticed that it brought the CPU to its knees. A 50MB video file would eventually peg all cores and make the mounted drive inaccessible for a long time. It would eventually load and play maybe 15 seconds before having to do it all over again. I noticed in the web UI that the cores would persistently stay at 100% and never dwindle. My first thought was the configuration was corrupt, so I proceeded with a fresh, unmodified Unraid install and imported the parity and data disks as they were before. That was fine, but it showed the same behavior. The top command hasn't yet pointed to anything obvious to me, so I'm a bit dumbfounded. At this point, the consistent factors between each attempt of this are the motherboard, the dataset, and the USB drive with Unraid. I can't imagine the RAM would be impacting anything.

 

My questions are: am I in the right direction thinking it is the CPU motherboard and a configuration with it? Could it actually be my parity/array/dataset? Is there anything in the mobo BIOS I could check for that might resolve these issues, and do you think wiping my disks should be a last-ditch effort? Obviously, I hope no more nuke-from-orbit solutions are necessary.

 

My apologies if I glossed over any details or left out any essential information. I'm getting to my wit's end since I was under the impression that migration to new hardware would be relatively painless. I've attached two diagnostics archives. One was generated as I wrote this post and one is from the Unraid from my backed up configuration file from the "working" install. If you need further clarification, please let me know. Thanks for reading.

 

Regards,

Keenan

crusader-diagnostics-20190614-1155.zip crusader-diagnostics-20190612-0136.zip

Link to comment

Thank you both for the quick responses!

 

53 minutes ago, itimpi said:

Have you tried stopping the array, restarting it in Maintenance mode; and then clicking on each drive in turn to run a file system check on the drive.     May not help but cannot do any harm and is a sensible check to have done.

 

My thought of the data being pristine may be eroding. The array was actively being used at the time the old motherboard went kaput, so corruption is definitely on the table. It just didn't cross my mind until now since I was able to at least mount and navigate the drives after the hardware swaps. I have not run any filesystem checks as of yet—just parity checks. I will try this and post the findings.

 

53 minutes ago, johnnie.black said:

Nothing jumps out, but a parity check is running, array will be noticeable slower during that.

 

Unfortunately, the slowness issue occurs both during and before/after a parity check.

 

Link to comment

Using xfs_repair seems to be flaky. I first tried it on a disk with the -n parameter, but it hanged for a long time (~2-3 hours). I tried through the terminal instead of the web interface using command "xfs_repair -v -L /dev/mapper/md1", and that zoomed right through and seemingly did it. However, the next two disks I tried on just seemingly hang at different points each time I attempt using any variation of command, now they are listed as unmountable when I start the array in non-maintenance mode. Can't seem to complete the checks on those, and I'm hesitant to try the other disks. Any ideas would be very appreciated.

Link to comment
3 hours ago, johnnie.black said:

Do you have another board/controller you can try?

I do not, but I am hoping for an RMA to be approved for the original ASRock board. I bought a new board because I read about a defect with Intel Atom C2000 hardware which will inevitably brick and didn't want to deal with the possibiity of this happening again. Once it arrives, I'll try with that and see how it goes. Thanks again!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.