Hide Forgot
Description of problem: Sometimes, but not always, when trying to unlock a locked station, the prompt disappears (application crashes?!), and I'm unable to unlock the station. Regretfully, I have no idea which component is in charge of that, nor where can I find logs for this. Direct me to the right location and I'll provide logs. Version-Release number of selected component (if applicable): gnome-screensaver-3.2.0-1.fc16.x86_64 gnome-session-3.2.1-1.fc16.x86_64 gnome-shell-3.2.1-1.fc16.x86_64 How reproducible: Sometimes. Steps to Reproduce: 1. Lock workstation 2. Go drink coffee 3. Come back to the workstation - sometimes the unlock password prompt disappears and you can't unlock the station. Actual results: Expected results: Additional info:
I've found that even though the dialog isn't visible, I can still type in my password and unlock the screen.
Jeff pointed out that bz#748779 is likely related; a potentially relevant piece of information from that bug is that this seems to occur on multiple-monitor setups. Certainly, I see it with multiple monitors, though I also find that dialog box is occasionally visible for me -- likely indicating a race condition somewhere. Jeff, Yaniv, do you have multiple monitors? Does the issue go away if you only use one?
I use two displays, and disabling the secondary display using the nVidia control panel seems to fix the issue. With both displays active I either get black screens or what appear to be partially drawn screens but in either case there is no feedback that it's accepting the keyboard input (although it does accept the password). I have noticed at times that it actually displays what was on the screen when the display was locked which could be a potential security issue. With one display active I see the normal unlock dialog on top of the wallpaper/background image and it seems to function normally. I have a fully patched Fedora 16 x86 system with a nVidia GTX 580 running the kmod-nvidia 290.10 driver on the 3.1.5-6.fc16.i686.PAE kernel.
The good news is that after updating, this problem seems to have been fixed! The bad news is that the update didn't go very well; X was segfaulting on startup after I rebooted. I ended up doing "yum remove kmod-nvidia*" and then "yum install kmod-nvidia-PAE" and that seemed to fix everything after rebooting.
Perhaps I spoke too soon. It seems that the unlock dialog appears if you lock the screen via the session menu (on the upper right) and then immediately unlock it. However if you leave the system alone and allow it to lock itself and power down the screen, it does not appear. I see a big black box, much larger than the unlock dialog, against my desktop background image.
possible duplicate: https://bugzilla.redhat.com/show_bug.cgi?id=816506 possibly related: https://bugzilla.redhat.com/show_bug.cgi?id=748560
I'm seeing something similar: Screenshot after suspend/resume: http://imgur.com/qnO5b Possible duplicates from my searching: https://bugzilla.redhat.com/show_bug.cgi?id=748779 https://bugzilla.redhat.com/show_bug.cgi?id=840542 https://bugzilla.redhat.com/show_bug.cgi?id=828952 I think this is only multi monitor, and the "blue" section seems to be related to the relative sizes of each monitor. Doesn't seem to happen if I just lock the screen, or suspend and immediately resume, but seems to happen most days when I come to work after having the laptop suspended over night.
*** Bug 840542 has been marked as a duplicate of this bug. ***
Description of problem: I have a dual monitor setup with an Nvidia Quatro Card (580). I am using the open source driver that came with fedora 17. I am using the Gnome desktop. When I lock the desktop, and come back to login the screen to the left is completely light blue with the right side is completely black. The Right side has the gnome tool bar but no login box. The bug does not appear on single monitor setups.
Desktop = Levono E20
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
hang on, what?! I saw this on F17. But I can't edit the field myself. So if I see on F17 a bug that someone else saw on F16, my only recourse is to CLONE the bug?!
I see something very similar with gnome-shell-3.6.2-6.fc18.x86_64. The screen shows a black/dark gray background (not the Spherical Cow theme), and the title bar suggests that GNOME Shell is still in a locked state. But no password prompt appears. I remember that the dialog did not appear when I pressed Esc, I actually had to sweep with the mouse. This is on a ThinkPad X220, with an external screen.
This has happened to be again. This time, I create a core file using gcore. I don't want to upload it because I don't know what's in it, but I'm certainly willing to help digging for the cause.
(In reply to comment #15) > This has happened to be again. This time, I create a core file using gcore. > I don't want to upload it because I don't know what's in it, but I'm > certainly willing to help digging for the cause. At least upload the backtrace.
Created attachment 688989 [details] GDB backtrace Requested backtrace from the core file
I'm having a similar on my HP Pavillon DV5-2060BR notebook. Sometimes when resuming from suspend, I can't unlock the machine. When things work as they should, I just simply tap the "Enter" key and enter my password to unlock the computer. I know that something is wrong when I have to use the mouse to bring the password dialog up - tapping the "Enter" key has no effect. In this case, I can enter the password into the password dialog but nothing happens - I always get the dark grey screen as if my screen was still locked. The machine is not fully locked up; Ctrl-Alt-F2 gives me a login prompt, from where I can kill the gnome processes and then log in back again. Anyway, I see no process(es) giving core dumps and the abort daemon does not show nothing.
I have this problem to reproduce: Boot computer to gnome login. Press altf2 and login as root. Do some things for a few minutes. Press altf1 to get back to gnome. You can see the screen fade out sometimes and the login or unlock screen ends up with no text boxes. Sometime the fade out is not seen but it still ends up with no text boxes. I am using winbind logins with pam_mount smb homes and have re-enabled the logout button in gnome in 64 bit fedora 18 if that helps.
Actually I've just tried this on a fresh fedora 18 64bit install: Boot computer to gnome login. Press altf2 and login as root. Do yum update. After some time, press altf1 to get back to gnome. You can see the screen fade out sometimes and the login or unlock screen ends up with no text boxes. My hardware is hp 8100 elite with added nvs quadro 290 graphics (dual head but only one monitor)
FWIW, I haven't had any problems since upgrading to Fedora 18. The lock screen now has the "window shade" pull up style and it works every time.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.