Re: [systemd-devel] systemd-cryptsetup@.service crash during boot with fido2-device=auto
> 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
Re: [systemd-devel] systemd-cryptsetup@.service crash during boot with fido2-device=auto
On Di, 17.05.22 23:03, Anton Hvornum (an...@hvornum.se) wrote: > Hi. > > I've been asking around everywhere for some assistance. > The full issue can be found here: > https://www.reddit.com/r/archlinux/comments/urnj8x/help_getting_fido2_and_systemdcryptenroll_working/ > > The short version is, I got `systemd-cryptenroll --fido2-device=auto > /dev/sda2` to work. > Unlocking it works with a password, but it's not trying to use the > fido2-device as expected. > > Whenever I add `/etc/crypttab` to the initramfs > `systemd-cryptsetup@luksdev.service` crashes. Crashes? What does that mean? As in segfault? If so, please provide a stacktrace, otherwise this is not actionable to us. > And I'm wondering, is it required for the USB device to come alive > before this service tries to execute? 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. > > As far as I can tell, it executed: > /lib/systemd/systemd-cryptsetup attach 'luksdev' '/dev/sda2' 'none' > 'luks,fido2-device=auto' > > And by default if executed on a live medium that will hang waiting for > the HSM to be inserted and will work. But I can't figure out why the > service would break if that is all it does. > > As soon as I create a /etc/crypttab or omit tpm2-device=auto from the > kernel command-line, the boot process breaks. Buf it I don't use > /etc/crypttab or I have tpm2-device=auto the service succeeds - but > won't use the fido device.. And that's probably obvious for everyone > here but I'm stumped. hmm, fido? or tpm? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptsetup@.service crash during boot with fido2-device=auto
Found the solution. `/etc/crypttab` had to be removed as it caused a startup crash. `libfido2.so.1` library was missing so installed the appropriate package (in this case libfido2) The kernel option `tpm2-device=auto` had to be removed, as it forces an override and ends up forcing a password prompt.. And this is independently of the order the options come in. I would assume that `fido2-device=auto` would force it to try accessing FIDO2 devices first, and then fallback to tpm2-device but that does not appear to be the case. Apologies for the lengthy email. Best regards, //Anton On Tue, May 17, 2022 at 11:03 PM Anton Hvornum wrote: > > Hi. > > I've been asking around everywhere for some assistance. > The full issue can be found here: > https://www.reddit.com/r/archlinux/comments/urnj8x/help_getting_fido2_and_systemdcryptenroll_working/ > > The short version is, I got `systemd-cryptenroll --fido2-device=auto > /dev/sda2` to work. > Unlocking it works with a password, but it's not trying to use the > fido2-device as expected. > > Whenever I add `/etc/crypttab` to the initramfs > `systemd-cryptsetup@luksdev.service` crashes. > Not sure how to debug it since it's the root partition. But I > increased the loglevel on the kernel to 7 and found that the Yubikey > comes up after the service crashes. > > And I'm wondering, is it required for the USB device to come alive > before this service tries to execute? > > As far as I can tell, it executed: > /lib/systemd/systemd-cryptsetup attach 'luksdev' '/dev/sda2' 'none' > 'luks,fido2-device=auto' > > And by default if executed on a live medium that will hang waiting for > the HSM to be inserted and will work. But I can't figure out why the > service would break if that is all it does. > > As soon as I create a /etc/crypttab or omit tpm2-device=auto from the > kernel command-line, the boot process breaks. Buf it I don't use > /etc/crypttab or I have tpm2-device=auto the service succeeds - but > won't use the fido device.. And that's probably obvious for everyone > here but I'm stumped. > > Any help would be appreciated but is in no way expected. > > //Anton
[systemd-devel] systemd-cryptsetup@.service crash during boot with fido2-device=auto
Hi. I've been asking around everywhere for some assistance. The full issue can be found here: https://www.reddit.com/r/archlinux/comments/urnj8x/help_getting_fido2_and_systemdcryptenroll_working/ The short version is, I got `systemd-cryptenroll --fido2-device=auto /dev/sda2` to work. Unlocking it works with a password, but it's not trying to use the fido2-device as expected. Whenever I add `/etc/crypttab` to the initramfs `systemd-cryptsetup@luksdev.service` crashes. Not sure how to debug it since it's the root partition. But I increased the loglevel on the kernel to 7 and found that the Yubikey comes up after the service crashes. And I'm wondering, is it required for the USB device to come alive before this service tries to execute? As far as I can tell, it executed: /lib/systemd/systemd-cryptsetup attach 'luksdev' '/dev/sda2' 'none' 'luks,fido2-device=auto' And by default if executed on a live medium that will hang waiting for the HSM to be inserted and will work. But I can't figure out why the service would break if that is all it does. As soon as I create a /etc/crypttab or omit tpm2-device=auto from the kernel command-line, the boot process breaks. Buf it I don't use /etc/crypttab or I have tpm2-device=auto the service succeeds - but won't use the fido device.. And that's probably obvious for everyone here but I'm stumped. Any help would be appreciated but is in no way expected. //Anton
