Description of problem: I have 3 partitions encrypted during installation. When I reboot the machine I have to enter the enryption key. The key is the same for all 3 paritions. Well, after I entered the key, it sometimes just fails to unlock the partition. This is reproducible and yes, I'm pretty sure I always entered the correct passphrase. Sometimes all 3 unlocks was fail, sometimes a single unlock work and the other two fail. Sometimes it simply unlocks all 3 partitions without problems. It's completely weird. Is there any way to debug this? Version-Release number of selected component (if applicable): cryptsetup-luks-1.0.6-2 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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.