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
Re: Regression in 4.17 Kernels (?)
Hi Yves-Alexis, Am Donnerstag, 23. August 2018, 13:53:32 CEST schrieb Yves-Alexis Perez: > On Thu, 2018-08-23 at 13:17 +0200, Rainer Dorsch wrote: > > Yes, I have never seen that with 4.16 and any kernel I used before. I run > > not 4.16. > > Sorry I'm a bit unsure how to read the last sentence. Can you retry right > now with 4.16 kernel (and changing only that) and report back? It's > possible that there is a regression in the USB handling in the 4.17 kernel > but we'd need a bit more information to confirm that. Sorry, this was a typo, I meant I run *now* 4.16 [again]. ...and I did not observe the issue. Feel free to ask, I am sorry that I did not provide more information, but since there is nothing in the log files, nothing on the screen, it is hard for me to provide anything useful. I could switch to a VT which the scanner is running shortly before the crash, but not sure if that helps. Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Regression in 4.17 Kernels (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-08-23 at 13:17 +0200, Rainer Dorsch wrote: > Yes, I have never seen that with 4.16 and any kernel I used before. I run not > 4.16. Sorry I'm a bit unsure how to read the last sentence. Can you retry right now with 4.16 kernel (and changing only that) and report back? It's possible that there is a regression in the USB handling in the 4.17 kernel but we'd need a bit more information to confirm that. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt+oDwACgkQ3rYcyPpX RFvuLAf/f8qVwnDNzB4z0B3/Q93Uc7JQlJsLqAcstdWLgxYgoiO0+m4LuwHscfde bWLF+MxSfU3+LsgzbzfPPHohUfxdQ4VYa5bD0BUzgowBBuKy0IvFytIwN8b0lH4r 3FCRenR8MK9f+ic0UvPTIS/T9Rg24xrbL6A96RIYKfiByuicKzG0rPW5SbVTgXnL QxzRcxNw3+uhus0S8SGtiT7G+rYi+27agCcrC0EYPyZP6HSrYV1YybPn7W5FmToB OQJLEij3OmSO44Qraohga6P5IsOD6/I+bkmkmkT6sSv8qT+1t60unx281K5KA9d9 MIUIwl1i47gSvCBxdpgBIf3gO5Y/DA== =I5LU -END PGP SIGNATURE-
Re: Regression in 4.17 Kernels (?)
Am Donnerstag, 23. August 2018, 11:57:17 CEST schrieb Yves-Alexis Perez: > On Wed, 2018-08-22 at 18:57 +0200, Rainer Dorsch wrote: > > The issue seems to be 100% reproducible with the 4.17 kernels I tried on > > my > > > system: > Hi, > > is it OK with other kernels? Yes, I have never seen that with 4.16 and any kernel I used before. I run not 4.16. Rainer -- Rainer Dorsch http://bokomoko.de/
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
linux_4.9.110-3+deb9u4_source.changes ACCEPTED into proposed-updates->stable-new
Mapping stable-security to proposed-updates. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 21 Aug 2018 16:50:09 +0200 Source: linux Binary: linux-source-4.9 linux-support-4.9.0-8 linux-doc-4.9 linux-manual-4.9 linux-kbuild-4.9 linux-cpupower libcpupower1 libcpupower-dev linux-perf-4.9 libusbip-dev usbip hyperv-daemons linux-headers-4.9.0-8-common linux-headers-4.9.0-8-common-rt linux-libc-dev linux-headers-4.9.0-8-all linux-headers-4.9.0-8-all-alpha kernel-image-4.9.0-8-alpha-generic-di nic-modules-4.9.0-8-alpha-generic-di nic-wireless-modules-4.9.0-8-alpha-generic-di nic-shared-modules-4.9.0-8-alpha-generic-di serial-modules-4.9.0-8-alpha-generic-di usb-serial-modules-4.9.0-8-alpha-generic-di ppp-modules-4.9.0-8-alpha-generic-di pata-modules-4.9.0-8-alpha-generic-di cdrom-core-modules-4.9.0-8-alpha-generic-di scsi-core-modules-4.9.0-8-alpha-generic-di scsi-modules-4.9.0-8-alpha-generic-di loop-modules-4.9.0-8-alpha-generic-di btrfs-modules-4.9.0-8-alpha-generic-di ext4-modules-4.9.0-8-alpha-generic-di isofs-modules-4.9.0-8-alpha-generic-di jfs-modules-4.9.0-8-alpha-generic-di xfs-modules-4.9.0-8-alpha-generic-di fat-modules-4.9.0-8-alpha-generic-di md-modules-4.9.0-8-alpha-generic-di multipath-modules-4.9.0-8-alpha-generic-di usb-modules-4.9.0-8-alpha-generic-di usb-storage-modules-4.9.0-8-alpha-generic-di fb-modules-4.9.0-8-alpha-generic-di input-modules-4.9.0-8-alpha-generic-di event-modules-4.9.0-8-alpha-generic-di mouse-modules-4.9.0-8-alpha-generic-di nic-pcmcia-modules-4.9.0-8-alpha-generic-di pcmcia-modules-4.9.0-8-alpha-generic-di nic-usb-modules-4.9.0-8-alpha-generic-di sata-modules-4.9.0-8-alpha-generic-di crc-modules-4.9.0-8-alpha-generic-di crypto-modules-4.9.0-8-alpha-generic-di crypto-dm-modules-4.9.0-8-alpha-generic-di ata-modules-4.9.0-8-alpha-generic-di nbd-modules-4.9.0-8-alpha-generic-di squashfs-modules-4.9.0-8-alpha-generic-di virtio-modules-4.9.0-8-alpha-generic-di zlib-modules-4.9.0-8-alpha-generic-di fuse-modules-4.9.0-8-alpha-generic-di srm-modules-4.9.0-8-alpha-generic-di linux-image-4.9.0-8-alpha-generic linux-headers-4.9.0-8-alpha-generic linux-image-4.9.0-8-alpha-generic-dbg linux-image-4.9.0-8-alpha-smp linux-headers-4.9.0-8-alpha-smp linux-image-4.9.0-8-alpha-smp-dbg linux-headers-4.9.0-8-all-amd64 kernel-image-4.9.0-8-amd64-di nic-modules-4.9.0-8-amd64-di nic-wireless-modules-4.9.0-8-amd64-di nic-shared-modules-4.9.0-8-amd64-di serial-modules-4.9.0-8-amd64-di usb-serial-modules-4.9.0-8-amd64-di ppp-modules-4.9.0-8-amd64-di pata-modules-4.9.0-8-amd64-di cdrom-core-modules-4.9.0-8-amd64-di firewire-core-modules-4.9.0-8-amd64-di scsi-core-modules-4.9.0-8-amd64-di scsi-modules-4.9.0-8-amd64-di loop-modules-4.9.0-8-amd64-di btrfs-modules-4.9.0-8-amd64-di ext4-modules-4.9.0-8-amd64-di isofs-modules-4.9.0-8-amd64-di jfs-modules-4.9.0-8-amd64-di ntfs-modules-4.9.0-8-amd64-di xfs-modules-4.9.0-8-amd64-di fat-modules-4.9.0-8-amd64-di md-modules-4.9.0-8-amd64-di multipath-modules-4.9.0-8-amd64-di usb-modules-4.9.0-8-amd64-di usb-storage-modules-4.9.0-8-amd64-di pcmcia-storage-modules-4.9.0-8-amd64-di fb-modules-4.9.0-8-amd64-di input-modules-4.9.0-8-amd64-di event-modules-4.9.0-8-amd64-di mouse-modules-4.9.0-8-amd64-di nic-pcmcia-modules-4.9.0-8-amd64-di pcmcia-modules-4.9.0-8-amd64-di nic-usb-modules-4.9.0-8-amd64-di sata-modules-4.9.0-8-amd64-di acpi-modules-4.9.0-8-amd64-di i2c-modules-4.9.0-8-amd64-di crc-modules-4.9.0-8-amd64-di crypto-modules-4.9.0-8-amd64-di crypto-dm-modules-4.9.0-8-amd64-di efi-modules-4.9.0-8-amd64-di ata-modules-4.9.0-8-amd64-di mmc-core-modules-4.9.0-8-amd64-di mmc-modules-4.9.0-8-amd64-di nbd-modules-4.9.0-8-amd64-di squashfs-modules-4.9.0-8-amd64-di speakup-modules-4.9.0-8-amd64-di virtio-modules-4.9.0-8-amd64-di uinput-modules-4.9.0-8-amd64-di sound-modules-4.9.0-8-amd64-di hyperv-modules-4.9.0-8-amd64-di udf-modules-4.9.0-8-amd64-di fuse-modules-4.9.0-8-amd64-di linux-image-4.9.0-8-amd64 linux-headers-4.9.0-8-amd64 linux-image-4.9.0-8-amd64-dbg linux-image-4.9.0-8-rt-amd64 linux-headers-4.9.0-8-rt-amd64 linux-image-4.9.0-8-rt-amd64-dbg linux-headers-4.9.0-8-all-arm64 kernel-image-4.9.0-8-arm64-di nic-modules-4.9.0-8-arm64-di nic-wireless-modules-4.9.0-8-arm64-di nic-shared-modules-4.9.0-8-arm64-di ppp-modules-4.9.0-8-arm64-di cdrom-core-modules-4.9.0-8-arm64-di scsi-core-modules-4.9.0-8-arm64-di scsi-modules-4.9.0-8-arm64-di loop-modules-4.9.0-8-arm64-di btrfs-modules-4.9.0-8-arm64-di ext4-modules-4.9.0-8-arm64-di isofs-modules-4.9.0-8-arm64-di jfs-modules-4.9.0-8-arm64-di xfs-modules-4.9.0-8-arm64-di fat-modules-4.9.0-8-arm64-di md-modules-4.9.0-8-arm64-di multipath-modules-4.9.0-8-arm64-di usb-modules-4.9.0-8-arm64-di usb-storage-modules-4.9.0-8-arm64-di fb-modules-4.9.0-8-arm64-di input-modules-4.9.0-8-arm64-di event-modules-4.9.0-8-arm64-di nic-usb-modules-4.9.0-8-arm64-di sata-modules-4.9.0-8-arm64-di i2c-modules-4.9.0-8-arm64-di
Re: Regression in 4.17 Kernels (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2018-08-22 at 18:57 +0200, Rainer Dorsch wrote: > The issue seems to be 100% reproducible with the 4.17 kernels I tried on my > system: Hi, is it OK with other kernels? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt+hP0ACgkQ3rYcyPpX RFuFzggAy+U/KGJJf3Tv+aFcrYkYpq5UsEaI7hjHzsnpfgqwwpM51ErIqi8HeTO6 M652r0Ha9tsbvsyIq7Wa7Fu7Z9VjZ23mM+SKiLDve3jiM8nIYmjX9JFyjcFq0Smb g8baM7qs3MmodFMH/RqlXFxp3HqPIKph4NnaYBFjbvKop3PfKzRItzpqFtGW3jJn zXRJwbBEgNASwJhuwY78dsBsBx4/m+MFGRb6ME+8Ol+lKayAx7F7L24xmFm5vLg6 8f3oebZ+JHQhJvFn8MrBOfnBlxOCmM9O8dbu0g+TvRKc3B1rN5trKzzpY59pLkPA LY3+YEll2W6BM4uZm+2Uo7NzVUwvTQ== =YnA3 -END PGP SIGNATURE-
