Bug 946964 - F19 gdm won't log in (gray screen only) when software rendering is used - any other DM works
Summary: F19 gdm won't log in (gray screen only) when software rendering is used - any...
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 19
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
Depends On:
TreeView+ depends on / blocked
Reported: 2013-04-01 04:33 UTC by Andre Robatino
Modified: 2015-01-09 18:52 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-01-09 18:52:28 UTC
Type: Bug

Attachments (Terms of Use)
part of /var/log/messages spanning failed login attempt (9.69 KB, text/plain)
2013-04-04 01:33 UTC, Andre Robatino
no flags Details
.xml file for 32-bit KVM guest for 19 Beta TC4 default install (2.71 KB, application/xml)
2013-05-12 21:27 UTC, Andre Robatino
no flags Details
.xml file for 64-bit KVM guest for 19 Beta TC4 default install (2.82 KB, application/xml)
2013-05-12 23:44 UTC, Andre Robatino
no flags Details
:0.log from /var/log/gdm in 64-bit KVM guest (48.78 KB, text/plain)
2013-05-13 16:35 UTC, Andre Robatino
no flags Details

Description Andre Robatino 2013-04-01 04:33:59 UTC
Description of problem:
I did successful default KVM installs of 19 Alpha TC3 (both i386 and x86_64) from the DVDs. I skipped creating a user during install, then used gnome-initial-setup to create the user after rebooting. After finishing, I am automatically logged into my user account and am able to use the GUI. However, if I reboot, after entering my username and password at the gdm prompts, I am never logged in. After a *very* long wait (up to 15 minutes!), I am returned to the gdm prompt without ever being logged in.

I *can* log in on a VT. During the long wait, it shows gnome-shell using up high CPU. I'm taking a wild guess as to the Component. I tried "enforcing=0" and it made no difference.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Do default KVM install of 19 Alpha TC3
2. Reboot, create user with gnome-initial-setup
3. Reboot again, try to log in with gdm
Actual results:
Can't login. Eventually get returned to login prompt

Expected results:
Logged in

Additional info:
After a full update (including gnome-shell-, no change.

Comment 1 Andre Robatino 2013-04-01 05:03:49 UTC
Proposing as Alpha Blocker by https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_installed_system_boot_behavior : " After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."

I am only seeing this on KVM. In VirtualBox, it seems possible to actually log in via gdm most of the time. Have not tried bare metal.

Comment 2 Robert Lightfoot 2013-04-03 04:45:11 UTC
Centos 6.4 qemu-kvm using Spice-VGA display I was able to login to default i386 gnome both at gnome-initial-setup and subsequent reboots.  So I cannot recreate this bug in F19-Alpha-TC3-I386.

Comment 3 Andre Robatino 2013-04-03 05:03:37 UTC
Should have specified earlier - my host is F18 x86_64. The KVM guest has 1 GiB RAM and is using spice.

Comment 4 Jens Petersen 2013-04-03 06:07:32 UTC
> I am only seeing this on KVM. In VirtualBox, it seems possible to actually
> log in via gdm most of the time. Have not tried bare metal.

It hard to see how that should make a difference.

FWIW I don't think I have seen any gdm login problems recently
in guests or bare metal.

Comment 5 Jens Petersen 2013-04-03 06:08:10 UTC
> Should have specified earlier - my host is F18 x86_64. The KVM guest has 1
> GiB RAM and is using spice.

Same here

Comment 6 Robert Lightfoot 2013-04-03 11:49:30 UTC
I have also tested this now on Centos 6.4 qemu-kvm and x86_64 platform.  No issue seem.

Comment 7 Adam Williamson 2013-04-03 18:26:55 UTC
Discussed at 2013-04-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-03/f19alpha-blocker-review-4.2013-04-03-16.01.log.txt . We seem to be having trouble reproducing this, but we'll try harder to match Andre's exact configuration; blocker determination is delayed for now.

Comment 8 Tim Flink 2013-04-03 19:26:56 UTC
I tried this on a KVM VM with SPICE (ovirt with F18 based node, if that matters) and was unable to reproduce.

After installing gnome desktop from TC3 x86_64 DVD and not creating a user during install, I was automatically logged in after completing gnome-initial setup. Subsequent logins were also not a problem for me.

Comment 9 Andre Robatino 2013-04-04 01:33:12 UTC
Created attachment 731437 [details]
part of /var/log/messages spanning failed login attempt

I was able to get a single successful login, but can't reproduce it. Attaching the part of /var/log/messages spanning a failed login attempt.

Comment 10 Jens Petersen 2013-04-04 05:37:37 UTC
I don't see it for TC4 guest either.

Comment 11 Jens Petersen 2013-04-06 02:09:24 UTC
Still happening with TC5?

Comment 12 Andre Robatino 2013-04-06 03:17:15 UTC
Yes, see https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_TC5_Install . At this point it's pretty obvious I'm the only one seeing it, so I'll be happy to submit any necessary log files (I can get in via VT, and scp them to my host, so that's no problem).

Comment 13 Adam Williamson 2013-04-08 16:17:24 UTC
Discussed at 2013-04-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-08/f19alpha-blocker-review-5.2013-04-08-16.01.log.txt . Rejected as a blocker: though the impact of this bug is bad, no-one else seems to be able to reproduce it, and we don't make issues that only one person can reproduce blockers usually. If we can pin down the conditions of this bug so it's reproducible and it still seems bad enough to infringe the criteria, we'll re-consider it.

Comment 14 Andre Robatino 2013-04-11 13:50:10 UTC
None of the following worked:

1) Increasing memory from 1 to 1.5 or 2 GiB (normally I use the default 1 GiB). Keep in mind my host only has 4 GiB, so too much for the guest is counterproductive.
2) Switching from Spice to VNC.
3) Using the nouveau driver instead of nvidia (nouveau doesn't work for me except with the 3.6.11 kernel unless I use the nomodeset boot option, in which case I only get 1024x768 resolution).
4) Leaving "Allocate entire disk now" checked (normally I uncheck it).
5) The boot option enforcing=0.

Each time I enter the password and hit Enter, it shows the time of my previous login attempt, so technically I *am* getting logged in, but always either I get kicked back to the login screen after a long wait, or the screen goes black and I'm unable to do much of anything, not even get to a VT, and usually have to hard power off.

In VirtualBox, I have similar trouble getting logged in, but in that case, the following trick works: go to a VT, run "killall gnome-shell", then go back to VT1. I get the login prompt back, I hit Enter, after a short wait it shows the login prompt again (instead of asking for password), I hit Enter *again*, and *this* time it asks for password and then I get logged in. The whole sequence is reproducible. (I have to do this in both my F19 and Rawhide VirtualBox guests.) With KVM, that doesn't work. When I go back to VT1, I have the unresponsive black screen and have to hard power off. I take it that gnome-shell is supposed to automatically restart when it's killed, and that in KVM it's not happening.

Nirik on IRC suggested that I try "systemctl restart gdm" as a substitute to get the login prompt back. Although it does indeed do that, both in VirtualBox and KVM, it doesn't allow me to log in on either one. Only "killall gnome-shell" does that, and only in VirtualBox.

I can easily get to a VT in KVM, to provide any logs, but someone needs to tell me which ones are important. I did provide a section of /var/log/messages in comment 9, and thought I saw some suspicious messages, but someone else needs to look at that.

Comment 15 Andre Robatino 2013-04-17 20:52:08 UTC
As of today's updates in Rawhide and F19, my VirtualBox guests seem to be fixed - I can log in normally, without difficulty. Have not tried KVM installs yet. I'll probably try default installs of 19 Alpha RC4 and see if they work, both before and after applying updates.

Comment 16 Andre Robatino 2013-04-17 20:59:01 UTC
Forgot to mention that in both Rawhide and F19, when I log in, it fails to remember previously running applications (I normally have a gnome-terminal), even though I have that set with gnome-session-properties, and when I bring it up, it shows that checked. It used to work.

Comment 17 Andre Robatino 2013-04-18 13:54:31 UTC
In my Rawhide and F19 VirtualBox guests (which have 1 GiB RAM), it appears I need a non-debug kernel to be able to log in, in addition to recent updates. In my KVM guests, starting with a 19 Alpha RC4 DVD install (either i386 or x86_64), I can't get logged in graphically, even by using the non-debug kernel http://koji.fedoraproject.org/koji/buildinfo?buildID=410037 , a full distro-sync, and increasing guest memory to either 1.5 or 2 GiB (the host only has 4 GiB so that's as high as it's worth going).

Comment 18 Shawn Starr 2013-04-21 07:11:47 UTC
use slub_debug=- for debug kernels for now in your grub options of using 1GB for guest VM

Comment 19 Jens Petersen 2013-04-23 02:25:04 UTC
top - 11:19:21 up 3 min,  2 users,  load average: 1.13, 0.63, 0.26
Tasks: 109 total,   2 running, 107 sleeping,   0 stopped,   0 zombie
%Cpu(s): 88.6 us,  6.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  4.2 hi,  0.3 si,  0.7 st
KiB Mem:   1019684 total,   542196 used,   477488 free,    32420 buffers
KiB Swap:  2031612 total,        0 used,  2031612 free,   188676 cached

 1080 gdm       20   0 1392408 153504  34836 R 89.81 15.05   1:15.94 gnome-she+
  504 root      20   0  329464  33136   8336 S 3.919 3.250   0:20.78 Xorg
 1241 root      20   0  119288   1400   1020 R 0.980 0.137   0:01.00 top

Really weird but since yesterday I have "started to see this" too...
though I almost feel it must be a new problem but both my RC2 and RC3
installs with some updates no longer start user desktop sessions,
the gdm gnome-shell just seems to loop after authentication before
finally giving up after some time and returning to the login UI.
Quite weird how this started just after Alpha went go...

After two attempts I can often no longer switch to vconsole.

I briefly tried strace and gdb on the runaway gnome-shell process
but didn't find anything significant yet, nor in log files.
Any suggestions about where to look or how to debug this?

Comment 20 Jens Petersen 2013-04-26 08:04:57 UTC
Proposing as BetaBLocker

Comment 21 Jens Petersen 2013-04-26 08:24:10 UTC
Hmm not sure what changed, but after yum update today gdm login
starts desktop sessions again today.

Comment 22 Andre Robatino 2013-04-30 21:14:22 UTC
Changing summary since I still saw this with Alpha Gold (RC4). Deleted my KVM guests shortly after, so don't know if it's still there with recent updates. Will retest with 19 Beta TC1. As mentioned above, the problem has been gone in my regular VirtualBox 19 and Rawhide guests for a while now.

Comment 23 Jens Petersen 2013-05-01 01:00:33 UTC
Okay thanks - then I will unpropose it as a beta blocker for now.
Please re-propose if you can still reproduce this for pre-Beta .

Comment 24 Andre Robatino 2013-05-02 05:56:44 UTC
Reproposing as Beta Blocker since I still see this with 19 Beta TC2. I did default GUI installs from the 32- and 64-bit DVDs, and set both a root and user password during install, setting the user as Administrator. After install, g-i-s did NOT come up and I got the gdm screen directly. Upon logging in, I was authenticated as usual, then after a very long wait staring at a gray screen, was kicked back to the gdm prompt. Logging in on a VT shows the gnome-shell process using close to 100% CPU. I tried selinux=0 which I had not tried before, but it didn't help.

Comment 25 Adam Williamson 2013-05-03 00:41:25 UTC
I'm still -1 on this so long as it's only affecting Andre. I don't think whatever Jens saw was the same thing, since he only hit whatever he hit for like a couple of days, while Andre's been seeing this for ages.

Comment 26 Adam Williamson 2013-05-06 16:56:04 UTC
Discussed at 2013-05-06 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-06/f19beta-blocker-review-3.2013-05-06-16.02.log.txt . Again, we have no indication anyone but Andre is hitting this (Jens seems to have hit something else), and so it's rejected as a blocker, but if we can definitely reproduce the issue somehow, it can be re-discussed.

Comment 27 Andre Robatino 2013-05-12 21:27:03 UTC
Created attachment 747003 [details]
.xml file for 32-bit KVM guest for 19 Beta TC4 default install

As promised in the meeting above, attaching the machine definition file for a 32-bit KVM guest for a 19 Beta TC4 default install. Behaves the same as before, with a brand new HDD and F18 x86_64 installed from scratch on the host. It doesn't look like much info, but as I've repeatedly said before, if anyone has any interest - any interest at all - in specific logs, *please* ask for them (preferably before I test).

Comment 28 Andre Robatino 2013-05-12 23:44:31 UTC
Created attachment 747024 [details]
.xml file for 64-bit KVM guest for 19 Beta TC4 default install

Comment 29 Andre Robatino 2013-05-13 15:32:47 UTC
This bug may be a dupe of bug 955779 (or vice versa).

Comment 30 Adam Williamson 2013-05-13 15:40:00 UTC
It doesn't seem hugely likely to me given the different 'hardware' configurations, but it's possible, I guess. Have you checked the GDM logs?

Comment 31 Andre Robatino 2013-05-13 16:34:16 UTC
After running the 64-bit guest and waiting for over half an hour, I still haven't gotten the gdm prompt back. The only log file in /var/log/gdm associated with this attempt is :0.log , which is growing gradually. Unlike my F18 host, there are no greeter or slave log files. Will attach :0.log .

Comment 32 Andre Robatino 2013-05-13 16:35:18 UTC
Created attachment 747295 [details]
:0.log from /var/log/gdm in 64-bit KVM guest

Comment 33 Andre Robatino 2013-05-20 06:20:32 UTC
I see the same problem in my F19 VirtualBox guest if I uncheck the "Enable 3D Acceleration" box (thereby forcing it to use software rendering). So it seems to be a general problem with software rendering, at least in VMs.

Comment 34 Andre Robatino 2013-07-01 15:44:00 UTC
Using a different DM works around the problem (successfully tried both kdm and lightdm). So definitely associated with gdm. I'm also seeing this bug in a fresh installed F19 box with blacklisted Intel 82865 video, and using a different DM works there as well.

Comment 35 Andre Robatino 2013-07-02 04:58:58 UTC
Just did a clean install of F19 on my host (previously F18). The behavior in a F19 KVM guest is exactly the same, and the same workaround (use a DM other than gdm) works.

Comment 36 Adam Williamson 2013-07-02 07:21:56 UTC
Still isn't the same here. Still works fine.

Comment 37 Andre Robatino 2013-07-02 07:42:52 UTC
Changing Summary since I see this whenever software rendering is used.

1) KVM guest
2) bare metal with blacklisted Intel 82865 video
3) VirtualBox guest with 3D turned off, forcing software rendering

On my main machine, which now has F19, and actually does hardware rendering, gdm does work properly *on the host*, but not on a guest (except for VirtualBox using 3D passthrough). That's the only place I see it work normally.

BTW, even though it's my best machine, it's not terribly powerful (2.7 GHz AMD LE-1640 CPU, GeForce 6150SE nForce 430/integrated/SSE2, 4 GiB RAM). Maybe this happens mostly with slower hardware.

Comment 38 Andrew Hatfield 2013-07-04 01:01:39 UTC
I have the same issue.  Upgrade of current stable F18 x86_64 to F19 via fedup.

Card: NVIDIA Corporation GK107 [GeForce GT 640] (rev a1)
Driver: nouveau or nvidia


Monitors: 2 x DVI

GDM loads, but only displays a blank black screen

LightDM and KDM work fine (ugly, but fine)

Comment 39 Jens Petersen 2013-07-04 02:03:09 UTC
Could it be an X/driver problem?

Comment 40 Andrew Hatfield 2013-07-04 02:37:07 UTC
A follow up - running startx works fine

Comment 41 Adam Williamson 2013-07-04 04:50:14 UTC
Is there any reason we're keeping both this and 955779 open? And Andrew, as per 955779, that does not in fact sound like 'the same issue'.

Comment 42 Andre Robatino 2013-07-10 15:08:29 UTC
With the 3.11 kernel in Rawhide, the VirtualBox guest additions don't build (see https://www.virtualbox.org/ticket/11946 ), and again, this bug appears when running that kernel. Previously I saw it when turning off 3D passthrough. So both methods of forcing software rendering in VirtualBox trigger the bug. So I have either 3 or 4 ways to trigger the bug, depending on how you count, and as previously mentioned, would be happy to attach lots of logs, if someone would tell me which ones. Or just close this bug and I can attach them to the other one, I don't care, although the description of that bug should be modified to make clear that the problem is much broader than that one bare metal platform.

Comment 43 Andre Robatino 2013-08-29 19:52:43 UTC
Well, I'm happy to report that this bug appears to be fixed in F20 and Rawhide, at least in my VirtualBox and KVM guests. Login from gdm works fine in a clean default GNOME install from the 20 Alpha TC2 x86_64 DVD. It could be tested nondestructively on bare metal by using the Desktop Live for 20 Alpha TC2, though I haven't tried that.

Comment 44 Andre Robatino 2014-01-12 08:52:45 UTC
I am running F20 Gold and have not seen this bug in F20 at all. Ignore my previous remark about testing nondestructively with the Desktop Live - seeing it requires an actual install (see https://bugzilla.redhat.com/show_bug.cgi?id=955779#c111 ).

Comment 45 Fedora End Of Life 2015-01-09 17:50:10 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 46 Adam Williamson 2015-01-09 18:52:28 UTC
let's just go ahead and close this, nothing's gonna change in F19 for this now.

Note You need to log in before you can comment on or make changes to this bug.