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

[Mikhail Morfikov]

On 22/12/2018 16:48, Guilhem Moulin wrote:
> Disk images, key files, and detached headers can reside on arbitrarily
> complicated file systems and block device stack, and setting up these
> stacks to make the files available prior to unlocking is really not the
> job of our initramfs boot scripts.  I'm thus closing this bug as
> ‘wontfix’, sorry.
> 
I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup
one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If not, I
can ask about this problem upstream, but I thought it is debian specific, so
that's why I opened the issue here.

It's not about accessing as many devices at initramfs phase as possible, only to
open as many devices as possible at boot time using the /etc/crypttab file
instead of mixing debian/systemd (and probably some other) specific solutions. I
didn't see any info that the /etc/crypttab file is used only in initramfs stage
or should be used only in that stage (am I wrong?). I have always been using the
cryptdisks_{start,stop} scripts to open devices specified in the /etc/crypttab
in my system, and it was working just fine.

There's the "initramfs" parameter, which takes care of setting the encrypted
root file system in the initramfs stage. I have this parameter set to all real
devices, because without it the decrypt_keyctl script can't read the password
from the kernel keyring and hence my system it's not able to open the rest of
the encrypted containers. That's why I thought it could work also with the LUKS
file images, but it doesn't.

If the LUKS file images were real devices, there wouldn't be an issue since all
of the listed devices would be opened using the same password at boot/initramfs
time. But when you deal with LUKS containers in a file, you have to use
different solution. That's why I asked if there's a way to use  only the
/etc/crypttab file to make it work.

If this can't/won't be done, I stick with the systemd service I have already,
because it works just fine, though if I moved from systemd to other init, it
would stop.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20181223/3dbb547e/attachment.sig>