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
Attachment:
signature.asc
Description: OpenPGP digital signature