[pkg-cryptsetup-devel] Bug#890798: Bug#890798: cryptsetup: Using luks2 produces an unbootable system

[Mikhail Morfikov]

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.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20180219/74d9019c/attachment.sig>