1.$ cat /etc/os-release NAME="Sisyphus" VERSION="20240122" ID=altlinux VERSION_ID=20240122 PRETTY_NAME="ALT Regular" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:sisyphus:20240122" BUILD_ID="Sisyphus 20240122" ALT_BRANCH_ID="sisyphus" HOME_URL="http://en.altlinux.org" BUG_REPORT_URL="https://bugs.altlinux.org/" LOGO=altlinux 2. Encrypted (with LUKS1) /home partition was created with installer. 3. Home partition was converted from LUKS1 into LUKS2 with cryptsetup (after install by using livecd). 4. LUKS2 decryption key was enrolled into TPM2 device on motherboard with systemd-cryptenroll utility. 5. An initrd image was rebuilted with make-initrd. 6. All was fine for several weeks, systemd updates worked successfully. Even when new filesystem update was performed at the last decade of april, all was fine. 7. Only officials repos are enabled all the time, with no other third-parties. Also snap and flatpack are completely disabled all the time. 8. Around middle of may 2024 after (probably) systemd update, the system started to aks /home decryption password again, and stopped using decryption key from TPM2. I continued to use my system that way (entering LUKS2 key manually on every system boot and mounting /home), with no actions for enrolling back any keys, in case just to see what may happened next. 9. With 24/05/2024 systemd update my system completely stops booting normally, and it didn't ask me either password for my encrypted /home partition, nor getting key from TPM2 device. 10. Booting in a failsafe mode and re-enrolling LUKS2 decription key into TPM2 device again and rebulding initrd after again helps me, and now system is booting ordinary way. Consider to test similar config (LUKS2+TPM, or, maybe not only TPM) before publish systemd updates. It seemes to me maybe better to check user's /etc/crypttab also? i.e. something like: cat /etc/crypttab | grep tpm and running systemd updates more safely (maybe with make-initrd after updates)?
