On my newly-installed laptop, I have two accounts configured in configuration.nix, including their personal packages, in addition to the system packages.
My account has some Gnome extensions, which I enabled, and all is fine.
My wife’s account is set to auto-login; she also enabled her Gnome extensions, but after each reboot, all her Gnome extensions are disabled again.
Is it on purpose?
How do I ensure that the extensions remain enabled?
Extensions are automatically disabled when GNOME Shell detects some issue. Try looking at the systemd journal if there are any suspicious messages (e.g. traces or crashes) around the time of the log-in.
As a bandaid for occasional GNOME Shell crashes I’ve been running a script at startup that checks whether extensions have been disabled and prompts to re-enable them.
That was enlightening… in a way. I ran journalctl --user -b -0, and the result is frightening The journal file is here.
There are so many errors, I don’t know where to look first…
And yet Gnome is running, and extensions can be enabled
If I’m not wrong, I can see:
Gnome starting with both Wayland (1 display) and X11 (2 displays)!
Gnome/X11 failing 3×, and cancelling… yet proceeding successfully
A big and repeating number of warnings about unknown keysyms
XOrg configuration happening 2×,
and a JS stacktrace for “RecentItems” in-between
A message about some contradiction in the launch process: “Requested transaction contradicts existing jobs: Transaction for gnome-session-x11@gnome.target/start is destructive (gnome-session-pre.target has ‘stop’ job queued, but ‘start’ is included in transaction).”
Service xdg-desktop-portal-gnome.service dying a slow death
Misc audio errors (alsa, pulseaudio (still there? I thought it was pipewire now…))
A multi-thread stacktrace for .gnome-shell-wr
Gnome/Wayland stopping along the way…
DBus failing and restarting soon after that
An error about org.usbguard1 being not found, whatever that is
That is another warning. You can get rid of it using services.usbguard.enable = true; NixOS option. It will install a program allowing you to control which USB devices can do what.
This is suspicious but it happens after the GNOME Shell errors so probably not relevant (or another effect of the crash).
The errors l am most concerned are:
sept. 02 18:15:52 junior .gnome-shell-wr[1349]: JS ERROR: Could not get a proxy for the current session: Gio.IOErrorEnum: GDBus.Error:org.freedesktop.login1.NoSuchSession: No session '1' known
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:114:23
sept. 02 18:15:52 junior .gnome-shell-wr[1349]: Could not issue 'GetUnit' systemd call
sept. 02 18:15:52 junior .gnome-shell-wr[1349]: meta_later_remove: assertion 'display' failed
sept. 02 18:15:52 junior .gnome-shell-wr[1349]: meta_later_remove: assertion 'display' failed
sept. 02 18:15:52 junior .gnome-shell-wr[1349]: clutter_actor_iter_next: assertion 'ri->age == ri->root->priv->age' failed
sept. 02 18:15:52 junior .gnome-shell-wr[1349]: Could not release device '/dev/dri/card0' (226,0): GDBus.Error:org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/_31'.
sept. 02 18:15:52 junior .gnome-shell-wr[1349]: Could not release device '/dev/dri/card1' (226,1): GDBus.Error:org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/_31'.
sept. 02 18:15:52 junior gnome-shell[1349]: **
sept. 02 18:15:52 junior gnome-shell[1349]: Clutter:ERROR:../clutter/clutter/clutter-main.c:490:_clutter_context_get_default: assertion failed: (ClutterCntx)
sept. 02 18:15:52 junior gnome-shell[1349]: Bail out! Clutter:ERROR:../clutter/clutter/clutter-main.c:490:_clutter_context_get_default: assertion failed: (ClutterCntx)
sept. 02 18:15:52 junior gnome-shell[1349]: == Stack trace for context 0x22b5630 ==
most likely causing the GNOME Shell crash, which triggers
sept. 02 18:15:53 junior systemd[1293]: Started Disable GNOME Shell extensions after failure.
shortly afterwards.
If you do not manage it to pin it on a specific extension, you might want to get the debug symbols for GNOME Shell as described in this comment and then get backtrace from coredumpctl.
Actually, there is another transaction failure before it so you might as well follow its instructions:
sept. 02 18:15:50 junior xsession[1709]: Failed to start graphical-session.target: Transaction for graphical-session.target/start is destructive (gnome-session-shutdown.target has 'start' job queued, but 'stop' is included in transaction).
sept. 02 18:15:50 junior xsession[1709]: See user logs and 'systemctl --user status graphical-session.target' for details.
I hadn’t; somewhere I picked up the impression that GNOME typically isn’t welcoming of feature suggestions, especially those catering to power users. I expect they’d decide that the correct response is to just fix whatever individual bugs are causing crashes.
They’re friendlier than you think, even if they don’t focus on UX for “power users”. Even then I think bugs like this are especially harmful for non-“power users”, so I doubt something like this would be rejected.
Perfectly legitimate not to want to spend time on it anyway, I certainly have my fair share of little NixOS contributions that I never end up actually pushing. But assuming hostility from FOSS projects leads to stagnation that is just not good for anyone - if you have time and energy to do so, just make a polite suggestion and see if it sticks. Maintainers only really get hostile if they’re being brigaded by reddit for a feature they’ve given a good reason for not accepting.
Anyway, sorry, besides the point of this thread. Nice to know there’s a workaround, and some low hanging fruit for UX improvements for GNOME.
I have the exact same problem. I thought it was a bug in my configuration, but declaratively created a new user and found out gnome extensions also disable themselves in the fresh user account too.
Plus, just like @nyx mentioned, when I run journalctl --user -b -0, I get a copious amount of gnome errors, although I don’t know how to interpret them.
Either way, this is a bug, and it’s present ever since I did a fresh install of NixOS last week. After googling this, this does seem to be a longstanding Gnome bug, since people on other distros have the exact same problem dating to a few years back, as far back as to Gnome 3.18, for example.