FS#66531 - [cryptsetup][json-c] no password prompt in initramfs

Attached to Project: Arch Linux
Opened by zarak (zarak) - Monday, 04 May 2020, 10:42 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 05 May 2020, 09:53 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

cryptsetup 2.3.2 breaks password prompt on boot (at the initramfs stage) to decrypt encrypted root partition.

The `running hook [encrypt]` is displayed, but no password prompt shows up. Keyboard seems to be working (I can return lines, and pressing keys show keycodes).

Downgrading to cryptsetup 2.3.1 solves this issue.

Configuration:

`mkinitcpio.conf`
```
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt lvm2 filesystems fsck)
```

```
$ bootctl --version
systemd 245 (245.5-2-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
```

/boot/efi/loader/entries/arch.conf
```
$ cat arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /amd-ucode.img
initrd /initramfs-linux.img
options cryptdevice=UUID=83dc202d-8014-4b12-887c-894c30ec1df9:cryptlvm root=/dev/mapper/vg-root resume=/dev/mapper/vg-swap
```

```
$ sudo blkid
...
/dev/nvme0n1p6: UUID="83dc202d-8014-4b12-887c-894c30ec1df9" TYPE="crypto_LUKS" PARTUUID="96213222-9455-cd42-a938-7c4b601885bb"
...
```
This task depends upon

Closed by  Christian Hesse (eworm)
Tuesday, 05 May 2020, 09:53 GMT
Reason for closing:  Fixed
Additional comments about closing:  json-c 0.14-2
Comment by zarak (zarak) - Monday, 04 May 2020, 10:46 GMT Comment by freswa (frederik) - Monday, 04 May 2020, 12:39 GMT
Maybe  FS#66498 ?
Comment by zarak (zarak) - Monday, 04 May 2020, 12:48 GMT
I don't know. I don't use the allow-discards flag, but I tried it while trying to make it work. From what I remember, it did not change anything, not even printing the "Discard/TRIM is not supported." message (however I haven't checked any log file, so I'm not totally sure)
Comment by nl6720 (nl6720) - Monday, 04 May 2020, 12:58 GMT
Try a systemd based initramfs with the sd-encrypt hook: https://wiki.archlinux.org/index.php/Mkinitcpio#Common_hooks & https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#Using_sd-encrypt_hook .

You'll need to replace the "cryptdevice=..." parameter with "rd.luks.name=83dc202d-8014-4b12-887c-894c30ec1df9=cryptlvm".
Comment by zarak (zarak) - Monday, 04 May 2020, 13:50 GMT
That's what I tried, I even generated crypttab.initramfs, but I could not manage to make it work, got stuck at boot by systemd trying to start cryptsetup, which timed out without asking for my password. journalctl stated things about plymouth, which is not installed on my machine, and nothing clear on what the real issue could be. I tried to tweaks some things, but I kept stuck on this error. I have no clue how it works nor how to debug it, so I switched back from sd-encrypt to encrypt and downgraded cryptsetup to be able to boot my computer
Comment by Christian Hesse (eworm) - Monday, 04 May 2020, 13:53 GMT
You could boot the live ISO, update it (not your system) to latest versions, including cryptsetup 2.3.2-1.
Then try to open your encrypted volume, adding option `--debug`.
Comment by zarak (zarak) - Monday, 04 May 2020, 14:28 GMT
Here's the photo of what's happening with the latest archlinux ISO. cryptsetup hangs after print the checksums.
I tried strace-ing it, not sure if it's useful (2nd photo) : `strace cryptsetup open /dev/nvme0n1p6 root`
Comment by Christian Hesse (eworm) - Tuesday, 05 May 2020, 07:34 GMT
I am confused now... Looks like you did not update the live environment and used cryptsetup 2.3.1-3.
So this version shows the same issue?
Comment by zarak (zarak) - Tuesday, 05 May 2020, 08:49 GMT
Sorry, I'm an idiot.

I did some more testing, and here's what I found: (pics attached)
- cryptsetup 2.3.2-1 and json-c 0.14-1 -> bug
- cryptsetup 2.3.1-3 and json-c 0.14-1 -> bug
- cryptsetup 2.3.1-1 and json-c 0.13.1-3 -> works (and currently on my machine)

I hope this better helps you. Let me know if and how I can help you further investigate this issue.
Comment by zarak (zarak) - Tuesday, 05 May 2020, 08:50 GMT
$ cryptsetup status cryptlvm
/dev/mapper/cryptlvm is active and is in use.
type: LUKS2
cipher: aes-xts-plain64
keysize: 512 bits
key location: keyring
device: /dev/nvme0n1p6
sector size: 512
offset: 32768 sectors
size: 502425615 sectors
mode: read/write
Comment by Christian Hesse (eworm) - Tuesday, 05 May 2020, 09:09 GMT
Looks like we can be sure this is caused by json-c update and/or compatibility commits (upstream 604abec333a0efb44fd8bc610aa0b1151dd0f612 & e6a356974330e3ae21579a5737976e9a2aad1b51).
Sadly I can not reproduce... Perhaps opening an upstream issue makes sense. Would you do that?
Comment by Christian Hesse (eworm) - Tuesday, 05 May 2020, 09:19 GMT
The new json-c is reported to have issues with broken RDRAND during initialization.
Wondering if this could cause the issue... Are you running recent AMD CPU with broken RDRAND?
Comment by Christian Hesse (eworm) - Tuesday, 05 May 2020, 09:26 GMT
Anybody wants to try json-c 0.14-2 (with cryptsetup 2.3.2-1)?
Comment by zarak (zarak) - Tuesday, 05 May 2020, 09:36 GMT
Yes indeed I am, I'm running Ryzen 3700X with the "RDRAND funky smelling output". It did not prevent me from booting since I got it, so I thought it was not a big deal tbh. Not sure how to patch it however. I'll give a deeper look , but it's curious, the case seems to be handled by json-c: https://github.com/json-c/json-c/blob/master/random_seed.c#L68
Comment by Christian Hesse (eworm) - Tuesday, 05 May 2020, 09:38 GMT
Just install json-c 0.14-2 into the live environment to test:

pacman -U https://www.archlinux.org/packages/testing/x86_64/json-c/download/
pacman -Sy cryptsetup
Comment by zarak (zarak) - Tuesday, 05 May 2020, 09:49 GMT
Yup, it's working !
Comment by Christian Hesse (eworm) - Tuesday, 05 May 2020, 09:51 GMT
Great, thanks for testing!

Loading...