Arch Linux boot halts on Reached target Multi-User System

Arch pushed out Gnome 3.28 today but unfortunately for me, my system failed to boot properly after the upgrade. The system simply locked up after the “Reached target Graphical Interface” stage. GDM (The GNOME Display Manager) was a prime suspect in my book, so the first order of business was booting into a lower runlevel to figure out what was going on.

Reached target Multi-User System

I’m using systemd-boot (because you can never have enough systemd…) so to enter the kernel command line, I simply hit the “e” key from the boot menu. Adding the kernel parameters systemd.unit=multi-user.target will boot the system into runlevel 3 (no display manager).

I then issued journalctl -u gdm.service to see what GDM was up to:

systemd[1]: Starting GNOME Display Manager...
systemd[1]: Started GNOME Display Manager.
gdm[631]: Tried to look up non-existent conversation gdm-launch-environment
gdm[631]: Freeing conversation 'gdm-launch-environment' with active job
systemd[1]: Stopping GNOME Display Manager...
gdm[631]: Failed to contact accountsservice: Error calling StartServiceByName for org.freedesktop.Accounts: GDBus.Error:org.freedesktop.systemd1.ShuttingDown: Refusing activation, D-Bus is shutting down.
gdm[631]: GLib: g_variant_new_string: assertion 'string != NULL' failed
gdm[631]: GdmLocalDisplayFactory: Failed to issue method call: GDBus.Error:org.freedesktop.systemd1.ShuttingDown: Refusing activation, D-Bus is shutting down.
systemd[1]: Stopped GNOME Display Manager.
gdm[631]: GLib: g_hash_table_find: assertion 'version == hash_table->version' failed

What I can tell from the log is that the gdm-password session is missing which might explain the sudden halt. However, add NVIDIA Optimus and Wayland to the mix and the force is just not strong enough within to bother with this on a Sunday morning. Instead I opted to see if LightDM would work. In my experience, it’s always useful to have fallback options when using bleeding edge distributions.

Issuing systemctl start lightdm.service fired up the display manager and I was back in business. I then proceeded to disable GMD with systemctl disable gdm.service and enabled LightDM with the command systemctl enable lightdm.service. Why do today what you can put off until tomorrow ;-)

Tomorrow has arrived and the issue seems to be related to Wayland / NVIDIA Optimus (GeForce GTX 860M). Setting WaylandEnable=false in /etc/gdm/custom.conf and thus using the Xorg backend works fine. It looks like Wayland sessions are off the table for the moment.

Update: Friday, April 13.
The issue has been resolved, probably by the relesease of mutter 3.28.1. Happy days!

Related