[SOLVED] Bad super.dat and backup has config from old array

[werdisturbed]

I searched but couldn't find my exact issue listed in the forum so here goes.

 

I woke up this morning to some errors in the GUI and did as I have in the past and rebooted the server.  The server never came up.  I hooked up a monitor and saw "no default or ui configuration directive found".  I searched for solutions to that and found it to be easier to just do a new install to USB and migrate the configuration to the new disk.  This resulted in the software never fully booting to where it was pingable.  I reverted to a fresh install and that boots without issue.

 

Looking through my config (cfg) files I can see that nearly all of them are corrupted.  I tried with just the minimal configurations coming over with the .key and super.dat file, was able to recover the key to the new USB (I don't trust the old one at this point) but the array configuration is still asking me to enter in the drives.  Expanding further through the old flash drive data I can see that most of the files within the /config directory are corrupted.  One of the text files that I know was previously readable is now displayed as "Ël$oYÿÈÓx{e}-™™JÓPJGÇ>Îä2°S®Xj)ëq§±õ«—ö„”Vúü¥¨]×0‡ó¦l‹cOk".

 

I do NOT have a current copy of the super.dat after this last drive configuration change.  I do NOT have a copy of the drive list from the Main tab of the web portal. 

 

I DO know what drive is the parity (only one parity in the array).  My question is as long as I put that drive into the parity slot, does the order of the rest matter?

 

Thanks in advance.

[trurl]

2 minutes ago, werdisturbed said:

I DO know what drive is the parity (only one parity in the array).  My question is as long as I put that drive into the parity slot, does the order of the rest matter?

If you assign parity correctly you should be good. If for some reason it offers to FORMAT anything, DON'T. Come back for further advice.

 

[werdisturbed]

Everything came up as expected since I had the correct parity drive.  Thanks so much for confirming!

 

To determine the parity drive, I slaved my largest capacity drives to a linux workstation and noted which one did not automatically mount.  Since I was able to read from the others, I could assume that one should be the parity drive.

[itimpi]

2 hours ago, werdisturbed said:

Everything came up as expected since I had the correct parity drive.  Thanks so much for confirming!

 

To determine the parity drive, I slaved my largest capacity drives to a linux workstation and noted which one did not automatically mount.  Since I was able to read from the others, I could assume that one should be the parity drive.

You can effectively do the same thing directly in Unraid with less effort by initially assigning all drives as data drives and starting the array.    The parity drive can then be identified by the fact it is the only unmountable drive.     You now use Tools >> New Config (with the option to retain current assignments to minimise chance of an error) and return to the Main tab to Unassign the now known parity drive from the data drive slot and assign it to the parity slot.   You can move around the other data drives at this point if you want.   Start the array to get back to normal operation.

[Manchineel]

I wanted to add for future reference: do NOT, and I repeat, DO NOT, ever mount drives belonging to the array automatically/in read-write mode outside Unraid (or from the Unassigned Devices plugin) if given the option. It will cause your parity to silently become invalid. If by accident that should happen, however, do not add back your parity, do not resilver disks, simply wipe parity and rebuild it from scratch (or using the "fix errors" mode on parity rebuild — errors are normal then: the parity has not been informed of the changes made by other OSs or a raw mount), and make sure turbo/reconstruct write is disabled while you do this. It will silently corrupt your data otherwise.