systemd-cryptsetup works when called manually, but when using the unit, it doesn't recognize FIDO2 key

[fogti]

systemd version the issue has been seen with

systemd 249 (v249.7-2.fc35)

Used distribution

Fedora Linux 35

Linux kernel version used (uname -a)

5.15.10-200.fc35.x86_64
dracut 055-6.fc35
(I don't have access to the affected machine right now, so I can't provide more exact info)

CPU architecture issue was seen on

x86_64

Expected behaviour you didn't see

systemd-cryptsetup unit file works as expected, and provides the same result as when calling the systemd-cryptsetup executable directly

Unexpected behaviour you saw

starting the specific systemd-cryptsetup service unit fails, it doesn't seem to recognize the plugged-in FIDO2 key; I think there was another bug (afaik #19872), that prevented the password fallback from working, so to boot into the system, a live disk boot was required to remove the fido2-device=auto setting from crypttab and rerun dracut.

Steps to reproduce the problem
not exactly known, but installing the specified fedora environment, then set up a FIDO2 key via systemd-cryptenroll, and adjust /etc/crypttab and create a dracut config to make sure that the fido2/yubikey libraries are present (this may not be necessary, but it precludes a possible failure scenario)
e.g. create etc/dracut.conf.d/yubikey.conf with the following content:

install_items+=" /usr/lib64/libfido2.so.1 /usr/lib64/libyubikey.so.0 "

In /etc/crypttab, a new entry for the root device is created with fido2-device=auto as option (maybe also add a timeout, but afaik that doesn't work as expected).
In the concrete system setup, a modification to the udev rules was done to make sure that libinput doesn't recognize the FIDO2 key as a keyboard, but it shouldn't affect this problem.
Run dracut --regenerate-all --force to regenerate the initrd.

Additional program output to the terminal or log subsystem illustrating the issue

Not available currently; I tried strace-ing it, and it worked as expected when called directly, but I was unable to trace the execution of the unit file. As this usually causes the boot to hang for a while, and then afaik switch to emergency mode, it's especially annoying to debug.

…

Potentially related
https://bugzilla.redhat.com/show_bug.cgi?id=1965482

[poettering]

So, what's the error you see?

So this works from a shell on the host, but not in a service in the initrd? What about from shell in the initrd or from a service on the host?

With the little info provided this really just looks like dracut problem, i.e. some parts necessary for libfido2 missing from your initrd.

[poettering]

maybe rules.d/60-fido-id.rules is missing in your initrd? and fido_id? only if that's in plce we can sanely wait for the fido2 device to be plugged in. If the rule or the tool are missing we'll not be woken up once the device is plugged in, or is probed by the kernel.

[guyru]

Thanks, I had the same issue in Debian and indeed I was missing 60-fido-id.rules and fido_id in my initramfs. After adding those files, the issue is now resolved, and the Yubikey is consistently recognized.

[fogti]

I'll regain access to the (on my end) affected system in roughly 2 weeks, and will try that.

[fogti]

yes, that works.