Pre Mga3 alpha2 Gnome - tested i586 with livecd and dvd install After the screen locks through inactivity and goes to the fullscreen clock it is impossible to unlock. You can slide the clock out of the way and enter a password but it doesn't actually unlock. The 'Unlock' button goes slightly more grey than it was before. Locking from the menu allows unlocking and logging out/in works OK. A few lines from auth.log https://dl.dropbox.com/u/4147101/mga3a2/DSC01084.JPG
CC: (none) => ennael1, mageia, mageia, tmb
Whiteboard: (none) => 3alpha2
CC: (none) => thierry.vignaudAssignee: bugsquad => olav
I think Blino fixed this one, but he said he still had a list of issues he was working through so will let him close it if needed.
So I just fixed something in dbus that caused (for me) a related issue. If you restart the systemd journal, then dbus would still have references to it's stdout and stderr pipes that were originally pushed to the journal. When the journal is restarted those pipes are lost. This is expected and is normally fine. The vast majority of services ignore SIGPIPE. Sadly when launching services via dbus, SIGPIPE would be turned back on again (as it was used internally in the fork in dbus-spawn). This meant that some services, e.g. fprintd which tried to output debug to stderr would then crash with SIGPIPE and fail. This caused the login screen on gnome-shell to not display a password dialog. Phew! Took a while to nail that one down. It's only because I've been hacking on the journal today to fix the memleak that I "clicked" that this was related. Probably nothing to do with the issue really reported here, but as it's related to unlocking generally I figured I may as well document it here! Upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=56043
*** Bug 7865 has been marked as a duplicate of this bug. ***
CC: (none) => jeffreybruton
Priority: Normal => release_blockerSummary: Mga3 alpha2 Gnome - Impossible to unlock the screen after it is locked through inactivity => Gnome - Impossible to unlock the screen after it is locked through inactivityWhiteboard: 3alpha2 => 3beta1
Is this really a problem still? I've never been able to reproduce this issue directly (lots of reasons why the unlock failed but they've all been detected and fixed and/or referenced upstream, in which case release-blocker status here seems overkill).
it is at least the case in the live yes
Does it use gdm+autologin? If so this is documented upstream behaviour (it requires gdm for the screen lock to work).
I don't know but blino or tmb should
This is still valid 3beta1 but not in the same way as originally reported in 3alpha2. Once the screen is locked through inactivity it asks for a password to unlock but doesn't accept an empty password (live session on live iso) or 'live'. It makes it impossible to unlock the screen.
Claire, do you happen to know if gdm is used on the live CD? (I've not got it handy to test, but a simple "ps aux | grep gdm" should suffice).
CC: thierry.vignaud => (none)
Looking in journalctl it gives an error. typed not pasted warning .. tcb_chkpwd[3603]: user unknown gnome-screensaver-dialog[3595]: pam_tcb(gnome-screensaver:auth): Authentication failed for live from live(uid=500) gnome-screensaver-dialog[3595]: gkr-pam: the password for the login keyring was invalid. not sure if this is relevant but just before these is another line. It isn't repeated on repeated login attempts though. dbus[903]: [system] Rejected send message, 5 matched rules; type="method_return", sender=":1.1" (uid=0 pid=900 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" requested reply="0" destination":1.26" (uid=500 pid=1839 comm="gnome-session ") The couple of trailing spaces are actually present in the message.
That returns nothing Colin
The KDE Live isos are also locking the screen instead of running a screensaver or blanking it. They probably shouldn't do this in live mode anyway. See bug 8353
Well, is this on first set of beta1 liveDVDs I'm not surprised... there was a package selection problem in meta-task wich I fixed only yesterday, so Gnome liveDVDs got half of KDE on them too, so they have GDM, KDM, XDM on them :/ and Mga defaults to kdm if both gdm and kdm is installed. Just look in /etc/sysconfig/desktop: DISPLAYMANAGER=kdm DESKTOP=GNOME :/ Anyway, I'll sort it out for next live media round
Taking the bug.
Status: NEW => ASSIGNEDAssignee: olav => tmb
Hmm, OK, thanks for the info Claire. Re: the "dbus:...Rejected..." message it appears to be harmless (I get it on my system too) but I want to nail down what causes it, just not had the motivation to go digging just yet - I'm sure I'll find it eventually tho' :) I wonder if "loginctl unlock-session X" would work (if run as root or as the live user) from a tty... doubt it would work under KDE, but perhaps (I've not looked at the patches applied there yet). Of course the fact that the KDE screensaver happily accepts a blank password means it's not needed there anyway. I can't see it being a problem with the gnome-screensaver pam.d file (it looks pretty simple), so perhaps there is some problem in the way blank passwords are handled in gnome? Either way, yes, we shouldn't even ask for a password, but all the same it would be nice to get it working with a blank password!
It does indeed Colin, loginctl shows uid 500 using session c1 loginctl unlock-session c1 then returning to vt1 it is unlocked
loginctl list-sessions rather shows c1, above
Interesting that it's "c1" rather than just "1". This indicates a PAM misconfiguration somewhere (not really "mis"configuration, but a "sub-optimal"configuration). I guess we're missing an include on the login_uuid pam module in our autologin setup...
I just tested with a gnome install using the x86-64 dvd. When the screen is locked, it ignores most key entries, but, if the enter key is pressed, then the lock screen with the clock displayed on it "scrolls up", revealing the gdm login screen, where you can enter the password to unlock the session. I think what's needed is either treating any key like the enter key, or adding instructions to the lock screen, indicating the enter key has to be pressed, before you can enter the password, to unlock the session.
CC: (none) => davidwhodgins
(In reply to comment #19) > I just tested with a gnome install using the x86-64 dvd. > > When the screen is locked, it ignores most key entries, but, > if the enter key is pressed, then the lock screen with the > clock displayed on it "scrolls up", revealing the gdm login > screen, where you can enter the password to unlock the session. This is just intended behaviour of the screen shield. Hitting escape or enter or dragging the screen up-words (as indicated by the animation) allows you to get to the login UI. Pressing any other key also makes the shield "bounce" to indicate it can be moved. I won't comment as to whether this is sensible or not, but it's that way by design. This is not what this bug is about tho'. I *think* that when used without gdm for login (which I believe is the case with the live CDs which use the autologin package), then the gnome-session cannot talk to gdm to do the authentication and unlock things, thus when locked, it stays locked. I've not specifically tested this recently tho', so not sure if this is all still true...
This bug is valid on a pre-3beta3 (11/12 Dec) Gnome installation from the classic installer dvd too. Once the screen has locked it can't be unlocked. This is with gdm, so the problem is not necessarily to do with autologin/kdm.
loginctl list-sessions shows session 2 uid 500 user claire rather than c1 as before. loginctl unlock-session 2 does unlock the session.
oh, sorry. It's a case of operator error. Please ignore comment 21 & comment 22 I noticed the caps-lock was on once I switched back to vt1! D'ohh! Just tested again and it's fine.
*** Bug 7986 has been marked as a duplicate of this bug. ***
Blocks: (none) => 8197
closing, as nobody seems to be able to reproduce again.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED