Bug 946964

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.

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.

Should have specified earlier - my host is F18 x86_64. The KVM guest has 1 GiB RAM and is using spice.

> 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.

> Should have specified earlier - my host is F18 x86_64. The KVM guest has 1
> GiB RAM and is using spice.

Same here

I have also tested this now on Centos 6.4 qemu-kvm and x86_64 platform.  No issue seem.

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.

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.

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.

I don't see it for TC4 guest either.

Still happening with TC5?

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).

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.

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.

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.

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.

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).

use slub_debug=- for debug kernels for now in your grub options of using 1GB for guest VM

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

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 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?

Proposing as BetaBLocker

Hmm not sure what changed, but after yum update today gdm login
starts desktop sessions again today.

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.

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 .

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.

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.

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.

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).

Created attachment 747024 [details]
.xml file for 64-bit KVM guest for 19 Beta TC4 default install

This bug may be a dupe of bug 955779 (or vice versa).

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?

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 .

Created attachment 747295 [details]
:0.log from /var/log/gdm in 64-bit KVM guest

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.

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.

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.

Still isn't the same here. Still works fine.

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.

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

packages: 
xorg-x11-drv-nvidia-libs-319.23-5.fc19.x86_64
kmod-nvidia-319.23-1.fc19.5.x86_64
nvidia-settings-desktop-1.0-32.fc19.x86_64
xorg-x11-drv-nvidia-319.23-5.fc19.x86_64
nvidia-settings-1.0-32.fc19.x86_64
kmod-nvidia-3.9.8-300.fc19.x86_64-319.23-1.fc19.5.x86_64
nvidia-xconfig-1.0-28.fc19.x86_64

Monitors: 2 x DVI

GDM loads, but only displays a blank black screen

LightDM and KDM work fine (ugly, but fine)

Could it be an X/driver problem?

A follow up - running startx works fine

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'.

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.

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.

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 ).

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.

let's just go ahead and close this, nothing's gonna change in F19 for this now.