Description of problem: After updating to the latest GNOME 3 updates, GDM drops me back to the login panel after a few seconds during which the screen stays black. After that, file .xsession-errors contains: pam: gdm-password[4018]: CRITICAL: dbus_g_proxy_call: assertion `DBUS_IS_G_PROXY (proxy)' failed aborting... gdm[4021]: ******************* START ********************************** ptrace: Operation not permitted. No stack. gdm[4021]: ******************* END ********************************** Version-Release number of selected component (if applicable): gdm-2.91.92-1.fc15 How reproducible: Always. Steps to Reproduce: 1. Boot system. 2. Enter user info. Actual results: GDM disappears but the screen stays black until after a few seconds GDM reappears. Expected results: GNOME session is started successfully. Additional info: None.
Created attachment 482961 [details] Log file of GDM greeter
Downgrade to gdm-2.91.91-1.fc15.x86_64 allows to log in successfully.
gdm-2.91.93-1.fc15.x86_64 exhibits same behavior
Created attachment 483204 [details] gdm backtrace Summary ... ******************* START ********************************** [Thread debugging using libthread_db enabled] 0x00007f88baf4607e in __libc_waitpid (pid=2020, stat_loc=0x7fffde9803bc, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:32 32#011 return INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL); #0 0x00007f88baf4607e in __libc_waitpid (pid=2020, stat_loc=0x7fffde9803bc, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:32 #1 0x000000000040ddcb in crashlogger_get_backtrace () at gdm-signal-handler.c:196 #2 gdm_signal_handler_backtrace () at gdm-signal-handler.c:223 #3 0x000000000040e10a in signal_handler (signo=<optimized out>) at gdm-signal-handler.c:251 #4 signal_handler (signo=<optimized out>) at gdm-signal-handler.c:232 #5 <signal handler called> #6 0x00007f88babd02c5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #7 0x00007f88babd1bdb in abort () at abort.c:92 assertion `%s' failed", args1=0x7fffde980e88) at gmessages.c:557 #9 0x00000031eb24ba52 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:577 #10 0x00000031efa13713 in dbus_g_proxy_call (proxy=0x0, method=0x31eda09bac "SetLanguage", error=0x7fffde981108, first_arg_type=64) at dbus-gproxy.c:2585 #11 0x00000031eda0567f in act_user_set_language () from /usr/lib64/libaccountsservice.so.0 #12 0x0000000000406d7d in gdm_session_settings_save (settings=0x1c07c40, username=<optimized out>) at gdm-session-settings.c:355 #13 0x0000000000408661 in save_account_details_now (worker=0x1c0f800) at gdm-session-worker.c:2104 #14 0x000000000040a2f8 in do_save_account_details_when_ready (worker=0x1c0f800) at gdm-session-worker.c:2150 #15 state_change_idle (worker=0x1c0f800) at gdm-session-worker.c:2258 #16 0x00000031eb242bcd in g_main_dispatch (context=0x1c0c7a0) at gmain.c:2440 #17 g_main_context_dispatch (context=0x1c0c7a0) at gmain.c:3013 #18 0x00000031eb2433a8 in g_main_context_iterate (context=0x1c0c7a0, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3091 #19 0x00000031eb2439ed in g_main_loop_run (loop=0x1c0eb40) at gmain.c:3299 #20 0x0000000000405458 in main (argc=1, argv=0x7fffde981588) at session-worker-main.c:203
*** Bug 683419 has been marked as a duplicate of this bug. ***
*** Bug 683411 has been marked as a duplicate of this bug. ***
*** Bug 683360 has been marked as a duplicate of this bug. ***
*** Bug 683323 has been marked as a duplicate of this bug. ***
rpm -q gsettings-desktop-schemas ?
I can't speak for Joachim, but on my system that appears to exhibit the same problem ... # rpm -q gsettings-desktop-schemas gsettings-desktop-schemas-2.91.91-1.fc15.noarch
(In reply to comment #9) # rpm -q gsettings-desktop-schemas gsettings-desktop-schemas-2.91.91-1.fc15.noarch
#10 0x00000031efa13713 in dbus_g_proxy_call (proxy=0x0, method=0x31eda09bac "SetLanguage", error=0x7fffde981108, first_arg_type=64) at dbus-gproxy.c:2585 proxy=0x0 doesn't look good. let me look into it.
to be sure, everyone here is running accountsservice-0.6.5-1.fc15 ?
Fully updated I had 0.6.4-3.fc15 - I pulled 0.6.5-1.fc15 from koji, upgraded, and I can log in now.
halfline, Since that update had negative karma until a few seconds ago, I don't know how you'd expect us to have gotten it through the normal F15 updates: https://admin.fedoraproject.org/updates/accountsservice-0.6.5-1.fc15,gdm-2.91.93-1.fc15?_csrf_token=0888285b48a27c71cc76eb648d2196a7b1361276 Anyway, I did fetch and install it from a console using links and it didn't address the issue. Through a combination of killing accounts-daemon and restarting GDM, I was able to finally get gdm to proceed to the rest of the session launch phase. So, 0.6.5-1 is still broken.
Same here - with both gdm-2.91.93-1.fc15 and accountsservice-0.6.5-1.fc15(from koji) no crashes, I can login as well.
(In reply to comment #15) > Since that update had negative karma until a few seconds ago, I don't know how > you'd expect us to have gotten it through the normal F15 updates: > https://admin.fedoraproject.org/updates/accountsservice-0.6.5-1.fc15,gdm-2.91.93-1.fc15?_csrf_token=0888285b48a27c71cc76eb648d2196a7b1361276 Well, you're hitting this bug at all then you're using updates-testing (which isn't effected by negative karma)... > Anyway, I did fetch and install it from a console using links and it didn't > address the issue. Through a combination of killing accounts-daemon and > restarting GDM, I was able to finally get gdm to proceed to the rest of the > session launch phase. oh, okay good. > So, 0.6.5-1 is still broken. not sure i'm following... You installed the update, killed the buggy accounts daemon, started the new hopefully-not-buggy accounts daemon and things started working right?
Issue resolved by upgrading to accountsservice-0.6.5-1.fc15.
(In reply to comment #17) > not sure i'm following... You installed the update, killed the buggy accounts > daemon, started the new hopefully-not-buggy accounts daemon and things started > working right? No, sorry I wasn't clear. I updated, rebooted and gdm was still bailing out at the gdmpassword check step. Killing accounts-daemon repeatedly has worked around its brokenness a few times in the past few weeks so I tried that again and it worked on the third attempt. I was in a hurry so I didn't gather more details but I can do so in a bit when I can reboot that machine again.
I can confirm that after updating to the accountservices packages from koji, the login problem is fixed. Next to figure out how to get rid of the idiotic 'Activities' junk that has taken over the place of a usable window manager.
(In reply to comment #19) > I was in a hurry so I didn't gather more details but I can do so in a bit when > I can reboot that machine again. Turns out there's two different issues in gdm .92/.93 and killing accounts-daemon has nothing to do with login actually succeeding. I filed the second bug with a trace as bug 683577. So, it seems that the accounts-daemon 0.6.5-1 RPM from koji does fix this bug.
*** Bug 679053 has been marked as a duplicate of this bug. ***
FWIW, I have gsettings-desktop-schemas-2.91.91-1.fc15.noarch as well.
*** Bug 683742 has been marked as a duplicate of this bug. ***
Considering this fixed then.