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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
