Bug 1002464

This is also on bare metal. 
Ctrl + Allt + F2
and 
Ctrl + Allt + F1
helps

Created attachment 793622 [details]
Output of 'journalctl -a'

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

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

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>
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

systemd-206-11.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-206-11.fc20

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).

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/

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.

When I updated to systemd-206.11 the unlock screen started to work correctly. No other issues seen.

Confirming that systemd-206.11 fixes the issue.

confirm this finally fixed the gnome screen lock.

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.

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.

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.

I just updated to F20 from F19 using fedup. If I lock the desktop, I cannot unlock.

systemd-208-9.fc20.x86_64

(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.

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.

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

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.

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).

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.

This is happening again with systemd-208-16.fc20.x86_64 - reopening.

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.

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

The patch seems to be here :

https://bugzilla.gnome.org/attachment.cgi?id=278429

Sorry I did a mistake.

not for the good bug :)

(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?

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 :(

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.

Created attachment 916924 [details]
journalctl -af

For comment #30

Sorry wrong bug. I posted also in the new bug https://bugzilla.redhat.com/show_bug.cgi?id=1112982

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.

best workaround would be just remove gnome screensavers
or move to KDE

yum remove gnome-screesa*

that should take care of it.

)) best workaround would be just remove fedora ? or not ?
fedora and centos it-s one root-system? but centOS not have this bug.

Fedora 22 also had the error when the os was in screen saver or locking mode, even if I have used "dnf update -y".

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?

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.

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.

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.

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).

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.

groupinstall (or install @workstation-product-environment) worked, even though not found in the repos.

follow-ups in the new bug...the problem(s) remain:
https://bugzilla.redhat.com/show_bug.cgi?id=1367955