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

[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.

> > > 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180822/3b4ea755/attachment.sig>