In fact, my computer freezes while trying to rekey these folders ...
Here is my log id: a289943501b480f6413b7c1c
It seems like it was working really hard to verify some old data in the folder that was written by a device that you have revoked. Now the folder looks to be in an ok state and fully keyed (I think); let me know if you have any more problems.
Unfortunately the logs that were sent are flooded with useless messages about the revoked device, and it's hard to diagnose exactly what went wrong. Those logs are just a snippet of the overall logs though. If you'd like to share the complete logs, I might be able to find out more. If so, do something like this and I'll see if I can get more info from them:
tar -czf /keybase/private/strib@github,ryanpcmcquen@github/logs.tgz ~/.cache/keybase/keybase.kbfs*
It still says the folder isn't rekeyed ... I'll send the complete logs over.
Hmm, I was looking at your personal private folder, but it does appears there's a shared private folder that has an issue now. I'll take a look at the new logs when I get them, thanks.
@strib, I sent it over!
Looks like the only device of yours that can access that shared folder is your paper key tide brass. Try keybase rekey paper from the command line, and enter that paper key. I _think_ that should do it.
I have done that at _least_ 20 times ... to no avail.
Ah ok, sorry I didn't know that. Can you try it one more time? When it doesn't work, try this magic command too:
echo 1 > /keybase/private/rpcm,USER/.kbfs_rekey
(substitute the other user's name for USER, I didn't want to reveal it here).
After that, run keybase log send so I can see fresh logs from this attempt. Thanks!
That command never completes, is it supposed to? I managed to take a picture of my screen just as my computer started overheating from that command. Here is the log id:
04d1a4b44a7b3308f529aa1c
I was able to get all this from a TTY since X11 started melting down and my terminal started spitting out this error:
Core temperature above threshold, cpu clock throttled
This is a reasonably potent machine with an 8-core i7 and 16gb of ram.
Yes, it's supposed to complete. Sigh. Seems like it's in some kind of pathological state due to a revoked device that's wrote to it in the past. Which should still work fine, and it's hard to figure out from the logs why you're getting into such an intense loop trying to do it. Did you end up ctrl-c'ing it, did it eventually finish, or did you have to reboot? I would expect it to complete eventually if given enough CPU. (Obviously this is a bad bug that we should fix, but still even in its current bad form I'd expect it to finish.)
I managed to get sudo reboot typed and executed when I started getting the threshold error.
Hmm ok I see. Other than just trying to let it run to completion once and giving your CPU over to it, I see the following possible options (until we can find the time to reproduce this and debug it ourselves):
Pick your poison.
Just reset the folder completely, I am almost positive it was empty anyway.
No problem, I can do that. But we need a signed statement from you saying its ok. Please run this command on a currently-valid keybase device, and substitute the USER name and current date and time where indicated:
keybase sign -m "<DATE_AND_TIME>: Please reset folder /keybase/private/rpcm,USER because it cannot be rekeyed due to a performance bug"
and send the results to me in a private chat (so you don't reveal the other username publicly).
Sent!
I reset the folder on our end. You should be able to access the folder now (and it will be empty). You might still see a rekey badge until the next time we deploy our servers (probably some time today). Let me know how things look.
Things look good now! Should we keep the issue open until we fix the performance bug?
Most helpful comment
No problem, I can do that. But we need a signed statement from you saying its ok. Please run this command on a currently-valid keybase device, and substitute the USER name and current date and time where indicated:
and send the results to me in a private chat (so you don't reveal the other username publicly).