Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#46769 - [gdm] gdm won't start on boot with nvidia drivers

Attached to Project: Arch Linux
Opened by Gabriele Musco (gabmus) - Saturday, 17 October 2015, 18:21 GMT
Last edited by Jan de Groot (JGC) - Wednesday, 15 February 2017, 14:35 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 12
Private No


GDM won't start on boot, even if it's enabled in systemd.
This behavior was tested after a clean install.
The same issue doesn't seem to happen on my optimus laptop (nvidia gpu disabled by default, the intel integrated one is used instead) so I think it has to be linked to the nvidia proprietary driver.
Don't know if it's any useful, but with the previous version of this package, on the same pc, gdm would start, but when logging in, I got gdm background and the cursor, to get to my gnome desktop I had to get to tty2 manually. Probably the two things are relied?

It's also worth a mention that after countless reboots at some point gdm started normally, exposing the same "blank background" behaviour described just above, but it didn't show up in the following reboots.

When logging into a tty and running "systemctl status gdm" it seemed like gdm was actually up and running, but effectively it wasn't.
I was able to start it manually by running "sudo systemctl stop gdm && sudo systemctl start gdm"

Additional info:
* package version(s): 3.18.0-1

Steps to reproduce:
- Install Arch with gdm and nvidia proprietary drivers
- reboot and see gdm not starting at boot
This task depends upon

Closed by  Jan de Groot (JGC)
Wednesday, 15 February 2017, 14:35 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#46762 
Comment by Gabriele Musco (gabmus) - Saturday, 17 October 2015, 18:24 GMT
Sorry, I forgot to mention that lxdm works perfectly, so the problem is probably just affecting gdm
Comment by Doug Newgard (Scimmia) - Saturday, 17 October 2015, 18:37 GMT
Duplicate of  FS#46762 ?
Comment by Gabriele Musco (gabmus) - Saturday, 17 October 2015, 18:52 GMT
Interesting, didn't see that bug report, thanks. Actually I didn't know GDM defaulted to Wayland. Disabling Wayland in /etc/gdm/custom.conf resulted in a working GDM. The "blank background" behaviour although is still there, forcing me to switch to tty2 manually.
But this doens't even explain why I was able to start GDM manually or even why at some point it started normally. It's something to investigate on for sure. But I'm not quite certain if this needs to be reported to upstream.
Anyway, regarding the Wayland default, I think Arch should stick to Xorg by default for some time. This cannot be reported upstream since GNOME mainly targets fedora, which, as far as I know, doesn't offer the possiblity to install proprietary drivers out of the box.
Comment by Void Break (voidbreak) - Monday, 19 October 2015, 03:00 GMT
Does pressing esc when hitting the gdm "blank background" get you to the gnome desktop?

I did a clean install with nvidia installed. I get stuck on the gdm "blank background" screen regardless of whether I disabled Wayland in /etc/gdm/custom.conf.
Comment by Gerhard Bogner (slashME) - Wednesday, 21 October 2015, 12:28 GMT
I have this problem as well - with wayland disabled in the gdm config:

When booting most of the time gdm starts but only displays a black screen. Switching to tty2 and restarting gdm from the command line results in the normal gdm screen. After logging in from gdm it gets stuck showing the background and cursor, and switching back to tty2 starts the gnome shell session.

This happens with both nvidia (355) and nvidia-beta (358) from aur. Additionally I'm using glibc recompiled without lock elision to avoid gnome shell crashing with nvidia >= 352 on Skylake CPUs.
Comment by Gerhard Bogner (slashME) - Thursday, 22 October 2015, 17:38 GMT
Interestingly both gdm and the gnome-shell session start fine without any manual restarting or vt-switching if I don't mount the windows ntfs partitions (on a ldm raid 0 array, read-only with mount points nowhere near the gdm user or my user's home directory). It might be a race condition somewhere...
Comment by Jan Alexander Steffens (heftig) - Thursday, 22 October 2015, 17:44 GMT
Likely a duplicate of  FS#46387 
Comment by Gerhard Bogner (slashME) - Thursday, 22 October 2015, 23:33 GMT
I don't think it's 46387 since I disabled Wayland in gdm's config a when I started having problems with the new nvidia driver, and I don't see any crashes in dmesg (as long a lock elision is disabled).
Comment by Brian Woodard (tesaf) - Friday, 23 October 2015, 20:54 GMT
Can confirm.
Comment by Georg (georg) - Tuesday, 27 October 2015, 08:45 GMT
Can also confirm this Bug! ESC Helps for me. Disabling Wayland doesn't. My Homefolder is encrypted. Does this matter?
Comment by Gerhard Bogner (slashME) - Tuesday, 27 October 2015, 15:33 GMT
My home directory is not encrypted. Hitting ESC if gdm fails to switch to the user's shell after logging in helps for me as well.
Comment by Gabriele Musco (gabmus) - Thursday, 29 October 2015, 15:00 GMT
Pressing ESC actually brings me to my GNOME session (tested with Wayland disabled). Pretty weird behavior if you ask me, but it works. Still this needs to be fixed someway, can't tell if it's an upstream bug or something Arch related or that Arch can solve internally.
Comment by Michael (mrl4214) - Monday, 11 April 2016, 05:35 GMT
Can confirm.