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.

Anyone? This has happened multiple times now and is incredibly frustrating. I can't figure out what's triggering it, seems to be network related. As a paid product, what type of support are we entitled to? I'm happy to do some digging of my own if I can at least be pointed in the right direction.

Make sure you've turned off Fast Boot as that will disable booting from USB (which Unraid requires)

Just checked this on mine too. It looks like it is in Settings > Services

The IPMI card has pins for both plugging into the motherboard header pins, as well as passing through to the case buttons. You don't lose functionality, depending on the size of your case you might need extensions though. I ended up making some longer cables so I could cable manage them.

The reason, btw, is because fast boot achieves its speediness by only enabling core hardware and features for POST and leaving everything else to the OS. Some of this "unnecessary" functionality that doesn't get loaded includes USB booting.

Couple more updates... on 6.12.10... just happened again. As far as I can tell there's some networking problem as everything on my Unraid boxes main IP is failing when this occurs. IPv4 address is 10.10.10.250 and nothing responds on it. Not Unraid Web GUI, not containers exposing ports on it through a custom bridge network. Other containers bridged to separate networks continue working fine throughout the outage.

This is what I was seeing when trying to reach Unraid. SSH: Console WebGUI unresponsive Ping successful

I have had this occur twice thrice since upgrading from 6.12.6 to 6.12.8 (just happened again while writing this post) This issue also may be related to creation of new Windows 11 VMs as both times it happened was during setting up of new VMs. I hadn't made the connection between VM<>hanging during the first crash yet so cannot remember exactly what I was doing, but the second hang occurred as I was seconds into the Windows 11 install (selecting language settings) using the following ISO via SPICE: en-gb_windows_11_business_editions_version_23h2_updated_feb_2024_x64_dvd_d1d5d364.iso Note, I was having issues with noVNC on the VM I was setting up on 18th March, which I hadn't had in the past setting up my Windows 11 and Windows Server VMs with 6.12.6, hence I moved to using SPICE, and started using SPICE directly for the second VM. All three times this happened, I patiently waited and eventually it came back. I mainly did this because I could tell some other functions were still working fine. Other VMs were still reachable as normal on their own IPs. I'm not sure if it's related to services on the same pinned cores or sharing the same network bridge as it keeps happening during work hours when I don't have a whole lot of time to investigate. Attached the three diagnostics downloaded soon after the hangs occurred. The server was upgraded to 6.12.8 and has not been rebooted since. All three hangs have occurred since. define-diagnostics-20240318-1458.zip define-diagnostics-20240322-1540.zip define-diagnostics-20240322-1643.zip

You want your Graphics Configuration settings to look like this: As above, ensure CSM is disabled. I've also changed a few other BIOS settings but I don't think they're relevant. Report back if the above doesn't work. I spent a bunch of time troubleshooting and finally got it working nicely. I have a HDMI dummy plug but I don't need to use it with these settings.

Interesting that it seems to work with 6.9.2? Definitely sounds like it's simply a regression. I only started using Unraid recently so it hasn't "worked" for me in any acceptable manner. When I joined the Unraid server to the domain, I was able to use any AD principal to access the shares, however, there was no way to limit what they could do. By default the EVERYONE principal has full control which defeats the purpose of security. Attempting to remove that (after adding suitable AD users or groups) would just completely kill access and I needed to restore permissions using the built-in tool, which then reverted to nobody/users and removed AD access. I'm sure there's a way to get it working by dealing with the ACLs directly but by that point, what is the value of the Unraid licence I've purchased? I previously had minimal Debian servers, joined to the domain, allowing me to authenticate with domain accounts and control their access but I am trying to avoid manual configuration in Unraid as I worry it may be overridden in upgrades or simply reboots. Reminds me of another annoyance which I hadn't bothered digging into yet... when Unraid server is joined to the domain, it doesn't register its IP addresses in DNS, whereas, my other Debian boxes do (ensuring correct config in /etc/resolv.conf and DCs in /etc/hosts)... sorry more digressions