Confirming on trixie (clevis-initramfs 20-1), with one correction to the impact statement: the bug also costs ~5.5 s on a *healthy* boot when more than one volume is unlocked by clevis. The fix is already in upstream v23 (Debian 23-1 in sid/forky), so a trixie stable update looks worthwhile.
Setup: two LUKS2 volumes in crypttab (root + resume swap), both with a clevis tpm2 pin (PCR 11), initramfs-tools, plymouth running. Why the report's "healthy boot" statement does not hold with two volumes: local-bottom/clevis only kills clevisloop once *all* local-top unlocking is done. After the first volume succeeds, luks2_decrypt() returns 1, the loop takes the failure branch (sleep 5, then the trailing sleep .5), and the askpass for the second volume waits for it. Measured with a temporary init-premount probe that logs `ps` to /dev/kmsg every 200 ms (kernel timestamps): 2.71 s root: tpm2_createprimary / load / unseal 4.16 s root unlocked, cryptsetup open succeeds -> `sleep 5` appears 4.57 s askpass for the swap volume is already waiting 9.16 s sleep 5 ends -> sleep .5 -> sleep .1 9.99 s clevis starts on the swap volume 11.85 s swap unlocked -> `sleep 5` again (killed by local-bottom) Workaround tested: a copy of the script in /etc/initramfs-tools/scripts/local-top/clevis with `shopt -s lastpipe` added (the script runs under bash, without job control), which makes the trailing `while` run in the current shell. Result: the window between "device-mapper: ioctl ... initialised" and "PM: Image not found" (i.e. both clevis unlocks) went from 9.9 s to 5.0 s (device-mapper at 4.14 s, resume check at 9.11 s), and the swap volume is now unlocked right after the root volume. Disclosure: I used an AI assistant (Claude) to help analyse the boot trace and draft this message; I reviewed the analysis, applied the workaround and measured the results on my own machine. Upstream status: v20, v21 and v22 still have the pipeline form; v23 replaces luks1_decrypt()/luks2_decrypt() with luks_decrypt(), which calls clevis_luks_unlock_device() without a pipeline. Upstream issue https://github.com/latchset/clevis/issues/342 (2021) describes the same"sleep 5 between each unlock" symptom and is still open.
