Hey Luc, Am 09.10.2014 um 09:54 schrieb luc: >> Am 03.10.2014 um 21:55 schrieb Jonas Meurer: >> Did you find time to do the additional testing/debugging yet? I'd like >> to fix this bug in time for Debian Jessie, provided that it's really a >> bug in the package and not an issue on your side ;) > > Not yet, but I intend to do so. > The problem occurs on a computer with some critical information on it, > and the partitions already use the full disk space. This implies I have > to do > some careful work of shrinking filesystems, logical volumes and so on > before I can > set up a test partition aside.
I see. But you don't need to resize your filesystems or go through similar hassle. Simply use file containers for testing. The following commands should setup a testing environment (use carefully, even though I tested them): # dd if=/dev/urandom of=/cont1 bs=1M count=3 # dd if=/dev/urandom of=/cont2 bs=1M count=3 # echo "testpw" | cryptsetup luksFormat /cont1 # echo "testpw" | cryptsetup luksFormat /cont2 # echo "cont1_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl" \ >> /etc/crypttab # echo "cont2_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl" \ >> /etc/crypttab # cryptdisks_start cont1_crypt # cryptdisks_start cont2_crypt >> As already mentioned - up to now I'm unable to reproduce the bug. For >> me, decrypt_keyctl works in all tested setups. The provided passphrase >> is stored in kernel keyring with first invokation and used for all the >> following device unlockings that have the same keyscript/keyname >> configured. > > I understand your point. It is difficult to debug here (as mentioned > earlier putting > some echo commands completely trashed the boot sequence). I'll do my best. I'm sorry that I brought you in troubles here. The echo command was untested and I at least should have written that. It was meant for debugging purposes only but it completely broke the keyscript. I'll try to not make such premature requests again :-/ Cheers, jonas >>> I test the decrypt_keyctl script with the following setup, and it works >>> as expected. Maybe you could try a similar setup: >>> >>> - create two small lvm logical volumes (5MB are more than enough) >>> - luksformat both logical volumes >>> - add them to your crypttab: >>> >>> clv1_crypt /dev/<VG>/<LV1> testkey1 luks,keyscript=decrypt_keyctl >>> clv2_crypt /dev/<VG>/<LV2> testkey1 luks,keyscript=decrypt_keyctl >>> >>> - try unlocking them via cryptdisks_start: >>> >>> # cryptdisks_start clv1_crypt >>> # cryptdisks_start clv2_crypt >>> >>> The second unlocking should use the key cached during first unlocking. >>> >>> It would be awesome if you could test this. I as well tested this setup >>> during boot process, and it works as expected as well. Also tested with >>> UUID instead of source device path in crypttab, same result. >>> >>> I've no glue what's different on your setups, and any help with >>> debugging would be highly appreciated. >>> >>>>> In case that you still encounter the bug, please paste your full >>>>> /etc/fstab and /etc/crypttab again. >>>> >>>> /etc/crypttab: >>>> >>>> sdb1_crypt UUID=9aa983b5-0224-406b-a177-7481162c6172 >>>> sda5_sdb1_common_key luks,keyscript=decrypt_keyctl >>>> sda5_crypt UUID=3764df68-de26-4a24-a7dc-1498cb6b20ab >>>> sda5_sdb1_common_key luks,keyscript=decrypt_keyctl >>> >>> Nothing suspicious here, looks ok to me. >>> >>>> Note that the two partitions contain physical volumes for LVM, as shown >>>> here: >>> >>> Actually the content of your encrypted devices should not matter at all. >>> >>> Kind regards, >>> jonas >>> >>> _______________________________________________ >>> pkg-cryptsetup-devel mailing list >>> pkg-cryptsetup-de...@lists.alioth.debian.org >>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel >>> >>> > > _______________________________________________ > pkg-cryptsetup-devel mailing list > pkg-cryptsetup-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org