I just updated to 26.05 and now after authenticating in GDM the login window fades away and then reappears at the user selection screen, indicating GNOME crashed while trying to start. I’ve seen this before when I had a broken GNOME extension so I disabled them but it’s persisted.
The user logs show “Failed to start unit gnome-session@gnome.target: GDBus.Error:org.freedesktop.systemd1.OnlyByDependency: Operation refused, unit gnome-session@gnome.target may be requested by dependency only (it is configured to refuse manual start/stop)”, followed by “Process 21371 (.gnome-session-) of user 1000 dumped core”.
The system logs don’t have much more, there’s “Process 21371 (.gnome-session-) of user 1000 terminated abnormally with signal 6/ABRT, processing…”.
I’ve tried disabling experimental GNOME options, specifying defaultSession, disabling services.xserver, disabling the GNOME keyring, trying to explicitly use Wayland in GDM. Nothing so far has made any difference.
Any ideas for further troubleshooting? I have no idea what could be causing this issue.
1 Like
I don’t know if this might work for you, but I had my niri setup made unusable with a similar issue because I was using GDM. I changed my display manager to ly and it started working again. Might be worth a try.
Have you tried adding a new user and use GNOME as them?
Yeah I just added a test user and it can log in totally fine. So something with the way my GNOME is set up might be wonky?
EDIT: For what it’s worth I used useradd and not Nix to add the user, so that probably still points to an issue with the Nix configuration.
I took a look through this and also tried the pam_env patch but it didn’t help anything unfortunately :(. I can definitely post some of this info over there though, if it’s indeed related (the symptoms seem slightly different).
I also included the logs of my login attempts with gdm.debug = true in the linked GitHub PR thread, maybe someone will spot something I missed in there.
Sorry to hear that you’re having trouble! It’s really unfortunate that we didn’t get gdm in better shape in time for the release 
Did I get that right that you’re seeing Gdm: session was killed with status 6 on your pre-upgrade user, but a user added with useradd doesn’t have the same issue? Thanks for your logs in the issue btw.
Edit: also I haven’t been able to test the fingerprint pam config at all, since I don’t have access to hardware that supports it… my Asahi macbook has TouchID but that part hasn’t been reverse engineered yet.
Yes, that’s likely correct. I didn’t check the logs with the new useradd user but all I did was useradd, passwd, then logged in as the new user and was immediately brought to the desktop. I could potentially deactivate fprintd to rule that out if you think it’s worth trying.
I am also on the unofficial NixOS Discord if you want a faster turnaround, but happy to keep communicating here, thanks for the help.
Being able to log in with another user could be because of GNOME extensions, at least that’s the first mention I found looking around for possible exit codes: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/data/org.gnome.Shell@.service.in#L21
And a new user wouldn’t have any extensions configured. I’m not sure if NixOS supports the OnFailure=org.gnome.Shell-disable-extensions.service service, so if you’re running any big gnome extensions, manually running gsettings set org.gnome.shell disable-user-extensions true in a tty for your main user could help?
No change unfortunately. I had already disabled all of my extensions but went ahead and even added that into my Nix config (confirmed after reboot that the value is true) and the login still fails in the same way. I’ve had a similar issue with extensions before but it typically automatically disabled the extension after a few failed sessions.
I also tried disabling fprintd (services.fprintd.enable and services.fprintd.tod.enable are false), but the error and symptoms do not change.
Since the log file doesn’t include formatting I should also mention that the main lines that stand out red are the “GDBus.Error:org.freedesktop.systemd1.OnlyByDependency” and “dumped core” lines. I also occasionally see “Ignoring duplicate name” red error spam from dbus-broker-launch.
No change unfortunately. […] I’ve had a similar issue with extensions before but it typically automatically disabled the extension after a few failed sessions.
Shame that it’s not the obvious solution, but good to know that the service should work.
The Ignoring duplicate name dbus-broker warnings should be harmless, I also see them.
I’ve been trying to make sense of the coredump, but as far as I can see, it doesn’t even seem to make it to the first debug logs, it gets an abort signal before logging/doing anything useful?
Also searching around for the error message you’re getting doesn’t really yield helpful results… I still don’t know what’s killing your gnome-session-init-worker
I also see
May 28 18:21:19 futomaki .gnome-session-[3397]: Starting GNOME session target: gnome-session@gnome.target
May 28 18:21:19 futomaki gsd-media-keys[2667]: Unable to get default source
May 28 18:21:19 futomaki gsd-media-keys[2667]: Unable to get default sink
in my logs, so these shouldn’t be fatal either.
could you add a -o with-unit to your journalctl command? maybe the user context in which its run is misconfigured for some reason.
Figured it out, posting here for anyone else who runs into a similar issue.
Once 7fdb156 hit nixos-26.05, I updated to it and was still running into this issue, even with extensions, fingerprint login, and the keyring disabled. After that I tried updating Stylix to the 26.05 branch which was slightly delayed from NixOS and Home Manager, which still didn’t fix it.
Then I tried an LLM which noticed that I had a lot of systemd user services in .config that referenced binaries for gnome-session 49.2. I backed them up and removed them, reactivated my system and they didn’t reappear (so I don’t think they were needed), rebooted and then I was finally able to log in. I also reset /org/gnome in dconf which could have helped.
So I guess one of those user services may have been the culprit, perhaps in combination with one of the other changes. In any case my system is working totally fine now on 26.05.
2 Likes