Hi all,
I'm seeing a similar error to what is described in https://bugzilla.redhat.com/show_bug.cgi?id=470740 Essentially, I have to enter my password 3 times on boot before my encrypted partitions unlock and I can boot, using graphical entry. If I hit Esc and enter at the text console, it seems to work on the first attempt (most of the time).
I have 3 encrypted partitions (/, /home, swap), but these don't seem to correspond to the number of times I have to enter. In other words, the behavior does not appear to be unlocking one partition at a time. After the first entry, it pauses a second, as if I've entered incorrectly (even though I haven't), and then the second entry errors out and resets the input field instantaneously, as if no attempt was made to unlock the drives. Then, the third entry works normally.
This is a recent issue for me, as I've had the same setup working across several of the last few Fedora releases. I've only seen this issue after upgrading to F26, and even then, it only appeared after some update (not sure when).
Does anybody have any suggestions on how to further troubleshoot this, or have any ideas why this is happening? Perhaps a more recent bug report which matches?
Any help would be appreciated, as this is quite annoying.
One interesting thing I noticed with this: if I hit "Backspace" a few times before typing the password, it seems to work on the first attempt. For some reason, something seems to be polluting the input buffer during boot, which makes it behave as a wrong password on the first attempt. Not sure what that could be. Also, I still have no idea why it requires two subsequent attempts after that to decrypt, instead of the expected one.
On Mon, Aug 28, 2017 at 3:13 AM Christopher ctubbsii@fedoraproject.org wrote:
Hi all,
I'm seeing a similar error to what is described in https://bugzilla.redhat.com/show_bug.cgi?id=470740 Essentially, I have to enter my password 3 times on boot before my encrypted partitions unlock and I can boot, using graphical entry. If I hit Esc and enter at the text console, it seems to work on the first attempt (most of the time).
I have 3 encrypted partitions (/, /home, swap), but these don't seem to correspond to the number of times I have to enter. In other words, the behavior does not appear to be unlocking one partition at a time. After the first entry, it pauses a second, as if I've entered incorrectly (even though I haven't), and then the second entry errors out and resets the input field instantaneously, as if no attempt was made to unlock the drives. Then, the third entry works normally.
This is a recent issue for me, as I've had the same setup working across several of the last few Fedora releases. I've only seen this issue after upgrading to F26, and even then, it only appeared after some update (not sure when).
Does anybody have any suggestions on how to further troubleshoot this, or have any ideas why this is happening? Perhaps a more recent bug report which matches?
Any help would be appreciated, as this is quite annoying.
On 08/28/2017 03:27 PM, Christopher wrote:
One interesting thing I noticed with this: if I hit "Backspace" a few times before typing the password, it seems to work on the first attempt. For some reason, something seems to be polluting the input buffer during boot, which makes it behave as a wrong password on the first attempt. Not sure what that could be. Also, I still have no idea why it requires two subsequent attempts after that to decrypt, instead of the expected one.
This may or may not be your issue. So, just something to consider.
A few years ago I had the same problem not with encrypted partitions but with the login at the GUI prompt (I was using KDM back then) after boot. I had to remember to hit backspace a few times otherwise it would tell me the password was wrong. I have a wireless USB keyboard and it turned out to be the problem with the USB receiver. Replacing that fixed the issue.
On 08/28/2017 05:16 PM, Ed Greshko wrote:
On 08/28/2017 03:27 PM, Christopher wrote:
One interesting thing I noticed with this: if I hit "Backspace" a few times before typing the password, it seems to work on the first attempt. For some reason, something seems to be polluting the input buffer during boot, which makes it behave as a wrong password on the first attempt. Not sure what that could be. Also, I still have no idea why it requires two subsequent attempts after that to decrypt, instead of the expected one.
This may or may not be your issue. So, just something to consider.
A few years ago I had the same problem not with encrypted partitions but with the login at the GUI prompt (I was using KDM back then) after boot. I had to remember to hit backspace a few times otherwise it would tell me the password was wrong. I have a wireless USB keyboard and it turned out to be the problem with the USB receiver. Replacing that fixed the issue.
Just a "funny" note here. I had to replace my keyboard due to "cat abuse". Unlike my old keyboard which had a dedicated power switch this one will go to sleep after a time. So, now I have to remember to hit any key if it has been idle for a time. The first key stroke only wakes up the keyboard and does not generate an event.
Ed Greshko:
Just a "funny" note here. I had to replace my keyboard due to "cat abuse". Unlike my old keyboard which had a dedicated power switch this one will go to sleep after a time. So, now I have to remember to hit any key if it has been idle for a time. The first key stroke only wakes up the keyboard and does not generate an event.
I never had much luck with my wireless keyboard. These days, on any keyboard, it's become a habit to toggle the caps lock before logging in, and watch for the login screen to give me the warning about the caps lock being on. It's also a reasonably safe key to press to wake up any screensavers.
On Tue, Aug 29, 2017 at 8:26 AM Ed Greshko ed.greshko@greshko.com wrote:
On 08/28/2017 05:16 PM, Ed Greshko wrote:
On 08/28/2017 03:27 PM, Christopher wrote:
One interesting thing I noticed with this: if I hit "Backspace" a few
times before
typing the password, it seems to work on the first attempt. For some
reason,
something seems to be polluting the input buffer during boot, which
makes it behave
as a wrong password on the first attempt. Not sure what that could be.
Also, I
still have no idea why it requires two subsequent attempts after that
to decrypt,
instead of the expected one.
This may or may not be your issue. So, just something to consider.
A few years ago I had the same problem not with encrypted partitions but
with the
login at the GUI prompt (I was using KDM back then) after boot. I had
to remember
to hit backspace a few times otherwise it would tell me the password was
wrong. I
have a wireless USB keyboard and it turned out to be the problem with
the USB
receiver. Replacing that fixed the issue.
Just a "funny" note here. I had to replace my keyboard due to "cat abuse". Unlike my old keyboard which had a dedicated power switch this one will go to sleep after a time. So, now I have to remember to hit any key if it has been idle for a time. The first key stroke only wakes up the keyboard and does not generate an event.
Well, I hope my issue is not a hardware problem. I don't want to replace my laptop right now. It does not "feel" like a hardware problem, though. For example, sometimes I can only type a few characters into the entry field before it stops accepting characters... before I finish typing my passphrase. It's as if the field is full of some other junk from some other systemd process (at the console, I've even seen service log messages printed into the space where I'm supposed to be typing my passphrase... but I don't know if this is simply another process printing to the same console, or if it's actually corrupting the input buffer). I have to backspace to completely delete everything in the input field before I can enter my passphrase.
It "feels" like it's a startup service problem... with some other background process barfing into STDIN, instead of waiting until after I unlock the disks. It still could be hardware... it would certainly explain the symptoms, but I have not had any other issues with the laptop's keyboard, and I really really "hope" it's not. Hope does not always match reality, though. :)
On Thu, Aug 31, 2017 at 9:44 PM, Christopher ctubbsii@fedoraproject.org wrote:
On Tue, Aug 29, 2017 at 8:26 AM Ed Greshko ed.greshko@greshko.com wrote:
On 08/28/2017 05:16 PM, Ed Greshko wrote:
On 08/28/2017 03:27 PM, Christopher wrote:
One interesting thing I noticed with this: if I hit "Backspace" a few times before typing the password, it seems to work on the first attempt.
Also seeing this, on a Dell Inspiron just upgraded to *F25* using dnf. (I'm a trailing-edge leading-edge guy.) My LUKS partition is lvm-managed and contains both root and home mounts, and I'm seeing two requests for password. That might be a red herring, though.
I also found that hitting backspace a few times (though no characters were showing in the password box) allowed me to log in successfully the first time. Also, at least once I noticed the first character didn't seem to display the password-mask dot, so perhaps the first character is being "lost" and hitting backspace is waking something up and giving focus to the dialog.
-
Christopher -
Ed Greshko -
Ed Greshko -
Ted Roche -
Tim