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. > > > 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. That's true, but it's kind of accidental rather than something we specifically intended to support. > 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. - 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. Ben. -- Ben Hutchings You can't have everything. Where would you put it?
signature.asc
Description: This is a digitally signed message part
