Bug 1569211 - GDM fails first login attempt after reboot
Summary: GDM fails first login attempt after reboot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 28
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: PrioritizedBug https://fedoraproject....
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-18 19:45 UTC by David Dreggors
Modified: 2018-05-12 17:01 UTC (History)
29 users (show)

Fixed In Version: gnome-shell-3.28.1-3.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-01 07:43:08 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Journalctl log showing auth failure (1.67 KB, text/plain)
2018-04-18 19:45 UTC, David Dreggors
no flags Details
Seahorse screenshot (345.85 KB, image/png)
2018-04-26 15:52 UTC, Jonathan Haas
no flags Details

Description David Dreggors 2018-04-18 19:45:34 UTC
Created attachment 1423716 [details]
Journalctl log showing auth failure

Description of problem:
After every reboot the first login attempt fails. At first I assumed I was mistyping the password. Then I started slowly pressing one key at a time to confirm and it still failed. Same pass on all subsequent tries works, even after locking screen.


Version-Release number of selected component (if applicable):
gdm-3.28.1-1.fc28.x86_64


How reproducible:
Every time

Steps to Reproduce:
1. Reboot laptop
2. Select User
3. Enter Password
4. Hit Enter or Click button

Actual results:
Login fails on first try


Expected results:
Login succeeds when correct password is entered

Additional info:
This is an upgrade from Fedora 27

Comment 1 David Dreggors 2018-04-21 00:38:09 UTC
Some extra info...

I have noticed that this does actually happen after I lock my screen as well.

I noticed one more possibly important fact. If I type characters (any number of characters) of the password in GDM login screen and then backspace to delete them all... then type in the password and press enter... it works.

So assume my password is 'MyPass!' (hypothetically), I type 'M' then backspace to delete that character then proceed to type 'MyPass!' it will then allow me to log in on the first attempt. Or... I type 'MyPass!' on first attempt (no backspace trick) and it fails... then type 'MyPass!' on second attempt... it works then too.

This seems very much like the first character is somehow entered wrong, but then just the act of deleting it and retyping it, or entering the password a second time it is entered correctly. Maybe libinput issue or similar?

Comment 2 Thomas Müller 2018-04-25 04:34:08 UTC
Same here on two different F28 systems.

Comment 3 Fedora Blocker Bugs Application 2018-04-26 02:29:05 UTC
Proposed as a Blocker for 28-final by Fedora user ddreggors using the blocker tracking app because:

 Fails basic functionality without user intervention. GDM cannot login on first attempt without trying a second time.

Comment 4 Adam Williamson 2018-04-26 03:42:58 UTC
Haven't seen this in any of my F28 tests so far.

Comment 5 Adam Williamson 2018-04-26 03:43:45 UTC
When you say "Select User", how do you do that exactly?

Comment 6 Adam Williamson 2018-04-26 03:45:39 UTC
Also, what keyboard layout do you use?

Comment 7 Thomas Müller 2018-04-26 04:39:35 UTC
After reboot there is a list of users. As I'm the only user I just press "enter" after which I'm asked to enter my password.

However, as the same issue also arises after locking the session, I don't think the user selection has anything to do with this.

I use a German keyboard layout.

Comment 8 sumantro 2018-04-26 06:18:55 UTC
I can't reproduce this. I tried regular en-US and upgraded from F27 to F28 without any issues. I have also checked it for root/created user across X and Wayland.

Comment 9 Jonathan Haas 2018-04-26 08:00:23 UTC
Can't reproduce with installation updated from F27 and German keyboard layout.

Comment 10 Kamil Páral 2018-04-26 08:53:47 UTC
David, Thomas, this is just a wild guess, but can you try the workaround mentioned in here?
https://fedoraproject.org/wiki/Common_F27_bugs#every-second-login-fails

I.e. try to use X11 session instead of Wayland session, and see if "auto-save-session" value is true or not. Thanks.

Comment 11 Parag Nemade 2018-04-26 11:17:18 UTC
Well I have somewhat similar thing to report here. Since I upgraded to Fedora 28, whenever screen gets locked out and I return back to unlock it, my first attempt after entering correct password fails (I kept blaming myself for wrong developed muscle memory) but after seeing this bug, I thought to report here.

This is consistent for me. The first attempt to unlock screen failed most times(may be I can say it always failed). But second attempt always succeeds.

I also already have gsettings get org.gnome.SessionManager auto-save-session -> false.

Comment 12 Paul W. Frields 2018-04-26 11:48:03 UTC
Can't reproduce this on any of my F28 systems.

Comment 13 Stephen Gallagher 2018-04-26 12:30:59 UTC
I cannot reproduce this either.

I'm inclined to vote -1 blocker on the following grounds:
1) Once this is identified, it can be resolved with an update
2) Most users would default to assuming they'd mistyped the first time and re-enter their password.

Comment 14 Matthew Miller 2018-04-26 13:11:28 UTC
-1 blocker for reasons Stephen notes (along with "can't reproduce" comments).

Comment 15 Jonathan Haas 2018-04-26 14:30:33 UTC
Those who experience the bug, can you right click on the password field and click "Show Text" (or whatever it is in your language) after entering the password for the first time to see if that matches what you're typing?

Comment 16 Thomas Müller 2018-04-26 14:45:18 UTC
(In reply to J. Haas from comment #15)
> Those who experience the bug, can you right click on the password field and
> click "Show Text" (or whatever it is in your language) after entering the
> password for the first time to see if that matches what you're typing?

Interesting... it appears to ignore the shift-key, i.e. a small letter is always entered.

Theory: Everybody who was not able to reproduce this uses a small letter at the beginning of his/her password?

Comment 17 Stephen Gallagher 2018-04-26 15:00:29 UTC
(In reply to Thomas Müller from comment #16)
> (In reply to J. Haas from comment #15)
> > Those who experience the bug, can you right click on the password field and
> > click "Show Text" (or whatever it is in your language) after entering the
> > password for the first time to see if that matches what you're typing?
> 
> Interesting... it appears to ignore the shift-key, i.e. a small letter is
> always entered.
> 
> Theory: Everybody who was not able to reproduce this uses a small letter at
> the beginning of his/her password?

I can actually now reproduce this (and yes, the shift is initially ignored) when attempting to enter a password for my GPG key using the GNOME askpass dialog (starts with a capital letter).

So I'd say the above theory seems likely. That's... quite a catch.

I'm still -1 blocker on it for the reasons above, but we should try to fix this as quickly as possible.

Comment 18 Thomas Müller 2018-04-26 15:07:03 UTC
Are there any use cases where the askpass dialog is also used to set a *new* password somewhere?
If yes and the same behavior applies there users are going to be frustrated if they can't use their password later on as the first letter is not what they would expect it to be.

Comment 19 Parag Nemade 2018-04-26 15:21:17 UTC
Thanks J. Haas, I also confirm its an issue with shift key. It ignores shift-key usage at the first time and if I backspace before completing password and retype my password, it works.

Comment 20 Adam Williamson 2018-04-26 15:23:04 UTC
I still can't reproduce this in a fresh install to a VM, FWIW. I installed from the RC-1.1 Workstation live, created user Test with password Test in gnome-initial-setup on first boot, and was able to log in first time both on the initial appearance of GDM after g-i-s was complete, and after a reboot. The 'show text' option shows that I truly did type 'Test'.

Stephen, how did you reproduce this exactly?

Comment 21 Adam Williamson 2018-04-26 15:24:04 UTC
Oh, I *can* reproduce the case for the lock screen, though. Dunno why I see that one but not the GDM one.

Comment 22 Stephen Gallagher 2018-04-26 15:25:42 UTC
(In reply to Adam Williamson from comment #21)
> Oh, I *can* reproduce the case for the lock screen, though. Dunno why I see
> that one but not the GDM one.

Yeah, I was about to say that: I can repro it on lock screen and askpass, but I didn't see it happen at GDM. Not sure why.

My running hypothesis is that we inherited this with the gtk3 rebase we pulled in for FE, since I am pretty sure I didn't see it before I updated yesterday (and I have had the -testing repos disabled since we entered Freeze).

Comment 23 Adam Williamson 2018-04-26 15:26:20 UTC
"Are there any use cases where the askpass dialog is also used to set a *new* password somewhere?"

The only case I can think of where it might happen is timed password expiry, we could test that.

Comment 24 Michael Catanzaro 2018-04-26 15:28:17 UTC
-1 blocker, this can be fixed post-release

Comment 25 Stephen Gallagher 2018-04-26 15:29:04 UTC
(In reply to Adam Williamson from comment #23)
> "Are there any use cases where the askpass dialog is also used to set a
> *new* password somewhere?"
> 
> The only case I can think of where it might happen is timed password expiry,
> we could test that.

Adam: I think this would already be covered by automated testing for https://fedoraproject.org/wiki/QA:Testcase_FreeIPA_password_change or am I mistaken?

Comment 26 Matthew Miller 2018-04-26 15:30:37 UTC
I'm definitely reconsidering my -1. If we can verify that it's just the first attempt and just the lockscreen/askpass, a zero-day would probably be okay.
      
I'll weight Michael Catanzaro and other Workstation team members' opinions on this heavily — if they're not going to be embarrassed, I'll try not to be. :)

Comment 27 Jonathan Haas 2018-04-26 15:37:27 UTC
I can verify that this also happens in the "create keyring" dialog in Seahorse when setting a password for the keyring. It's not a huge problem, as you need to enter the password twice and the problem only happens in the topmost password box, but it's definitely annoying.

Comment 28 Mathieu Bridon 2018-04-26 15:42:07 UTC
I've actually seen this about a year ago.

I had upgraded from Fedora Workstation 26 to 27. I don't remember whether this happened to me before the upgrade, but it certainly happened after.

I remember that it was happening a bit before GUADEC, so I'd figure I'd try and find someone there to fix it.

It stopped happening right before GUADEC, when I reinstalled my machine. (the day I was supposed to take the plane, I run an unfortunate `rm -rf /` and had to reinstall and restore my data from backup)

So I guess this isn't a recent regression, but something old which just doesn't happen for most people?

Comment 29 Michael Catanzaro 2018-04-26 15:48:19 UTC
(In reply to Matthew Miller from comment #26)
> I'm definitely reconsidering my -1. If we can verify that it's just the
> first attempt and just the lockscreen/askpass, a zero-day would probably be
> okay.
>       
> I'll weight Michael Catanzaro and other Workstation team members' opinions
> on this heavily — if they're not going to be embarrassed, I'll try not to
> be. :)

I think we should try to fix it ASAP, of course. But if we have a zero-day update, then users will hopefully only hit this bug once or twice at most, in which case they probably won't even notice.

(In reply to J. Haas from comment #27)
> I can verify that this also happens in the "create keyring" dialog in
> Seahorse when setting a password for the keyring. It's not a huge problem,
> as you need to enter the password twice and the problem only happens in the
> topmost password box, but it's definitely annoying.

OK, that changes everything. I have two thoughts on this:

 (a) Most of seahorse is already super broken and has been for a long time, that's why we don't install it anymore
 (b) That's a GTK+ dialog

(b) is very significant because up until now, all the reported password entries were gnome-shell: that's why I reassigned the bug to gnome-shell. Now you're saying this affects GTK+ as well, right? I just tested with seahorse, and the password entry was a normal GTK+ dialog drawn by seahorse itself, not the black overlay that gnome-shell draws when it asks for your password? That's *really* seriously weird; it's hard to imagine what could break password entry in two unrelated toolkits. Maybe ibus?

Comment 30 Michael Catanzaro 2018-04-26 15:50:28 UTC
(In reply to Michael Catanzaro from comment #29)
>  (a) Most of seahorse is already super broken and has been for a long time,
> that's why we don't install it anymore

(BTW please keep this in mind: seahorse is no longer on the live image. We actually had a presentation at GUADEC a couple years ago that was all about how almost all of the menu items and dialogs were broken. Please don't consider seahorse at all when making a blocker determination.)

Comment 31 Jonathan Haas 2018-04-26 15:52:58 UTC
Created attachment 1427284 [details]
Seahorse screenshot

I'm not sure Seahorse uses a GTK+ dialog, it draws the black shadow and so on.

Here I entered "Test" in both password boxes, but it ignored the first shift key press.

Comment 32 Stephen Gallagher 2018-04-26 15:55:22 UTC
(In reply to Michael Catanzaro from comment #29)
> (In reply to Matthew Miller from comment #26)
> > I'm definitely reconsidering my -1. If we can verify that it's just the
> > first attempt and just the lockscreen/askpass, a zero-day would probably be
> > okay.
> >       
> > I'll weight Michael Catanzaro and other Workstation team members' opinions
> > on this heavily — if they're not going to be embarrassed, I'll try not to
> > be. :)
> 
> I think we should try to fix it ASAP, of course. But if we have a zero-day
> update, then users will hopefully only hit this bug once or twice at most,
> in which case they probably won't even notice.
> 
> (In reply to J. Haas from comment #27)
> > I can verify that this also happens in the "create keyring" dialog in
> > Seahorse when setting a password for the keyring. It's not a huge problem,
> > as you need to enter the password twice and the problem only happens in the
> > topmost password box, but it's definitely annoying.
> 
> OK, that changes everything. I have two thoughts on this:
> 
>  (a) Most of seahorse is already super broken and has been for a long time,
> that's why we don't install it anymore
>  (b) That's a GTK+ dialog
> 
> (b) is very significant because up until now, all the reported password
> entries were gnome-shell: that's why I reassigned the bug to gnome-shell.
> Now you're saying this affects GTK+ as well, right? I just tested with
> seahorse, and the password entry was a normal GTK+ dialog drawn by seahorse
> itself, not the black overlay that gnome-shell draws when it asks for your
> password? That's *really* seriously weird; it's hard to imagine what could
> break password entry in two unrelated toolkits. Maybe ibus?


I just tested this and it is NOT using the GTK+ dialog, it's using the GNOME Shell dialog. I'm not sure when that changed, but I hope that information is less alarming.

Comment 33 Michael Catanzaro 2018-04-26 16:02:11 UTC
(In reply to J. Haas from comment #31)
> Created attachment 1427284 [details]
> Seahorse screenshot
> 
> I'm not sure Seahorse uses a GTK+ dialog, it draws the black shadow and so
> on.
> 
> Here I entered "Test" in both password boxes, but it ignored the first shift
> key press.

Yeah, that's the gnome-shell prompt. OK, less alarming indeed.

Well, still bad, but more understandable.

Comment 34 Jonathan Haas 2018-04-26 16:34:52 UTC
You actually kinda can reproduce this outside of gnome-shell password prompts. If you manage to exit a gnome-shell password prompt while a standard GTK textfield already is focused, and then you try to directly type uppercase text, it will ignore the shift key press.

You can easily reproduce that with the Seahorse dialog I took a screenshot of, but I also managed to reproduce it with a password prompt in Nautilus.

Comment 35 Jared Smith 2018-04-26 18:48:26 UTC
This also appears to affect the "unlock" dialog in Gnome Control Panel, for what it's worth.

Comment 36 David Dreggors 2018-04-27 17:47:46 UTC
(In reply to Adam Williamson from comment #6)
> Also, what keyboard layout do you use?

Sorry I just saw this, I use English (US) keyboard layout. Also, by select user I meant on GDM login screen where you see your user (or others if they exist), I click myself if not already highlighted.

I added this info late I know, it seems there has been much movement on this bug and much has been discovered. Again, sorry for late reply.

Comment 37 David Dreggors 2018-04-27 17:53:02 UTC
(In reply to Thomas Müller from comment #16)
> (In reply to J. Haas from comment #15)
> > Those who experience the bug, can you right click on the password field and
> > click "Show Text" (or whatever it is in your language) after entering the
> > password for the first time to see if that matches what you're typing?
> 
> Interesting... it appears to ignore the shift-key, i.e. a small letter is
> always entered.
> 
> Theory: Everybody who was not able to reproduce this uses a small letter at
> the beginning of his/her password?

To confirm, I do use a capital letter as first character.

I would like to also remind all here that I was able to backspace after typing first character on first login attempt, then retype it and the shift key works (capital letter is entered this time).

Comment 38 Adam Williamson 2018-04-27 20:55:46 UTC
This also affects other modifiers - I've just realized, because it affects pasting passwords into the password prompt :( This will affect everyone who uses a password manager, when they go to enter e.g. an ssh key via the ssh-askpass integration. Hitting 'ctrl-v' just gives you a 'v'. Just like with the 'shift' case, hitting backspace and then ctrl-v again works, or it works on the second attempt.

Comment 39 fujiwara 2018-04-27 21:56:13 UTC
I cannot reproduce the problem.
Did you install the latest mutter & gnome-shell?

Comment 40 Adam Williamson 2018-04-27 22:05:38 UTC
Lots of people have reproduced this so far, I don't think it's plausible to claim that the bug doesn't exist at this point. Yes, everyone is testing with the latest gnome-shell and mutter, in fact we think 3.28.1 actually *introduced* this bug. Multiple GNOME devs have already reproduced this and are discussing how to fix it, e.g. in this log from #fedora-desktop:

<garnacho> https://gitlab.gnome.org/GNOME/mutter/merge_requests/97 is for the password thing btw, root cause pending, but that's enough to fix it
<halfline> garnacho: nice
<halfline> hmm
<halfline> so that code got added here it seems: https://bugzilla.gnome.org/show_bug.cgi?id=725102
<halfline> and in that bug it says this: "switching the keymap
<halfline> should be done at a time when no key is currently pressed down, but let's leave that task to higher level code"
<garnacho> yeah, quite fishy that it changes while typing stuff, it's clearly not due to the focus change
<halfline> it's the same keymap again ?
<garnacho> in essence yes
<garnacho> maybe some explicit keymap change to cater for per-window IM -> clutter focus changes?
<garnacho> I guess that mention in the code is there for the situations where you shuffle modifier keys around
<garnacho> but hardly stands true with <super>space :/
<garnacho> s/in the code/in the bug/
<halfline> well your patch makes sense to me on the surface. i wish rtcm was here
<halfline> i wonder if it's from InputSourceManager's _keyboardOptionsChanged or from activateInputSource
<halfline> i guess if activating the input source is async and it happens on focus in that might explain it
* halfline tries adding some logs
<garnacho> halfline: not sure it's simply that. I've been trying with a polkit dialog, and took my time before typing
<garnacho> it's somehow sent around the same time shift is pressed
<garnacho> but yeah, ideally the keymap shouldn't even change :)
<halfline1> i was working on adding some backtrace dumpping to InputSource activate but had to run to a meeting

Comment 41 Carlos Garnacho 2018-04-29 15:15:36 UTC
(In reply to Adam Williamson from comment #40)
> Lots of people have reproduced this so far, I don't think it's plausible to
> claim that the bug doesn't exist at this point. Yes, everyone is testing
> with the latest gnome-shell and mutter, in fact we think 3.28.1 actually
> *introduced* this bug.

FWIW, 3.28.1 *re*introduced this bug, because 3.28.0 had other bug that prevented this in the first place on the most common setups. This seems to stem in untimely changes to the org.gnome.desktop.input-sources.sources dconf key that reset current modifier state.

My wild guess is that those actually come from ibus, but gnome-shell can protect itself from those, I opened https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/91 about it.

Comment 42 Fedora Update System 2018-04-29 23:25:57 UTC
gnome-shell-3.28.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f1989df398

Comment 43 Adam Williamson 2018-04-29 23:27:16 UTC
I backported the fix to Rawhide and F28 and submitted an update for F28. Thanks, Carlos. Can folks affected by this test and see if the update fixes it for you? Thanks!

Comment 44 Thomas Müller 2018-04-30 11:22:30 UTC
So far gnome-shell-3.28.1-3.fc28 is looking good. :)

Comment 45 David Dreggors 2018-04-30 15:08:06 UTC
This does not yet appear in updates-testing, should it?

Comment 46 Michael Catanzaro 2018-04-30 15:12:47 UTC
(In reply to David Dreggors from comment #45)
> This does not yet appear in updates-testing, should it?

Not yet. There will be an automated comment on this bug when it reaches testing.

Comment 47 Adam Williamson 2018-04-30 15:25:28 UTC
In the meantime you can download it direct from Koji for testing, the update page has a link through to the Koji build - https://koji.fedoraproject.org/koji/buildinfo?buildID=1077605

Comment 48 Adam Williamson 2018-04-30 16:21:17 UTC
Discussed during F28 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-04-26/f28-final-go-no-go-meeting.2018-04-26-17.02.txt . It was generally felt that, while this is clearly a serious bug, it's not actually going to significantly inconvenience people during install boot and install of Workstation: even if they hit it they'll likely just assume they mis-typed, and type their password again, and it will work. Beyond that, it can be fixed with an update. Thus, this was rejected as a blocker.

Comment 49 Fedora Update System 2018-04-30 19:54:22 UTC
gnome-shell-3.28.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f1989df398

Comment 50 Fedora Update System 2018-05-01 07:43:08 UTC
gnome-shell-3.28.1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 51 Christian Stadelmann 2018-05-12 11:14:59 UTC
I am still seeing this or a related bug. With gnome-shell 3.28.1-3.fc28 installed, every text I type is using the english (US) keyboard layout in gdm, no matter what keyboard layout I configured. Switching the layout at runtime does not change anything. I have 3 layouts configured (de: neo, de: nodeadkeys, us). GDM always uses the last one no matter which one I configure.

On any tty and within any Gnome session, keyboard layouts behave correctly, using the default de:neo keyboard layout.

This looks like bug #1573923 to me.

Comment 52 Michael Catanzaro 2018-05-12 17:01:05 UTC
(In reply to Christian Stadelmann from comment #51)
> This looks like bug #1573923 to me.

I think the fix for this bug introduced that one.


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