882f5f429e
Previously we would call umount from ExecStartPost= of systemd-cryptsetup instance in order to get rid of the keydev mount (i.e. filesystem containing keyfile). Let's generate unit to handle umount. Making this symmetrical (both mount and umount of keydev are handled by units) fixes the problem with lingering keydev mounts. Motivation for the change is the issue where keydev mount would stay around even if device was successfully unlocked and mount is no longer needed. That could happen previously because when generator options are not prefixed with "rd." we run generators twice (e.g. rd.luks.key=...). In such case disk is unlocked in initramfs phase of boot (assuming the initrd image contains the generator and is able to handle unlocking of LUKS devices). After switchroot we however enqueue start job for systemd-cryptsetup instance (because units are regenerated second time) and that pulls in its dependencies into transaction. Later the main systemd-cryptsetup unit not actually started since it is already active and has RemainaAfterExit=yes. Nevertheless, dependencies get activated and keydev mount is attached again. Because previously we called umount from ExecStartPost= of systemd-cryptsetup instance the umount is not called second time and keydev filesystem stays lingering. |
||
|---|---|---|
| .. | ||
| cryptsetup-generator.c | ||
| cryptsetup-keyfile.c | ||
| cryptsetup-keyfile.h | ||
| cryptsetup-pkcs11.c | ||
| cryptsetup-pkcs11.h | ||
| cryptsetup.c | ||