Can't log out from Gnome 3.16 Promo (Tumbleweed)

Please help or advise, if you can!
I downloaded the Gnome 3.16 promo ISO, which is based on OpenSUSE Tumbleweed, and installed it to my hard drive. The system works fine, but when I log out from Gnome Shell, it throws me into black tty console with system messages (like “Reached graphical boot target” or so). No display manager, not login prompt, so I even cannot switch users. My system has GDM installed, but I wonder why it is not used.

This isn’t the kind of help you are looking for, but AFAIK the Gnome promo ISO isn’t supposed to be installed under any circumstances. Just wait a week or two, and the Tumbleweed snapshots will come with 3.16 installed.

The problem is supposedly in GDM 3.16, which seems to be broken. I repeated my install with regular Tumbleweed-Gnome ISO. As long as I was was on initial 3.14 version, all worked fine. Bu then I upgraded form the Gnome-Next repo and with GDM 3.16 I again souldn’t log out. I fixed this by switching to LightDM, which works fine. But still… I wish GDM was fixed too someday.

Thanks for highligting that: GDM 3.16 doesn’t even start after “zypper dup” to Tumbleweed 20150330, while lightDM is OK.
It’s amazing how such an evident thing escaped OpenQA…

This is with Gnome 3.16 on Tumbleweed, with Intel video.

I can login and logout with no problems.

I cannot switch to a virtual console (CTRL-ALT-F2 for example) from within the GDM screen, and attempting that might lockup GDM. I can switch to a virt console from within a Desktop (at least from within KDE).

I cannot shutdown or reboot from within a desktop (tried with Gnome, KDE and Icewm). A forced power-off is the only way out. As best I can tell, something is looping. But I have not got the hang of the new “top” format to be able to work out what is looping.

Also, from GDM I can log into “Gnome-wayland”. This seems to work okay, except that “ssh-agent” has not been started…

I have filed 3 bug reports on this:

Bug 925944 Running “gdm” (from Gnome 3.16), cannot switch virtual consoles

Bug 925946 gdm: cannot shutdown or reboot when GDM is the display manager

Bug 925947 “ssh-agent” is not started for Gnome-wayland

I switched back to “lightdm” (which is what I normally use), and everything seems fine from there, though there is no option to start Gnome-wayland.

As for why these got through – the OpenQA testing is never going to be complete. They presumably have not designed tests that check for these problems. We Tumbleweed users are the more complete testing setup.

My advice for the moment: don’t use GDM unless you really want to test for these problems. My testing was with Intel video (two different computers). Maybe someone with different graphics card should do some testing too.

Now that I updated to Gnome 3.16, I’m hitting more or less the same problems with GDM: can’t log out or shutdown from Gnome shell, but shutting down from gnome-terminal or a tty works fine.

Actually, autologin doesn’t work and there are problems with VT-switching, but the basic functions of GDM seem OK.
This was possibly enough to clear OpenQA testing.

Just upgraded to 20150403 (Tumbleweed) (x86_64) but still no joy: a patch to Mesa related to Intel 965 chips didn’t any magic.
Using Gnome-on-wayland session is a nightmare: desktop delays, touchpad hiccups, jerky rendering and … no way out other than pulling the plug. It seems only a developer testbed for now, to be avoided on daily work.

I noticed that GDM uses a wayland session of its own, at least on my laptop:


 619 root   `- systemd-logind                                                            
 654 root   `- sshd                                                                      
 667 root   `- gdm                                                                       
 718 root       `- gdm-session-wor                                                       
 820 gdm            `- gdm-wayland-ses                                                   
 825 gdm                `- dbus-daemon                                                   
 868 gdm                `- gnome-session                                                 
 914 gdm                    `- gnome-shell                                               
 955 gdm                        `- Xwayland                                              
 994 gdm                        `- ibus-daemon                                           
 998 gdm                            `- ibus-dconf                                        
1066 gdm                            `- ibus-engine-sim                                   
1016 gdm                    `- gnome-settings-

while nothing similar is seen with ligtdm or xdm, which show no such flaws.
Some symptoms with VT-switching are also similar to those we experienced last November when the Intel graphics kernel module was broken.

So far, I bet my 5 cents on wayland, or something related to the graphic subsystem, being the culprit of the VT-switch, logout, restart or shutdown problems we are witnessing with GDM.
Thanks nrickert for hinting at that.

Going LIGHTDM for daily use, but will keep testing gdm at night

I’m currently updating Tumbleweed on my system with Nvidia graphics. I’ll have to see if I can run it with a 3.18 kernel, since the Nvidia driver won’t install for 3.19 kernels (and no new driver yet from nvidia). If that can work, I’ll give “gdm” a try.

I tried that.

As long as I use “lightdm” everything is working well.

I tried switch to “gdm”. I edited “/etc/sysconfig/displaymanager” and made the change there. I then rebooted.

The desktop never comes up.

It looks as if “gdm” is being started, then crashes, and this seems to be happening in a loop. I could not break out of the loop, except with force power-off. I have since switched back to “lightdm” where everything is working again.

Maybe Wayland doesn’t like the nvidia drivers.

For those still liking gdm but fed up with wayland…
it is possible to restore the old behaviour simply by uncommenting the 8th line on /etc/gdm/custom.conf so that it displays like:

# GDM configuration storage
# Note: settings from /etc/sysconfig/displaymanager have a higher priority

# Uncoment the line below to force the login screen to use Xorg

That way, wayland is gone:


  600 root    `- systemd-logind
  630 root    `- gdm
  717 root        `- gdm-session-wor
  784 gdm            `- gdm-x-session
  791 gdm                `- Xorg
  896 gdm                `- dbus-daemon
  898 gdm                `- gnome-session
  917 gdm                    `- gnome-settings-
  956 gdm                    `- gnome-shell
 1019 gdm                        `- ibus-daemon
 1024 gdm                            `- ibus-dconf
 1092 gdm                            `- ibus-engine-sim

and (almost) everything works as usual:

Virtual terminal switching from gdm greeter WORKS
Virtual terminal switching from gnome session WORKS
Logging out users WORKS
Shutdown from gdm greeter WORKS
Shutdown from gnome session WORKS
Restart (either from gdm or gnome session) does NOT work
“shutdown -r now” from Gnome-terminal WORKS

This adds to nrickert’s feeling that we are witnessing wayland-related problems, not gdm problems proper.

Thanks for posting that.

Personally, I prefer “lightdm”. But it is good to know that one can force “gdm” to use rather than wayland.

The problems that we are seeing with wayland are not really surprising. It is still early days for full adoption of wayland. The testing has to start somewhere. Those running into problems can think of themselves as finding some of the bugs and providing feedback. Hopefully some of this (or the corresponding bugzilla reports) gets back to the wayland developers.

According to bug 925946, the shutdown or reboot problem is due to a weird behaviour of the i915.ko driver of kernel 3.19.3-1 in a very unlikely condition triggered by gdm 3.16 (everything according to Murphy’s law). :wink:

You should be safe using an earlier kernel, or lightdm as display manager, or a kernel from the Kernel:stable repo with a backported patch.

Hi Nick, apparently with the new 3.19.4 kernel gdm-on-wayland works as intended, no more need to disable it.
I am still seeing delays and artifacts on the gnome-on-wayland session though.