Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #61862 > unrolled thread

Bug#906664: initramfs-tools: Add partition table support to get_fstype

Back to article view | Back to linux.debian.kernel

Contents

  Bug#906664: initramfs-tools: Add partition table support to get_fstype Nazar Mokrynskyi <nazar@mokrynskyi.com> - 2018-08-19 14:50 +0200
    Processed: Re: Bug#906664: initramfs-tools: Add partition table  support to get_fstype "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-08-21 02:10 +0200
    Bug#906664: initramfs-tools: Add partition table support to get_fstype Ben Hutchings <ben@decadent.org.uk> - 2018-08-21 02:10 +0200
      Bug#906664: initramfs-tools: Add partition table support to get_fstype Nazar Mokrynskyi <nazar@mokrynskyi.com> - 2018-08-21 08:00 +0200
        Bug#906664: initramfs-tools: Add partition table support to get_fstype Ben Hutchings <ben@decadent.org.uk> - 2018-08-22 22:30 +0200
          Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype Guilhem Moulin <guilhem@debian.org> - 2018-08-23 12:40 +0200
    Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype Guilhem Moulin <guilhem@debian.org> - 2018-08-23 12:50 +0200

#61862 — Bug#906664: initramfs-tools: Add partition table support to get_fstype

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.

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

Patch would look something like this:

get_fstype ()
{
	local FS FSTYPE FSSIZE RET
	FS="${1}"

	# blkid has a more complete list of file systems,
	# but fstype is more robust
	FSTYPE="unknown"
	eval $(fstype "${FS}" 2> /dev/null)
	if [ "$FSTYPE" = "unknown" ]; then
		FSTYPE=$(blkid -o value -s TYPE "${FS}")
	fi
-	RET=$?
+
+	if [ -z "${FSTYPE}" ]; then
+		if [ ! -z $(blkid -o value -s PTTABLE "${FS}") ]; then
+			FSTYPE="pttable"
+		fi
+		RET=$?
+	fi
+
+	RET=$?

	if [ -z "${FSTYPE}" ]; then
		FSTYPE="unknown"
	fi

	echo "${FSTYPE}"
	return ${RET}
}


This would be the first step, after that it would be possible to adjust cryptsetup integration to scan decrypted partition table for partitions with partprobe or kpartx.

I don't know how to send patch properly, so redirect me to proper place if this is not the right one.

[toc] | [next] | [standalone]

#61874 — Processed: Re: Bug#906664: initramfs-tools: Add partition table support to get_fstype

Processing control commands:

> notfound -1 0.131ubuntu8
Bug #906664 [initramfs-tools] initramfs-tools: Add partition table support to get_fstype
There is no source info for the package 'initramfs-tools' at version '0.131ubuntu8' with architecture ''
Unable to make a source version for version '0.131ubuntu8'
No longer marked as found in versions 0.131ubuntu8.
> found -1 0.132
Bug #906664 [initramfs-tools] initramfs-tools: Add partition table support to get_fstype
Marked as found in versions initramfs-tools/0.132.
> tag -1 wontfix
Bug #906664 [initramfs-tools] initramfs-tools: Add partition table support to get_fstype
Added tag(s) wontfix.

-- 
906664: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906664
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#61876

[Multipart message — attachments visible in raw view] — view raw

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.

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.

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

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

[toc] | [prev] | [next] | [standalone]

#61877

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

[toc] | [prev] | [next] | [standalone]

#61890

[Multipart message — attachments visible in raw view] — view raw

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?

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Wed, 22 Aug 2018 at 21:22:19 +0100, Ben Hutchings wrote:
> 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.

They ideally should but currently don't, cf. #565676.  Currently
(2.02.176-4.1) /scripts/local-top/lvm2 only activate volumes holding the
root system and/or resume device.

So for dm-crypt in LVM, the underlying LV needs to be activated when
/scripts/local-top/cryptroot waits for the source device [0].


For LVM in dm-crypt however, instead of activating the LV manually [1]
we could let /scripts/local-{top,block}/lvm2 do it; while the cryptroot
scripts have been running since 12 years or so, I think we could run it
before lvm2 instead.

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

This was reported as #906283 a few days ago, and I proposed to remove
the check, for LUKS devices at least.

-- 
Guilhem.

[0] https://sources.debian.org/src/cryptsetup/2:2.0.4-2/debian/initramfs/scripts/local-top/cryptroot/#L61
[1] https://sources.debian.org/src/cryptsetup/2:2.0.4-2/debian/initramfs/scripts/local-top/cryptroot/#L158

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, 23 Aug 2018 at 12:16:35 +0200, Jonas Meurer wrote:
> 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?

That's not a regression AFAIK, see https://bugs.debian.org/906283#10 :-)
But I'll remove the check for LUKS, then.
 
>>> 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 guess you mean the other way around, as the /script/local-top/cryptroot
has been running last since forever :-P  As I just wrote, if
/script/local-{top,block}/lvm2 were to depend on cryptroot, we wouldn't
have to manually activate the device for LVM in dm-crypt setups.

-- 
Guilhem.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web