Hello, I working on standard Fedora 19 installation, have disk encrypted with Luks, default installer setup with lvm: Urządzenie Rozruch Początek Koniec Bloków ID System /dev/sdb1 * 2048 1026047 512000 83 Linux /dev/sdb2 1026048 867686399 433330176 83 Linux /dev/sdb3 867686400 972543999 52428800 83 Linux /dev/sdb4 972544000 976773119 2114560 5 Extended /dev/sdb5 972548096 976773119 2112512 83 Linux All partition except /dev/sdb2 (home) are accessable during boot normally - password is accepted. But system dont start, after accepting passphrase they ask next about pass for /home partition, few times, and next drop into emergency shell. I 100% sure that i provice correct password, root and swap partition are mounted. I try unlock /dev/sdb2 partiton on second computer (also Fedora 19, both systemupdated daily), usig cryptsetup, eg. [root@localhost piotr]# cryptsetup luksOpen /dev/sdb3 c1 Hasło dla /dev/sdb3: -for / sdb3 is ok, i can mount it, but: root@localhost piotr]# cryptsetup luksOpen /dev/sdb2 c2 Hasło dla /dev/sdb2: Dla tego hasła nie ma dostępnego klucza. Hasło dla /dev/sdb2: Dla tego hasła nie ma dostępnego klucza. Hasło dla /dev/sdb2: Dla tego hasła nie ma dostępnego klucza. [root@localhost piotr]# for /dev/sdb2 i have "No key available with this passphrase" message L uks partition seems to be correct: root@localhost piotr]# cryptsetup -v isLuks /dev/sdb2 Command successful. Heres dupm from my header: [root@localhost piotr]# cryptsetup luksDump /dev/sda2 LUKS header information for /dev/sda2 Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha1 Payload offset: 4096 MK bits: 512 MK digest: 81 ad bd 3d f5 77 cb d6 0c c1 06 44 08 b5 95 91 f0 3b 39 92 MK salt: 4e bb 9f b6 4d 4f cd da 8e 50 2c a7 3c 18 cb be d7 b0 64 e6 3a 5d ee 33 c9 26 43 9c 59 aa 0c 8f MK iterations: 46375 UUID: 6f5cd34f-d066-4678-8b2e-4aa01722bf59 Key Slot 0: ENABLED Iterations: 185652 Salt: e6 f6 94 41 f6 2a 08 a5 78 b3 49 d8 ac e6 cd 10 a4 95 8c d6 9b ce 22 3b 62 9e 0e 2c 6b 49 bc a5 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED I also tryed deal with locale, eg: LANG=en_US cryptsetup luksOpen /dev/sdb2 c3 Enter passphrase for /dev/sdb2: No key available with this passphrase. but with no effect. Heres conent of my crypttab: luks-f5516cbe-f746-4876-b70e-3e22be73ef35 UUID=f5516cbe-f746-4876-b70e-3e22be73ef35 none luks-1e582a36-28eb-415d-9ce9-acd57d076324 UUID=1e582a36-28eb-415d-9ce9-acd57d076324 none luks-d52b03d1-f9b4-4e16-9f06-3edeb4e02d64 UUID=d52b03d1-f9b4-4e16-9f06-3edeb4e02d64 none After few days working with this problem i stuck; cant access my data. .. anyone know whats going on ?
Are you sure you are using correct device (note sda/sdb)? Also UUID do not match with your crypttab... # cryptsetup luksOpen /dev/sdb2 c2 # cryptsetup luksDump /dev/sda2 ... Anyway, either you have wrong password (wrong keyboard setting maybe) or the keyslot is corrupted.
Yes, this is my fault. Now i working on second computer and encryted disk that i cant access is conencted as /dev/sdb. Here's correct output: cryptsetup luksDump /dev/sdb2 LUKS header information for /dev/sdb2 Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha1 Payload offset: 4096 MK bits: 512 MK digest: 54 97 2b 30 10 4c 23 db 49 b6 71 97 fe a2 f5 e4 e6 eb ed 15 MK salt: ae a7 e6 67 e5 87 8d 72 35 33 1c b7 67 4f 80 f2 26 c1 02 19 46 76 a5 9f 54 f7 68 ea b7 7b f1 1c MK iterations: 43375 UUID: 1e582a36-28eb-415d-9ce9-acd57d076324 Key Slot 0: ENABLED Iterations: 194824 Salt: 44 c2 26 99 b8 29 5e 5b 23 f1 71 c4 a3 f8 16 ca c7 a2 7c f7 92 ff 2d 01 c1 b7 93 94 7b 5b b6 df Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
Please provide keyslot checker output, as suggested here: http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6896 It can reveal keyslot corruption. (All this seems like LUKS visible header is ok but keyslot area is overwritten or so). Ans maybe we should integrate keyslot checker directly to cryptsetup...
Hello, According to tests, password was one for all system (same for /, /home and swap), like in default fedora installation - once typed it unlocked all partitions. It contained only letters (lower and upper case) and numbers - no special characters. [root@localhost ~]# ./chk_luks_keyslots /dev/sdb2 Sectors with entropy below threshold (0.850000): Keyslot 0: start: 0x1000 Keyslot 1: start: 0x40000 keyslot not in use Keyslot 2: start: 0x7f000 keyslot not in use Keyslot 3: start: 0xbe000 keyslot not in use Keyslot 4: start: 0xfd000 keyslot not in use Keyslot 5: start: 0x13c000 keyslot not in use Keyslot 6: start: 0x17b000 keyslot not in use Keyslot 7: start: 0x1ba000 keyslot not in use
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Ill close this bug, after some time I just format this disk and he has bad sectors. So is probably hardware problem fault. Thanks for tracking ^^