reverting gdm restores normal autologon.

I see this with the TimedLogin configured in live images. Live images append this content to /etc/gdm/custom.conf:

[daemon]
TimedLoginEnable=true
TimedLogin=liveuser
TimedLoginDelay=60
FOE

with this, gdm crashes in a loop, same messages as Clyde, on live image boot. If you remove the file and restart prefdm.service , gdm comes up okay (except, obviously, without a timed login active).

Critical, as it breaks live spins.

I can reproduce that behaviour here with VirtualBox 4.0.2 and xfce-i386-20110203.iso nightly media.
It is hard to get the messages logged that pop up to console. Though, I am able to boot into runlevel 3 and run startx well as root.

Created attachment 477213 [details]
gdm error msgs from gdm-2.91.6-2.fc15.x86_64

gdm-2.91.6-2.fc15.x86_64 did not resolve problem. Attached is portion of errors in /var/log/messages.  Numerous instances of these msgs as same behavior as reported still exists.  Removing /etc/gdm/custom.conf allows logon. Contents of custom.conf were:

[daemon]
TimedLoginEnable=true
TimedLogin=kunkelc
TimedLoginDelay=10

This bz should really be titled:

 GDM in timedlogon error loop
vice
 GDM in autologon error loop

clyde: apparently the bug actually has nothing to do with auto or timed login; it's just a problem when the login dialog becomes a scrolled widget, which happens to happen when we enabled timed login.

gdm-2.91.6-3.fc15.x86_64 does not fix the problem for me....

 desktop-x86_64-20110207.15.iso  fails same way...

I think I this last night too, on a new rawhide installation.  I tried killing off /etc/gdm/custom.conf, as well as downgrading to a few previous GDM, without much luck.  When booting to runlevel 3, I see GDM try to spawn itself a few times in a loop, and then give up.  The system generally seems to run alright, and X can start separately if I boot to runlevel 3 and load a window manager via. startx.

(In reply to comment #9)
> I think I this last night too, on a new rawhide installation.  I tried killing
> off /etc/gdm/custom.conf, as well as downgrading to a few previous GDM, without
> much luck.  When booting to runlevel 3, I see GDM try to spawn itself a few
> times in a loop, and then give up.  The system generally seems to run alright,
> and X can start separately if I boot to runlevel 3 and load a window manager
> via. startx.

Er, sorry; I meant obviously 'when booting to runlevel 5, I see GDM..'

i also get this error also even with the TC1 Live image

Leaving notes on proposed blockers as I won't be at the meeting tomorrow most
likely:

+1 blocker, although interestingly we don't exactly have a criterion that covers this...there ought to be one.

Per 2011-02-11 Alpha blocker bug meeting - 
AGREED: 674978 - accepted as a F14Alpha blocker, impacts logging into desktop on all live images

(In reply to comment #13)
> Per 2011-02-11 Alpha blocker bug meeting - 
> AGREED: 674978 - accepted as a F14Alpha blocker, impacts logging into desktop
> on all live images

you might wanna correct that to " F15Alpha Blocker "

downloaded Nightly compose image 20110212 and GDM stoill goes in a loop

Fix should be building now, will push out update request when it finishes

gdm-2.91.6-8.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/gdm-2.91.6-8.fc15

Needs gtk3 which causes a dependency problem with just about every gnome package??

make sure you have the right repos set (branched, not rawhide, I was clearly on crack when I replied to your test email).

gdm-2.91.6-8.fc15 has been pushed to the Fedora 15 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gdm'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gdm-2.91.6-8.fc15

[kunkelc@P5K-EWIFI ~]$ sudo yum --enablerepo=updates-testing update gdm
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package gdm.x86_64 1:2.91.6-3.fc15 will be updated
--> Processing Dependency: gdm = 1:2.91.6-3.fc15 for package: 1:gdm-plugin-fingerprint-2.91.6-3.fc15.x86_64
---> Package gdm.x86_64 1:2.91.6-8.fc15 will be an update
--> Processing Dependency: libgdk-3.so.0()(64bit) for package: 1:gdm-2.91.6-8.fc15.x86_64
--> Processing Dependency: libgtk-3.so.0()(64bit) for package: 1:gdm-2.91.6-8.fc15.x86_64
--> Running transaction check
---> Package gdm.x86_64 1:2.91.6-8.fc15 will be an update
--> Processing Dependency: libgdk-3.so.0()(64bit) for package: 1:gdm-2.91.6-8.fc15.x86_64
--> Processing Dependency: libgtk-3.so.0()(64bit) for package: 1:gdm-2.91.6-8.fc15.x86_64
---> Package gdm-plugin-fingerprint.x86_64 1:2.91.6-3.fc15 will be updated
---> Package gdm-plugin-fingerprint.x86_64 1:2.91.6-8.fc15 will be an update
--> Processing Dependency: libgtk-3.so.0()(64bit) for package: 1:gdm-plugin-fingerprint-2.91.6-8.fc15.x86_64
--> Finished Dependency Resolution
Error: Package: 1:gdm-plugin-fingerprint-2.91.6-8.fc15.x86_64 (updates-testing)
           Requires: libgtk-3.so.0()(64bit)
Error: Package: 1:gdm-2.91.6-8.fc15.x86_64 (updates-testing)
           Requires: libgtk-3.so.0()(64bit)
Error: Package: 1:gdm-2.91.6-8.fc15.x86_64 (updates-testing)
           Requires: libgdk-3.so.0()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
[kunkelc@P5K-EWIFI ~]$

(In reply to comment #21)

Hey Clyde, the issue you see is a dependency issue that will be fixed by several other updated packages in updates-testing.  Can you retest with an updated 'updates-testing' repo? 

I'm moving this issue to VERIFIED based on my manual testing by pulling down updated packages to resolve deps.

(In reply to comment #22)
> (In reply to comment #21)
> 
> Hey Clyde, the issue you see is a dependency issue that will be fixed by
> several other updated packages in updates-testing.  Can you retest with an
> updated 'updates-testing' repo? 

Note, you can enable the kojipkgs repo to get content before it lands
updates-testing (http://kojipkgs.fedoraproject.org/mash/branched/).

This was updates-testing from kojipkgs.  I also tried manual updating and it failed also.  I think I borked my F15 Alpha installation and contaminated it with some rawhide files.  Anyway, tied to install F15Alpha TC2 to retest and it won't install says missing package perl(date/time).  Now I don't have any F15Alpha systems unless I go back to TC1 (which I will try later and then do an updates testing).

(In reply to comment #24)
> This was updates-testing from kojipkgs.  I also tried manual updating and it
> failed also.  I think I borked my F15 Alpha installation and contaminated it
> with some rawhide files.  Anyway, tied to install F15Alpha TC2 to retest and it
> won't install says missing package perl(date/time).  

See bug#677799 for the perl-DateTime dependency problem.

> Now I don't have any
> F15Alpha systems unless I go back to TC1 (which I will try later and then do an
> updates testing).

Is the problem due to missing dependencies?  You should be permitted to click "ignore" for those types of issues.  You mention "missing package", that seems like your mirror isn't updated yet.  Can you retry today, or point to another mirror?

(In reply to comment #25)
> (In reply to comment #24)
<snip>
> Is the problem due to missing dependencies?  You should be permitted to click
> "ignore" for those types of issues.  You mention "missing package", that seems
> like your mirror isn't updated yet.  Can you retry today, or point to another
> mirror?

OK, I went back to TC1, did a clean install to bare metal, made sure the repos pointed to the correct location, updated, and, voila!  Can now do timed logon without gdm doing the two-step.

I guess this can be closed as fixed?

The package needs to get pushed to stable before we can close it.

I have been playing around with gdm-2.91.6-9.fc15 and it is not gdm that is crashing but gnome-session. I will look into providing more info soon.

Unfortunately I still haven't managed to get a backtrace out of my VM, but when I swich from init 3 to 5 I loose my network connection and have to restart libvirtd afterwards (wft?). However I have made an interesting observation:

Feb 18 23:06:49 localhost gdm-simple-slave[2507]: DEBUG(+): GdmWelcomeSession: Running welcome_session process /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWindow
Feb 18 23:06:49 localhost gnome-session[2532]:GLib-GIO-ERROR: Settings schema 'org.gnome.screensaver' is not installed#012#012aborting...
Feb 18 23:06:49 localhost abrt[2538] saved core dump of pid 2532 (/usr/bin/gnome-session) to /var/spool/abrt/ccpp-1298088409-2532.new/coredump (9576488 bytes)

Next thing to try is if it works with gnome-screensaver installed.

After installing gnome-screensaver I at least get a gdm window, however the greeter loops. I only see "Automatic login" but now countdown and this loops every second, I cannot even click "Cancel".

For the gnome-session issue refer to bug 678712.

loop means it's crashing. it crashes, respawns, crashes, respawns...

gdm-2.91.6-9.fc15 has been pushed to stable

gdm-2.91.6-8.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

in gdm-2.91.93-1.fc15 have the same problem. loop in gdm.

for the fifth time, it's not 'the same problem'. it's the same _symptom_. this symptom will happen _any time there's a crash-on-start bug in gdm_ - no matter what that bug actually is. Please file a new bug, with the trace from /var/log/gdm/*greeter* .