First boot issue: collection/login not published on the bus, prevents applications from running
Background
Hello, there's an issue with the gnome-keyring on first boot. There's a bug opened in the Debian bugtracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035061. I can also confirm the issue in Kali Linux (a Debian derivative). I'd be curious to know if other distros are also affected.
The bug is quite severe as it prevents applications from running. chromium
is affected, apparently geary
as well, maybe others. OTOH, a reboot is enough to fix it, and maybe that's why the bug wasn't reported here yet (or at least, I couldn't find it).
Reproducing
You can reproduce it by grabbing a Debian installer, install it in a VM (choose GNOME desktop of course). Then boot it, then apt update && apt install -y chromium
, and try to start chromium. Issue: it doesn't start. Then reboot, try to start chromium: this time it starts.
The issue can be reproduced with Debian stable "bookworm" or Debian unstable, both come with gnome-keyring 42.1
. However, the issue is NOT present with Debian oldstable "bullseye", that comes with gnome-keyring 3.36.0
. Interestingly, all of these Debian systems come with the same version of chromium 120.0.6099.71
, so it seems that we can rule out a change in chromium.
Some links for Debian images:
- torrent link for Debian 12 "bookworm": https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-12.4.0-amd64-netinst.iso.torrent
- torrent link for Debian 11 "bullseye": https://cdimage.debian.org/cdimage/archive/11.8.0/amd64/bt-cd/debian-11.8.0-amd64-netinst.iso.torrent
Diving into the issue
Now I'm looking at the Debian stable system, with gnome-keyring 42.1
.
Here's how it looks like on the bus for the first boot:
$ gdbus introspect --session -d org.freedesktop.secrets \
-o /org/freedesktop/secrets/collection --recurse | grep node
node /org/freedesktop/secrets/collection {
node /org/freedesktop/secrets/collection/session {
And now on the second boot:
$ gdbus introspect --session -d org.freedesktop.secrets \
-o /org/freedesktop/secrets/collection --recurse | grep node
node /org/freedesktop/secrets/collection {
node /org/freedesktop/secrets/collection/session {
node /org/freedesktop/secrets/collection/login {
So collection/login
is not published on the bus during first boot. This is consistent with error case of Geary, as reported in the Debian bug above:
Oh, this also breaks Geary as well; it fails to start with an error about no such secret collection at path /org/freedesktop/secrets/collection/login.
I enabled G_MESSAGES_DEBUG=all
for the gnome-keyring-daemon, in order to understand better what's the difference between first boot and second boot.
First boot:
Nov 29 03:35:52 kali gnome-keyring-d[758]: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
Nov 29 03:35:52 kali gnome-keyring-d[758]: couldn't set environment variable in session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
Nov 29 03:35:52 kali gnome-keyring-d[758]: keyring alias directory: /home/kali/.local/share/keyrings
Nov 29 03:35:52 kali gnome-keyring-d[758]: closing prompt
Nov 29 03:35:52 kali gnome-keyring-d[758]: matching: (1) [ { CKA_CLASS = 0xC74E4DB3 } ]
Nov 29 03:35:52 kali gnome-keyring-d[758]: matching: (2) [ { CKA_CLASS = CKO_SECRET_KEY }, { CKA_0xC74E4E1B = (7) NOT-PRINTED } ]
Nov 29 03:35:52 kali gnome-keyring-d[758]: initialization complete
Nov 29 03:35:52 kali gnome-keyring-d[758]: matching: (3) [ { CKA_CLASS = 0xC74E4DB3 }, { CKA_TOKEN = (1) "\x01" }, { CKA_ID = (5) "login" } ]
Nov 29 03:35:52 kali gnome-keyring-d[758]: gkm_store_get_attribute: CKR_ATTRIBUTE_TYPE_INVALID: CKA_ID not in schema
Nov 29 03:35:52 kali gnome-keyring-d[758]: gkm_object_real_get_attribute: CKR_ATTRIBUTE_TYPE_INVALID: no CKA_ID attribute
Nov 29 03:35:52 kali gnome-keyring-d[758]: created object: (4) [ { CKA_CLASS = 0xC74E4DA9 }, { CKA_VALUE = (4) NOT-PRINTED }, { CKA_0xC74E4E0E = (1) NOT-PRINTED }, { CKA_TOKEN = (1) "\x01" } ]
Nov 29 03:35:52 kali gnome-keyring-d[758]: created object: (5) [ { CKA_CLASS = 0xC74E4DB3 }, { CKA_ID = (5) "login" }, { CKA_0xC74E4E11 = (8) NOT-PRINTED }, { CKA_TOKEN = (1) "\x01" }, { CKA_LABEL = (5) "Login" } ]
Nov 29 03:35:52 kali gnome-keyring-d[758]: refresh_with_login: refreshing: /home/kali/.local/share/keyrings/user.keystore
Nov 29 03:35:52 kali gnome-keyring-d[758]: refresh_with_login: closing: /home/kali/.local/share/keyrings/user.keystore
Nov 29 03:35:52 kali gnome-keyring-d[758]: begin_lock_file: modifying: /home/kali/.local/share/keyrings/user.keystore
Nov 29 03:35:52 kali gnome-keyring-d[758]: complete_lock_file: closing: /home/kali/.local/share/keyrings/user.keystore
Second boot:
Nov 29 03:40:18 kali gnome-keyring-d[751]: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
Nov 29 03:40:18 kali gnome-keyring-d[751]: couldn't set environment variable in session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
Nov 29 03:40:18 kali gnome-keyring-d[751]: keyring alias directory: /home/kali/.local/share/keyrings
Nov 29 03:40:18 kali gnome-keyring-d[751]: closing prompt
Nov 29 03:40:18 kali gnome-keyring-d[751]: matching: (1) [ { CKA_CLASS = 0xC74E4DB3 } ]
Nov 29 03:40:18 kali gnome-keyring-d[751]: matching: (2) [ { CKA_CLASS = CKO_SECRET_KEY }, { CKA_0xC74E4E1B = (7) NOT-PRINTED } ]
Nov 29 03:40:18 kali gnome-keyring-d[751]: matching: (2) [ { CKA_CLASS = CKO_SECRET_KEY }, { CKA_0xC74E4E1B = (5) NOT-PRINTED } ]
Nov 29 03:40:18 kali gnome-keyring-d[751]: initialization complete
Nov 29 03:40:18 kali gnome-keyring-d[751]: matching: (3) [ { CKA_CLASS = 0xC74E4DB3 }, { CKA_TOKEN = (1) "\x01" }, { CKA_ID = (5) "login" } ]
Nov 29 03:40:18 kali gnome-keyring-d[751]: gkm_store_get_attribute: CKR_ATTRIBUTE_TYPE_INVALID: CKA_ID not in schema
Nov 29 03:40:18 kali gnome-keyring-d[751]: gkm_object_real_get_attribute: CKR_ATTRIBUTE_TYPE_INVALID: no CKA_ID attribute
Nov 29 03:40:18 kali gnome-keyring-d[751]: created object: (5) [ { CKA_CLASS = 0xC74E4DA9 }, { CKA_VALUE = (4) NOT-PRINTED }, { CKA_0xC74E4E0E = (1) NOT-PRINTED }, { CKA_TOKEN = (1) "\x01" }, { CKA_0xC74E4E0F = (8) NOT-PRINTED } ]
Nov 29 03:40:18 kali gnome-keyring-d[751]: refresh_with_login: refreshing: /home/kali/.local/share/keyrings/user.keystore
Nov 29 03:40:18 kali gnome-keyring-d[751]: refresh_with_login: closing: /home/kali/.local/share/keyrings/user.keystore
We can see that there's one more created object on first boot, with a label of "Login".
So here's my understanding now. On first boot, the gnome-keyring-daemon creates the "login keyring", however the change is not published on the bus. Some applications fail to start because of that. On second boot, since the login keyring already exists, it's published on the bus and everything works.
After looking at the code a few hours, it doesn't look like there's a one-line fix. My impression is that the scenario of "updating the collections on the bus" is not supported: collections are published on the bus early during program startup. The "login keyring" is created if it doesn't exists, but it happens only after the collections were published on the bus. And I don't see any places in the code where collections are updated after creation. It seems that it's rather static, collections are created at init and that's it.
One additional detail: you'd think that a restart of gnome-keyring-daemon is enough to fix it, but not exactly. If I restart it (via systemd --user
), and then I start chromium, GNOME prompts me for my password, saying "The login keyring did not get unlocked when you logged into your computer". However I can just click cancel, and then chromium proceeds and starts successfully...
Ending words
Thanks for reading! If someone could confirm that the issue also exists with other distros, I think that would be a good starting point. If you need more logs, I can provide. Thanks again!