Le 2014-10-08 23:21, Jonas Meurer a écrit :
Hey Luc,
Hi Jonas,
Am 03.10.2014 um 21:55 schrieb Jonas Meurer:
Am 03.10.2014 um 21:15 schrieb Luc Maisonobe:
I failed to reproduce the bug you discovered so far. Can you please
give
the latest packages from
https://people.debian.org/~mejo/debian/mejo-unstable/ a try and see
whether decrypt_keyctl still doesn't work for you?
The new packages allow to boot, but I still have to enter the key
twice,
once for each encrypted device.
Very strange. I'm still unable to reproduce the issues you encounter.
Could you do some futher testing for me?
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.
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.
best regards,
Luc
Kind regards,
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
