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

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.

Created attachment 323030 [details]
File /etc/fstab, per request

Per your request, /etc/fstab is attached

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

You can see the hardware and a screenshot here

http://www.greenbeltcomputer.biz/fc10_p1.html

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.

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!

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.

Created attachment 323146 [details]
Screenshot showing updates to cryptsetup and initrd, per request

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.

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.

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.

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

So far, using your version of cryptsetup-luks, I have not had a single problem with entering the passphrase.

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.

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!

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.

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.

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.

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.

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?

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

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.

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

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

reopening.

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

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.

Created attachment 326236 [details]
Screenshot of keycheck program output from tty2

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?

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.

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?

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

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?

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

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.

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.

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

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

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

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?

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

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.

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

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?

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

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)

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.

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.

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?

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

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.

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.

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?

This is a blocker for any kernel bugfixes.

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.

see https://bugzilla.redhat.com/show_bug.cgi?id=501198 for probably `my` issue

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.

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)

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.

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.

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

So we leave the bug a bug without knowing it's true nature because we don't trigger it with dracut. Cool.