Bug 1002464 - cannot unlock gnome lock screen
cannot unlock gnome lock screen
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
RejectedBlocker AcceptedFreezeException
: Reopened
Depends On:
Blocks: F20AlphaBlocker F20AlphaFreezeException
  Show dependency treegraph
 
Reported: 2013-08-29 05:14 EDT by Mike FABIAN
Modified: 2016-08-17 23:27 EDT (History)
32 users (show)

See Also:
Fixed In Version: systemd-206-11.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1098740 (view as bug list)
Environment:
Last Closed: 2014-07-10 00:56:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cannot-unlock-lock-screen.ogv (1.71 MB, video/ogg)
2013-08-29 05:14 EDT, Mike FABIAN
no flags Details
Output of 'journalctl -a' (881.66 KB, text/x-log)
2013-09-04 07:24 EDT, Petr Schindler
no flags Details
journalctl -af (8.89 KB, text/plain)
2014-07-09 15:15 EDT, llarevo
no flags Details

  None (edit)
Description Mike FABIAN 2013-08-29 05:14:50 EDT
Created attachment 791654 [details]
cannot-unlock-lock-screen.ogv

Installation of Fedora 20 TC2 (netinstall) in qemu using:

    ionice -c 3 qemu-kvm -enable-kvm -m 2048M -smp 4 -drive file=./Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2-output.log -name Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2 -cdrom /local/mfabian/iso/Fedora-20-Alpha-TC2/Fedora-20-Alpha-TC2-x86_64-netinst.iso -boot c -spice port=6000,disable-ticketing -vga cirrus -display vnc=:4 -net nic -net user,hostname=Fedora-20-Alpha-TC2-x86_64-netinst.iso.qcow2,hostfwd=tcp::5556-:22 -monitor stdio -usb

- Installation in Japanese
- everything else default
- in gnome-initial-setup, I removed the non-existing "anthy"
  input method and added "Kanji Kana" (kkc), everything else
  default
- after first login into gnome, type ESC to close the introduction
  video
- close browser
- open a gnome-terminal
- lock the screen by using the menu item at the top right
  (see attached video) or wait until the lock screen starts
  automaticall (behaviour is the same)

Now the lock screen cannot be unlocked anymore.

It flickers and says "Authentication failure" all the time
(認証エラー). One cannot type more than one letter into the
password entry field, then it is apparently already tested
as a password, which fails. As if something hits the "Unlock" button
or presses the ENTER key automatically.
Comment 1 Flóki Pálsson 2013-08-29 19:32:24 EDT
This is also on bare metal. 
Ctrl + Allt + F2
and 
Ctrl + Allt + F1
helps
Comment 2 Petr Schindler 2013-09-04 07:24:46 EDT
Created attachment 793622 [details]
Output of 'journalctl -a'
Comment 3 Petr Schindler 2013-09-04 07:25:20 EDT
This happens after boot before another session is started.

Reproducer:
1. boot f20 gnome and log in
2. lock the screen
3. try to unlock

It tries to authenticate the user and fails. If another session is open (for example some virtual console) it start to work fine.

You can find output of journalctl -a in comment 2
Comment 4 Dethlef Madsen 2013-09-05 14:42:25 EDT
ack: tested with Fedora-Live-Desktop-i686-20-Alpha-TC4.iso 05-Sep-2013 03:51

real hardware, no VM

ctrl+alt+f2 and ctrl+alt+f1 still helps
Comment 5 Michele Baldessari 2013-09-08 06:49:56 EDT
If the login state for the user is in "closing" then it is probably:
https://bugs.freedesktop.org/show_bug.cgi?id=67273

So we'd need the following in systemd:
commit 76e665855edef5b7103cb09d114377d477bfae02
Author: Lennart Poettering <lennart@poettering.net>
Date:   Fri Jul 26 18:59:46 2013 +0200

    logind: update the session state file before we send out the CreateSession() reply
    
    https://bugs.freedesktop.org/show_bug.cgi?id=67273
Comment 6 Fedora Update System 2013-09-09 06:46:08 EDT
systemd-206-11.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-206-11.fc20
Comment 7 Fedora Update System 2013-09-09 12:22:52 EDT
Package systemd-206-11.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-206-11.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-16167/systemd-206-11.fc20
then log in and leave karma (feedback).
Comment 8 Kamil Páral 2013-09-09 12:49:25 EDT
Discussed at 2013-09-09 blocker review meeting [1]. This was rejected as a blocker and accepted as a freeze exception for Alpha. While this doesn't violate any of the F20 alpha release criterion, it is a rather ugly problem that's easy to hit. A tested fix would be considered past freeze.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-09/
Comment 9 Robert Lightfoot 2013-09-09 15:57:11 EDT
systemd-206.11 resolves this bug, but as of 9/9/2013 had not propagated to the mirrors.  I had to direct download it from koji.
Comment 10 Kamil Páral 2013-09-10 04:36:50 EDT
When I updated to systemd-206.11 the unlock screen started to work correctly. No other issues seen.
Comment 11 Martin Krizek 2013-09-10 04:47:56 EDT
Confirming that systemd-206.11 fixes the issue.
Comment 12 Parag Nemade 2013-09-11 01:04:04 EDT
confirm this finally fixed the gnome screen lock.
Comment 13 Fedora Update System 2013-09-13 23:09:07 EDT
systemd-206-11.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 robertcrews432 2013-12-28 18:01:39 EST
I am experiencing the identical problem with the "general availability" Fedora 20 installed from Live Media on real hardware (not a VM). Arch: x86_64. No modifications, except I added packages tigervnc, tigervnc-server, emacs, wget from yum. Movie from original post shows exactly what I am seeing, except my UI is English. Following the discussion above, I have systemd 208.9.fc20. Can no longer install 206.11 since the updates-testing repo also has 208.9.fc20. The ctl+alt+f2 and ctrl+alt+f1 work-arounds described above do not work for me.
Comment 15 Mark C. Edwards 2013-12-28 23:37:16 EST
Confirming the problem on the f20 x86_64 (real hardware). Update applied 12-28 caused the lock screen authentication to fail on two different x86_64 machines. The ctl-alt-f2 fails. Was able to login as root and shutdown.
systemd-libs-208-9.fc20.x86_64, systemd-208-9.fc20.x86_64
is the installed version.
Comment 16 Brad Smith 2013-12-31 18:09:48 EST
I just updated to F20 from F19 using fedup. If I lock the desktop, I cannot unlock.

systemd-208-9.fc20.x86_64
Comment 17 Brad Smith 2014-01-01 11:17:16 EST
(In reply to Brad Smith from comment #16)
> I just updated to F20 from F19 using fedup. If I lock the desktop, I cannot
> unlock.
> 
> systemd-208-9.fc20.x86_64

I have to retract this assertion. Screen unlock started to work. The only change made to the system other than normal yum updates was the deletion of virtually all systemd journal files from FC19.
Comment 18 robert.piro 2014-01-10 10:08:18 EST
I cannot unlock either 

      systemd-208-9.fc20.x86_64

I am not sure as to why the bug has been changed to CLOSED ERRATA. The bug is UNSOLVED! There is no fix/update provided by F20.
Comment 19 robertcrews432 2014-01-11 15:09:32 EST
I ran sudo yum update today and saw package names that might bear on this problem. After completing the update, I rebooted -- not sure if that was needed -- and verified the problem is resolved for me. Here are the updates that I think did it:

Jan 11 10:12:37 Updated: 1:NetworkManager-openvpn-0.9.8.2-4fc20.x86_64
Jan 11 10:12:50 Updated: 1:NetworkManager-openvpn-gnome-0.9.8.2-4fc20.x86_64
Comment 20 Dario Izzo 2014-01-24 04:36:16 EST
I made a fresh install of fedora 20 (x86_64), then I installed 

sudo yum -y install tigervnc-server
vncpasswd
Password:# input
Verify:# confirm

vncserver :4 -geometry 1024x768 -depth 24
sudo systemctl stop firewalld.service (this is not ideal but just to make my point)

From my windows machine I then use togherVN (or ultraVNC) to connect to the screen. If locked I cannot login as the unlock button seems to be pressed automatically several time a second (so I do not have time to enter the password)

This seems to be the same bug here reported and it does not look as its solved.
Comment 21 yurifun 2014-04-27 12:53:18 EDT
I also can not unlock my desktop, until find blog with workaround.
http://blog.mornati.net/fedora-18-cant-unlock-the-screen/

When i add "fs.inotify.max_user_watches=100000" into /etc/sysctl.d/inotify.conf my problem go away.

This is the kernel parameter, perhaps gdm or systemctl watches more than 8192 files (this is default value).
Comment 22 Eric 2014-05-09 10:45:39 EDT
I also can not unlock my gnome-session. I am VNCing into a fully updated Fedora 20 box, running a vnc server on a virtual display, :1. The symptoms are exactly the same as described before.

I can however vnc onto my :0 display and unlock it, but it seems to be using a different UI than what spawns with vncserver. But let me be clear, I am still using gnome shell with vncserver:1.
Comment 23 james labocki 2014-06-23 12:44:47 EDT
This is happening again with systemd-208-16.fc20.x86_64 - reopening.
Comment 24 Adam Williamson 2014-06-24 01:30:41 EDT
This bug was closed a long time ago, it was a fairly specific bug in systemd that was pretty clearly addressed. I think re-opening the report is more confusing than helpful; I doubt the problem you're seeing now is actually caused by the same code problem as the initial reports from 2013. Can someone please file a new bug with clear steps to reproduce? Thank you.
Comment 25 Aurelien GUERSON 2014-06-25 06:55:22 EDT
Same problem

Fedora 20 x86_64

systemd-208.17.fc20.x86_64


A new bug report here :
https://bugzilla.redhat.com/show_bug.cgi?id=1112982

Regards
Comment 26 Aurelien GUERSON 2014-06-25 07:10:23 EDT
The patch seems to be here :

https://bugzilla.gnome.org/attachment.cgi?id=278429
Comment 27 Aurelien GUERSON 2014-06-25 07:14:02 EDT
Sorry I did a mistake.

not for the good bug :)
Comment 28 Keith 2014-06-30 14:06:22 EDT
(In reply to Aurelien GUERSON from comment #26)
> The patch seems to be here :
> 
> https://bugzilla.gnome.org/attachment.cgi?id=278429

How do you apply this patch?
Comment 29 Aurelien GUERSON 2014-07-01 03:40:42 EDT
Sorry, bad copy/paste, I said I did a mistake. This patch is for this bug :

https://bugzilla.gnome.org/show_bug.cgi?id=729246 :(
Comment 30 llarevo 2014-07-09 15:13:46 EDT
I confirm the bug on a headless F20 installation.

Access is done via x0vncserver and Vinagre, following http://www.janbambas.cz/headless-fedora-20-and-vnc-with-autologin

Deleting all journallogs as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1002464#c17 doesn't help for me.

Yum is supersuper slow since fedup from F19, but this probably another issue. My journalctl -af output when trying to unlock is attached.
Comment 31 llarevo 2014-07-09 15:15:47 EDT
Created attachment 916924 [details]
journalctl -af

For comment #30
Comment 32 llarevo 2014-07-09 15:20:57 EDT
Sorry wrong bug. I posted also in the new bug https://bugzilla.redhat.com/show_bug.cgi?id=1112982
Comment 33 Adam Williamson 2014-07-10 00:56:05 EDT
I think we can probably close this report again at this point, since we have the new one. To me it does look, from the logs, like the issues the new reporters are hitting are different.
Comment 34 Ritesh Dhandha 2014-09-23 13:29:06 EDT
best workaround would be just remove gnome screensavers
or move to KDE

yum remove gnome-screesa*

that should take care of it.
Comment 35 ruslan133 2014-11-05 04:24:17 EST
)) best workaround would be just remove fedora ? or not ?
fedora and centos it-s one root-system? but centOS not have this bug.
Comment 36 Yang Xiang 2016-03-02 08:10:30 EST
Fedora 22 also had the error when the os was in screen saver or locking mode, even if I have used "dnf update -y".
Comment 37 jumanji 2016-08-17 11:44:21 EDT
Sadly, this bug is not fixed, nor should it be an "errata." It reflects failure to perform basic top-level functionality. For example, I just installed FC24 on a new machine and see this problem. I installed server, then added gnome after the fact via dnf, as in "dnf install gnome". It manifests in several ways, where some may be related:

1. The lockscreen does not recognize the user password. I disabled the lockscreen, but it is astonishing that gnome can't get this basic functionality right after all these years.

2. I am unable to confirm as the administrator when I need to do something that requires elevated privileges. For example, when I click on the "unlock" icon to set the time/date, I see a dialog that asks for the Administrator password. It...doesn't...work. If gnome asks me for the Admin password and I put in the correct Admin password, it should recognize i

3. Finally, gnome apparently cannot correctly handle the return key as the default for the accept button in pw dialogs.  When trying to log in to gnome as a regular user after running systemctl "gdm.service start", I type my password and have to click the button for it to work. If I type the password and hit the return key, it doesn't work.

I have done a number of google searches and nothing solves these problems for me. It's a huge pain. Also, it's surprising that gnome's password problems have been ongoing for such a long time (years) and are still present in the current release (although a gnome problem, not a redhat problem). Gnome is simply not usable when basic pw functionality doesn't work.  Also, if the bug was supposedly fixed in the past, why isn't it staying fixed? Is there some fundamental process problem relating to source management, multiple editors or stale packages that are propagating into installs or dev systems?
Comment 38 Adam Williamson 2016-08-17 11:55:05 EDT
see comment #24. just because a bug's subject matches your symptom does not mean it's the same bug. This bug report properly a specific issue in systemd three years ago. That bug does not exist any more.

what you're seeing is not remotely normal; I don't know what's going on in your case, but it does not affect all systems. In typical installations all of the things you describe work fine. Please open a new bug, with more details on your specific installation of Fedora.
Comment 39 jumanji 2016-08-17 19:14:24 EDT
Thanks for the reply. I appreciate that perspective. I would love to see gnome implement bullet-proof, intuitive password support (I assumed that's what it had and I was unpleasantly surprised). And, I am not saying that my reported problems affect all systems. But, if it's not remotely normal, then from my user perspective, it probably shouldn't be happening on a Fedora 24 server dvd iso clean install to a new/blank drive on a new mobo build with dnf-added gnome. Maybe I did something wrong, but not intentionally, nor did I do anything that seemed abnormal. At a glance, same problem or not, the gnome screen lock pw problems go as far back as 2008, the admin pw problem goes back to at least 2014 and maybe earlier.

Happy to open a new bug, but as of today, I have stopped trying to use gnome. It has been a huge time sink and I do not feel confident that the problem will be fully resolved given the long history of similar problems. And, I'm out of time. Screen lock doesn't work on a new install??? When functionality breaks over and over, it's either time to look at the development/deployment process, the development team or how the functionality is being architected, implemented and integrated into the OS. Maybe there are vestigial packages that are being pulled, maybe it's not receiving the right focus, maybe it's hampered by legacy code and needs to be rewritten from scratch, etc. 

Anyway - I will report and hope someone can fix it for good.
Comment 40 Adam Williamson 2016-08-17 19:17:43 EDT
I suspect your problem may boil down to 'dnf-added gnome'. What did you run exactly? The best way to install GNOME if you don't install Workstation out of the box is 'dnf groupinstall workstation-product-environment'. If you installed a smaller group, or just did 'dnf install gnome-shell' and relied on dependencies or something like that, it could explain the problem.
Comment 41 jumanji 2016-08-17 22:45:51 EDT
Thanks for the additional info.

I think I did dnf groupinstall gnome. I definitely did not install workstation-product-environment. Before using dnf, I went back to the FC24 installer to try to amend the install with the installer, but based on my experience, the FC24 installer has many UX issues and could not recognize an active install to amend (I guess my modern OS/installer expectations need re-scoping). So, I used dnf.

Also, if this is the source of the problem, then it should be easy to reproduce and someone there can fix the install dependencies so that gnome functions properly when installed. I can also try adding the workstation-product-environment, but I was trying to avoid a lot of extra stuff, I was just trying to get gnome. Too late now, I guess. I have also moved past that point, since I have installed KDE and switcher, etc. But, for what it's worth, I'll give it a try.

And, if dnf-related, maybe it points to my comment above re: development/deployment process.  If gnome has dependencies that are required for correct function, then they should be included in the dependency list no matter how gnome is installed. Alternately, if the recommended install is for workstation-product-environment, then deprecate direct gnome installs and generate dnf text to tell the user what they need to do. Or, coordinate fixes for gnome so that it is capable of working in a minimal install (may speak to implementation/integration issues).
Comment 42 jumanji 2016-08-17 22:55:17 EDT
dnf group list -v environment shows nothing available in the default x86_64 repos/fedora cache containing the word environment and using workstation-product-environment also does not work.
Comment 43 jumanji 2016-08-17 23:09:50 EDT
groupinstall (or install @workstation-product-environment) worked, even though not found in the repos.
Comment 44 jumanji 2016-08-17 23:27:56 EDT
follow-ups in the new bug...the problem(s) remain:
https://bugzilla.redhat.com/show_bug.cgi?id=1367955

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