I forgot to mention that the exact error message is:
"Command failed: No key available with this passphrase."

When it works it looks like this:
"key slot 0 unlocked.
Command successful."

Have I already mentioned that I'm sure that I always entered the correct key? ;)

You can open the partitions manually and see whether the bug occurs, too. The
easiest way would be to use a live medium, I guess.

With

cryptsetup luksOpen /dev/whatever foo

you can decrypt the device /dev/whatever and make the contents available at
/dev/mapper/foo

With

cryptsetup luksClose foo

you can close it again.

I've exactly the same problem on F9.
Sometimes it works without problems, sometime it doesn't, and I'm sure of my key.
In rescue mode I can easily access to my data with a crypsetup luksOpen /dev/foo ...
I've tested with a simple key like foobar same problem...

Is there any message in syslog from device-mapper?

I can't find anything for the moment ... it's during the boot...

yes, but if you boot without "quiet" and "rhgb" option, it should be displayed
on screen immediately before cryptsetup fail message.

(I just want to know if the mapping is rejected by device-mapper for some
reason, e.g. because some temporary mapping, udev or anyone uses it, or there is
real problem in cryptsetup itself)

Hard to have some logs :( even without rhgb and quiet option. This morning this
is what I've done :
- First boot on battery ... I've tried to boot 5 times ... so 3x5 passphrase (
I'm sure of it )
The error message was : 
Enter LUKS passphrase for /dev/mapper/VG00-LV-root :
3 tentative :
Command failed : No key available with this passphrase.
- 6th boot with AC power : it works without problems ??? Really strange isn't it ?  

I've tried to reboot on battery and it works...
I'm using : cryptsetup-luks-1.0.6-2.fc9.x86_64 on F9 fully updated.

manually open the partitions also doesn't work for me.

hm, looks like the partitions are already in use when I try to open them. when
decrypting fails and I get a root shell, running df shows all partitions already
mounted all having the same size. when I access them I only see empty folders.

Can you please attach /etc/fstab, /etc/crypttab and the output of mount after
you got into the root shell when it failed? You can run "mount -o remount,rw /"
to mount / writable to store the output of mount, eg with 
mount >> /root/mount-2008-06-17.txt

Please provide the information I requested in comment 10.

[root@tiffy Packages]# cat /etc/fstab 
UUID=f1dbd301-c934-42e7-983c-99cbefec0f80 /                       ext3   
defaults        1 1
UUID=62f84a8d-8387-486b-809d-b10043e3c0f6 /tmp                    ext3   
defaults        1 2
UUID=52a60e3d-e2b5-42ca-ae6f-d67328023665 /usr                    ext3   
defaults        1 2
UUID=d59eaead-e052-437e-a8a6-e7d414386d74 /home                   ext3   
defaults        1 2
UUID=8e77f598-414a-4f8d-a055-6fac293a3963 /var                    ext3   
defaults        1 2
UUID=91714b6f-87de-46fc-a52b-246f956402a6 /boot                   ext3   
defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
UUID=08fecbbd-81e5-4005-b6a5-914f6ccf1e1a swap                    swap   
defaults        0 0
[root@tiffy Packages]# cat /etc/crypttab 
luks-sda8               /dev/sda8       none
luks-sda3               /dev/sda3       none
luks-sda2               /dev/sda2       none
[root@tiffy Packages]# 

mount output will follow after next reboot :)

[root@tiffy ~]# cat mount.txt 
/dev/sda6 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
/dev/mapper/luks-sda8 on /tmp type ext3 (rw)
/dev/sda5 on /usr type ext3 (rw)
/dev/mapper/luks-sda3 on /home type ext3 (rw)
/dev/mapper/luks-sda2 on /var type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[root@tiffy ~]# cat df.txt 
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6             9.7G  666M  8.5G   8% /
/dev/mapper/luks-sda8
                      9.7G  666M  8.5G   8% /tmp
/dev/sda5             9.7G  666M  8.5G   8% /usr
/dev/mapper/luks-sda3
                      9.7G  666M  8.5G   8% /home
/dev/mapper/luks-sda2
                      9.7G  666M  8.5G   8% /var
/dev/sda1             9.7G  666M  8.5G   8% /boot
tmpfs                1009M   68K 1009M   1% /dev/shm
[root@tiffy ~]#

(In reply to comment #13)

> [root@tiffy ~]# cat df.txt 
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sda6             9.7G  666M  8.5G   8% /

Is the size correct for the rootfs? Or is there another filesystem on your computer, where this size is correct?

I do not know, what happens here, but the next thing I would do, is to look at the output of

blkid

and

dmsetup --table

in the root shell. Maybe this gives a better hint.

this is my df after the finally managed to get my machine up:

[root@tiffy ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6             9.7G  666M  8.5G   8% /
/dev/mapper/luks-sda8
                     1011M  184M  776M  20% /tmp
/dev/sda5             9.7G  5.3G  3.9G  58% /usr
/dev/mapper/luks-sda3
                       29G   21G  6.6G  77% /home
/dev/mapper/luks-sda2
                       97G   72G   20G  79% /var
/dev/sda1              99M   18M   76M  19% /boot
tmpfs                1009M   12K 1009M   1% /dev/shm

looks somewhat different, eh? 

will paste the output from dmsetup when I face the issue the next time.

The output of 

ls -l /dev/mapper/luks-sda8 /dev/sda6 /dev/sda5 /usr

in the root shell might be also interesting.

now it really gets annoying, tried 1h to get access to my machine.

here are some more input:

[root@tiffy ~]# ll /dev/mapper 
total 0
crw-rw---- 1 root root  10, 60 Aug  7 19:46 control
brw-rw---- 1 root disk 253,  0 Aug  7 19:47 luks-sda3
[root@tiffy ~]# 

[root@tiffy ~]# ll /dev/sda*
brw-rw---- 1 root disk 8, 0 Aug  7  2008 /dev/sda
brw-rw---- 1 root disk 8, 1 Aug  7 19:47 /dev/sda1
brw-rw---- 1 root disk 8, 2 Aug  7  2008 /dev/sda2
brw-rw---- 1 root disk 8, 3 Aug  7  2008 /dev/sda3
brw-rw---- 1 root disk 8, 4 Aug  7  2008 /dev/sda4
brw-rw---- 1 root disk 8, 5 Aug  7 19:47 /dev/sda5
brw-rw---- 1 root disk 8, 6 Aug  7 19:47 /dev/sda6
brw-rw---- 1 root disk 8, 7 Aug  7  2008 /dev/sda7
brw-rw---- 1 root disk 8, 8 Aug  7  2008 /dev/sda8
[root@tiffy ~]# 

as already mentioned. I have three encrypted partitions. sda2, sda3 and sda8. decryption of sda3 ALWAYS works, sda2/8 took 1h today to them unlocked with around 30 tries/reboots.

Interesting, I tried recently 3 notebooks to install encrypted Fedora.
Two of them works without problem... Always.

Yesterday I hit someting similar
Command failed : No key available with this passphrase.

I bet it is not cryptsetup fail, but something in boot process. I'll try to debug it later... (I need to switch disk 'cause it is my stable developer machine :-)

any news on this? it's really a f9 showstopper.

Well, I am not able to reproduce it at all. My problem mentioned in comment #18 is the bug 461416 and cannot be in F9 (there is no plymouth in F9).

I reinstalled Fedora9 with almost the same mapping of discs and everything works
perfectly (on i686 - btw which arch you are using?)

So there must be something other related:
any modified udev rules, some hacks in initscript of maybe corrupted root fs or hw problem...

How the wrong df output in comment #13 can happen?
This seems to me like serious system corruption.

When the system ask for luks password, it is still in initrd or later in boot process?
With you uncrypted root configuration it should ask later according to crypttab, no cryptsetup in initrd...

(In reply to comment #20)
> I reinstalled Fedora9 with almost the same mapping of discs and everything
> works
> perfectly (on i686 - btw which arch you are using?)

[root@tiffy ~]# uname -a
Linux tiffy.tuxgeek.de 2.6.25.14-108.fc9.i686 #1 SMP Mon Aug 4 14:08:11 EDT 2008 i686 i686 i386 GNU/Linux
[root@tiffy ~]#

> So there must be something other related:
> any modified udev rules, some hacks in initscript of maybe corrupted root fs or
> hw problem...

it's a fresh install of F9, no hacks. :)

> How the wrong df output in comment #13 can happen?

no idea.

> This seems to me like serious system corruption.
> When the system ask for luks password, it is still in initrd or later in boot
> process?
> With you uncrypted root configuration it should ask later according to
> crypttab, no cryptsetup in initrd...

it's after initrd.

looks like this bug is known by upstream people:

http://www.spinics.net/lists/dm-crypt/msg01102.html

(In reply to comment #22)
> http://www.spinics.net/lists/dm-crypt/msg01102.html

That's another issue - I am sure that your notebook has no ARM processsor:)
F9 has altrady cryptsetup 1.0.6. But the mentioned udev problem is possible
(I wasn't able to reproduce on F9 but...)
Maybe it somehow connected to your problem too.

Pleae, could you try to install and test
cryptsetup-luks-1.0.6-4.fc10
from current rawhide (it has included udev fix)?

It should work on F9 without any changes (I run it here).
(But better keep old F9 rpm version for possible downgrade...)

For more info, what is the udev problem in cryptsetup see my post
http://www.spinics.net/lists/dm-crypt/msg01290.html

(In reply to comment #23)
> (In reply to comment #22)
> > http://www.spinics.net/lists/dm-crypt/msg01102.html
> 
> That's another issue - I am sure that your notebook has no ARM processsor:)

sure, but the symptom is the same. :)

> F9 has altrady cryptsetup 1.0.6. But the mentioned udev problem is possible
> (I wasn't able to reproduce on F9 but...)
> Maybe it somehow connected to your problem too.
> 
> Pleae, could you try to install and test
> cryptsetup-luks-1.0.6-4.fc10
> from current rawhide (it has included udev fix)?

installed cryptsetup-luks from rawhide, same problem.

> It should work on F9 without any changes (I run it here).
> (But better keep old F9 rpm version for possible downgrade...)
> 
> For more info, what is the udev problem in cryptsetup see my post
> http://www.spinics.net/lists/dm-crypt/msg01290.html

Hmmmmm. I really want to know what's wrong here...

Please is it possible to catch "dmsetup table" before and after failed command?
And if possible strace of cryptsetup... (the new from rawhide is better).

after some research today I found out that this problem only happens when you put /var on an encrypted luks partition. to workaround this I manually created a /var/lib/ folder (this is the folder where randon-seed, check rc.sysinit for this, is created) on the / partition. when you now boot the machine with rw / partition, everything works as expected.

Milan, do you have some further comments on this?

Well I was not able to reproduce even with read only /var.

The /var/lib/random-seed file is maintained by initsrcipts only and just keeps initial entropy for initializing kernel random number generator after boot.

There is several problems with entropy after boot, and initscripts runs twice cryptsetup to 1) mount possible /var and initialize RNG and 2) run all cryptsetup mapping which have key set to RNG (like swap encrypted with random key). Still some reported bugs (like #235605, #448665 but nothing what should cause this type of error...)

Inside cryptsetup RNG is required for new key slot setting and slot remove operation (wiping the unused slot). But luksOpen operation should not require RNG.

There must be some confusion in initscript <-> cryptsetup interaction...

Anyway, the "Command failed: No key available with this passphrase." is printed even if there is some problem with underlying device.

I changed this in new rawhide build, so IO error and incorrect LUKS header detection now prints more descriptive error message.

Maybe try cryptsetup-luks-1.0.6-5.fc10 if the error message is still the same...

Well, the workaround in comment #26 solves this particular issue.

I cannot reproduce this and initscripts already take care about mounting /var to load randon seed...

Another mystery password issue was identified to be outside of cryptsetup, see bug #470740 .

I am closing this bug, please reopen if you think that there is a new info, thanks.