[pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype

[Jonas Meurer]

Hello,

Am 22.08.2018 um 22:22 schrieb Ben Hutchings:
> On Tue, 2018-08-21 at 08:38 +0300, Nazar Mokrynskyi wrote:
>> 21.08.18 02:57, Ben Hutchings пише:
> [...]
>>> LVM inside LUKS (I don't know why you call it multi-layer LVM) is well
>>> supported in Debian, so I find this statement surprising.
>>
>> I know it is supported and expressed this awareness initially.
>> I call it multi-layer because it has concepts of VGs, PVs and LVs,
>> which are not straightforward to use, I know  this is not technically
>> correct, sorry about that.
>> For instance, I was recently moving my fully encrypted Ubuntu (LVM on
>> top of LUKS) from 500GB HDD to 256GB SSD.
>> It was a painful and risky operation with no support from graphical
>> utilities. I did it successfully, but I'd like to not doing this ever
>> again.
>> Which is why I found regular partition table much easier to use - I
>> can just open it with GParted, shrink partitions, move them to the
>> beginning of the disk and `dd` as much of it as I need. Easy.
> 
> Yes, shrinking is easy to get wrong with the command line tools.
> 
> On the other hand, moving to new physical media is generally easier and
> safer with LVM: you add the new PV to the group, use pvmove to move all
> volumes, and then remove the old PV.  This can be interrupted without
> losing data.
> 
>>> What's more, Linux block drivers have to opt in to supporting
>>> partitions, and dm-crypt doesn't do that.  So the kernel doesn't look
>>> for a partition table on a dm-crypt device.
>>
>> The primary issue for me is that LUKS container can contain a valid
>> partition table and I can add a hook for initramfs to recornize it,
>> but because cryptsetup integration checks for known partitions an
>> doesn't find any, it closes LUKS container immediately with "unknown
>> fstype, bad password or options?".
>> This is extemely inconvenient and requires me to edit initramfs's
>> files, wich will be reverted on upgrades, and I'd like to avoid it by
>> having native support so this use case.
> 
> So this should be dealt with in cryptsetup-initramfs.

Mh. When using LUKS, the cryptsetup scripts should not do any post
checks by default. Can you send a detailed log of the script execution?
Maybe indeed our initramfs rewrite introduced a regression here.
Guildhem, could you look into this?

>> Why not returning `pttable` too, indicating that it is not a garbage
>> inside of it?
>> Or do you suggest that cryptsetup integration needs to be adjusted
>> instead?
> 
> I think cryptsetup should be adjusted.
> 
> Looking at the local-top script from cryptsetup-initramfs, it seems to
> depend rather too closely on details of both initramfs-tools and lvm2.
>  
> - Why does it try to activate a volume group directly?  lvm2's scripts
> should do that.

The problem is that we support both setups with dm-crypt on top of lvm
and lvm on top of dm-crypt. That's why we mess around with lvm directly,
since the lvm2 local-top script is executed after cryptroot.

> - I don't think it should probe the contents of the encrypted volume at
> all.  That would mean that a wrong password for a non-LUKS device won't
> be specifically detected and reported.  But LUKS is strongly
> recommended, and I don't think this makes the non-LUKS user experience
> significantly worse.

For non-LUKS devices, the post checks are the only possibility to detect
whether you successfully entered the correct passphrase (or provided the
correct key). Besides, it provides a security measure against accidently
overriding the wrong partitions when setting up encrypted tmpfs or swap
partitions.

Cheers,
jonas

-------------- 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/20180823/fe9154a7/attachment.sig>