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
-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: Started GNOME Keyring daemon.
gdm-password]: gkr-pam: couldn't unlock the login keyring.
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.