systemd NSSwitch Confusion
The Setup
This was definitely a fun issue to run into over this week. So it started with an update to my openSUSE desktop and was greeted with a frozen plymouth screen forever. I tried reverting, and got my box to boot again so I knew it was an issue with this update. I don’t update very often so it didn’t do me much good to read the snapshot release notes because a lot had changed from the last time I updated and the latest.
So I re-applied the update and modified systemd-boot ( read about my migration to systemd-boot here) to show verbose output and disable plymouth so I can read the boot logs to see what is happening.
This is the last lines I got on my verbose boot logs:
Reached target Network.
Starting NTP client/server...
Starting CUPS Scheduler...
Starting OpenSSH Daemon...
Starting Permit User Sessions...
Starting WPA Supplicant daemon...
Finished Permit User Sessions.
Starting X Display Manager...
Starting Hold until boot process finishes up...
Started WPA Supplicant daemon.
wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by xx:xx:xx:xx:xx:xx
iwlwifi 0000:05:00.0: Unhandled alg: 0x707
These logs were helpful, but kind of led me down a rabbit hole for a few hours. First thing I though was that my wifi drivers/chip was bad, since it was the last logs in the boot output. So with modprobe.blacklist=wlwifi,iwlmvm,iwldvm I still got the same thing, only this time the Starting X Display Manager was the last log now. So I tried the same thing with nomodeset to try to remove any gpu driver issues, but alas the same thing happened. The graphical display could not start.
The next thing I tried was to not enter graphical, but to enter multi-user instead of the graphical target. So slap a systemd.unit=multi-user.target onto the expanding systemd-boot parameters. However, this did work and dropped me into a TUI logon screen. After this I could logon and view logs to start to get to the bottom of this. The first thing I tried to do was to start graphical.target manually and see the logs that come of it, so systemctl isolate graphical.target resulted in… Nothing. None of my CTRL+ALT+F1 through CTRL+ALT+F12 resulted in a graphical display. So the next thing I did was make sure everything was good, systemctl status display-manager.service (for openSUSE) was all good. GDM was green and no issues in the logs. Next I checked to make sure I was in graphical systemctl status graphical.target showed green… Strange again that “everything is all good”.
Finally a strange log entry for PAM not authenticating a user that didn’t exist (there was no uid in /etc/passwd for this user). This was a similar log to the one that I saw:
Starting User Manager for UID 60578...
(systemd)[5466]: pam_sss(systemd-user:account): Access denied for user gdm-greeter: 10 (User not known to the underlying authentication module)
PAM failed: User not known to the underlying authentication module
user@60578.service: Failed to set up PAM session: Operation not permitted
user@60578.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
user@60578.service: Main process exited, code=exited, status=224/PAM
user@60578.service: Failed with result 'exit-code'.
Failed to start User Manager for UID 60578.
Started Session c36 of User gdm-greeter.
This error finally got me on the right track and I found this openSUSE forum post: https://forums.opensuse.org/t/no-graphical-login-after-gnome-49-update/188389/3 which was created pretty close to when I was was experiencing issues. This post pointed me to the official bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1250513 and my issue was finally revealed: systemd dynamic users.
The Resolution
So, I finally know what the issue was. OpenSUSE decided to switch to using Dynamic Users for gdm and if your /etc/nsswitch.conf file is not compatible it broke the graphical logon for GNOME. The fix was really simple. Start up your box with systemd.unit=multi-user.target in your systemd-boot option and login. Then, if you don’t have any custom nsswitch configurations, run cp /usr/etc/nsswitch.conf /etc/nsswitch.conf to overwrite your broken config with a working default one. Reboot and your issue should be resolved.
The actual thing that was missing in the original nsswitch.conf is the systemd option.
Original nsswitch.conf file:
passwd: compat
group: compat
shadow: compat
Fixed nsswitch.conf file:
passwd: compat systemd
group: compat [SUCCESS=merge] systemd
shadow: compat systemd
The Reason
I’m glad you’ve chosen to stick around to learn a little bit about dynamic users, because they are not talked about often. At least I haven’t heard of them.. The first thing I’ve found is this blog post by Pid Eins on 0pointer.net. Mind you this blog post was created on October 2017, so it took 7 years for GNOME to start to use this systemd feature. The second great article I found is this blog post by the GNOME team which explains the dependencies that they started using with systemd in June of 2025.
Read the GNOME blog post first, because they explain how there’s now a strong dependency of Let’s start with the easier of the changes. GDM is gaining a dependency on systemd’s userdb infrastructure. GNOME and systemd do not support running more than one graphical session under the same user account, but GDM supports multi-seat configurations and Remote Login with RDP. This means that GDM may try to display multiple login screens at once, and thus multiple graphical sessions at once. At the moment, GDM relies on legacy behaviors and straight-up hacks to get this working, but this solution is incompatible with the modern dbus-broker and so we’re looking to clean this up. To that end, GDM now leverages systemd-userdb to dynamically allocate user accounts, and then runs each login screen as a unique user.systemd-userdb for various (good) reasons. But systemd-userdb is what is required for dynamic users to function properly.
This particular change makes the GDM service run with DynmicUser=true in it’s systemd unit file. Because the nsswitch.conf did not honor systemd-userdb users this is what broke my box as discussed above. systemd-userdb does not create these dynamic users in the /etc/passwd or /etc/shadow files, but in systemd itself. The userdb also is cool because it can store not only your usual UNIX user attributes in a JSON file, it can also store a bunch of attributes that can be associated with you user account and used with systemd-homed.
This change makes the GDM service (user) account run under a dynamic uid instead of a static uid like in the past. This makes this service more secure as it no longer has a known uid and “sticky” user permissions resulting in files permanently being tied to the uid they specified in the past. Essentially this gives the new dynamic user account read-only to most system files, and ensures it has ephemeral files that are removed after the service is stopped or the machine is restarted. But can still read from the existing /etc/gdm/ configuration files.
