Description of problem: After restart of recent Fedora 15 TC2 there is often no user list on gdm login screen. Only "other" option is visible. If the option "other" is selected and then canceled one or more times (not same every time), the list eventually appears. Version-Release number of selected component (if applicable): gdm-2.91.6-8.fc15.x86_64 How reproducible: often Steps to Reproduce: 1. Reboot 2. Observe login screen Actual results: There is no user list Expected results: There should be user list every time
Created attachment 482350 [details] photo of user list without users I think I see the same - see the attached photo. Trying "other" multiple times makes no difference. gdm-2.91.91-1.fc15.i686 xorg-x11-drv-intel-2.14.0-2.fc15.i686
Actually, what I saw was the release blocker on Bug 672135. Radek, can you verify if that also explains what you see?
What I have reported is different from Bug 672135. The list of users is not visible at all (when the bug happens). Not just names.
A screen shot or photo of your issue could perhaps helping getting it fixed.
I can confirm this bug. On the fresh boot greeter is empty, you are only able to select "Other". Account name shows up after idling for ~10 seconds. Sometimes not (maybe I need more patience and wait longer). After logging in with "Other" and logging out, greeter now is listing my account immediately. I have to notice that bug report #672135 and attached image "photo of user list without users" is not relevant to this bug. p.s. I am using fresh install of fedora 15 alpha.
Created attachment 485729 [details] Users not displayed Here is a photo of not displayed users in the list.
I seem to have a complete user list now: - gdm-2.91.93-2.fc15 - glib2-2.28.3-1.fc15 - gtk2-2.24.3-1.fc15 - gtk3-3.0.3-1.fc15 Please update and report back.
Got these packages, but user list is still empty. (In reply to comment #5) > I can confirm this bug. On the fresh boot greeter is empty, you are only able > to select "Other". Account name shows up after idling for ~10 seconds. I have to correct my self, waiting for the user list to show up does not do anything. The only way to get accounts in the list is by clicking "Other" and going back (by cancel button or by logging out if you've logged in).
(In reply to comment #8) > Got these packages, but user list is still empty. The user list has been reproducibely complete for 1-2 days now whereas before it used to show no or some random number of users. Please make sure that your system is really up to date with respect to both of fedora and updates-testing repositories. I might have installed a few packages from the build server which are more recent than those in fedora or updates-testing but Fedora mirrors should catch up shortly. Alternatively, I recommend that you try with the latest live spin from: http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-i386-20110315.01.iso which am downloading right now myself.
(In reply to comment #9) Sorry, I forgot that desktop-i386-20110315.01.iso does -not- include packages from updates-testing but you can still try to update GNOME related packages from the running live system. Then create a few users, log out and see what happens ..
Can still confirm this issue. Those times, when the userlist is not loaded correctly, I get this in /var/log/messages: Mar 25 12:39:56 fedora gdm-simple-greeter[1331]: DEBUG(+): GdmUserChooserWidget: User removed: MY_VERY_SECRET_USERNAME And other times, when userlist is retrieved and displayed successfully, I'm not getting errors alike, but instead: Mar 25 12:22:39 fedora gdm-simple-greeter[7160]: DEBUG(+): GdmUserChooserWidget: User added: thomas Mar 25 12:22:39 fedora gdm-simple-greeter[7160]: DEBUG(+): GdmUserChooserWidget: User added name:thomas logged-in:1 pixbuf:0x15a6140 But there are times, when I get both (these cases are rare and usually lead to no userlist).
Btw, having this issue on x86_64 with latest updates (updates-testing etc.)
Still seeing this sometimes. It's non-deterministic. gdm-2.91.94-1.fc15.x86_64 accountsservice-0.6.7-1.fc15.x86_64 I can confirm tuxor's observation that "User removed" is logged when it happens.
I've been seeing this less on my desktop lately, but doing the desktop_login validation test on a VM installed from the Beta TC1 desktop live image, it's happening quite a lot. I too see 'User removed' in /var/log/gdm logs. Proposing as Beta blocker as it's an infringement of the desktop_login validation test which is marked as Beta stage, though we don't really have a criterion for this.
I've seen this periodically for the past couple of weeks as well -- it seems to me to be some sort of race condition, as sometimes it happens and sometimes it doesn't. (In my particular case, it fails to show the user list approximately 25% of time.)
to me it seems like I'm running into this quite often after reboots!
So, I proposed this as a blocker as it's a fail on a Beta-level validation test, but it doesn't hit any criteria and I think that's probably right: this seems NTH not blocker to me, there are easy workarounds (reboot if you really *need* the user list, or just type a user name) and it can be fixed with an update. propose drop to NTH. votes?
this does need fixing for ga, but you can log in still. its just not the best experience im +1 to nth
(In reply to comment #17) > votes? +1 to NTH. In fact, I'd suggest NTH for Final and avoid disrupting gdm at this stage.
okay, i'm bumping to f15beta-accepted, and setting f15blocker for now, we can argue it at the next review meeting...
Discussed during the 2011-04-08 blocker review meeting [1]. AcceptedNTH for Beta. If a tested fix is available in time, will include in Beta [1] http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-08/f-15-beta-blocker-review.2011-04-08-17.00.html
Discussed at 2011-04-15 blocker review meeting. We're worried about this one, but it doesn't fit the release criteria very well. We are interested in whether this can cause live autologin to fail; if so we think this merits blocker status, if not, probably not. We will test and revisit next week. This is still definitely accepted as NTH. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I cannot reproduce. It would be good to hear if the people who can reproduce this problem notice any difference with the accountsservice 0.6.9 update that I've built today. It fixes a possible crasher bug related to user removal.
I encountered this bug today, only once in about 10 logins since I installed gdm yesterday (previously I was using lxdm). My F15 partition is up-to-date so this bug is very much alive. As other people remarked this bug cannot be consistently reproduced.
This happens to me quite often. Latest F15 with update-testing. To me it seems like some kind of a race condition. This machine is not very fast. This is what's in messages: Apr 16 19:28:06 base gdm-simple-greeter[1063]: Gtk-WARNING: gtkwidget.c:6778: widget not within a GtkWindow pr 16 19:28:07 base gdm-simple-greeter[1063]: Gtk-WARNING: gtk_widget_size_allocate(): attempt to allocate widget with width -47 and height -47
I updated to 0.6.9 and so far I am not seeing this problem any more. I have rebooted ~8 times since installing it have not seen this problem occur once since installing the new version. Prior to that update it virtually never worked properly for me, so it is working much better at the very least.
I tried rebooting a few times and this bug is still present with: $ rpm -qa 'gdm*' 'accounts*' | sort accountsservice-0.6.9-1.fc15.x86_64 accountsservice-libs-0.6.9-1.fc15.x86_64 gdm-3.0.0-2.fc15.x86_64 gdm-plugin-fingerprint-3.0.0-2.fc15.x86_64
In beta review for this bug is stated as workaround to press Cancel on "Other" but this does not work for me, I still see only "Other" after pressing Cancel. I have to restart Xorg to change things (Ctrl+Alt+Backspace - I have it enabled). It is not necessary to reboot. I even may see correct list after reboot, but it may display just "Other" after login/logout or Xorg restart.
hit this on my first reboot with the updated accountsservice.
(In reply to comment #27) > I tried rebooting a few times and this bug is still present with: > > $ rpm -qa 'gdm*' 'accounts*' | sort > accountsservice-0.6.9-1.fc15.x86_64 > accountsservice-libs-0.6.9-1.fc15.x86_64 > gdm-3.0.0-2.fc15.x86_64 > gdm-plugin-fingerprint-3.0.0-2.fc15.x86_64 Amending my report. I have seen this bug only once on two different systems after many reboots and logouts. There was an update to gdm along with accountsservice on Apr 16. (The last four lines below are from my experiment with downgrading accountsservice.) # egrep 'accountsservice|gdm' /var/log/yum.log Apr 06 08:47:15 Updated: 1:gdm-3.0.0-1.fc15.x86_64 Apr 06 08:47:29 Updated: 1:gdm-plugin-fingerprint-3.0.0-1.fc15.x86_64 Apr 10 02:55:31 Updated: pulseaudio-gdm-hooks-0.9.22-5.fc15.x86_64 Apr 16 17:16:07 Updated: accountsservice-0.6.9-1.fc15.x86_64 Apr 16 17:16:08 Updated: accountsservice-libs-0.6.9-1.fc15.x86_64 Apr 16 17:16:17 Updated: 1:gdm-3.0.0-2.fc15.x86_64 Apr 16 17:16:18 Updated: 1:gdm-plugin-fingerprint-3.0.0-2.fc15.x86_64 Apr 18 10:03:30 Installed: accountsservice-0.6.7-1.fc15.x86_64 Apr 18 10:03:30 Installed: accountsservice-libs-0.6.7-1.fc15.x86_64 Apr 18 12:11:07 Updated: accountsservice-0.6.9-1.fc15.x86_64 Apr 18 12:11:07 Updated: accountsservice-libs-0.6.9-1.fc15.x86_64
(In reply to comment #30) ... > There was an update to gdm along with accountsservice on Apr 16. Tried downgrading gdm and rebooting. The bug occurred on the first try. gdm-3.0.0-1.fc15.i686 gdm-plugin-fingerprint-3.0.0-1.fc15.i686
This appears to a timing issue and possibly related to the fingerprint plugin. With gdm-plugin-fingerprint removed, I can't reproduce the problem. With gdm-3.0.0-1, it happens on pretty much every boot and restarting prefdm fixes it. With gdm-3.0.0-1, it happens very rarely, even with gdm-plugin-fingerprint installed. The only difference between the two versions is that the Fedora logo was added! Could it be that the slight difference in loading the logo is just enough time to miss the race condition whatever it is?
(In reply to comment #32) > This appears to a timing issue and possibly related to the fingerprint plugin. > With gdm-plugin-fingerprint removed, I can't reproduce the problem. With > gdm-3.0.0-1, it happens on pretty much every boot and restarting prefdm fixes > it. With gdm-3.0.0-1, it happens very rarely, even with gdm-plugin-fingerprint > installed. The only difference between the two versions is that the Fedora > logo was added! Could it be that the slight difference in loading the logo is > just enough time to miss the race condition whatever it is? Good question! An experiment would be to replace the logo with a huge image file that could possibly slow the greeter down enough to reproduce the bug ... From skimming the images here: $ xdg-open /usr/share/pixmaps/ I believe the logo is this file: $ rpm -qf /usr/share/pixmaps/fedora-logo-sprite.svg fedora-logos-14.0.1-500.fc14.noarch There is a foot logo in gdm: $ rpm -qf /usr/share/pixmaps/gdm-foot-logo.png gdm-2.32.1-2.fc14.x86_64
(In reply to comment #33) > An experiment would be to replace the logo with a huge image > file that could possibly slow the greeter down enough to reproduce the bug ... I did manage to reproduce this bug once after: $ sudo gconf-editor Making this change: apps:gdm:simple-greeter:logo_icon_name:start-here-1 And right-clicking and selecting "Set as Default". IIRC, I simply logged out. I couldn't reproduce it again.
I removed gdm-plugin-fingerprint and I also do not see this happen again in a short time... (few reboots, restarts).
I just did an update and restarted. The user list showed "Other..." only. Details here: Bug 691232 - gdm loses user name after software update
*** Bug 691232 has been marked as a duplicate of this bug. ***
I saw this bug once with the latest GNOME3 test day i686 live image on the following machine http://www.smolts.org/client/show/pub_d16f8e5b-3ea1-4b4d-83be-a3ecc1a96b62 but couldn't reproduce it after several reboots. See also my other comment https://bugzilla.redhat.com/show_bug.cgi?id=691232#c8
I see this quite regularly with the SoaS live image.
If someone sees this, what logs or other information should they collect from the system before logging out/rebooting? (Just so we're prepared.)
I see this quite regularly, but I don't know how to collect the infomation you mentioned.
if people who see this regularly could add Enable=true to the [debug] section of /etc/gdm/custom.conf and could then reproduce, and then attach /var/log/messages /var/log/gdm/:0-slave.log /var/log/gdm/:0-greeter.log that would be great. I'm still trying to reproduce this but it happens very infrequently for me.
Created attachment 494692 [details] /var/log/messages with gdm debugging enabled With /etc/gdm/custom.conf: ... [debug] Enable=true After restarting, I had "Other..." only.
Created attachment 494698 [details] /var/log/gdm/:0-slave.log with gdm debugging enabled
Created attachment 494699 [details] /var/log/gdm/:0-greeter.log with gdm debugging enabled
(In reply to comment #43) > Created attachment 494692 [details] > /var/log/messages with gdm debugging enabled > > With /etc/gdm/custom.conf: > ... > [debug] > Enable=true > > After restarting, I had "Other..." only. $ rpm -qa 'gdm*' accountsservice | sort accountsservice-0.6.9-1.fc15.x86_64 gdm-3.0.0-2.fc15.x86_64 gdm-plugin-fingerprint-3.0.0-2.fc15.x86_64
Steve, you have the fingerprint plugin disabled? I guess that eliminates that as the cause.
(In reply to comment #47) > Steve, you have the fingerprint plugin disabled? I guess that eliminates that > as the cause. It's installed is all I know: gdm-plugin-fingerprint-3.0.0-2.fc15.x86_64 (IOW, I have not knowingly disabled it.)
*** Bug 697180 has been marked as a duplicate of this bug. ***
I'm going to push an accounts service update to updates-testing which I think may help things. It also makes debug mode signficantly more chatty, so if my changes don't fix things, I should get a much clearer idea why in the next round of logs.
accountsservice-0.6.9-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/accountsservice-0.6.9-2.fc15
Created attachment 494768 [details] /var/log/messages with gdm debugging, accountsservice-0.6.9-2.fc15.i686 "Other..." only both before and after updating (different system from the one in Comment 43). This should have both, separated by: Apr 25 14:53:38 spruce yum[1675]: Updated: accountsservice-0.6.9-2.fc15.i686 $ rpm -qa 'gdm*' 'accountsservice*' | sort accountsservice-0.6.9-2.fc15.i686 accountsservice-libs-0.6.9-2.fc15.i686 gdm-3.0.0-2.fc15.i686 gdm-plugin-fingerprint-3.0.0-2.fc15.i686
Created attachment 494771 [details] /var/log/gdm/:0-slave.log with gdm debugging, accountsservice-0.6.9-2.fc15.i686
Created attachment 494772 [details] /var/log/gdm/\:0-greeter.log with gdm debugging, accountsservice-0.6.9-2.fc15.i686
With gdm debugging on, one system showed "Other..." only on several boots, and the other showed a user on several boots. With gdm debugging off, on the first reboot, both systems displayed an alert during boot saying: "Could not create ICE listening socket: Cannot establish any listening sockets: Log Out". This was after "Starting LSB: start and stop sendmail....", IIRC. Clicking "Log Out" allowed the boot to continue and gdm displayed a user. accountsservice-0.6.9-2.fc15.i686 accountsservice-libs-0.6.9-2.fc15.i686 gdm-3.0.0-2.fc15.i686 gdm-plugin-fingerprint-3.0.0-2.fc15.i686
thanks for the updated logs. They pointed out another bug in the code, which i'll push another test update for.
Update is here: https://admin.fedoraproject.org/updates/accountsservice-0.6.9-4.fc15
(In reply to comment #57) > Update is here: > https://admin.fedoraproject.org/updates/accountsservice-0.6.9-4.fc15 Thanks. I have this update on two systems now. After around a half dozen restarts, I have not observed this bug -- the user name was always displayed in the gdm greeter. (both with gdm debugging on and off) On one system, I have seen some stalls while logging out from the gnome-shell. After clicking "Log Out" in the Log Out dialog, the desktop is shaded and there is a significant delay before the gdm greeter appears. NB: I installed a large package update too.
Just installed this as a part of a minor -testing push this morning and GDM autologin is now broken. The process table shows the X server has started and GDM has a child process of pam-autologin in the sleep state. The slave log is empty while this is happening. Stopping prefdm.service and restarting it makes no difference. Disabling autologin in custom.conf allows the greeter to appear and function normally. Nothing really stands out in greeter.log: Gtk-Message: Failed to load module "pk-gtk-module" (gnome-settings-daemon:1826): Gtk-WARNING **: gtk_window_set_wmclass: shouldn't set wmclass after window is realized! ** (process:1858): DEBUG: Greeter session pid=1858 display=:0 xauthority=/var/run/gdm/auth-for-gdm-vMDFF1/database Gtk-Message: Failed to load module "pk-gtk-module" Gtk-Message: Failed to load module "pk-gtk-module" Failed to play sound: File or data not found Gtk-Message: Failed to load module "pk-gtk-module" gdm-simple-greeter[1858]: Gtk-WARNING: gtkwidget.c:6778: widget not within a GtkWindow gdm-simple-greeter[1858]: Gtk-WARNING: gtk_widget_size_allocate(): attempt to allocate widget with width -47 and height -47 Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1800007 (Login Wind) Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1800007 (Login Wind) Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1800007 (Login Wind) Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. (gnome-settings-daemon:1826): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
(In reply to comment #59) > Just installed this as a part of a minor -testing push this morning and GDM > autologin is now broken. ... Confirming ... accountsservice-0.6.9-4.fc15.x86_64: Hangs at "Started LSB: Start start and stop sendmail." or "reloading sm-client:" (different systems). After pressing ctrl-alt-backspace, the gdm greeter appears and login is possible. accountsservice-0.6.7-1.fc15.x86_64: Autologin works as expected. Snippet from /etc/gdm/custom.conf: [daemon] AutomaticLoginEnable=true AutomaticLogin=joeblow
okay i've mopped up the autologin regression in a build pushed here: https://admin.fedoraproject.org/updates/accountsservice-0.6.9-5.fc15
Confirming -5 fixes autologin.
accountsservice-0.6.9-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 700806 has been marked as a duplicate of this bug. ***
*** Bug 701349 has been marked as a duplicate of this bug. ***