Arch Linux

I'm experiencing the same problem. If you go to tty2 and do `sudo systemctl restart gdm.service` it does work normally, and you can login.

EDIT: Actually for me, after some waiting period it does show up on its own, it just needs long time.

the same problem. GDM took a long time to start.

AMD 3900x and Nvidia 2080Ti

Same, `sudo systemctl restart gdm.service` did not help. I see a white cursor (underscore) in the top left corner that starts to flash after a second.

Same for me! Either it just doesn't show up or only after a very long while. Maybe it is a graphics card issue as I also have a 2080 Ti. Restarting the service also doesn't help most of the time.

I can confirm it as well on a Thinkpad E560. Booting LTS kernel solves the issue, and is able to start GNOME on wayland. On 5.3 after 1.5 minutes timeout GNOME is started with X. Early KMS had no influence on it either (at least with i915 and intel_agb).

-

This is possibly the same issue as https://bugs.archlinux.org/task/64985

Possible workarounds:
* Try out the patch linked in the above bug. PKGBUILD & patches here: https://gitlab.com/intgr/arch-pkg-gdm/tree/master/trunk
* Many users in forums are recommending "early KMS" to fix GDM issues: https://wiki.archlinux.org/index.php/Kernel_mode_setting#Early_KMS_start

I tried setting "i918", then with "intel_agp", then with "nouveau" for early KMS, but that didn't change the outcome. Upgrading all packages to 3.34, then cloning the linked trunk and reinstalling gdm with "makepkg -si" did not solve the issue for me as well, sadly. Tell me if I did something incorrectly or if any debug info may help you. Thanks for your comment, still!

Please change the category to "Packages: Extra"

Looks like I started to have the same issue with GDM 3.36.2-1. After boot it just shows a black screen with a blinking cursor in the upper left.
If I go to tty2, and back to tty1 it loads imidiatelly.

Here's what systemd shows:
Jun 13 08:57:29 elitebook systemd[1]: Started GNOME Display Manager.
Jun 13 08:57:30 elitebook gdm[625]: GdmDisplay: Session never registered, failing
Jun 13 08:57:30 elitebook gdm[625]: Child process -698 was already dead.
Jun 13 08:57:30 elitebook gdm[625]: Child process -698 was already dead.
Jun 13 08:57:30 elitebook gdm[625]: Child process -737 was already dead.
Jun 13 08:57:53 elitebook gdm-password][1058]: gkr-pam: unable to locate daemon control file
Jun 13 08:57:53 elitebook gdm-password][1058]: gkr-pam: stashed password to try later in open session
Jun 13 08:57:53 elitebook gdm-password][1058]: pam_unix(gdm-password:session): session opened for user pashinskikh by (uid=0)
Jun 13 08:57:53 elitebook gdm-password][1058]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
Jun 13 08:57:57 elitebook gdm[625]: Child process -805 was already dead.

Same problem on my laptop here with just an integrated graphic card, in Wayland as well in Xorg mode.
Switching to terminal and back solves the problem... still a nasty workaround.

Why not adopt the same fix that other distros have?
See https://gitweb.gentoo.org/repo/gentoo.git/tree/gnome-base/gdm/files/gdm-CanGraphical-wait.patch
PKGBUILD: https://gitlab.com/intgr/arch-pkg-gdm/tree/master/trunk

Hi everyone,
I've also run into this extremely annoying bug. At first I thought it was related to not having enough entropy at boot time, so I installed rng-tools and enabled rngd.service, but that didn't solve the issue.

I ultimately figured out that adding a delay to the gdm.service allowed me to start GDM consistently. To do this I inserted "ExecPreStart=/bin/sleep 2" line into the gdm.service file, so it looks like:

... more ...
[Service]
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/gdm
... more ...

In order to prevent this change from being overwritten, I created a pacman hook that will always insert the delay after a gdm package update.

Hook is installed here: /etc/pacman.d/hooks/gdm.hook

And the hook looks like:

[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

This seems to work well for me, and I don't have to reapply the fix after updating GDM.

I hope this helps others.

thanks for that 2 second sleep tip - works perfectly for me. It's crude but I prefer it to the things other distros seem to be doing to solve the same problem

Cannot reproduce the issue (gdm 3.38.2).

Upstream bug https://gitlab.gnome.org/GNOME/gdm/-/issues/103 is still open, and this is effecting me with GDM 40 and 41. On most boots, GDM starts eventually, but doesn't offer the Wayland session. Debug logs show it repeatedly trying to start an X session but failing to open /dev/dri/card0.

I would recommend working around this by adding the GPU driver (e.g. `i915`) to the initcpio MODULES.

I already have amdgpu in there (card is Vega 64), but it does not help. I also tried NOT loading the module early and got the same results.

Am getting this now as a user of `gnome-unstable`, following an upgrade last night that I made to my machine.

It's clearly an upstream bug which only affects specific drivers. Since it's very old, I'm closing this task. If new problems happen, then you can open a new task with detailed logs.