Multiple registration keys found - Pro1.key vs Pro2.key

[landS]

Good day crew,

 

My USB drive, originally on v5 (or maybe even 4), needed a new key when bumping up to v6 (if my faulty memory serves)...

So of course 'Fix Common Problems' is now complaining...Checking on /boot/config...I have Pro1.key and Pro2.key

 

Given that this is a Lexar JD_FireFly - 2 GB I am guessing this USB drive will need to be replaced sooner as opposed to later as it is growing a little long in the tooth.

 

What is my course of action?

 

Thanks

[Squid]

Your course of action is to figure out which key is actually valid...  Rename Pro1.key to be Pro1.key.bak, then reboot.  If the array starts up fine then you're good to go.  If not, rename the file back and rename the other file to Pro2.key.bak and you'll be good to go and FCP will no longer bitch and complain to you about that.

 

Here's the reasoning behind the test (and why FCP complains about it)

 

unRaid when it starts up looks at the key files and matches it up to the GUID of the flash drive.  If there's more than one key then it looks at each .key file until it finds one that matches.

 

That's nice and convenient, as if you have multiple unRaid servers, you can throw all of the .key files you are using onto each flash drive and never have to worry about which actually belongs to which server.

 

The problem is IF you have multiple servers and multiple key files on the flash drive. (which are valid for the other server(s).

 

If your flash drive happens to die, then the course of action is to copy over the contents from the dead/dying flash drive to the new flash drive, boot up unRaid, and transfer the registration to the new flash.

 

But, you've got 2 perfectly valid (ie: not blacklisted) .key files -> which one does unRaid pick to transfer to the new flash (and blacklist the old one in the process).  It doesn't know which flash GUID actually died, so currently it throws all the files up in the air and picks one at random.  Which means that your other server(s) flash drive might in the process get incorrectly blacklisted.  BTW, I've been informed that this process when the system finds multiple key files is going to change come 6.4

 

 

 

[landS]

Thanks for the sanity check on the next move, the educational FYI, and the upcoming bullet dodge squid

As soon as my CrashPlan Docker is done syncing on Tower1 (was on Tower2) I will go through this joyous exercise!  Only 1.5 weeks to wait now 

 

You are my favorite cephalopod around mate    Enjoy a beer bath

Edited April 17, 2017 by landS

[Squid]

14 minutes ago, landS said:

 Enjoy a beer bath

Thanks for that...  

[landS]

For anyone who has the same issue... SSH in as root and MC ... even if you rename the WRONG key... you can just SSH back in after rebooting and swap the .bak names around on all extra keys until you hit the right one

[Squid]

5 hours ago, landS said:

For anyone who has the same issue... SSH in as root and MC ... even if you rename the WRONG key... you can just SSH back in after rebooting and swap the .bak names around on all extra keys until you hit the right one

Since the flash drive is still exported over the network with array started, (unless you changed its export settings), you can do all this over the network also...

[landS]

On 4/21/2017 at 8:21 PM, Squid said:

Since the flash drive is still exported over the network with array started, (unless you changed its export settings), you can do all this over the network also...

I tried this first... Despite using a share setting that should have given full read/write... I could not rename or even delete the key files.... Normally my flash is setup to not be accessible.