Red Hat Bugzilla – Bug 896633
Password entry dialog does not appear when screen is locked for 15+ min - VirtualBox related
Last modified: 2014-02-05 10:03:54 EST
Description of problem:
When I leave my laptop locked for a longer period (my current estimate is more than 15 minutes) the password entry dialog does not appear after I have slided up the screensaver screen that is displayed as of F18.
Currently I have to turn off the laptop with the on/of switch and reboot to have a working environment again.
Version-Release number of selected component (if applicable):
Name : gnome-screensaver
Arch : x86_64
Version : 3.6.1
Release : 1.fc18
Size : 1.1 M
Repo : installed
Summary : GNOME Screensaver
URL : http://www.gnome.org
License : GPLv2+
Description : gnome-screensaver is a screen saver and locker that aims to have
: simple, sane, secure defaults and be well integrated with the
By locking the laptop and leaving it unattended for at least 15 minutes
Steps to Reproduce:
2.Leave unattended for 15 minutes
3.Slide up "screensaver screen"
Normal behavior is that the "unlock screen" appears after sliding up the screensaver screen. When the problem occurs only a black screen appears.
Also entering the password "in the blind" does not unlock the screen.
"Unlock screen" appears so password can be entered and system is unlocked
Currently none. If more info is required please let me know.
Today I encountered the same issue again.
In an attempt to see whether I could stop the screensaver "manually" I entered a terminal using <Ctrl>-<Alt>-<F2> and logged in.
However, I could not find a running process that I could relate to the screensaver. What I did come across is the following (result of "ps -ef | grep watch-log):
root 808 1 0 09:36 ? 00:00:00 /usr/bin/abrt-watch-log -F BUG corruption stack overflow protection fault WARNING: at nable to handle ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed INFO: possible recursive locking detected : nobody cared IRQ handler type mismatch /var/log/messages -- /usr/bin/abrt-dump-oops -xD
root 809 1 0 09:36 ? 00:00:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD
I have no idea whether or not it is related to this issue but it seemed better to provide the info than to withold it.
Today I encountered the same issue again, however it ONLY seems to happen when I have a VirtualBox image also open. Today I had Win7 running in VBox when the issue re-appeared.
Hopefully this helps in reproducing the error.
I created a clone of this report as I'm not sure it is exactly the same problem, and its against Fedora 17.
The bug is at https://bugzilla.redhat.com/show_bug.cgi?id=910456
(In reply to comment #3)
> I created a clone of this report as I'm not sure it is exactly the same
> problem, and its against Fedora 17.
> The bug is at https://bugzilla.redhat.com/show_bug.cgi?id=910456
I am also not sure if this is the same problem.
When faced with the issue again today I have tried the workaround as described by you in bug #910456 (change terminal and login as root etc).
In my case there is no gnome-screensaver and/or gnome-screensaver-dialog process.
Furthermore it only seems to happen when I have a virtual machine (VBox) running. So far I have not been able to reproduce it without VBox open.
Anyway thanks for jumping in and sharing your info.
Am I correct in assuming that the currently implemented "workaround" is that when VirtualBox is running the screen no longer gets locked?
At least I noticed that currently I get the message that an application prevents locking.
Today I had locked my laptop using <Ctrl>+<Alt>+L and when I came back after a while I experienced not exactly, but a similar issue.
Although the password box appeared I could not enter any my password.
I was able to work around the issue by selecting "Login as another user" and then just login as myself again.
Is there any information I can provide to help determine the cause of this incident?
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
Thank you for reporting this bug and we are sorry it could not be fixed.