fredskis

Great - thank you @itimpi for confirming that 🙂 I think this is back to working now then! Thanks again @JorgeB

4 hours later, still no output from those commands. Oh well, here goes a format 😁 🤞🏽 Edit: Interestingly, format completed very quickly - I thought it would constitute a lengthy clean process as well - I guess it successfully cleaned during the original format operation? Any reason to be concerned that the disks list ~1.9% of data already "Used"? 421 GB for the 22 TB disk and 498 GB for the 26 TB disk I had a quick look with lsblk and didn't notice any bonus partitions nor do I see files when trying to browse the mount points

Thanks for that. Been about 10 minutes now and no output from either. Guessing they weren't formatted then.

That's the question I'm asking - if it's possible to determine. Between the clear supposedly finishing and the first power event that triggered the parity check (a day or so) I didn't get a chance to manually validate. As I understand it, if the format never completed then the behaviour explains itself and there is no useful data on those disks anyway and my solution would be to format again. However, I don't know if there's a chance for the format to have happened and then the power event caused something strange to happen or to revert to a previous config while there having been some data written to those disks that I now can't identify...

Hi all, Back with another weird issue. Long story short, I have the error in the title on two drives following a power outage during parity check, wondering how to pull data off them before reformatting and re-adding to array. Details below: I recently added 3x new 26 TB HDDs to my array. One replaced a failed 14 TB drive (removed failed drive, added new (Disk 7) rebuilt disk) One replaced the existing 22 TB Parity (added 26 TB Parity 2, recalculated, removed Parity 1) The final 26 TB one, along with the 22TB previously-Parity 1 drive were added as new disks, Disk 15 and Disk 14 respectively. After the final two disks were added parity, they were cleared as normal, this took a couple of days. I didn't monitor the state after this but there was a power outage that resulted in an unsafe shutdown. On restart, the array was recalculating parity, as expected. During the next couple of days, there was another power outage. When the array came back up, it mounted, but the two new disks now show up with the FS attribute showing as "auto" and the error: Unmountable: unsupported or no file system I have looked through other threads and performed the following steps. Firstly, there is no Check Filesystem Status section in these disks settings, probably because they're not even identified as xfs, so I can't "click the Check button" as is referenced in other threads. See below Disk 14 and Disk 15 Settings. I've also added a Disk 13 Settings screenshot of a good disk that does show the section and button. I instead manually ran xfs_repair -v /dev/md14p1 and xfs_repair -v /dev/md15p1 on the disks. This immediately detects a bad primary superblock and then takes over a day on each drive (I guess it's scanning the whole disk?) and fails to find a secondary superblock. Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ................................................ Sorry, could not find valid secondary superblock Exiting now. Is there a next step to try and repair the filesystem on these disks and attempt to view what files may have been placed there in the day or two they were live before this problem? Ideally I'd just want to access and pull those files off, then I assume reformat these two again? I have since solved my power issue - I have a UPS that is now 3-4 years old and Unraid is configured to shut down when it reaches 10 minutes of battery run-time left. The UPS used to last about 2 hours, however, due to battery degradation, now after an hour on no power, it quickly drops from reporting ~45 mins runtime left to 2 mins, then loses power within the minute. I have now recalibrated it and set Unraid to shut down after 20 minutes of a continued power outage event to avoid this same problem. I've also attached diagnostics. define-diagnostics-20251222-1021.zip

Can you confirm that in that time it did at least one full pass of all memory? I recently did a memtest of 2x 32GB DDR4 SODIMMs and it took longer than overnight to complete the first pass.

So you say they passed Memtest, but also that they locked up on Memtest? Which is it? If they're locking up, that's pointing to the problem... If you're running them at their rated speed or less then clearly points to faulty RAM. Can you figure out which stick(s) are bad? It's a time consuming process but the best way is to hammer them with Memtest for a while

Disable Fast Boot otherwise Unraid can't automatically boot as Fast Boot disables USB boot. Set iGPU to Multi Monitor to allow IPMI video output and iGPU access to Unraid. Set SlimSAS configuration to SATA if you plan on using the SAS plug on the board to split to 4x SATA drives.

I'll check when I get home but I was using most of the PCIe slots plus both M.2 slots. I have two 2TB NVMe drives as mirrored cache, the IPMI card in the top PCIe slots closest to the CPU, then two HBA cards (one slot gap between them for cooling), and one ASUS 10GbE card in the bottom slot. I can double check the actual slots when I get home, although since then I've changed to a HBA with more slots so one more slots available .

I didn't know about the ASRock board when I was choosing to be honest. I thought the ASUS was the only LGA 1700 board that supported ECC RAM. The 14 onboard SATA slots look great on the ASRock and largely negates the requirement for more PCIe slots for more HBAs. However, for me, IPMI was the killer feature.

Go to Advanced > Onboard Devices Configuration You'll find a setting for SlimSAS Configuration. You want to change that to SATA.

How did you manage this by the way? Was a Windows installer ISO sufficient? Or did you have to bodge together something custom? As I understand it, the Intel ME driver etc (Windows-only) installer also includes firmware updates for the chipset or some subcomponents of it? Unless I've misunderstood it... but I always see on motherboard manufacturer manuals/guides, to ALWAYS upgrade Intel ME.

Interesting, 1.1.34 is the latest version for the full sized board/card. (I've got 1.1.33 installed) https://www.asus.com/motherboards-components/motherboards/workstation/pro-ws-w680-ace-ipmi/helpdesk_bios?model2Name=Pro-WS-W680-ACE-IPMI

My screenshot was from the ATX sized WS W680-ACE IPMI where the IPMI card is a separate add-in card that occupies a PCI-e slot and needs to be wired in to front panel headers, power, etc (ugly). Seems they're not so comparable to the built-in mATX version though if these differences exist? Have you got the latest BIOS? Edit: actually, going by your screenshot, seems you've got the same version as me. Hmm.