Bug 890444 - unable to unlock screen on F18 Beta
Summary: unable to unlock screen on F18 Beta
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 18
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-27 00:36 UTC by Nicholas Schuetz
Modified: 2014-02-05 14:13 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 14:13:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Nicholas Schuetz 2012-12-27 00:36:15 UTC
Fedora 18 Beta, Current patch level (as of 12/26/2013)

I've encountered this with both on my desktop and laptop after updating last Friday.

To replicate:

1.  Install F18. Update to current patch level.

2.  Log into a gnome sessions, puts around, open a terminal, do some general work, then walk away and let it lock.

3.  When you return, you will be unable to hit ESC and get the password(un-lock) prompt.  You will have to use the mouse the swipe the screen up to have access to the password prompt underneath.  

4.  Now, enter your password.  It attempts to load your session again, however, it hangs.

5.  The only solution is to ctrl+alt+f2, then login as root and then kill your user's 'gnome-session' process.  

6.  Then hit ctrl+alt+f1 to get back in (This will reload your gnome shell but all of your apps that were running before will be there, like eclipse, etc..)


Versions:
[nick@desktop ~]$ rpm -qa |grep gnome-shell
gnome-shell-3.6.2-6.fc18.x86_64

[nick@desktop ~]$ rpm -qa |grep gnome-screensaver
gnome-screensaver-3.6.1-1.fc18.x86_64

[nick@desktop ~]$ rpm -qa |grep gdm
pulseaudio-gdm-hooks-2.1-4.fc18.x86_64
gdm-3.6.2-5.fc18.x86_64
gdm-libs-3.6.2-5.fc18.x86_64

[nick@desktop ~]$ rpm -qa |grep systemd
systemd-195-13.fc18.x86_64
systemd-libs-195-13.fc18.x86_64
systemd-sysv-195-13.fc18.x86_64

Comment 1 Nicholas Schuetz 2013-01-24 00:32:31 UTC
An observation regarding this bug...  This seems to happen when i have virt-manager running on the host.

Comment 2 Nicholas Schuetz 2013-01-24 19:57:55 UTC
Ok, i've definitely confirmed that this only occurs when virt-manager is up and i have an active console open for a VM.  I think gnome-shell is having issues grabing control of the keyboard/mouse when in a locked state.

Comment 3 Steve Tyler 2013-01-24 21:44:37 UTC
Confirmed with an F18 host and qemu-kvm[1].

It looks like the VM mouse grab prevents gdm from fully unlocking the display. If you move your pointer outside the VM window and wait until the display locks, does the problem occur?

Test procedure:

Configure the display to lock after 1 minute to speed testing.
Start a VM using a Live image.[2]
Move the pointer into the VM window and check that the VM is grabbing mouse events.
Wait more than 1 minute for the host display to lock.
Press escape.
The clock window is displayed, but pressing escape does not result in the gdm login dialog being displayed.

Recover by switching to a console (ctrl-alt-f2), logging in as root, and restarting the display manager:
# systemctl restart display-manager

[1] # rpm -q qemu-kvm gdm gnome-shell
qemu-kvm-1.2.2-3.fc18.x86_64
gdm-3.6.2-5.fc18.x86_64
gnome-shell-3.6.2-6.fc18.x86_64

[2] $ qemu-kvm -m 2048 -cdrom ~/xfr/fedora/F18/F18-Final/Final/Fedora-18-x86_64-Live-Desktop.iso -vga vmware

Comment 4 Thomas Neuber 2013-02-13 19:53:37 UTC
My observation regarding this bug are slightly different.

* virt-manager was never installed on the affected machine.
* qemu-kvm was installed on that machine, but the behavior is still the same after uninstallation of that package.
* I use VMware Workstation 9 instead. The problem encounters on the local display even if the virtual machines are used from a remote location via VMware Workstation Server. I can reproduce the problem still after shutting the vmware daemons down. Therefore I believe, it is not related to virtualization.
* The problem encounters if a menu of a gnome application is open. I can reproduce it using nautilus and opening the menu by clicking on the gear wheel.

Comment 5 Steve Tyler 2013-02-15 04:50:47 UTC
Thanks for your report, Thomas.

I can confirm that simply leaving a menu displayed until the screen locks reproduces this bug. My test case is the help menu in gnome-terminal.

gdm-3.6.2-5.fc18.x86_64
gnome-shell-3.6.2-6.fc18.x86_64
gnome-terminal-3.6.1-1.fc18.x86_64
systemd-197-1.fc18.1.x86_64

Comment 6 Marc Sauton 2013-02-27 00:48:11 UTC
Have a similar situation, with F18 as a KVM guest on a RHEL 6 KVM host, but using a vncviewer to reach that F18 system remotely, provides the vnc pwd if used, and then it seem impossible to unlock the screen in the vncviewer and gnome session, was able to use the esc key a few times to get the prompt, and then no more response, or seem to hang after the account password is provided to unlock, had to kill that gnome session from another ssh connection, and later disabled the lock feature, test env.:

uname -a ; rpm -q gdm gnome-shell gnome-terminal systemd tigervnc-server gtk-vnc2
Linux ca1.example.com 3.7.9-201.fc18.x86_64 #1 SMP Mon Feb 18 21:07:56 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
gdm-3.6.2-5.fc18.x86_64
gnome-shell-3.6.3-2.fc18.x86_64
gnome-terminal-3.6.1-1.fc18.x86_64
systemd-197-1.fc18.1.x86_64
tigervnc-server-1.2.80-0.8.20130124svn5036.fc18.x86_64
gtk-vnc2-0.5.1-5.fc18.x86_64

Comment 7 Christopher Wawak 2013-04-30 01:41:43 UTC
Same here, Lenovo t420s, and after putting in the unlock password, just hangs there. Have to kill gnome-shell. If it helps, in this state, when I hit caps lock, the light does toggle on and off.

Linux hostname 3.8.8-203.fc18.x86_64 #1 SMP Wed Apr 24 13:12:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
gdm-3.6.2-5.fc18.x86_64
gnome-shell-3.6.3.1-1.fc18.x86_64
gnome-terminal-3.6.1-2.fc18.x86_64
systemd-197-1.fc18.2.x86_64
package tigervnc-server is not installed
gtk-vnc2-0.5.2-1.fc18.x86_64

Comment 8 David Balažic 2013-12-14 23:06:39 UTC
I jut installed Fedora-Live-Desktop-x86_64-19-1.iso (Fedora 19, the default download ISO) into VirtualBox 4.3.4 (the latest) on Windows 8.1.

I started the Software Update app and the after a while the screen locked.

I can not enter the password. As if the input field were dead. I can navigate to the Cancel button by using TAB or click it with the mouse. Then the lock screen appears (with the clock) again.

Workaround: SIGHUP the gnome-shell process

Comment 9 Fedora End Of Life 2013-12-21 10:05:46 UTC
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.

Comment 10 Dharmendra yadav 2014-01-27 05:04:55 UTC
(In reply to Nicholas Nachefski from comment #0)
> Fedora 18 Beta, Current patch level (as of 12/26/2013)
> 
> I've encountered this with both on my desktop and laptop after updating last
> Friday.
> 
> To replicate:
> 
> 1.  Install F18. Update to current patch level.
> 
> 2.  Log into a gnome sessions, puts around, open a terminal, do some general
> work, then walk away and let it lock.
> 
> 3.  When you return, you will be unable to hit ESC and get the
> password(un-lock) prompt.  You will have to use the mouse the swipe the
> screen up to have access to the password prompt underneath.  
> 
> 4.  Now, enter your password.  It attempts to load your session again,
> however, it hangs.
> 
> 5.  The only solution is to ctrl+alt+f2, then login as root and then kill
> your user's 'gnome-session' process.  
> 
> 6.  Then hit ctrl+alt+f1 to get back in (This will reload your gnome shell
> but all of your apps that were running before will be there, like eclipse,
> etc..)
> 
> 
> Versions:
> [nick@desktop ~]$ rpm -qa |grep gnome-shell
> gnome-shell-3.6.2-6.fc18.x86_64
> 
> [nick@desktop ~]$ rpm -qa |grep gnome-screensaver
> gnome-screensaver-3.6.1-1.fc18.x86_64
> 
> [nick@desktop ~]$ rpm -qa |grep gdm
> pulseaudio-gdm-hooks-2.1-4.fc18.x86_64
> gdm-3.6.2-5.fc18.x86_64
> gdm-libs-3.6.2-5.fc18.x86_64
> 
> [nick@desktop ~]$ rpm -qa |grep systemd
> systemd-195-13.fc18.x86_64
> systemd-libs-195-13.fc18.x86_64
> systemd-sysv-195-13.fc18.x86_64

Comment 11 Fedora End Of Life 2014-02-05 14:13:03 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.