Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround

[Wim Bertels]

Hallo,

Debugging what happens on fresh installation with an encrypted / partition and a normaal /boot partition

1. The loaded initramfs image (which was generated with a the version of crypttab at the moment of generation, let's call it crypttab_initramfs), opens the entries in crypttab_initramfs
2. At that point / (and also /etc or /etc/crypttab) is accessible for systemd.
3. Here the problem begins: systemd tries to re-open all the entries in /etc/crypttab;
this makes sense for entries that could or should not be opened by initramfs; this doesnt make sense for entries that were already opened.
>> Systemd should not try to open entries in /etc/crypttab that already have been opened.
(?a race condition because of the structure of systemd?)

U can simulate this.
1. Create an encrypted system, normal /boot, encrypted /root and maybe other encrypted devs
2. Generate the initramfs to boot with (eg update-initramfs)
3. ! Then change the crypttab entries to use a keyfile from a device (passdev script) and don't update the initramfs image.
4. Reboot
5. U will get the 1m30 delay caused by a job started by systemd using the keyfile again

As a workaround (on your own resposibility!), to get rid of the delay and still boot using a keyfile:
just generate the initramfs image with the setup u want,
and then change /etc/crypttab entries to passphrase entries

For example crypttab used to generate initramfs image:
crypt_root UUID=1b5 /dev/disk/by-label/ext_dev:/dir/key:10 luks,tries=1,keyscript=passdev
crypt_swap UUID=8af crypt_root luks,tries=1,keyscript=decrypt_derived

Then change to
crypt_root UUID=1b5 none luks
crypt_swap UUID=8af crypt_root luks,tries=1,keyscript=decrypt_derived
and don't regenerate the initramfs image!, just reboot.

hth,
Wim Bertels