Bug 890444
Summary: | unable to unlock screen on F18 Beta | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nicholas Schuetz <nick> |
Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | cwawak, david.balazic, i4uyadav, msauton, rstrode, stephent98, tako |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-02-05 14:13:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Nicholas Schuetz
2012-12-27 00:36:15 UTC
An observation regarding this bug... This seems to happen when i have virt-manager running on the host. 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. 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 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. 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 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 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 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 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. (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 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. |