Bug#618862: Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround
Am 27.08.2015 um 10:28 schrieb Martin Pitt: > unmerge 756202 > reopen 786393 > reopen 618862 > thanks > > Meh, #756202 is something entirely different than #786393 and #618862. Yes and no. At least the bug report in [1] has cryptswap UUID=x-xxx---xdc3 sda4_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap in his crypttab. So it's the same keyscript issue. But yeah, for the original bug reporter it might actually just be a broken UUID for the swap line in /etc/fstab. Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756202#10 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#618862: Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround
unmerge 756202 reopen 786393 reopen 618862 thanks Meh, #756202 is something entirely different than #786393 and #618862. Unmerging and reopening the latter two. Sorry for the noise! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround
Hallo, The file /etc/init/cryptdisk.conf refers to a possible race condition (/lib/cryptsetup/cryptdisks.functions) " # This job currently still does not guarantee a race-free startup; instances # of cryptdisks-udev may be started in parallel with this job. " hth, Wim Referencing: 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?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786393: systemd: should not try to open encrypted devs that were already opened succesfully, workaround
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
