Peer ID did not match requested ID

[grimlock]

Just wanted to confirm, before I give up on this node…

As I was moving files and re-arranging things, I believe I may have messed up the identity of this node; even though I was working on another one which is running fine…

Is there a way to fix this error?
If I simply replace the identity files with a new identity… would the new one just take over, or do I need to really start from scratch here?

2020-12-29T05:51:37.815Z ERROR contact:service ping satellite failed {“Satellite ID”: “SATELLITE_ID", “attempts”: 11, “error”: "ping satellite error: failed to dial storage node (ID: NODE_ID) at address HOST_PORT: rpc: tls peer certificate verification error: tlsopts error: peer ID did not match requested ID", “errorVerbose”: "ping satellite error: failed to dial storage node (ID: NODE_ID****) at address HOST_PORT: rpc: tls peer certificate verification error: tlsopts error: peer ID did not match requested ID\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatelliteOnce:141\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatellite:95\n\tstorj.io/storj/storagenode/contact.(*Chore).updateCycles.func1:87\n\tstorj.io/common/sync2.(*Cycle).Run:152\n\tstorj.io/common/sync2.(*Cycle).Start.func1:71\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}

[BrightSilence]

A node can only run with the identity it was created with. A new identity would by definition be a new node and you will have to start over clean. If you don’t clean up the data yourself, garbage collection will do it later. But I don’t recommend waiting for that as it would leave around old database files that are no longer correct as well. It’s better to just start clean. That is, unless you are able to recover the original identity.

[grimlock]

Thanks for the reply @BrightSilence, I’m just gonna finish searching for the file in my drives…
and here I go again this time with a backup, lol

[BrightSilence]

It’s best to put the identity in the data location. That way you know you won’t mix it up between nodes and it comes with the added benefit that your node will not start/will stop should the data location not be available. You also don’t really need a backup if you do it that way (though it can’t hurt), since if the data location is lost, the identity is useless anyway.

Anyway, I hope you have a bit more luck with your next node!

[grimlock]

That’s exactly what I was doing… keeping the identify files in the same folder as the data (identity and storage/config). I guess I should just need to pay more attention.
Not a great money loss there, but 6 months hurts a little.

Thanks again

[Vadim]

i do not think garbige collector clear it, it will stay thare forever. It not belong to new node.

[Pac]

@BrightSilence

You also don’t really need a backup if you do it that way (though it can’t hurt)

I still think a backup can’t hurt too, because if you are unlucky your disk could end up corrupted where the identity lies, but still have enough valid stored data for a transfer to a new disk to be worth it in order to save the node. In which case, you would be more than happy to have a backup of your identity somewhere, otherwise the entire node would be lost.

[grimlock]

Interesting point, @Vadim

for the science, I’m gonna setup the new node using the same storage folder and watch to see what the garbage collector does on the first few days…

[BrightSilence]

Since the garbage collector matches against a bloom filter and removes any piece that doesn’t match, it should clean up the old data. It’ll take a while though since every run will only clean up about 90%. It’ll never be completely gone, but close enough after a few runs.

@grimlock of course if I’m wrong… you won’t have a good way to clean up old data anymore. Try at your own risk

[grimlock]

I can always generate a list of the existing files before I start the new node…
if I’m brave enough I can always delete them myself