GDM locks entire system after Update

Hi there, when I update my system, post reboot I enter my password, and upon enter, they screen blanks out, and I can only see my cursor. The entire system is locked, and I cannot even go to the console. However I can ssh to the system. If I roll back, all resumes working.

Any suggestions? I cannot update my systems currently.

Other things I noticed.

  • After the rebuild and if I do not login via GDM. And then login via a console, it echos out “Linux” twice.
  • journalctl -b -p3 shows:
    • gkr-pam: unable to locate daemon control file.
    • The conf file should be located in the following directory: /etc/pam.d/gkr-pam (quick search), but nothing there.
    • I could not find gkr-Pam.conf on my system.
    • on my other system running an older version of gnome also does not have it. So I think it’s unrelated. Seems to just be password stashing.
  • running from a other machine over ssh looking at journalctl I noted (not existing on both boot)
evo gnome-session[4593]: gnome-session-binary[4593]: WARNING: Desktop file /nix/store/mkhr8kmi8lfs96ild49wnn33qdvw9cy4-gdm-46.2/share/gdm/greeter/autostart/orca-autostart.desktop for application orca-autostart.desktop could not be parsed or references a missing TryExec binary
evo gnome-session-binary[4593]: WARNING: Desktop file /nix/store/mkhr8kmi8lfs96ild49wnn33qdvw9cy4-gdm-46.2/share/gdm/greeter/autostart/orca-autostart.desktop for application orca-autostart.desktop could not be parsed or references a missing TryExec binary

evo org.gnome.Shell.desktop[4739]: Window manager warning: Failed to parse saved session file: Failed to open file “/run/gdm/.config/mutter/sessions/103f7a265c880f25e7172298949465330300000047270000.ms”: No such file or directory

evo systemd-xdg-autostart-generator[7525]: Exec binary '/run/wrappers/bin/gnome-keyring-daemon' does not exist: No such file or directory


evo systemd-xdg-autostart-generator[7525]: /run/current-system/sw/etc/xdg/autostart/gnome-keyring-secrets.desktop: not generating unit, executable specified in Exec= does not exist.

Now looking at items in that list:

on working system:

❯ sudo bat /run/wrappers/bin/gnome-keyring-daemon

File: /run/wrappers/bin/gnome-keyring-daemon   <BINARY>**strong text**

not working system:

❯ sudo /run/wrappers/bin/gnome-keyring-daemon
gnome-keyring-daemon: failed dropping capabilities - -9, aborting

Other:

❯ bat -p /run/current-system/sw/etc/xdg/autostart/gnome-keyring-secrets.desktop | grep Exec
Exec=/run/wrappers/bin/gnome-keyring-daemon --start --components=secrets

on a working system, share/gdm/greeter/autostart/orca-autostart.desktop does not exist, but does on the one that is not working.

Just some additional observations.

Extensions!!! :rage: :anger: :exploding_head: :dizzy_face:

NOw to figure out which was the cause.

In my case it was the “just perfection” extension which I was using for hiding my bar, and some other visual preferences.

Seems like anything that deals with visuals are dangerous in extension land.

  • Issue opened here upstream.
  • Issue opened on package (just in case)

That file is nonsense. You probably got it from a bullshit AI-generated article. Notice the error says nothing about a config file.

The correct daemon control file path is /run/user/1000/keyring/control but not being found just means that the daemon is not starting properly as you can see later:

But that should have no effect on your system starting.

That is a different command. And I get the same result on my working system – the service is not supposed to be run as root.


We really need more complete logs, otherwise we cannot even guess. Since it locks up even console, that sounds like a kernel thing. Most commonly these issues are caused by GPU/driver bugs (e.g. the extension causes GNOME Shell do some GPU operation, which the driver does not like and crashes).

Thanks for the reply!

You must have missed my previous replies (maybe reading and replying via email?). I figured it out. It was the “Just Perfection” Gnome extension. I had opened issues upstream and linked them here as well.

Extensions generally should not be able to cause hangups like that. It is most likely a GPU driver bug that the extension just happens to trigger accidentally.

1 Like

I see. I was having issues with my GPU driver, but solved that after this. Maybe I will give it a go again now that my NVidia driver is actually activating again.

1 Like

Well unfortunately even with a working GPU/Driver, they issue persists.

Is there a specific log you suggest? Or just keep trolling journalctl for errors?

I mean, in some ways, it is “solved” (as in a work around), but… maybe makes sense to continue in case others run into this?

For reference. On the issue I created on the nixpkgs repo, someone else was able to reproduce the issue.