Breaking change in cryptsetup 2.6.1-3

Support
1

I just installed the latest stable updates on my laptop and found that my LUKS unlock with TPM2 was broken. Took me a while to track it down but I finally narrowed it down to just the cryptsetup 2.6.1-3 package – by downgrading to 2.6.1-1 the automatic unlock works again.

I strongly suspect that it’s related to this change, but I’m not certain the best route to get it reported to the upstream – I’ve heard that arch folks tend to turn away reports from manjaro users.

Anyone have suggestions with regards to how I would get this reported/fixed upstream in a way that won’t be ignored?

2 Likes
2

Please follow the announcements

There are more replies regarding this issue.

1 Like
3

That’s actually a different problem than what I’m experiencing. Grub does not error with mine, it starts the boot sequence and prompts for a passphrase to unlock the volume when it is configured to unlock automatically with the TPM. I tried the grub change recommended by that post and it did not correct the issue. The fix was to downgrade cryptsetup.

4

I’ll re-release 2.6.1-1 as 2.6.1-3.1 and the current 3 revision as 3.2 to unstable …

5

Having the same issue with cryptsetup-2.6.1-3.2. the following log line appears after booting the system using the recovery key:

systemd-cryptsetup[293]: TPM2 support is not installed.

Downgrading cryptsetup to 2.6.1-1 using:

sudo pacman -U https://archive.org/download/archlinux_pkg_cryptsetup/cryptsetup-2.6.1-1-x86_64.pkg.tar.zst

and re-enrolling the new key in the luks headers with systemd-cryptenroll solved the problem.

6

I had the same problem an tracked it down to to a dependency between cryptsetup and systemd.

Till cryptsetup-26.1-1 tss2-{{esys,rc,mu},tcti-''}* were installed from cryptsetup.
After 26.1-1 this was removed and systemd (253.1-3)installs these files.

The problem is now cryptsetup is up to date with mainstream but systemd is not.

7

Somehow the wrong cryptsetup was pushed to stable branch. Will fix it again.