On 2018-02-19 01:44, Guilhem Moulin wrote: > Control: retitle -1 cryptsetup: Using luks2 with argon2 PBKDF produces an > unbootable system > > On Mon, 19 Feb 2018 at 00:02:02 +0100, Mikhail Morfikov wrote: >> Since in Debian Sid we have a cryptsetup v2 for some time, I wanted to >> wipe my current system and install a fresh one in the LUKS/LVM setup. > > Note that LUKSv1 devices can be converted to LUKSv2, no need to wipe the > whole device. One needs to add a new slot to change the PBKDF from > PBKDF2 to argon2i, though. Yes, I know about this, but I wanted change the entire disk layout and needed a fresh LUKS container anyway.
>> cryptsetup luksFormat /dev/sdb1 \ >> --type luks2 \ >> […] >> --pbkdf argon2i \ >> […] >> The LUKS2 container could be easily opened using that livecd (with the >> cryptsetup and lvm2 package from Sid), but system was unable to boot >> with an error saying something about missing libgcc_s.so.1 . > > Looks like we only tried unlocking luks2+PBKDF2 unlocking at initramfs > stage. argon2i and argon2id use pthread_cancel, so that file needs to > be copied to the initrd. Done in 9a70b2d. > >> I tried to fix this locally and added the missing lib to the initramfs, but >> unfortunately this step fixed the issue only partially -- the system was able >> to detect the LVM volumes but it was asking to type password for the >> container >> again and again, and the boot failed ultimately. > > I was not able to reproduce that, even with libgcc_s.so.1 in the initrd. > Could you start the boot script in debug mode so we see why it loops? > > https://wiki.debian.org/CryptsetupDebug > I had to create LUKS1 container because I needed my system to be fully functional after the weekend, but I can try converting LUKS1 to LUKS2 and see what's wrong there when I get some free time, if of course the problem still persist. >> I also found this link that describes the exact same issue. >> https://bugs.archlinux.org/task/56771 > > cryptsetup auto-creates the lock directory (chosen at compile time) > assuming its parent exists. Your link mentions 2.0.0 which had > /run/lock/cryptsetup for locking directory; it was a problem since > /run/lock wasn't present at initramfs stage. OTOH 2.0.1 uses > /run/cryptsetup, which should be created automatically. I just pushed a > change (e31db51) to create it before calling cryptsetup, in order to > avoid warnings. >
signature.asc
Description: OpenPGP digital signature
