I updated my laptop yesterday, and today the keyring reset problem happened again, and when I opened seahorse, there was no keyring there, though there were many keyring files in ~/.local/share/keyrings/. Something is up and this is becoming very annoying.
I’ve since deleted the unnecessary keyring files, tried copying the old one (login.keyring) to the new one (Default_keyring.keyring), and it just gets ignored (it stops displaying). I’m not sure if there’s something “wrong” with my original keyring, but I haven’t been able to find a validation tool to see if there’s something “invalid” in it that’s the source of all of this.
~/.local/share/keyrings $ ls -ltra
total 36
-rw------- 1 bruno bruno 207 Mar 13 17:30 user.keystore
-rw------- 1 bruno bruno 12483 Aug 24 21:09 login.keyring
-rw-r--r-- 1 bruno bruno 15 Sep 5 06:29 default
-rw------- 1 bruno bruno 2894 Sep 5 06:32 Default_keyring.keyring
drwxr-xr-x 42 bruno bruno 4096 Sep 5 06:48 ..
drwx------ 2 bruno bruno 4096 Sep 5 06:48 .
default shows Default_keyring, but even if I change it to login, nothing changes, as on the next logout/login, no keyring is displayed.
The only two interesting things in sudo journalctl are:
systemd[1460]: Started GNOME Keyring daemon.
gdm-password][1440]: gkr-pam: couldn't unlock the login keyring.
So the daemon starts properly, and it fails to unlock but I think that’s acceptable as I’ve seen in Gnome-keyring 42.0 and autologin (I login with a Yubico) and ERRO [gkr-pam: couldn't unlock the login keyring.] however, I have an empty password set for my keyring, so I’d think it maybe shouldn’t throw that error at all (unless something changed in seahorse or gnome-keyring) recently.
Thanks @Mirdarthos ! Unfortunately, I’ve been through the first and some more. No cake. The final one seems promising, and I’ll be able to test further in a few hours.
There’s no “Show All” anywhere, and I’ve tried the other filters too:
The troubleshooting assumes the keyring shows, which doesn’t for me, and I’ve tried creating a new one. It works until I try to fill it with my login.keyring data. Then it’s ignored. (I believe this might be an indicator something’s wrong with it, but it’s decrypted and I see no problem inside the file – again, if there’s a way to validate it or see what’s wrong, I’m happy to check and fix it, otherwise I’ll just not reboot my laptop until Friday, when I can spend some time debugging, starting from an empty file and seeing the entry with the problem, assuming that’s the culprit here, which I’m not sure it is)
I also thought that initially, but looking at my ls -ltra above, it doesn’t seem to be the case.
[SOLUTION] In any case, I seem to have figured it out now! The culprit was, indeed, an invalid/malformed secret in the login.keyring file. Apparently MongoDB’s Compass had (or still has) a version which stored (or stores) the JSON secret with the prettified version (multiline) instead of a “minified”, single-line version, which broke the parsing/schema!
Let’s hope this doesn’t happen again. What a soap opera! Thanks for helping again @Mirdarthos !
P.S.: If anyone’s curious on how I debugged this, it was good old trial-and-error. I copied my login.keyring file to test.keyring, and commented out everything (started all lines with # except the block with the keyring name), since that worked, I just kept going one by one until it failed to load. Then it was obvious what was causing it.
