Re: systemd-cryptsetup@.service crash during boot with fido2-device=auto

[Anton Hvornum <anton@xxxxxxxxxx>]

> Crashes? What does that mean? As in segfault?
>
> If so, please provide a stacktrace, otherwise this is not actionable
> to us.

It was the systemd service systemd-cryptsetup@luksdev.service failing
(casual usage of crashing, apologies): https://i.imgur.com/HUletsU.jpg
No idea how to get the log for it since it's root being unlocked at
the time and recovery shell won't let me in due to locked root (I'm
guessing root not being available until / is unlocked)
Kernel debug verbosity 7 didn't give much either.

But the error is caused by `/etc/crypttab` containing the same
mapper-name as what systemd is trying to load I suspect.
That is independently on luks.* options to the kernel command line are
being used. So I clearly have a misconception on how that workflow is
intended to be used and I'm trying to learn/figure it out.

> Some initrds don't pick up the relevant fido2 udev
> rules. i.e. 60-fido-id.rules and such. Contact your distro's initrd
> maintainers for help on that.

I don't use udev in this step (to my knowledge) but use `systemd` hook instead.
Arch Linux instructions tells me to replace udev for systemd at least.
However kernel debug shows that udev rules still kick in so I'm
stumped here too.

> hmm, fido? or tpm?

fido.
Kernel command line:
rd.luks.options=fido2-device=auto,tpm2-device=auto,timeout=20
I would assume fido2 would be tried first.
Then tpm2.
And finally password prompt as a backup.
But it goes straight to the password prompt if TPM is not configured
on a hardware level.
It also never gives the opportunity for fido2 to be challenged.

Thank you for taking the time!
//Anton