[pkg-cryptsetup-devel] Bug#917067: Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Guilhem Moulin]

Hi,

On Sat, 22 Dec 2018 at 04:09:02 +0100, Mikhail Morfikov wrote:
> All of the containers should be opened at boot time, but only the first two are.

Presumably because /dev/mapper/some_img is not required at initramfs
stage, ie, it's not holding /, /usr or the resume device(s).

> When I add "initramfs" to the third container, I get the following error:
> 
> -------
> cryptsetup: ERROR: Couldn't resolve device /home/me/luks/some.img
> -------

/home isn't mounted at initramfs stage, and the “real” home mountpoint
$rootmnt/home isn't mounted either, see initramfs-tools(7).

The cryptroot initramfs boot scripts won't try to mount anything; if an
extra file-system (other than / and /usr) needs to be mounted at early
boot stage, you'll need to arrange for it yourself, for instance with a
local-block script.
 
> For now, I use a systemd service which uses cryptdisks_start and
> cryptdisks_stop scripts. In this way the file image can be opened
> using the same password in the kernel keyring, but is there a way to
> make it work using only the /etc/crypttab file?

If you remove ‘keyscript=decrypt_keyctl’ systemd should be able to
unlock the device later in the boot process, once /home has been
mounted.  (systemd doesn't support ‘keyscript=’ currently, cf. #618862.)
To preserve unattended unlocking you could use a key file instead.

Cheers,
-- 
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/20181222/3b5d91d8/attachment.sig>