How to make boot drive encryption work with PKCS#11 Smart card in Fedora (35)

On Fedora Workstation 35 here. systemd v249 I am trying to unlock root LUKS volume with smart card on BOOT, but it does not work. I added to /etc/crypttab mydisk UUID=496e1cd5-712f-44ab-ad02-5fb6f7419af8 none pkcs11-token-uri=auto,luks,discard My disk is properly enrolled with sudo systemd-cryptenroll --pkcs11-token-uri=auto /dev/... and I can the slot with luksDump I verified I can mount with sudo /usr/lib/systemd/systemd-cryptsetup attach MountName /dev/... none pkcs11-uri=auto In reboot there is a password prompt. Console reads: Entering Cryptography Setup712f-44ab-ad02-5fb6f7419af8: Please enter passphrase for disk WDS...[diskmodel]: **Only the recovery password works here. There is no way to use the smart card and enter the pin for it** I am using the same crypttab approach and same smart card to unlock other drives (external HDD) and it works (Although not in disks, only on boot, Disks app always asks for password when I try to mount, but this is another issue). The smart card is Yubikey based. As per the announcement here: https://www.phoronix.com/scan.php?pa...lock-Encrypted and man here: https://www.freedesktop.org/software...@.service.html This functionality should work. I quote from the documentation:

In order to unlock a volume a password or binary key is required. systemd-cryptsetup@.service tries to acquire a suitable password or binary key via the following mechanisms, tried in order:

If a key file is explicitly configured (via the third column in /etc/crypttab), a key read from it is used. If a PKCS#11 token, FIDO2 token or TPM2 device is configured (using the pkcs11-uri=, fido2-device=, tpm2-device= options) the key is decrypted before use.

If no key file is configured explicitly this way, a key file is automatically loaded from /etc/cryptsetup-keys.d/volume.key and /run/cryptsetup-keys.d/volume.key, if present. Here too, if a PKCS#11/FIDO2/TPM2 token/device is configured, any key found this way is decrypted before use.

If the try-empty-password option is specified it is then attempted to unlock the volume with an empty password.

The kernel keyring is then checked for a suitable cached password from previous attempts.

Finally, the user is queried for a password, possibly multiple times, unless the headless option is set.