Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype
Am 23.08.2018 um 12:43 schrieb Guilhem Moulin:
> 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.
Agreed. Thanks for looking into 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?
>>>
>>> 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.
Upps, you're right. I'm to busy these days and didn't check properly.
Cheers
jonas
signature.asc
Description: OpenPGP digital signature
Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype
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 signature.asc Description: OpenPGP digital signature
Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype
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.
signature.asc
Description: PGP signature
Bug#906664: [pkg-cryptsetup-devel] Bug#906664: initramfs-tools: Add partition table support to get_fstype
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
signature.asc
Description: PGP signature
Bug#906664: initramfs-tools: Add partition table support to get_fstype
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
Bug#906664: initramfs-tools: Add partition table support to get_fstype
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
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 ow...@bugs.debian.org with problems
Bug#906664: initramfs-tools: Add partition table support to get_fstype
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 signature.asc Description: This is a digitally signed message part
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.
