Description of problem: Booting a VM with many LUKS devices (9 devices, one per file system: / /usr /var /var/log /var/log/audit /tmp /opt /home and swap), clevis-luks-askpass exits after unlocking 1 device only, but systemd doesn't restart it because there is no change in the /run/systemd/ask-password directory. / /usr and swap were unlocked in the initramfs phase. We talk here about unlocking the rest: /var /var/log ... Currently, with actual code, it's not possible to unlock all these local file systems without modifying heavily the configuration through following Article https://access.redhat.com/articles/4500491 We suppose here that BZ 1784084 was implemented. Debugging shows the following race condition due to contention on the CPU (my VM has only 2 CPUs, which slows down the boot while setting up LUKS devices): 1. 1 systemd-cryptsetup@ instance sets a path in /run/systemd/ask-password 2. clevis-luks-asspass.service executes "/usr/libexec/clevis-luks-askpass -l" 3. the tool unlocks the device then finds out no other device has to be unlocked, hence starts exiting 4. at that moment other systemd-cryptsetup@ instances set their path in /run/systemd/ask-password 5. due to clevis-luks-asspass.service still being active from systemd's point of view (but currently exiting), systemd doesn't start a new clevis-luks-asspass.service instance later This leads to a hang of the boot. The only way to un-hang the boot is to "touch /run/systemd/ask-password" directory (done because I had a debug-shell ...). There is a design issue here: the script /usr/libexec/clevis-luks-askpass should probably run *forever* and get killed by systemd once cryptsetup.target is reached. Version-Release number of selected component (if applicable): clevis-11-2.el8.x86_64 How reproducible: Always on my VM having 2 CPUs and 9 LUKS devices (6 to unlock early after switching root)
AC: System with multiple LUKS encrypted partitions (included /) bound to tang server will boot without need of typing passwords.
Created attachment 1652060 [details] Proposed patch to use one clevis-luks-askpass per device
*** Bug 1751912 has been marked as a duplicate of this bug. ***
*** Bug 1784084 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:1595