[pkg-cryptsetup-devel] Bug#914458: Bug#914458: cryptsetup-initramfs: Unable to open the LUKS system container at boot with the right password 6 times

[Guilhem Moulin]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20181123/174ffb8e/attachment.sig>