t33j4y

After reading the link, I upgraded server #2 to 7.3.0-rc.2 and the behavior is now on par with server #1 Thanks!

I'm running two Unraid servers, both of which I just upgraded to 7.2.5. Server #1 (plain media server, no dockers, onboard 1G NIC, Xeon E3-1225V6, 32GB) GUI is as snappy as it was before upgrading Server #2 (personal file server, 9 dockers, 10G card, AMD Ryzen 5 PRO 4650G, 64GB) GUI is slow - takes up to 5 seconds to switch between tabs. Both are accessed on local IP (no redirect) I've tried stopping all dockers but to no avail. The only error the log shows is webGUI: error: /plugins/dynamix.my.servers/include/unraid-api.php - wrong csrf_token but I don't have the Unraid Connect app installed. I'm at a loss as to where to look for issues, so any pointers would be greatly appreciated! Thanks in advance.

While looking through my Appdata Backup files, I found that xml files for dockers that I have long since uninstalled are still being backed up. There are no folders in my Appdata for said dockers, so I am wondering where these residuals are coming from. Can anyone shed a light on this? There is no sign of residuals when running Cleanup Appdata or Fix Common Errors Thanks in advance! EDIT: Found it! Turns out that templates (XML files) are still stored in /boot/config/plugins/dockerMan/templates-user/

Any chance that Gigabyte motherboards will get some love? Running a MC12-LE0 and would really like a better way to control fan speed than the awful Fan Profiles in the BMC :-(

Just did this. The flexibility and robustness of Unraid never ceases to amaze me :-)

So, I did this and it worked. However, I expanded the step-by-step instructions to hopefully help others looking for this information. I guess for those who do a lot of server maintenance, things are obvious but it kind of threw me for a bit with the old user script apparently not working and the docs.unraid.net article not having a revision timestamp (so I wasn't able to verify if it was up to date) Also, I removed the unmount part as it didn't make sense, since the disks weren't mounted after removing the file system. So, here goes: To use the parity-preserve method Start the array in maintenance mode Click on the disk you want to remove, and then click Erase. This erases the file system from the device while maintaining parity, then stop the array. Start the array again and record array assignments Start the array in Normal mode. The disk won't mount, but the remaining disks are online. Record array assignments, especially the parity drive (take a screenshot and save it) Optionally enable 'Reconstruct Write' for faster zeroing (but only if all drives are healthy): Go to in Settings → Disk Settings (look for 'Tunable (md_write_method)' and change to 'Reconstruct Write' Zero out the disk using the dd command from a terminal window: Open a terminal window on the Unraid server Tip: If opening terminal from Unraid GUI, as the first thing, type 'tmux' to persist the terminal window as the dd command will abort if the terminal is closed - you can later connect to the same terminal window by typing 'tmux attach') Then enter the appropriate command: For Unraid 6.12 or later: dd bs=1M if=/dev/zero of=/dev/mdXp1 status=progress For Unraid 6.11 or earlier: dd bs=1M if=/dev/zero of=/dev/mdX status=progress (Replace X with the specific number of the data disk you're removing. If in doubt, use 'lsblk' command in terminal window to identify disks and number. The 'mdXp1' overview will be at the end of the command output) Once the clearing is complete, close the terminal windows and stop the array (from the Unraid GUI) Reset the array configuration, retaining all current assignments: Go to 'Tools' and select the 'New Config' function. Under 'Preserve current assignments', select 'All' Unassign the disk you want to remove Go back to 'Main' windows and unassign the disk you want to remove Remember to double-check all assignments - especially the parity drive (this is where the screenshot of your assignments comes in handy) Scroll down to the section where you can start the array Check the box indicating "Parity is already valid." Start the array to finish the removal. Finishing up If you enabled 'Reconstruct Write), remember to set it back to 'Auto' Optionally run a correcting parity check afterward to ensure parity integrity. Shut down your server, physcially remove the disk and restart the server. Let me know if this is helpful, anything should be changed or optimized.

Seems the link is broken - assuming it is now this: Removing disks from array | Unraid Docs Is the "Preserving parity" option still valid for 7.2.3 ?

One of my servers is on 7.0.1 - should I shoot for 7.1.3 directly or go 7.1.2 -> 7.1.3?

Hi, yes this is the mobo I am using. While I had a number of issues as this thread shows, I don't remember any issues regarding booting. Assuming you have ensured that you have latest BIOS - have you tried - disabling secure boot? - fiddling around with BIOS boot modes (CSM or UEFI) ? - booting into GUI mode (you'll need a keyboard, mouse and monitor connected)? - another USB stick

I think it would benefit resolution if you posted your hardware specs - there might be others with the same gear (specifically mobo) who can post their experience. If someone else on 6.12.14 with the same mobo is getting more like your 11W @ idle, you will already have narrowed it in quite a bit to be something local to you. On the other hand, if others with same mobo - or chipset - report the same ~24W, you will be know where to look more.

Wanted to wrap this up, so here goes. 1. I never managed to get the script for method 2 to complete. So while it seemed a good way, either I was doing something wrong that made the script complete prematurely and without any errors in log or it is not mature enough for general use? 2. After considering that I had enough backup and safety net, I ended up doing what I stated in option B (see quote below) and then weathered the parity rebuild time and the (slightly) higher exposure to risk. Everything went well 🙂

Yes, everything was done within unraid.

@bmartino1 Before the clear, the drive had approx 500GB on it, which was written over the last couple of months after a preclear. Data was moved away, the drive was reformatted (stop array, swap to XFS encrypted, start array and wait for format. Then the same, swapping back to XFS) Then created the 'clear-me' folder and that was it.

Unsure what you mean by "I wnat to know how much space was written to it." - if you mean as a result of running the script: I'm not concerned per se, I just want to make the right choice to proceed and not botch things and make more work for myself than necessary :-)

Hmm... so do I: A. Try running the script again? B. Ditch method 2 and go to method 1 (which means rebuild parity) and jump in at step 3? Make sure that the drive or drives you are removing have been removed from any inclusions or exclusions for all shares, including in the global share settings. Shares should be changed from the default of "All" to "Include". This include list should contain only the drives that will be retained. Make sure you have a copy of your array assignments, especially the parity drive. You may need this list if the "Retain current configuration" option doesn't work correctly Stop the array (if it is started) Go to Tools then New Config Click on the Retain current configuration box (says None at first), click on the box for All, then click on close Click on the box for Yes I want to do this, then click Apply then Done Return to the Main page, and check all assignments. If any are missing, correct them. Unassign the drive(s) you are removing. Double check all of the assignments, especially the parity drive(s)! Do not click the check box for Parity is already valid; make sure it is NOT checked; parity is not valid now and won't be until the parity build completes Start the array to commit the changes; system is usable now, but it will take a long time rebuilding parity