KeenanW

Members
  • Posts

    6
  • Joined

  • Last visited

KeenanW's Achievements

Noob

Noob (1/14)

0

Reputation

  1. In case anyone can't increase the resolution in Manjaro to anything beyond 1024x768, run the command sudo pacman -S xf86-video-qxl and reboot the VM.
  2. It turned out to be the array. I wasn't sure what else I could do to save the data, but I ended up starting fresh and all the issues described above went away.
  3. 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!
  4. 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.
  5. Thank you both for the quick responses! 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. Unfortunately, the slowness issue occurs both during and before/after a parity check.
  6. 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