Now that I have solved some very real problems in debian based distros using encrypted luks and smartcards I'd like to share. This seems daunting. Debian is known for red tape.... I need to prepare some items before moving forward
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042094
yes. someone asked for supporting systemd-pkcs11 in initramfs-tools but was told that debian is moving to dracut and that they won't fix. I emailed him but don't know if he is using a smartcard like I am and I realized that I didn't test configuring encrypted root without a smartcard at all. My fallback mode will cover this case but there will be a delay as the system looks for a smartcard....
Debian is moving from initramfs to dracut. Since I couldn't get dracut to work this may become a problem. There is a discussion about ubuntu needing dracut to support encryption and other stuff related to this at https://github.com/dracut-ng/dracut-ng/issues/748
From the last comment it seems like dracut wants to slim the initrd down to minimal. while this is a good optimization it does not work for all use cases e.g. portable systems such as live USBs.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042094
https://groups.google.com/g/linux.debian.bugs.dist/c/hpLz9mBW6G0/m/AQ3kN5IBCAAJ
#1024775 - systemd-cryptenroll --pkcs11-token-uri=list PKCS#11 tokens not supported on this build
This is the most directly PKCS#11-specific Debian bug I found. It points to Debian builds lacking PKCS#11 support in systemd-cryptenroll, which is a prerequisite for PKCS#11-backed LUKS enrollment and boot unlock.
#1007268 - Enable LUKS unlock with security keys (FIDO2/PKCS11/TPM2)
This is a feature/support gap bug for Debian’s systemd-cryptsetup path. It explicitly mentions PKCS#11 for unlocking LUKS disks, so it is very relevant even if it is not phrased as a boot regression.
#1042094 - initramfs-tools: Please support systemd-cryptsetup unlocked encrypted root filesystem
This one is root-boot specific. The snippet is TPM2-focused, but it is about Debian’s initramfs path not supporting systemd-based token-backed root unlock properly. That is adjacent to PKCS#11 and likely part of the same packaging gap.
#1031254 - cryptsetup: unable to boot rootfs via TPM / unknown option tpm2-device tpm2-pin
Not PKCS#11, but very relevant to the same “systemd token unlock for encrypted root fails at boot on Debian” class of issue.
#1092977 - debian-installer: systemd-cryptsetup ...
This appears to involve encrypted root installed via Debian testing, with systemd-cryptsetup behavior during boot. Again, not PKCS#11-specific from the search snippet, but in the same boot path.
#1098221 - systemd: systemd-cryptsetup-generator ...
This is about discrepancies between Debian crypttab handling and systemd-cryptsetup-generator. That matters for token-based boot unlock because those options are carried via crypttab.
#1075882 - systemd + crypttab not working after 256-2
Generic crypttab regression after a systemd upgrade. Not PKCS#11-specific, but potentially relevant if you are seeing a newer-systemd root boot failure.