Bug 470740 - Must enter passphrase multiple times before system will decrypt and boot
Must enter passphrase multiple times before system will decrypt and boot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
11
i386 Linux
high Severity urgent
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F10Target F11Target
  Show dependency treegraph
 
Reported: 2008-11-09 17:14 EST by Bob Cochran
Modified: 2013-01-22 20:31 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-12 11:21:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot showing RPM information for cryptsetup-luks and plymouth (169.64 KB, image/png)
2008-11-09 19:35 EST, Bob Cochran
no flags Details
File /etc/fstab, per request (772 bytes, application/octet-stream)
2008-11-09 19:37 EST, Bob Cochran
no flags Details
Screenshot showing updates to cryptsetup and initrd, per request (174.97 KB, image/png)
2008-11-10 23:25 EST, Bob Cochran
no flags Details
Exact passphrase in hex (50.19 KB, image/png)
2008-11-10 23:29 EST, Bob Cochran
no flags Details
The passphrase in cleartext after entering it with Dell USB keyboard. (229.56 KB, image/jpeg)
2008-11-10 23:35 EST, Bob Cochran
no flags Details
Screenshot showing text when I cannot enter the last character of the passphrase. (179.94 KB, image/jpeg)
2008-11-17 22:19 EST, Bob Cochran
no flags Details
Program to dump the keyboard strokes (319 bytes, text/plain)
2008-12-08 11:53 EST, Charlie Brej
no flags Details
Screenshot of keycheck program output from tty2 (76.19 KB, image/jpeg)
2008-12-08 20:35 EST, Bob Cochran
no flags Details
Picture of boot screen (text) showing password prompt before INIT of keyboard (202.46 KB, image/jpeg)
2009-01-23 15:48 EST, Tom London
no flags Details

  None (edit)
Description Bob Cochran 2008-11-09 17:14:32 EST
Description of problem:

After updating to cryptsetup-luks-1.0.6-6.fc10.i386, I often must enter my LUKS passphrase multiple times (sometimes 6 or more times) before the passphrase is accepted. I know the passphrase to be correct.


Version-Release number of selected component (if applicable):

Noted above.

How reproducible:

This does not happen every time. Sometimes, the passphrase is accepted the first time it is entered, on a fresh boot. It might be related to the procedure that is followed (by the cryptsetup code) if you enter the passphrase incorrectly the first time. That does happen to me sometimes. This may also be related to using a USB keyboard, because that is the type of keyboard I'm using.

Steps to Reproduce:
1. Turn system power on.
2. Wait for "password" prompt.
3. Enter passphrase. 
4. The response:

command failed: no key available with this passphrase

will be issued aand the password prompt appears again.

5. The same command failed... message will be issued even if you subsequently type the correct passphrase.
  
Actual results:

Correct passphrase doesn't work, as noted above. Ability to boot the encrypted system is blocked. One can reboot by using CTRL-ALT-DEL and keep on trying with the passphrase. Eventually, the phrase will be accepted and booting continues.

Expected results:

I should be able to enter the correct passphrase and immediately boot the system.

Additional info:
Comment 1 Milan Broz 2008-11-09 18:28:22 EST
You mention after update - only cryptsetup was updated? If so, which version worked before?

Which version of plymounth is on your system (rpm -q plymouth)?
(The password prompt is provided by plymouth currently.)

You have only one encrypted device, or there are more encrypted partitions?
(maybe attach /etc/fstab just for reference, thanks)

(Also see bug 448875 - I was never able to reproduce this.)
Comment 2 Bob Cochran 2008-11-09 19:35:18 EST
Created attachment 323029 [details]
Screenshot showing RPM information for cryptsetup-luks and plymouth

Screenshot showing install dates for cryptsetup-luks and plymouth, as well as versions.
Comment 3 Bob Cochran 2008-11-09 19:37:19 EST
Created attachment 323030 [details]
File /etc/fstab, per request

Per your request, /etc/fstab is attached
Comment 4 Bob Cochran 2008-11-09 19:44:53 EST
Responding to your needinfo request...cryptsetup-luks was updated with a bunch of others from rawhide, and I forget which packages specifically were updated. Yes, the passphrase prompting and validation worked fine before that specific update, there were no issues with the passphrase. 

I am now having trouble reproducing this error myself. It seems to be happening randomly. I'm going to post a photo to the internet later tonight showing the hardware I am using. Basically I have an external USB hard drive connected to a USB hub which is connected to an older Dell D420 laptop. I'm now wondering if the USB keyboard I'm using might be the root of the problem. Also I wonder if there is a timing issue between the time the prompt for the password displays, and when the password is actually typed in. That is, does it help to wait a few seconds after seeing the password prompt before trying to type it in...say 20 seconds or so?

Bob
Comment 5 Bob Cochran 2008-11-09 22:18:27 EST
You can see the hardware and a screenshot here

http://www.greenbeltcomputer.biz/fc10_p1.html
Comment 6 Milan Broz 2008-11-10 06:58:21 EST
I thought that USB problems in initrd had been fixed (e.g. bug 433746).

Well, I'll try to reproduce this but I think that the core problem is not in cryptsetup itself.
Comment 7 Milan Broz 2008-11-10 11:54:40 EST
I am not able to reproduce this, but we hit this problem several times and the problem can be completely outside cryptsetup.

I'll need verify that cryptsetup really receives correct password (for some reason people writing plymouth decided to move whole logic there).

Bob, if you have testing configuration with this problem, can you please help me to find the root cause?

I built testing rpm which prints password to screen - it is insecure, but good for debugging here.

If possible please
- update package from here
http://mbroz.fedorapeople.org/tmp/cryptsetup-luks-1.0.6-6.1.echo.fc10.i386.rpm

- rebuild you initrd using
mkinitrd /boot/initrd-$(uname -r).test.img $(uname -r)

- change /boot/grub/menu.lst to point to new ramdisk (or change this during the boot manually)

In text mode, after password entry you should see password echoed to screen:

Entered password: 'password'
In hex: 70 61 73 73 77 6f 72 64

(you can even try bad password - just to match that it prints the same text as entered)

Please, could you verify that it really matches your entered password?
If not, please paste here what's different, thank you!
Comment 8 Bob Cochran 2008-11-10 23:22:43 EST
Hi Milan, thanks for giving me an opportunity to help. I have followed your instructions and have a lot to report. After reading your request on my other computer, but before I could apply the updates you requested, I turned on the laptop system I'm using to test Fedora 10. Again and again, my passphrase was being rejected if I use my USB keyboard to type it in. I noticed that with the USB keyboard...I could not type in the very last character of my passphrase (the cursor stopped moving and the final asterisk representing that last character did not show up.) After 9 failed attempts (meaning 3 reboots) to get my passphrase typed in with the USB keyboard, I restarted the computer a final time, and typed in the passphrase using the laptop's built-in keyboard. Success! The machine booted.

At that point I downloaded your modified version of crypsetup-luks. I installed it, rebuilt my initrd as requested, and modified the /initrd...line in grub.conf so it gets used. Please see the attached screenshot so you can review exactly how I installed it. I want to underline that I have not installed any other Fedora 10 updates from rawhide. Tonight, I have only updated cryptsetup with your provided rpm, rebuilt the initrd and edited grub.conf per directions.

Please see another attached screenshot showing the exact text of my passphrase. I typed the passphrase into gedit and gedit appended a linefeed, x'0a'. That linefeed is not the last character of the passphrase. The question mark '?' is the final character of the passphrase. 

Now I restarted the computer, and typed in the passphrase using my USB keyboard. Success! The passphrase is being accepted suddenly! See the two attached photos showing the passphrase prompt and the cleartext of the actual passphrase. I am going to try rebooting several more times to see if I have trouble entering the passphrase with the USB keyboard. Sometimes the passphrase works fine with the keyboard. And sometimes, like tonight, it gets rejected. 

The particular USB keyboard I am using is the Dell model SK-8135, their part number CN-0DJ425-71616-67R-177C. It is about 3 years old. I notice that once I'm logged in to Fedora 10 and using a terminal window or gedit, there is sometimes difficulty getting a space entered when pressing the space bar. For purposes of testing this problem, I could buy a new USB keyboard if you wish. (The laptop does not have a PS/2 port.) 

Let me go add all the attachments I've developed for this test effort. 

Thank you again for the chance to help test Fedora 10.
Comment 9 Bob Cochran 2008-11-10 23:25:27 EST
Created attachment 323146 [details]
Screenshot showing updates to cryptsetup and initrd, per request
Comment 10 Bob Cochran 2008-11-10 23:29:04 EST
Created attachment 323148 [details]
Exact passphrase in hex

This is the text of the exact passphrase. However the final character of the passphrase is a question mark '?', not a linefeed x'0a'. That was appended by gedit when I saved the passphrase to a document, then dumped it with hexedit.
Comment 11 Bob Cochran 2008-11-10 23:35:40 EST
Created attachment 323149 [details]
The passphrase in cleartext after entering it with Dell USB keyboard. 

Photo of the passphrase cleartext right after I typed it in at the "password" prompt. In this case, we have success -- I was able to get the hard drive unlocked and the boot process continued successfully. I am going power off the laptop and monitor for a few minutes to see what result that has when I reboot the system.
Comment 12 Bob Cochran 2008-11-11 00:17:44 EST
I just cold-booted the laptop once and restarted it twice more. At each prompt for the LUKS password, the passphrase was correctly recognized whether I used the USB keyboard (I used it twice) or the laptop's keyboard (once.) I will try again later on around 0900 EST to see if this stays consistent.
Comment 13 Milan Broz 2008-11-11 02:43:23 EST
Thanks for testing but I need catch the situation when the password is rejected - and check if password is garbled or not.

It can be caused by an unexpected USB resets (usb hub can be power-overloaded with attached USB discs for example or your keyboard is really broken) etc. But this is only speculation... 

But if tyou keyboard works in X, it should work during boot too. Not the right time to buy new keyboard yet, I would say:-)
Comment 14 Bob Cochran 2008-11-12 17:40:56 EST
So far, using your version of cryptsetup-luks, I have not had a single problem with entering the passphrase.
Comment 15 Bill Nottingham 2008-11-17 13:18:49 EST
Moving this to target - as this has not been root caused yet, and we are not seeing this in many test situations here, we are unlikely to hold the release for this.
Comment 16 Milan Broz 2008-11-17 13:20:43 EST
Please can you rebuild your ramdisk again, now with the released cryptsetup version rpm?

- force reinstall back cryptsetup-luks-1.0.6-6.fc10.i386.rpm from fedora repository
- recreate the ramdisk the same way as comment #7 says

If the bug is reintroduced, there is some strange timing issue.

If not, the former initrd was probably updated with some old component.

Thanks for testing!
Comment 17 Bob Cochran 2008-11-17 22:19:46 EST
Created attachment 323834 [details]
Screenshot showing text when I cannot enter the last character of the passphrase. 

This screenshot shows passphrase entry failures -- 2 of them. The problem is, for whatever reason, I am not allowed to enter the very last character of the passphrase. I type the passphrase and the cursor stops before I can type in that last character.
Comment 18 Bob Cochran 2008-11-17 22:29:35 EST
I think we are really close to finding the problem now. While preparing to do the changes you asked for in comment #16, I was unable to enter my passphrase. See comment 17. After taking photos of the screen at that point...guess what, I was able to enter the last character of the passphrase and thereby continue a normal boot. So just by waiting a short time (and I'm not sure whether we need to wait seconds or minutes), I will be allowed to type in the final passphrase character. I saw some of this yesterday too but was caught up in another activity and didn't photograph it. It feels like 

if I enter my passphrase right away

then

I will have difficulty entering the last character

if I can't enter the last character of my passphrase, but I wait, I may be allowed to enter it after the waiting period

if a wait elapses between the time the passphrase is requested on the screen (when the "password:" prompt appears) and the time I actually type it in, the passphrase will be accepted.

My passphrase has 21 characters and I wonder of there is a problem after typing the 20th character of the passphrase. 

I have done the changes you requested in comment 16. I will reboot the system now and see what happens.
Comment 19 Bob Cochran 2008-11-17 22:48:53 EST
I just rebooted my system and entered my passphrase without a problem. I will continue testing for a few days and see what happens. 

I do have a 45-second timeout period in grub. All my systems show the grub screen and this one is no exception. I wonder if the grub timeout period is affecting plymouth when it captures the passphrase?

Thanks for asking me to help test Fedora.
Comment 20 Milan Broz 2008-11-18 04:07:58 EST
Bob, thanks. The picture in comment #17 clearly shows that cryptsetup receives password without the last character - so it does the right thing to not accept it.

I'll reassign this to plymouth - it reads password from the terminal now.

Still posibility that some hw interacting here but first we need to check that plymouth cannot cause this.
Comment 21 Ray Strode [halfline] 2008-11-18 09:53:12 EST
Hi Bob,

First, just to make sure we're on the same page, can you update plymouth to the latest tagged release?

You should be able to do that by typing (as root):

yum update

followed by

sudo /usr/libexec/plymouth/plymouth-update-initrd

After doing those steps you should be at plymouth-0.6.0-0.2008.11.17.3.fc10

Reboot.  If the problem is still present, then can you reboot again, and this time remove rhgb from the kernel command line at grub and add plymouth:debug instead?

This should give us more messages that might tell us what's going on.

One more question, can you ever reproduce this problem with the usb keyboard unplugged and using just the internal laptop keyboard?
Comment 22 Bob Cochran 2008-11-18 22:14:33 EST
Hi Ray,

I have updated plymouth as you requested and I'm at the version you mention. I rebooted the machine and had no problem entering my passphrase. 

I believe I did have this problem with the internal laptop keyboard, however the USB keyboard was left plugged into the USB port on the side of the large monitor and I just opened up the laptop and typed the passphrase and watched the screen output on the large monitor. I will unplug the keyboard next time if trouble arises.
 
I will continue to work with this over the next several days, however there is one small issue for me -- my wife is traveling tomorrow for a few days and has the laptop machine I use for testing Fedora 10. I won't be able to try again with this problem until Saturday, November 22. But I will come back to it at that time. I'm also expecting to get a new just laptop for myself soon (smile).

I appreciate very much the chance to help test Fedora 10. Thank you for the honor.

Bob
Comment 23 Ray Strode [halfline] 2008-11-19 09:22:10 EST
I'm glad to hear the system is working for you again.  I'm going to close the report, but if after your wife comes back, you run into the problem again, please reopen it and we'll investigate further.
Comment 24 Bob Cochran 2008-12-05 18:35:38 EST
Hi Ray,

This bug is definitely reoccurring. It happens with the USB keyboard I am using. Any attempt to type the last character of the passphrase (it is still the same passphrase as previously disclosed) fails for a time. Then suddenly a keypress at the position of the last character will generate a character, but I'm not sure what character it finds. If I press the backspace key and backspace until there are no asterisks in the "password:" prompt, and then I retype the passphrase, it will again refuse to let me type the very last character of the passphrase.

The problem does not occur with the laptop's own keyboard. It happens with the Dell USB keyboard I am using. In order to boot my system I am routinely typing all but the last character of the passphrase, then opening the laptop until the monitor is upright, then typing that last character with the laptop keyboard. I normally use this system with the laptop closed but connected to a 19" Dell external monitor. I could open the laptop monitor and display on that screen too, but I prefer to focus on the large external monitor. 

Thanks

Bob
Comment 25 Bob Cochran 2008-12-05 18:37:11 EST
I forgot to say...I am at the current updates as of 12/04/2008...here is my uname -a output:

Linux deafeng3.signtype.info 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux

Bob
Comment 26 Ray Strode [halfline] 2008-12-08 11:12:24 EST
reopening.
Comment 27 Charlie Brej 2008-12-08 11:53:30 EST
Created attachment 326144 [details]
Program to dump the keyboard strokes

Hi Bob, I attached a little program to dump the keyboard codes. Could you run it in a console (Ctrl+Alt+F2) and type in the question mark from the usb keyboard, a couple spaces, one from the laptop one, couple more spaces, press return and Ctrl+C to quit.

# gcc keycheck.c -o keycheck ; ./keycheck
Comment 28 Bob Cochran 2008-12-08 20:33:42 EST
Hi Charlie, I copied your code, compiled and ran it as requested. Here is a screenshot showing my results (in CTRL+Alt+F2). You are seeing character output on the screen in the manner you requested: first with the USB keyboard, then with the laptop keyboard. I'm sorry for the awful photo coloring, it looks like the Ufraw program doesn't know the right white balance presets for the camera I'm using. I'll get my wife to fix the photos I took and I'll send you an update later. 

I am suddenly not having a problem with the USB keyboard my last three attempts to answer with the passphrase. I'm very puzzled at the inconsistency. The laptop's internal keyboard seems to work consistently with the passphrase. The first time this happened, I first started Windows XP to check something with Internet Explorer. Then I shut down the laptop and connected the external hard drive I use to boot Fedora 10 with. I left the monitor switched on. I then booted Fedora and I had no difficulty entering the passphrase with the usb keyboard.

The second time I restarted the computer from within Fedora 10 and booted Fedora 10. Again, the passphrase worked using the USB keyboard. Then I shut down the computer for about 20 hours and I came back to it tonight to download your code and respond to your request. Again, entering the passphrase from the USB keyboard seems to work okay. 

I will post the photo of my keycheck output in a moment.
Comment 29 Bob Cochran 2008-12-08 20:35:29 EST
Created attachment 326236 [details]
Screenshot of keycheck program output from tty2
Comment 30 Charlie Brej 2008-12-10 16:02:46 EST
Brilliant, thanks Bob.
What is happening is that the USB keyboard is inserting a NULL character before the question mark. I have no idea why its doing that (and how other applications cope) but Ray has put in something to skip the null characters which deals with this problem.

Just as a curiosity, what is the usb keyboard you're using? Do you have to press the function key (or some other modifier key) to get the question mark?
Comment 31 Ray Strode [halfline] 2008-12-10 16:19:42 EST
Something isn't right, though, because my NUL skipping code is in 0.6.0-0.2008.11.14.2 which is older than what Bob has installed.
Comment 32 Tom London 2009-01-19 10:03:27 EST
Not sure if this is the same issue, but I've noticed that during plymouth boot, the nice plymouth "popup" for Luks passphrase is displayed before my USB keyboard is "initialized".

In a bit more detail, my USB keyboard has some LEDs that blink when the keyboard is "activated" and one gets turned on.

This occurs during the "grub display menu phase" (i.e., when it waits for me to select which kernel I want to boot).

But the LEDs are reset quickly there after, and typically do not flash again till about .5-1 second after the popup is displayed.

I've noticed that I sometimes enter the first character or 2 before the LEDs are activated, and if so, my first entered passphrase will fail.

When this happens, the second prompt for passphrase will succeed (with the correctly entered passphrase ;) ), but the first (incorrect) passphrase is used to try to unlock my "other" encrypted partitions.

Is there any way to synchronize the "popup" with the "initialization" better?
Comment 33 Milan Broz 2009-01-19 10:23:20 EST
(In reply to comment #32)
> Not sure if this is the same issue, but I've noticed that during plymouth boot,
> the nice plymouth "popup" for Luks passphrase is displayed before my USB
> keyboard is "initialized".

I saw this several times too (even in different distros - USB keyboards resets after cryptsetup prompt is displayed).

This is problem of timing in initrd/kernel.

I guess USB devices will need some settle command in initramdisk (similar to storage devices already have) ...

Maybe the USB device (keyboard here) can be also reset during entering password because the current overload or some special USB hub (un)configuration during the boot...
Comment 34 Charlie Brej 2009-01-19 10:32:49 EST
Hmmm, that sounds annoying as I doubt there is anything sensible we can hook onto to tell if a keyboard has been initialised (considering that this may be an auxiliary keyboard). What make/model is it? Does it have a hub in the keyboard? Do you go via an external hub? Can you see is you get any syslog messages when you unplug/plug in the keyboard?

The only thing I can think of is that the kernel gives a few second settle down for some usb hubs and devices.

Bob: btw, have you had any more instances?
Comment 35 Tom London 2009-01-19 10:54:02 EST
(In reply to comment #34)
> Hmmm, that sounds annoying as I doubt there is anything sensible we can hook
> onto to tell if a keyboard has been initialised (considering that this may be
> an auxiliary keyboard). What make/model is it? Does it have a hub in the
> keyboard? Do you go via an external hub? Can you see is you get any syslog
> messages when you unplug/plug in the keyboard?
> 
> The only thing I can think of is that the kernel gives a few second settle down
> for some usb hubs and devices.
> 

Yeah, external keyboards....

I have a laptop (Thinkpad X200 (and X61)) that I use in 2 "docked" environments:  my "@home" setup that includes a USB->PS/2 adapter (sorry, old keyboard and mouse).  This is where I'm working now.  I see this issue every boot on this system.

Second, my "@work" setup: same laptop but USB keyboard connected via "USB 2.0 mini Hub" to Thinkpad dock.  I will verify behaviour on setup #2 in about an hour or 2. 

Here is what I find in /var/log/messages using setup #1:

Jan 19 07:24:16 tlondon kernel: usb 6-2: new low speed USB device using uhci_hcd and address 2
Jan 19 07:24:16 tlondon kernel: usb 6-2: New USB device found, idVendor=05f3, idProduct=0203
Jan 19 07:24:16 tlondon kernel: usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 19 07:24:16 tlondon kernel: usb 6-2: Product: PC Keyboard/Mouse to USB  Adapter
Jan 19 07:24:16 tlondon kernel: usb 6-2: Manufacturer: P.I. Engineering
Jan 19 07:24:16 tlondon kernel: usb 6-2: configuration #1 chosen from 1 choice
Jan 19 07:24:16 tlondon kernel: input: P.I. Engineering PC Keyboard/Mouse to USB  Adapter as /devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/input/input6
Jan 19 07:24:16 tlondon kernel: generic-usb 0003:05F3:0203.0001: input,hidraw0: USB HID v1.00 Keyboard [P.I. Engineering PC Keyboard/Mouse to USB  Adapter] on usb-0000:00:1d.0-2/input0
Jan 19 07:24:16 tlondon kernel: input: P.I. Engineering PC Keyboard/Mouse to USB  Adapter as /devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.1/input/input7
Jan 19 07:24:16 tlondon kernel: generic-usb 0003:05F3:0203.0002: input,hidraw1: USB HID v1.00 Mouse [P.I. Engineering PC Keyboard/Mouse to USB  Adapter] on usb-0000:00:1d.0-2/input1

For comparison, here is what I find in /var/log/messages from setup #2:

Jan 16 14:01:40 tlondon kernel: hub 1-5.3:1.0: 4 ports detected
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.1: new low speed USB device using ehci_hcd and address 6
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.1: New USB device found, idVendor=045e, idProduct=0084
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.1: Product: Basic Optical Mouse
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.1: Manufacturer: Microsoft
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.1: configuration #1 chosen from 1 choice
Jan 16 14:01:40 tlondon kernel: input: Microsoft Basic Optical Mouse as /devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.3/1-5.3.1/1-5.3.1:1.0/input/input6
Jan 16 14:01:40 tlondon kernel: generic-usb 0003:045E:0084.0001: input,hidraw0: USB HID v1.10 Mouse [Microsoft Basic Optical Mouse] on usb-0000:00:1a.7-5.3.1/input0
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.2: new full speed USB device using ehci_hcd and address 7
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.2: New USB device found, idVendor=03f0, idProduct=1017
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.2: Product: hp LaserJet 1300
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.2: Manufacturer: Hewlett-Packard
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.2: SerialNumber: 00CNCB954325
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.2: configuration #1 chosen from 1 choice
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.4: new low speed USB device using ehci_hcd and address 8
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.4: New USB device found, idVendor=413c, idProduct=2003
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.4: Product: Dell USB Keyboard
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.4: Manufacturer: Dell
Jan 16 14:01:40 tlondon kernel: usb 1-5.3.4: configuration #1 chosen from 1 choice
Jan 16 14:01:40 tlondon kernel: input: Dell Dell USB Keyboard as /devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5.3/1-5.3.4/1-5.3.4:1.0/input/input7
Jan 16 14:01:40 tlondon kernel: generic-usb 0003:413C:2003.0002: input,hidraw1: USB HID v1.10 Keyboard [Dell Dell USB Keyboard] on usb-0000:00:1a.7-5.3.4/input0
Jan 16 14:01:40 tlondon kernel: modprobe used greatest stack depth: 4344 bytes left


I'll verify "timing" with setup #2 and report here.
Comment 36 Ray Strode [halfline] 2009-01-19 11:31:59 EST
I guess this isn't something we'd fix in plymouth, but (as Milan says) in the initrd.  The initrd needs to make sure that it delays calling ask-for-password until the keyboard is up.
Comment 37 Charlie Brej 2009-01-19 11:37:44 EST
I might be way off base here but, perhaps what is happening is the initrd was formed while in the other setup so it does not include some modules to make the keyboard work. Once / is mounted it finds the relevant modules and loads them. This happens around the same time as the system notices the encrypted partitions and shows a password popup.
Comment 38 Tom London 2009-01-19 12:03:42 EST
(In reply to comment #37)
> I might be way off base here but, perhaps what is happening is the initrd was
> formed while in the other setup so it does not include some modules to make the
> keyboard work. Once / is mounted it finds the relevant modules and loads them.
> This happens around the same time as the system notices the encrypted
> partitions and shows a password popup.

Don't think this is what is happening, as I create the initrds in either of the 2 setups described above.

It fails the same in both.
Comment 39 Tom London 2009-01-19 12:08:13 EST
(In reply to comment #35)
> (In reply to comment #34)
> 
> I'll verify "timing" with setup #2 and report here.

Its behavior is the same with the second setup.  I can easily enter 3 characters after the "enter passphrase popup" and before I start seeing "you've entered a character circles" in the propmt line.(In reply to comment #36)

> I guess this isn't something we'd fix in plymouth, but (as Milan says) in the
> initrd.  The initrd needs to make sure that it delays calling ask-for-password
> until the keyboard is up.

Sounds reasonable....  How to help?
Comment 40 Ray Strode [halfline] 2009-01-19 13:30:37 EST
Hey Charlie,

The initrd asks for password before / is mounted (it uses the password to decrypt / so it can be mounted after all).

I guess we need to ask someone who knows how the usb keyboard drivers gets loaded (are they builtin? does a udev event get sent out that the initrd needs to wait for?)
Comment 41 Ray Strode [halfline] 2009-01-19 13:35:30 EST
Tom, one thing that would be useful to know is.  If you let it sit at the password screen for 30 seconds or so does it work reliably?
Comment 42 Tom London 2009-01-19 14:01:46 EST
Yes.

Actually, 30 seconds appears way overkill.

3-5 seconds appears reliably "enough" (at least on my system).

I'll try over the next few days by masking the leds and counting to 2 or 3 to verify, but I don't recall a case where I needed to wait more than just a few seconds for keystrokes to be "echoed".

My recollection is that this all happens before udev starts (and before / is decrypted), so I'm thinking it must be "built in".....
Comment 43 Ray Strode [halfline] 2009-01-19 14:36:05 EST
okay this must be something the initrd needs to block on and isn't then.  Reassigning.

Peter will probably instantly know what's wrong as soon as he reads the report.
Comment 44 Tom London 2009-01-23 15:48:04 EST
Created attachment 329881 [details]
Picture of boot screen (text) showing password prompt before INIT of keyboard

I attach a picture of booting w/ encrypted root.

Notice the "Password:" prompt about halfway down the screen, followed by USB notifications for the mouse and the keyboard.

The text appeared to flow on the screen smoothly (that is, no noticeable delays between lines).

The '*' on the last line (after mouse and keyboard stuff) is me entering the passphrase......
Comment 45 Tom London 2009-02-09 11:02:11 EST
I'm noticing recent kernels exhibiting far less "delay" between the GUI screen prompt and the LED on my keyboard going on (e.g., 0.93, 0.96).

Looks like less than 1 second....

Did something change?
Comment 46 Bug Zapper 2009-06-09 05:51:46 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 47 udo 2009-06-14 12:06:38 EDT
I am also having trouble with getting the password to my encrypted harddisk accepted when trying kernels built with Fedora 11.
This is on a normal x86_64 pc, no USB but PS/2 keyboard. Text mode boot.
Even a simple short (not 21 character) password like `test123` is not accepted.
I noticed this with building 2.6.30 on F10, which booted OK, and rebuilt on F11 does not accept the password anymore.
Same for 2.6.29.4
What is the workaround?

plymouth 0.7.0-0.2009.05.15.1.fc11 (everything is `yum update` current)
Comment 48 udo 2009-06-14 12:26:29 EDT
BTW: I do see an asterisk for each letter, no asterisk is missing.
Also: as soon as I type the first letter of the password, the Password: prompt is repeated below the messages from the detected USB-devices, together with the first asterisk for the first letter of the password.
Comment 49 udo 2009-06-15 09:37:16 EDT
Since this bug can render a system unbootable and only recoverable with extra effort the fipority and/or severity were understated.
Also: this problem is blocking others since I cannot install a newer kernel anymore and I have to rely on the F10-built ones.
Comment 50 udo 2009-06-15 12:07:02 EDT
s/fipority/priority/

and: to make it absolutely clear:

over here the password is not accepted at all. 
so I cannot boot a new kernel AT ALL.

Also for this bug: why was this released when the F10 situation worked?
Comment 51 Charlie Brej 2009-06-16 11:10:33 EDT
(In reply to comment #50)

AFAIK there have been no changes in the password handling stuff between the F10 updated and the F11 packages. 

You say you have a working F10 kernel/initd. Could you recreate the initrd for that kernel and try booting with that? (keep the original)

# mkinitrd -f /boot/initrd-$(uname -r).img.test $(uname -r) 

Then duplicate the F10 kernel entry in /etc/grub.conf, give it a different title and add a .test to the end of the initrd to match the newly created initrd .img and try booting with that (you may need to select it in the grub boot menu).
Comment 52 udo 2009-06-16 11:37:20 EDT
I built 2.6.30 on F10, booted OK.
I built 2.6.29.4 on F10 before that, was OK.

Enter F11:
I rebuilt  2.6.30 to add some features. Password enter issue.
As a test, after asking on linux-kernel, I built 2.6.29.4 again on F11. Same problem.

Now I did the mkinitrd thing. Same thing.

So what is the issue?
Probably it is in the ramdisk. It is not the kernel source code, but cryptsetup or plymouth?
Please advise on how to find out.
Comment 53 udo 2009-06-17 12:14:42 EDT
So what is the issue?
Probably it is in the ramdisk. It is not the kernel source code, but cryptsetup
or plymouth?
Please advise on how to find out.
Comment 54 udo 2009-06-18 09:59:58 EDT
Peter, do you think my issue is different and needs a separate bug?
Can we please do some tests to find out more?
If so: what can I do?
Comment 55 udo 2009-06-18 11:15:21 EDT
This is a blocker for any kernel bugfixes.
Comment 56 Ray Strode [halfline] 2009-06-18 17:56:02 EDT
Hi udo,

Your issue is different than the original report.  You may get more traction filing it separately.

When you file the report against mkinitrd make sure you include your /etc/crypttab file and the output of 

zcat /boot/initrd-blah.img | cpio --extract --list
zcat /boot/initrd-blah.img | cpio --extract --to-stdout init

for a working initrd and a non-working initrd.
Comment 57 udo 2009-06-19 10:09:25 EDT
see https://bugzilla.redhat.com/show_bug.cgi?id=501198 for probably `my` issue
Comment 58 Andrew 2009-07-10 05:31:06 EDT
I must admit I didn't bother to read the above - but didn't you just encrypt multiple partitions? I did that under F9 and had to enter my pass phrase twice. Now I've done the default in F11 and I only get asked once.
Comment 59 udo 2009-12-09 11:25:40 EST
I encrypt my partition containing lvm2.

in fedora 12 I had the first build of kernel 2.6.32 which uses dracut.
No issues so far. (except some textual noise which does not reflect the situation after the boot)
Comment 60 Hans de Goede 2010-01-12 10:31:50 EST
This is a mass edit of all mkinitrd bugs.

Thanks for taking the time to file this bug report (and/or commenting on it).

As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on
certain libraries it provides, but mkinitrd itself is no longer used.

In Fedora 13 mkinitrd will be removed completely. This means that all work
on initrd has stopped.

Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. 

If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.
Comment 61 udo 2010-01-12 10:51:43 EST
Are we sure that the core issue that causes this bug does not cause harm with dracut?
Just closing a few bugs because a package disappears does not show a dedication for quality.

Please explain why the root cause is not a problem for dracut.
Comment 62 Hans de Goede 2010-01-12 11:21:00 EST
(In reply to comment #61)
> Are we sure that the core issue that causes this bug does not cause harm with
> dracut?
> Just closing a few bugs because a package disappears does not show a dedication
> for quality.
> 
> Please explain why the root cause is not a problem for dracut.    

dracut is a complete rewrite, not re-using any code, using a completely different
princicple to find the rootfs to boot. And as you've indicated yourself in comment #59, dracut does not seem to exhibit this problem.

Closing again.
Comment 63 udo 2010-01-12 11:28:25 EST
So we leave the bug a bug without knowing it's true nature because we don't trigger it with dracut. Cool.

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