gdm broken after update

seth · 2025-09-23 20:07:19

@windy,
Dude, you missed the party

/usr/share/xsessions is populated with entries from Cinnamon

Ok, but you want the entries from gnome there - oc. symlinking the dir as in #67, https://bbs.archlinux.org/viewtopic.php … 0#p2263450 won't work, but you could https://man.archlinux.org/man/lndir.1 the contents for gnome.
nb. that this doesn't imply you'll be able to also start a gnome session on X11

@stronnag, see #73 - we don't yet know the crucial factor, adding the user there just gives pam something it should™ not want itfp.

dcc24 · 2025-09-23 20:16:07

seth wrote:

It might help to diff
md5sum /{etc,usr/lib}/pam.d/*
between the systems.

Good idea. My broken machine is back to 48 right now, so this won't be very helpful until I upgrade again, but here it goes in case it gives an idea:

The relevant file is /etc/pam.d/gdm-launch-environment. On the broken system (GDM 48):

auth       required                    pam_succeed_if.so    audit quiet_success user in gdm:gnome-initial-setup
auth       optional                    pam_permit.so
auth       required                    pam_env.so

account    required                    pam_succeed_if.so    audit quiet_success user in gdm:gnome-initial-setup
account    optional                    pam_permit.so

password   required                    pam_deny.so

session    optional                    pam_loginuid.so
session    optional                    pam_keyinit.so       force revoke
session    required                    pam_succeed_if.so    audit quiet_success user in gdm:gnome-initial-setup
session    optional                    pam_permit.so
-session   optional                    pam_systemd.so
-session   optional                    pam_elogind.so
session    required                    pam_env.so

... and on the working one (GDM 49):

#%PAM-1.0

auth       required                    pam_succeed_if.so    audit quiet_success user ingroup gdm:gnome-initial-setup
auth       optional                    pam_permit.so
auth       required                    pam_env.so

account    required                    pam_succeed_if.so    audit quiet_success user ingroup gdm:gnome-initial-setup
account    optional                    pam_permit.so

password   required                    pam_deny.so

session    optional                    pam_loginuid.so
session    optional                    pam_keyinit.so       force revoke
session    required                    pam_succeed_if.so    audit quiet_success user ingroup gdm:gnome-initial-setup
session    optional                    pam_permit.so
-session   optional                    pam_systemd.so
-session   optional                    pam_elogind.so
session    required                    pam_env.so

Basically the user check "in" was changed to a group check "ingroup". This was introduced during the 49 beta and is present in the latest package.

Last edited by dcc24 (2025-09-23 20:17:58)

windy · 2025-09-23 20:22:35

seth wrote:

@windy,
Dude, you missed the party

Yeah, sorry about the delay. I tried to catch up with the thread and answer as many hints as possible.

Ok, but you want the entries from gnome there - oc.

Uhm, I don't understand, why do I want that? My desktop environment is Cinnamon. That is also the reason that I use X11 because Wayland-support for Cinnamon is still experimental.

olivarch · 2025-09-23 20:50:34

Brillant, thanks!

mypetbirdrules wrote:

I have had the same Arch Linux installation since the mid-2010s, though it has moved between different
iterations of Thinkpad laptops over the years. Upon updating to GNOME 49, I ran into the same issue as other users in this thread. If you are like me and:
1. Use Wayland
2. Use GDM with GNOME
3. Suddenly ran into an issue where booting was met with a black screen and either a blinking or solid white underline at the top left
Then we might have had the same issue.
I had the following log messages:
journalctl -r
Sep 23 13:11:00 USERNAME systemd[1]: Failed to start User Manager for UID 60588.
Sep 23 13:11:00 USERNAME systemd[1]: user@60588.service: Failed with result 'exit-code'.
Sep 23 13:11:00 USERNAME systemd[1]: user@60588.service: Main process exited, code=exited, status=224/PAM
Sep 23 13:11:00 USERNAME (systemd)[1114]: user@60588.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Sep 23 13:11:00 USERNAME (systemd)[1114]: user@60588.service: Failed to set up PAM session: Operation not permitted
Sep 23 13:11:00 USERNAME (systemd)[1114]: user@60588.service: PAM failed: Authentication service cannot retrieve authentication info
If this applies to you, then what fixed it for me was appending the following to my /etc/shadow file:
gdm-greeter:!*:20224::::::
Note: I did not have to rollback the versions of any software package. This solves the GDM permission issue on Wayland with the latest package versions available. Thank you to everyone in the thread who helped troubleshoot this!

dcc24 · 2025-09-23 20:52:49

Someone on reddit found out that an update to /etc/nsswitch.conf back in March might be the culprit, which would explain why the problem doesn't happen in newer installs:

$ diff -y --suppress-common-lines  nsswitch.conf nsswitch.conf.pacnew
group: files systemd                                          | group: files [SUCCESS=merge] systemd
shadow: files                                                 | shadow: files systemd
                                                              > gshadow: files systemd
#hosts: files mymachines myhostname resolve [!UNAVAIL=return] | hosts: mymachines resolve [!UNAVAIL=return] files myhostname
hosts: files resolve dns                                      <

So, can someone test if changing shadow: files to shadow: files systemd works?

seth · 2025-09-23 21:09:03

@windy, because of https://bbs.archlinux.org/viewtopic.php … 8#p2263248 though

Sep 23 21:15:42 hostname gnome-session-i[1132]: Starting GNOME session target: gnome-session-x11@gnome-login.target
Sep 23 21:15:42 hostname gnome-session-i[1132]: Failed to start unit gnome-session-x11@gnome-login.target: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit gnome-session-x11@gnome-login.target not found.
Sep 23 21:15:42 hostname kernel: traps: gnome-session-i[1132] trap int3 ip:7f99bb0b5b8c sp:7ffd272ead90 error:0 in libglib-2.0.so.0.8600.0[64b8c,7f99bb06f000+a7000]

/usr/lib/systemd/user/gnome-session-x11@.target which was in v48 but isn't in v49 - no idea whether restoring the xsession data will actually fix /that/…
Do you btw. autologin into cinnamon?

windy · 2025-09-23 21:26:38

seth wrote:

/usr/lib/systemd/user/gnome-session-x11@.target which was in v48 but isn't in v49 - no idea whether restoring the xsession data will actually fix /that/…

It does not. I just copied all gnome files into the xsessions directory, but gdm still fails to start with the same message.

Do you btw. autologin into cinnamon?

No.

calculon102 · 2025-09-23 21:32:49

dcc24 wrote:

Someone on reddit found out that an update to /etc/nsswitch.conf back in March might be the culprit, which would explain why the problem doesn't happen in newer installs:
$ diff -y --suppress-common-lines  nsswitch.conf nsswitch.conf.pacnew
group: files systemd                                          | group: files [SUCCESS=merge] systemd
shadow: files                                                 | shadow: files systemd
                                                              > gshadow: files systemd
#hosts: files mymachines myhostname resolve [!UNAVAIL=return] | hosts: mymachines resolve [!UNAVAIL=return] files myhostname
hosts: files resolve dns                                      <
So, can someone test if changing shadow: files to shadow: files systemd works?

Yes, that works!

I removed the previous workaround gdm-greeter from /etc/shadow and merged the /etc/nsswitch.conf.pacnew with this change into /etc/nsswitch.conf.

So blame on us, that we did not correctly merge the nsswitch-changes before, I assume?

stronnag · 2025-09-23 21:32:54

dcc24 wrote:

Someone on reddit found out that an update to /etc/nsswitch.conf back in March might be the culprit, which would explain why the problem doesn't happen in newer installs:
$ diff -y --suppress-common-lines  nsswitch.conf nsswitch.conf.pacnew
group: files systemd                                          | group: files [SUCCESS=merge] systemd
shadow: files                                                 | shadow: files systemd
                                                              > gshadow: files systemd
#hosts: files mymachines myhostname resolve [!UNAVAIL=return] | hosts: mymachines resolve [!UNAVAIL=return] files myhostname
hosts: files resolve dns                                      <
So, can someone test if changing shadow: files to shadow: files systemd works?

I had that, was missing the newer `gshadow: files systemd` ... which, when added, fixes everything. Didn't seem that simple yesterday.

dcc24 · 2025-09-24 06:14:39

calculon102 wrote:

So blame on us, that we did not correctly merge the nsswitch-changes before, I assume?

Exactly. I'm glad we finally have a root cause and a fix

alex1124 · 2025-09-24 10:35:29

My newly installed system didn't encounter the gdn crash, but the logs show that the gdm user is missing. I tried to manually create a gdm user, but it seems to have only eliminated the warning, and the screen refresh rate is still not adjustable.

seth · 2025-09-24 11:07:23

@windy, can you still log into a cinnamon session with eg. lightdm?
You'll have to look for a new DM anyway if you don't want/can use wayland because X11 support will drop from GDM, regardless of the current mess arguably the config should not be interpreted of GDM fail more gracefully on X11 attempts, "should" … )

windy · 2025-09-24 12:12:01

seth wrote:

@windy, can you still log into a cinnamon session with eg. lightdm?

Yes, Cinnamon works without any problems when started with LightDM.

You'll have to look for a new DM anyway if you don't want/can use wayland because X11 support will drop from GDM

LightDM with the slick-greeter seems to be the official DM for Linux Mint, so it looks better integrated with Cinnamon than GDM.

regardless of the current mess arguably the config should not be interpreted of GDM fail more gracefully on X11 attempts

A segmentation fault does not look right in my opinion and I would be glad to help diagnose this even if I switch to LightDM.

Dexter23 · 2025-09-24 12:25:53

Hi everyone
I switch from X11 to wayland by comment this line:
#WaylandEnable=false in the file /etc/gdm/custom.conf, i reboot the system and GDM now start normally, on a terminal if i do this command:
echo $XDG_SESSION_TYPE the output return is: wayland.
So it's working.
But i noticed that flameshot not work in wayland, any idea?
Thanks.

seth · 2025-09-24 12:41:58

https://wiki.archlinux.org/title/Flames … me_Wayland ?

zapi · 2025-09-24 13:52:39

WHat a Pity becaus im using X11 because Im using barrier to share mouse and that kind of apps doesnt work well with wayland...

Ill have to install another UI

Dexter23 · 2025-09-24 14:00:13

seth wrote:

https://wiki.archlinux.org/title/Flames … me_Wayland ?

Hi i remove with "sudo pacman -R flameshot-git" and install the flatpak version and put this command to fix the error "Unable to capture screenshot"

flatpak permission-set screenshot screenshot org.flameshot.Flameshot yes

Now it works.
Thanks.

seth · 2025-09-24 14:56:07

The flatpak stuff shoudl™ work w/ the repo version as well - wayland simply handles these kinds of permissions through flatpak/xdg-desktop-portal (if at all)

partizan · 2025-09-24 18:21:10

dcc24 wrote:

Someone on reddit found out that an update to /etc/nsswitch.conf back in March might be the culprit, which would explain why the problem doesn't happen in newer installs:
$ diff -y --suppress-common-lines  nsswitch.conf nsswitch.conf.pacnew
group: files systemd                                          | group: files [SUCCESS=merge] systemd
shadow: files                                                 | shadow: files systemd
                                                              > gshadow: files systemd
#hosts: files mymachines myhostname resolve [!UNAVAIL=return] | hosts: mymachines resolve [!UNAVAIL=return] files myhostname
hosts: files resolve dns                                      <
So, can someone test if changing shadow: files to shadow: files systemd works?

Yes. That's correct fix.

https://gitlab.archlinux.org/archlinux/ … -/issues/9

windy · 2025-09-24 19:34:01

partizan wrote:

dcc24 wrote:
So, can someone test if changing shadow: files to shadow: files systemd works?
Yes. That's correct fix.

My nsswitch.conf already contains this line, but GDM produces segmentation faults nonetheless. Is my issue unrelated?

seth · 2025-09-24 19:40:43

Yes. Are you still trying to run GDM on X11?
It's officially not supported, the only indication that this still works is https://bbs.archlinux.org/viewtopic.php … 8#p2263248 (and that GDM itself actually falls back to X11 when wayland fails and that it still accepts the config parameter - stuff you'd expect to not happen when compiling it w/o X11 support)

windy · 2025-09-24 19:44:03

seth wrote:

Yes. Are you still trying to run GDM on X11?

Well, no, I switched to LightDM. But I thought it would help to narrow down the segfault.

If this is to be expected because of the dropped support, I am happy to just uninstall GDM for good.

partizan · 2025-09-24 19:46:52

windy wrote:

partizan wrote:
dcc24 wrote:
So, can someone test if changing shadow: files to shadow: files systemd works?
Yes. That's correct fix.
My nsswitch.conf already contains this line, but GDM produces segmentation faults nonetheless. Is my issue unrelated?

Most likely, yes. Just to be sure, backup old files and try to use exact files from corresponding packages, not only "contains this line". nsswitch.conf and maybe gdm/custom.conf...

windy · 2025-09-24 21:07:43

partizan wrote:

Most likely, yes. Just to be sure, backup old files and try to use exact files from corresponding packages, not only "contains this line". nsswitch.conf and maybe gdm/custom.conf...

nsswitch.conf was unmodified, but the custom.conf contained some additional entries. After reverting to the default, GDM started.

However, after setting

[daemon]
WaylandEnable=false

I observed the previous segfaults again.

seth · 2025-09-24 21:28:23

If this is to be expected because of the dropped support, I am happy to just uninstall GDM for good.

I guess segfaulting should™ not but has to be expected from <gnomestuff> but as mentioned: regardless of the current mess, X11 support is supposed to be completely removed w/ v50 - leaving GDM behind is inevitable if you want to stay on X11

Arch Linux

#76 2025-09-23 20:07:19

Re: gdm broken after update

#77 2025-09-23 20:16:07

Re: gdm broken after update

#78 2025-09-23 20:22:35

Re: gdm broken after update

#79 2025-09-23 20:50:34

Re: gdm broken after update

#80 2025-09-23 20:52:49

Re: gdm broken after update

#81 2025-09-23 21:09:03

Re: gdm broken after update

#82 2025-09-23 21:26:38

Re: gdm broken after update

#83 2025-09-23 21:32:49

Re: gdm broken after update

#84 2025-09-23 21:32:54

Re: gdm broken after update

#85 2025-09-24 06:14:39

Re: gdm broken after update

#86 2025-09-24 10:35:29

Re: gdm broken after update

#87 2025-09-24 11:07:23

Re: gdm broken after update

#88 2025-09-24 12:12:01

Re: gdm broken after update

#89 2025-09-24 12:25:53

Re: gdm broken after update

#90 2025-09-24 12:41:58

Re: gdm broken after update

#91 2025-09-24 13:52:39

Re: gdm broken after update

#92 2025-09-24 14:00:13

Re: gdm broken after update

#93 2025-09-24 14:56:07

Re: gdm broken after update

#94 2025-09-24 18:21:10

Re: gdm broken after update

#95 2025-09-24 19:34:01

Re: gdm broken after update

#96 2025-09-24 19:40:43

Re: gdm broken after update

#97 2025-09-24 19:44:03

Re: gdm broken after update

#98 2025-09-24 19:46:52

Re: gdm broken after update

#99 2025-09-24 21:07:43

Re: gdm broken after update

#100 2025-09-24 21:28:23

Re: gdm broken after update

Board footer