clevis-luks-askpass does not wait for tpm device to appear

[dadevel]

While booting the kernel takes longer than expected to initialize my TPM.
Relevant dmesg log entries:

tpm0: tpm_try_transmit: send(): error -62
tpm0: [Firmware Bug]: TPM interrupt not working, polling instead

The TPM is fully functional afterwards, but this leads to the peculiar problem that clevis-luks-askpass tries to find a TPM before the kernel is done initializing it. So /dev/tpm0 doesn't exist at this point. At least I think that's what happens.

Relevant journalctl excerpt:

systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: Started Forward Password Requests to Clevis.
systemd[1]: clevis-luks-askpass.service: Succeeded.
systemd[1]: clevis-luks-askpass.service: Start request repeated to quickly.
systemd[1]: clevis-luks-askpass.service: Failed with result 'start-limit-hit'.
systemd[1]: Failed to start Forward Password Requests to Clevis.

So my workaround is this clevis-luks-askpass.patch:

--- a/clevis-luks-askpass
+++ b/clevis-luks-askpass
@@ -35,6 +35,10 @@
     esac
 done
 
+until [ -c /dev/tpm0 ]; do
+    sleep 1
+done
+
 while true; do
     for question in "${path}"/ask.*; do
         # question will expand to itself, in case no files match, so we verify

I know that this is a bad solution.
How can this case be handled properly?

[sarroutbi]

Hi @dadevel.

I guess the best option for this should be playing with StartLimitIntervalSec=interval, StartLimitBurst=burst options for this particular unit. If the default values (5 restarts in a 10sec period) are not valid, playing around with those values and the Restart= option could help in this particular scenario. You can have a look at systemd.unit and systemd.service man pages for more information.