[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]

Control: retitle -1 cryptsetup-initramfs: user is prompted for password even when the detached header is missing

On Fri, 23 Nov 2018 at 17:05:13 +0100, Mikhail Morfikov wrote:
> So, to open my laptop, I have to connect the USB device (my phone)
> first. In order to make this work, I had to write some script and put
> it in the /etc/initramfs-tools/scripts/local-block/mount-boot file.

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.
 
> So where's the problem? Why it's not working well now, and it was
> working in the past?

I don't think it was ever working as it should.  local-block scripts are
called with the name of a local block device to create/unlock/activate
(e.g. devices holding /usr).  And they are run after local-top scripts,
so they can assume that the root device node is present.

AFAICT, what happened before is that the loop failed before the password
prompt, so cryptroot failed early, and init moved to local-block without
root device node.  There, since /scripts/local-block/cryptroot doesn't
depend on mount-boot, the script was likely run — and failed — another
time before mount-boot had a chance to run, and the 3rd run cryptroot
can finally succeed.  All of this is brittle and racy, and broke when
(inadvertently) removed the checks for detached header presence.

-- 
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/34a04686/attachment.sig>