I built a Rawhide live image for testing with today's packages, 2013-07-10. Among other bugs, I noticed that, once the screen lock kicks in, you don't seem to be able to escape it. Hitting 'Esc' shows the unlock dialog with "Authentication failure" showing under the password entry; whatever you try and do there, you can't get out of it. In F19, hitting Esc simply takes you right back to the desktop. At the time I try to unlock, I see these messages in journalctl: Jul 10 20:10:44 localhost dbus-daemon[541]: dbus[541]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' Jul 10 20:10:44 localhost dbus[541]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' Jul 10 20:10:44 localhost systemd[1]: Starting Fingerprint Authentication Daemon... Jul 10 20:10:44 localhost dbus-daemon[541]: dbus[541]: [system] Successfully activated service 'net.reactivated.Fprint' Jul 10 20:10:44 localhost dbus[541]: [system] Successfully activated service 'net.reactivated.Fprint' Jul 10 20:10:44 localhost systemd[1]: Started Fingerprint Authentication Daemon. Jul 10 20:10:44 localhost fprintd[1604]: Launching FprintObject Jul 10 20:10:44 localhost fprintd[1604]: ** Message: D-Bus service launched with name: net.reactivated.Fprint Jul 10 20:10:44 localhost fprintd[1604]: ** Message: entering main loop Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: (gnome-shell:1245): Gjs-WARNING **: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No sessions for liveuser available for reauthentication Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: ShellUserVerifier<._reauthenticationChannelOpened@/usr/share/gnome-shell/js/gdm/util.js:254 Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: wrapper@/usr/share/gjs-1.0/lang.js:213 Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: (gnome-shell:1245): Gjs-WARNING **: JS ERROR: TypeError: this._userVerifier is undefined Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: ShellUserVerifier<._verificationFailed@/usr/share/gnome-shell/js/gdm/util.js:436 Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: wrapper@/usr/share/gjs-1.0/lang.js:213 Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: ShellUserVerifier<._reportInitError@/usr/share/gnome-shell/js/gdm/util.js:249 Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: wrapper@/usr/share/gjs-1.0/lang.js:213 Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: ShellUserVerifier<._reauthenticationChannelOpened@/usr/share/gnome-shell/js/gdm/util.js:265 Jul 10 20:10:44 localhost /etc/gdm/Xsession[928]: wrapper@/usr/share/gjs-1.0/lang.js:213 Proposing as a Final blocker at least for F20; this can easily get you stuck half way through an install (if you just leave the install running, screen lock tends to kick in).
Saw this on my running desktop today, where my user does have a password...
Ping? Ignore c#1 (that was https://bugzilla.gnome.org/show_bug.cgi?id=704884 I think), this bug is still happening in current Rawhide and is kinda bad. It would be good to have it fixed for Alpha.
Are you still seeing this ?
If the login state for the user is in "closing" then it is probably: https://bugs.freedesktop.org/show_bug.cgi?id=67273 So we'd need the following in systemd: commit 76e665855edef5b7103cb09d114377d477bfae02 Author: Lennart Poettering <lennart> Date: Fri Jul 26 18:59:46 2013 +0200 logind: update the session state file before we send out the CreateSession() reply https://bugs.freedesktop.org/show_bug.cgi?id=67273 If not then the above is not relevant
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
mclasen: I just got back from vacation, I'll try and remember to check this tomorrow.
Looks good in Alpha RC4, hitting esc from the blank screen takes me back to the desktop. Also works fine if I manually 'lock' the screen.