Glitch art distortion

GNOME Display Manager No Longer Starts Automatically

  • Adam Douglas

Around the beginning of January 2021 I started experiencing an issue where when I turn on my computer or reboot Arch Linux loads up but it stays at the console and it doesn’t load GDM (GNOME Display Manager) for me to login. The system works fine otherwise. Since then I now have experienced this on 3 other systems. I’ve procrastinated trying to figure this out long enough so I went down this rabbit hole to see what I could do to resolve it.

I realize some of the links I’ve provided are quite dated but please realize this issue has been going on for many years. If you want to dig into this deeper make sure to take a look at all the links under “References” at the bottom of the post.

These are just my results in finding a work around solution.

Environment

My system is configure as follows.

  • Arch Linux x86_64 kernel 5.10.13-arch1-1
  • GNOME Shell v3.38.3
  • GDM v3.38.3
  • WaylandEnable=false (disabled in /etc/gdm/custom.conf)
  • NVIDIA GeForce GTX 970

Problem

GDM (GNOME Display Manager) does not load and you are left at the console without a login prompt. In some cases the console is blank.

Looking at the specific “gdm.service” logs you can see that GDM was unable to start.

1

$ journalctl -ru  gdm.service

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Feb 15 17:01:56 adamsdesk systemd[1]: gdm.service: Failed to enqueue OnFailure= job, ignoring: Unit plymouth-quit.service not found.
Feb 15 17:01:56 adamsdesk systemd[1]: gdm.service: Triggering OnFailure= dependencies.
Feb 15 17:01:56 adamsdesk systemd[1]: Stopped GNOME Display Manager.
Feb 15 17:01:56 adamsdesk systemd[1]: gdm.service: Failed with result 'exit-code'.
Feb 15 17:01:56 adamsdesk systemd[1]: gdm.service: Main process exited, code=exited, status=1/FAILURE
Feb 15 17:01:56 adamsdesk gdm[389]: Gdm: Failed to contact accountsservice: Error calling StartServiceByName for org.freedesktop.Accounts: Refusing activation, D-Bus is shutting down.
Feb 15 17:01:56 adamsdesk systemd[1]: Stopping GNOME Display Manager...
Feb 15 16:56:51 adamsdesk gdm[389]: Gdm: Child process -479 was already dead.
Feb 15 16:56:45 adamsdesk gdm-password][722]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
Feb 15 16:56:45 adamsdesk gdm-password][722]: pam_env(gdm-password:session): deprecated reading of user environment enabled
Feb 15 16:56:45 adamsdesk gdm-password][722]: pam_unix(gdm-password:session): session opened for user adam(uid=1000) by (uid=0)
Feb 15 16:56:45 adamsdesk gdm-password][722]: pam_systemd_home(gdm-password:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Feb 15 16:56:45 adamsdesk gdm-password][722]: gkr-pam: stashed password to try later in open session
Feb 15 16:56:45 adamsdesk gdm-password][722]: gkr-pam: unable to locate daemon control file
Feb 15 16:56:22 adamsdesk gdm[389]: Gdm: Child process -461 was already dead.
Feb 15 16:56:22 adamsdesk systemd[1]: Started GNOME Display Manager.
Feb 15 16:56:22 adamsdesk systemd[1]: Starting GNOME Display Manager...

As far as I can tell this is a common race condition where the the GDM (GNOME desktop manager) loads before the DRM (direct rendering manager) is fully initialized. Which means in basic terms GDM service is started before the video driver is loaded. It is a little more technical than this and honestly this is best explained by Adam Williamson as to the issues and why it is still not fixed after 8 years of the issue being originally reported to the GDM project. There has even been some unofficial patches released for Arch Linux and one for Gentoo. The GDM project commits seem to have stalled 2 years ago, GNOME / gdm - wip/can-graphical-support.

If this is the case the solution is to patch GDM so it will wait until DRM is fully initialized but how that is done properly is beyond me.

Note

For my situation I'm not experiencing the issue of not enough entropy at boot time [SOLVED] Slow Startup Time - systemd-random-seed.service.

Solution

I’m not sure I would call these permanent solutions but rather a work around. System updates could change the results or heck could even finally fix the problem properly.

Solution / One

Each time the computer system is booted you must manually change the TTY (TeleTYpewriter) by pressing ALT+F2 and then ALT+F1 on the keyboard. This will cause GDM service to be started again and you will be able to continue on as normal.

I’ve personally found this solution to work 100% of the time on 4 systems.

Solution / Two (Recommended)

Create a udev rule and video device driver systemd service file to instruct GDM to only start when DRM (direct rendering manager) is ready with the device driver card0 (video card).

This solution works 100% of the time for me in testing. I honestly feel this is the best work around solution since it is deliberately creating the behaviour we want so GDM will start automatically as expected.

1

$ nano /etc/udev/rules.d/99-make-udev-drm-aware.rules

1

SUBSYSTEM=="drm", TAG+="systemd"

1

# nano /etc/systemd/system/gdm.service.d/10-wait-for-card.conf

1
2
3

[Unit]
Wants=dev-dri-card0.device
After=dev-dri-card0.device

Solution / Three

Edit the “gdm.service” adding “ExecStartPre=/bin/sleep 1” and “Type=idle” as shown below. Some people have reported this to work however, this is going to depend on each situation and may not work 100% of the time.

Changing “Type=idle” from the default of “Type=simple” does cause a delay in execution but may not work for all situations. This is explained in detail in the man page “systemd.service(5)”.

Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway. – Man page, SYSTEMD.SERVICE(5)

Adding “ExecStartPre=/bin/sleep 1” will definitely add delay in execution. However the amount of delay may vary from each situation and may vary each time the system is booted.

In testing this I found indeed it did work 100% of the time. I even found this solution to work when only adding “ExecStartPre=/bin/sleep 1”. So in my situation it seems adding “Type=idle” is unnecessary. Saying all this though I feel this is not an ideal work around solution and just so happens to work out of perfect timing (luck).

1

# systemctl edit gdm.service

1
2
3

[Service]
Type=idle
ExecStartPre=/bin/sleep 1

Note

These changes will be stored at "/etc/systemd/system/gdm.service.d/override.conf".

Note

Do not add "ExecStart=/usr/bin/gdm" as this is already defined (/usr/lib/systemd/system/gdm.service).

Oh some have reported that for some reason these changes are overwritten when system updates are applied. I’m not sure how this would occur if you are indeed applying them as I’ve instructed. However if for some reason this is occurring you can fix this in Arch Linux with a pacman hook, “/etc/pacman.d/hooks/gdm.hook”.

1

# nano /etc/pacman.d/hooks/gdm.hook

1
2
3
4
5
6
7
8
9
10
11

[Trigger]
Operation=Install
Operation=Upgrade
Type=Package
Target=gdm

[Action]
Description=Adds a small delay to /usr/lib/systemd/system/gdm.service to work around bug
Depends=coreutils
When=PostTransaction
Exec=/usr/bin/sed -i '/^\[Service\]/a ExecStartPre=\/bin\/sleep 2' /usr/lib/systemd/system/gdm.service

Solution / Four

Change from Arch Linux kernel stable to Arch Linux kernel long-term support (LTS). I’ve personally tried this option and it didn’t work for me. Based on what I’ve discussed here this isn’t a kernel issue anyways so this is not even a work around as far as I’m concerned.

Solution / Five

Create Xorg configuration file to define video card device instead of using auto detection.

In testing this worked 100% of time. However personally I feel this is out of luck and may not work for everyone. The reason I say this is because what would cause this to make GDM start after DRM is ready? It just feels like it may create an indirect delay in the loading of GDM and just happens that DRM is full initialized. I personally don’t trust this work around solution but that is most likely because I don’t fully understand how this could work.

1

$ lspci | grep -i 'vga\|3d\|2d'

1

01:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1)

1

# nano /etc/X11/xorg.conf.d/20-nvidia.conf

1
2
3
4
5
6

Section "Device"
        Identifier "Nvidia Card"
        Driver "nvidia"
        VendorName "NVIDIA Corporation"
        BoardName "GeForce GTX 970"
EndSection

Solution / Six

Apply one of the following unofficial patches to resolve the issue (only one applies directly to Arch Linux). I don’t recommended this as per Adam Williamson explanation as this doesn’t solve it as a work around nor as a permanently solution. As well if I understand it correctly, you will need to apply this patch every time an update is done to GDM. Granted you could create a hook to auto apply the patch after each update. For those that want to take the risk and/or understands this better than I you could give it a try.

  • Marti Raudsepp / arch-pkg-gdm
  • Gentoo CanGraphical Patch (https://gitweb.gentoo.org/repo/gentoo.git/tree/gnome-base/gdm/files/gdm-CanGraphical-wait.patch)
References
Changelog
    • Change topic from gdm to GNOME
    • Change "GDM" in title to "GNOME Display Manager"
    • Add tag #gdm
    • Apply admonition style for note
    • Fix thumbnail resolution
    • Fix broken link
    • change topic
    • remove tags gdm, support, video
    • change topic

Comments

Reply via email