21.08.18 02:57, Ben Hutchings пише:
> Control: notfound -1 0.131ubuntu8
> Control: found -1 0.132
> Control: tag -1 wontfix
>
> On Sun, 2018-08-19 at 15:39 +0300, Nazar Mokrynskyi wrote:
>> Package: initramfs-tools
>> Version: 0.131ubuntu8
>> Severity: wishlist
>>
>>
>> Hi,
>> I'd like to have fully encrypted system with partition table inside
>> of LUKS container. It is easier to manage for me than multi-layer
>> LVM.
> 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.
> 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.
>> However, there are 2 issues with this described here:
>> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1786688
>>
>> The first issue is that after decryption of LUKS container there is a
>> filesystem check and `get_fstype` function returns `undefined` for
>> any partition table.
>>
>> I'd like it to return `pttable` or something similar instead, so that
>> after decryption it will not lock container back with "unknown
>> fstype, bad password or options?".
> [...]
>
> I think the current behaviour of get_fstype is correct. It doesn't
> print any error message; it just tells the caller whether a filesystem
> was detected and if so what type it is. It's up to the caller whether
> to treat a failure as fatal, or to check for a partition table as well.
Well, I think technically LVM is not a file system either, but `get_fstype`
returns `lvm` for it.
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?
>
> Ben.
>
Sincerely, Nazar Mokrynskyi
github.com/nazar-pc
