Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boot Password Fails Always When First Entry Was Incorrect #1740

Closed
Nekroze opened this issue Feb 11, 2016 · 21 comments
Closed

Boot Password Fails Always When First Entry Was Incorrect #1740

Nekroze opened this issue Feb 11, 2016 · 21 comments
Labels
C: other P: minor Priority: minor. The lowest priority, below "default." R: cannot reproduce Resolution: Attempts to replicate the problem have not been reliably successful enough to proceed. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.

Comments

@Nekroze
Copy link

Nekroze commented Feb 11, 2016

I have a consistent issue on my laptop using Qubes 3.1 RC2 where if I enter the boot up password (for an encrypted root file system) and type the password incorrect the first time, any following attempts to input the password (regardless of the password being correct or not) will not be accepted and will not progress to boot.

The only solution I have found is to reboot and type it in correctly the first time.

@andrewdavidwong
Copy link
Member

Are you still experiencing this issue on 3.1 (stable)? I am unable to reproduce it.

@Nekroze
Copy link
Author

Nekroze commented Apr 8, 2016

@axon-qubes I am still having the issue with the latest stable build I have installed.

Since you are unable to reproduce perhaps it is more specific to my configuration. I am using non UEFI booting and have Qubes installed on a BTRFS encrypted raid 0.

Let me know if I can provide any other information to help.

While this is technically a bug I can actually see it possible being useful, no HID based brute forcing will work because the first attempt failing causes all others to fail even if they are correct. But I don't like using a bug to (arguably) "enhance" security.

@andrewdavidwong
Copy link
Member

Since you are unable to reproduce perhaps it is more specific to my configuration. I am using non UEFI booting and have Qubes installed on a BTRFS encrypted raid 0.

Yes, it sounds like it probably has to do with one of those factors.

Let me know if I can provide any other information to help.

During the startup process, when you reach the grey screen with the Qubes logo where you usually enter your passphrase, press the Delete key to view the console. You can also enter your passphrase from this interface. See if you notice any helpful or relevant error messages through the startup process (especially after entering your passphrase incorrectly).

@Nekroze
Copy link
Author

Nekroze commented Apr 14, 2016

@axon-qubes: I get no errors or anything I would not expect after entering it wrong followed by correct, it just goes back to the prompt after entering it correctly or incorrectly. After entering it wrong one or two more times it says the crypto service for the root disk has failed and no longer will ask for passwords.

@andrewdavidwong
Copy link
Member

Maybe @marmarek can help.

@marmarek
Copy link
Member

Does it prompt for the same thing (when you switch to text prompt)? Or maybe second and next prompts are about different disk? Do you see any additional messages between prompts?
That may have something to do with RAID0 - for example it may try to use one of mirrored disk directly. That would be a bug obviously, but I'm just guessing.

@Nekroze
Copy link
Author

Nekroze commented Apr 18, 2016

@marmarek The second prompt is for the same disk. In between attempts (not including when the previously mentioned crypto fail message occurs) it just says "Started Forward Password Requests to Plymouth" which it prints 3 or 4 times each attempt before prompting for input once more.

@andrewdavidwong andrewdavidwong added T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. C: other P: minor Priority: minor. The lowest priority, below "default." and removed question labels May 19, 2016
@liilac
Copy link

liilac commented Jul 4, 2016

Could you take a photo of that output page?

@Nekroze
Copy link
Author

Nekroze commented Jul 6, 2016

@ileyd: My apologies but I have switched to using LVM rather than BTRFS for the RAID0 root which does not have this issue. Sadly I do not have any hard drives left to run a test install on and I need my primary laptop running perfectly over the next month or so for work.

If anyone else wants to try and replicate this I was using legacy/csm/bios booting on BTRFS raid0 for the root disk and the re-install that is not affected by this issue was the same except I used lvm2 (non thin) raid0 for the root disks and UEFI booting.

@Nekroze
Copy link
Author

Nekroze commented Sep 13, 2016

Having now upgraded to 3.2rc3 where I was unable to successfully get UEFI booting to work (worked fine on 3.1 but thats another issue) so I am now using legacy/csm/bios booting with the ssd's in BTRFS raid0 and I have noticed that this issue has returned. Can't test further right now but wanted to make it known that this still seems to be happening for me.

@andrewdavidwong
Copy link
Member

@Nekroze How about now? Are you still experiencing this issue?

@andrewdavidwong andrewdavidwong added the help wanted This issue will probably not get done in a timely fashion without help from community contributors. label Dec 23, 2016
@andrewdavidwong andrewdavidwong added this to the Far in the future milestone Dec 23, 2016
@Nekroze
Copy link
Author

Nekroze commented Dec 24, 2016

@andrewdavidwong Unfortunately my laptop has taken a long dirt nap. I have ordered a Librem 13 however it will not have the hardware configuration required to test this however it was still happening as of about a month ago.

@andrewdavidwong
Copy link
Member

In that case, since no one else has been able to reproduce this (as far as I'm aware), we'll close this one for now. If anyone experiences this in the future, let us know.

@jpouellet
Copy link
Contributor

jpouellet commented May 26, 2017

I've intermittently observed this as long as I can remember, even recently.

After reading #977, where @rustybird describes:

Normally, the disk password entered during the boot process is used to decrypt both the root partition and the swap partition.

But if a wrong password is entered initially, subsequent tries prompt separately for the root partition and the swap partion password, i.e. you have to enter the same password twice now. This can be observed by looking at the LUKS UUIDs in the console (after pressing to leave the plymouth splash screen) or the journal.

I now wonder if the behavior I've been observing is not in fact the requirement of typing the correct passphrase twice if I mis-type it the first time. My passphrase is quite long and complex, and I've noticed a correlation between bad ergonomic positioning of the angle of my laptop relative to my arms and the frequency of getting it wrong, meaning that if I type it wrong the first time, there's a good chance I'll get it wrong more than once afterwards. There have been times where I very carefully type the password and strongly suspect I typed it correctly, but did continue booting. Perhaps I did get it right and then it prompts again (without observable difference) for the swap partition?

Perhaps that's been the real issue all along?

@jpouellet
Copy link
Contributor

jpouellet commented May 26, 2017

FWIW I'm not using btrfs, as seemed to be related to #977.

@jpouellet
Copy link
Contributor

Potentially relevant: #1912 (comment) ?

@andrewdavidwong
Copy link
Member

I now wonder if the behavior I've been observing is not in fact the requirement of typing the correct passphrase twice if I mis-type it the first time. My passphrase is quite long and complex, and I've noticed a correlation between bad ergonomic positioning of the angle of my laptop relative to my arms and the frequency of getting it wrong, meaning that if I type it wrong the first time, there's a good chance I'll get it wrong more than once afterwards. There have been times where I very carefully type the password and strongly suspect I typed it correctly, but did continue booting. Perhaps I did get it right and then it prompts again (without observable difference) for the swap partition?

Perhaps that's been the real issue all along?

Could very well be. This one is inherently difficult to diagnose.

@andrewdavidwong
Copy link
Member

Could very well be. This one is inherently difficult to diagnose.

At least with respect to normal usage. If you wanted to test it, perhaps the way to go would be to have a very short, simple password (just for testing purposes, so that you can be sure you've typed it correctly), then see whether typing it incorrectly leads to having to type it in twice.

@unman
Copy link
Member

unman commented Jul 14, 2019

@andrewdavidwong
I cant reproduce this with 4.0. I dont see a second prompt and dont have any issue in typing in the correct password after two or three failed attempts.
Neither with BTRFS or without.

@jpouellet - do you still experience this issue in normal use? At all?

If not, can I suggest closure?

@jpouellet
Copy link
Contributor

@jpouellet - do you still experience this issue in normal use? At all?

Not that I readily recall.

If not, can I suggest closure?

Sure.

@andrewdavidwong
Copy link
Member

Closing this for now as "cannot reproduce." If you believe this is a mistake, or if anyone can reproduce the issue, please leave a comment, and we'll be happy to reopen this. Thank you.

@andrewdavidwong andrewdavidwong added R: cannot reproduce Resolution: Attempts to replicate the problem have not been reliably successful enough to proceed. and removed help wanted This issue will probably not get done in a timely fashion without help from community contributors. labels Jul 15, 2019
@andrewdavidwong andrewdavidwong removed this from the Release TBD milestone Jul 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: other P: minor Priority: minor. The lowest priority, below "default." R: cannot reproduce Resolution: Attempts to replicate the problem have not been reliably successful enough to proceed. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Development

No branches or pull requests

6 participants