Manjaro GDM doesn't start after update - user120 authentication

Last update did an oopsy on my Gnome XORG system. I’ve been trying to solve this for like a week with no success.

That’s the error that appears exactly after booting up.

Using tty for troubleshooting.

systemd-homed-service disabled (default - was like that at first)

exapsy systemd[1108]: pam_systemd_home(systemd_user:account): systemd-homed is not available: Unit dbus-org-freedesktop-home1.servce not found
exapsy systemd[1108]: PAM failed: Authentication service cannot retrieve authentication info
exapsy systemd[1108]: user@120.service: Failed to set up PAM session: Operation not permitted
exapsy systemd[1108]: user@120.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted

systemd-homed service enabled

exapsy systemd[1108]: pam_systemd_home(systemd_user:account): Not a user managed by systemd-homed: No home for user gdm known
exapsy systemd[1108]: PAM failed: Authentication service cannot retrieve authentication info
exapsy systemd[1108]: user@120.service: Failed to set up PAM session: Operation not permitted
exapsy systemd[1108]: user@120.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted

You can have a full journalctl -b --priority=err here https://gist.github.com/exapsy/7777c27347588084788350dcba158719

I tried many solutions including

  • Adding onFailure=restart-gdm inside /usr/lib/systemd/system/usr@.service
  • Removing pam_systemd_home.so from /etc/pam.d/system-auth and any other file
  • Placing pam_unix.so as [success=1 default=ignore] instead of pam_systemd_home.so and reorder it to be first
  • Reinstalling systemd
  • Reinstalling gdm
  • Reinstalling systemd-homed
  • Restarting sudo systemctl restart user@120.service results in the same errors
  • Removing ~/.profile (mv ~/.profile ~/.profile.bk)

I really dont wanna format right now, I want just peace (not having to re-setup literally everything) and to finally solve this and get some piece of troubleshooting knowledge.

System information

$ uname -a
Linux exapsy 5.10.68-1-MANJARO #1 SMP PREEMPT Wed Sep 22 12:29:47 UTC 2021 x86_64 GNU/Linux

In the error log there is a line unix_chkpwd[842]: could not obtain user info (gdm) I’m not sure what this means and if there is a issue with the gdm user, that could maybe explain gdm not starting. What is the status of the gdm service?

How have you reinstalled gdm? there is gdm-plymouth & gdm available.

From a announcement from stable update thread: on gdm and gdm-plymouth:

Log into your system via tty and depending on your use of Plymouth or bootsplash-systemd choose a option from this post

What is the status of the gdm service?

● gdm-plymouth.service - GNOME Display Manager
     Loaded: loaded (/usr/lib/systemd/system/gdm-plymouth.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-09-30 23:16:29 EEST; 1min 30s ago
   Main PID: 809 (gdm)
      Tasks: 3 (limit: 38416)
     Memory: 4.9M
        CPU: 26ms
     CGroup: /system.slice/gdm-plymouth.service
             └─809 /usr/bin/gdm

Sep 30 23:16:29 exapsy systemd[1]: Starting GNOME Display Manager...
Sep 30 23:16:29 exapsy systemd[1]: Started GNOME Display Manager.
Sep 30 23:16:31 exapsy gdm[809]: Gdm: GdmDisplay: Session never registered, failing
Sep 30 23:16:31 exapsy gdm[809]: Gdm: GdmDisplay: Session never registered, failing
○ gdm.service - GNOME Display Manager
     Loaded: error (Reason: Unit gdm.service failed to load properly, please adjust/correct and reload service manager: File exists)
     Active: inactive (dead)

Sep 30 23:19:24 exapsy systemd[1]: gdm.service: Two services allocated for the same bus name org.gnome.DisplayManager, refusing operation.

I reinstalled gdm-plymouth as well pacman -S gdm-plymouth libgdm-plymouth with no success

`gdm.service: Two services allocated for the same bus name org.gnome.DisplayManager, refusing operation.`

This is interesting, this error leads me to this and this solution. Your log has this line:

 gnome-session-binary[1191]: Unrecoverable failure in required component org.gnome.Shell.desktop

Also something that when thrown in a search engine pops up a link to a issue with gdm & wayland.

This is rather old tho so not sure why it effects you now.

Does uncommenting #WaylandEnable=false in /etc/gdm/custom.conf change the situation?

Does uncommenting #WaylandEnable=false in /etc/gdm/custom.conf change the situation?

That did something strange. The same crash screen appeared, but now TTY opened with a blinking cursor that never prompted me to enter username/passwd.

I entered from a live USB to inspect what went wrong

$ mount /dev/mypartition /mnt
$ chroot /mnt
$ journalctl -b 1 --priority=err | grep "gdm"
Sep 16 15:44:57 gdm[738]: Gdm: Failed to contact accountsservice: Error calling StartServiceByName for org.freedesktop.Accounts: Refusing activation, D-Bus is shutting down

Which makes it kinda interesting

Full log: https://pastebin.com/thnAkGcc

It feels going forward and back again, I hope someone with more knowledge of the boot process steps in and helps out and that you can get this fixed and sorry that I could not help you.

I’m on Wayland and i’m experiencing a similar issue since last update: at every boot GDM seems to works as expected but, after selecting user, at the password prompt it crashes and i get a blank screen.

After switching to TTY2 and back to TTY1, GDM restarts and works well.

This happens every time with my usual setup: laptop with closed lid connected to a external monitor.
I tried booting with external monitor disconnected and with integrated display the login was ok. So i tried just setting the external monitor as “primary” in Gnome Settings, but nothing changed.

Tried also reinstalling gdm.

I don’t use Plymouth and don’t have splash kernel flag.

I see a lot of errors in my journalctl -b 0 but i am not able to find what causes them, even comparing before and after switching to TTY2.

I hope to get some suggestion to try further to resolve this without just wait for the next update like :crossed_fingers:

inxi -Fxzc0

journalctl -b -0

EDIT:
Seems that upgrading
manjaro-pipewire (20210928-1 -> 20211001-1)
solved the problem for me.

Does not compute. The only change with that update was dropping the sof-firmware dependency.

This is interesting.

I just tried a couple of reboot after this upgrade and it just worked.

I also shut down and booted up again with no problem (lid closed, power on by plugging power supply as usual).

I had this issue everyday since last week’s stable update

A few days I had a similar Problem see this thread (german)
no GDM, but LXDM worked (thx to @megavolt )
I “solved” my problem with a new installation.

lgc

That was just a short break :expressionless:

The issue reappeared today, exactly as first described.
I noticed that if i wait enough (8-10 seconds) GDM will crash even before i select user.

So manjaro-pipewire was not involved at all, it is something that can happen or not.
Maybe some hardware failure

Check if there are new configuration files to merge? See: pacnew.

Nothing relevant in pacnew files, AFAIK.

This part of journal

00:12:28 gdm-session-wor: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
00:12:28 gdm-session-wor: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
00:12:24 gdm-session-wor: gkr-pam: unable to locate daemon control file
00:12:18 gnome-session-b: Unrecoverable failure in required component org.gnome.SettingsDaemon.XSettings.desktop
00:12:11 gdm-session-wor: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
00:12:01 gnome-session-b: Unrecoverable failure in required component org.gnome.SettingsDaemon.XSettings.desktop`

made me find this, so i tried

dbus-launch gsettings reset org.gnome.clocks world-clocks

like reported by @Chrysostomus, and then rebooted.
The issue is still there, but at a first impression i have to wait longer for GDM to crash: about 10 seconds, which is enough to accomplish login