Post #4274976

I should have threaded this entire thing but it was all scattershot posting anything, lets start the thread now. And to make it clear: I'd be appreciating advice here, if there are any wizards around. So, after an update + reboot yesterday my laptop (Arch btw) doesn't want to do decryption for the full disk encryption anymore. Setup: UEFIone nvme drive, gpt, two partitions: /efi and encrypted lvmencryption is LUKS2, aes-xts-plain64, hmac(sha256) for integrityinside are then the actual partitions + swapsystemd-boot into a dracut uefi imagesecureboot stuff but I turned that off for troubleshooting The issue occurs when systemd-cryptsetup tries to open the luks partition, immediately after the password is entered - unfortunately there doesn't appear to be an option to fall back to a shell to troubleshoot/look at the logs in more details. Initially the error message was: device-mapper: table: 253:0: integrity: unknown target type For good luck I added dm_integrity to dracuts force_drivers (assuming it had somehow forgotten that dm-integrity is a thing). This changed the error message, I assume by "solving" the issue of missing dm-integrity at that point in the boot process. Now I am stuck with device-mapper: table: 253:1: crypt: Error allocating crypto tfm (-ENOENT) (same spot in the boot process). For good luck I threw a few more kernel modules into the force_drivers option (everything that was used, directly or indirectly, by dm_crypt on the live USB, force_drivers+=" dm_integrity dm_crypt aead dm_mod dm_bufio encrypted_keys trusted tee asn1_encoder ") but no dice. The disk encryption itself is fine, after rolling back all updates over the last week or so (by booting from a USB dongle) it boots without (noticable) issues. By upgrading packages in small groups I managed to narrow the "causing" update down to the jump from glibc 2.43 to 2.44, specifically https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/commit/47e26c81a1e45ba847372781dd6ca6a7b381367a ). There was nothing in the notes for 2.44 that looked to be relevant but I know shitall about that, lol. I found a temporary workaround, downgrading glibc to a 2.43 version before regenerating the image, but it's not a solution. Interestingly I noticed that the glibc 2.44 version of the linux-*.efi is only 60MB while the 2.43 (functional) version is 90MB - no idea what this matters but -30% is def. noticable, lol. But yeah, if there are any folx with ideas lmk...