On Fri, 23 Nov 2018 at 19:12:30 +0100, Mikhail Morfikov wrote: >> cryptsetup-initramfs' ‘cryptroot’ is run (last) is local-top, so before >> your own script. So ‘cryptroot’ is bound to fail after trying to open >> the device a couple of times. Please move your script to local-top, and >> maybe add a loop to make it block when the device is not present. > I moved the script to local-top/ and now I'm unable to unlock the system > container. I tried 15 times, and it can't detect the USB device.
Did you also add a loop to wait for the block device holding the LUKS header? Since the device is discovered asynchronously you need to wait for it in order to eliminate the race. > So something has been changed somewhere. Yes, the check for header presence, as written previously. Since 2:2.0.3-2 it's (incorrectly) done in the password prompt loop, which eats more time hence is more likely to hit the ‘rootdelay’ timeout. But I maintain that the local-block logic is racy in the first place. Since you need your USB device to unlock the root device, you need to make sure it's available before ‘cryptroot’ is run. Again, in both < and ≥2:2.0.3-2, ‘cryptroot’ is run a first time (at local-top stage) — and fails to unlock the root device, then a second time (at local-block stage) — and also fails to create the root device, then your script mounts /boot, and finally ‘cryptroot’ is run again — and this time not bound to fail. In <2:2.0.3-2 the header presence check caused the first two executions to fail *early*; in ≥2:2.0.3-2 the first two executions each issue 3x (configurable with ‘tries=<num>’) dummy passwords prompts hence don't fail so quickly. Assuming that the script would fail early was problematic: it might take time to run — whether it succeeds to unlock the root device or not — because there are a whole bunch of other available devices to unlock (resume devices, devices holding /usr, etc.) -- Guilhem.
signature.asc
Description: PGP signature
