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.
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: Starting GNOME Display Manager... systemd: Started GNOME Display Manager. gdm: Tried to look up non-existent conversation gdm-launch-environment gdm: Freeing conversation 'gdm-launch-environment' with active job systemd: Stopping GNOME Display Manager... gdm: 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: GLib: g_variant_new_string: assertion 'string != NULL' failed gdm: GdmLocalDisplayFactory: Failed to issue method call: GDBus.Error:org.freedesktop.systemd1.ShuttingDown: Refusing activation, D-Bus is shutting down. systemd: Stopped GNOME Display Manager. gdm: 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.
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
/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!