Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
Thanks Ben!
Looking at these now...
On Fri, Mar 03, 2023 at 09:28:26PM +0100, Ben Hutchings wrote:
>Control: tag -1 upstream fixed-upstream patch
>
>On Mon, 09 Jan 2023 12:12:19 +0100 Laurent Bigonville
> wrote:
>> Package: grub-common
>> Version: 2.06-7
>> Severity: serious
>> File: /usr/sbin/grub-probe
>>
>> Hello,
>>
>> On a newly installed laptop, it seems that grub-probe is not able to
>> detect that files are on an encrypted FS.
>>
>> New laptop:
>>
>> $ sudo grub-probe -t abstraction
>> /usr/share/images/desktop-base/desktop-grub.png
>> lvm
>>
>> $ sudo lsblk
>> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
>> nvme0n1 259:0 0 476,9G 0 disk
>> ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
>> ├─nvme0n1p2 259:2 0 488M 0 part /boot
>> └─nvme0n1p3 259:3 0 476G 0 part
>> └─nvme0n1p3_crypt 254:0 0 475,9G 0 crypt
>> ├─new_laptop--vg-root 254:1 0 27,9G 0 lvm /
>> ├─new_laptop--vg-swap_1 254:2 0 976M 0 lvm [SWAP]
>> ├─new_laptop--vg-home 254:3 0 40G 0 lvm /home
>> └─new_laptop--vg-libvirt 254:4 0 60G 0 lvm /var/lib/libvirt
>[...]
>
>I can reproduce this. What changed is that we now use LUKS2 instead of
>LUKS1. Although GRUB has some LUKS2 support, it doesn't probe LUKS2
>volumes automatically.
>
>I found the 3 upstream commits that are enough to make the "grub-probe
>..." line work and am attaching a debdiff with those. I don't know
>whether this is enough to completely fix the problem.
>
>Ben.
>
>--
>Ben Hutchings
>Never put off till tomorrow what you can avoid all together.
>
>diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog
>--- grub2-2.06/debian/changelog2023-02-25 21:16:55.0 +0100
>+++ grub2-2.06/debian/changelog2023-03-03 19:21:28.0 +0100
>@@ -1,3 +1,15 @@
>+grub2 (2.06-8.2) UNRELEASED; urgency=medium
>+
>+ * Non-maintainer upload.
>+ * Fix probing of LUKS2 devices (Closes: #1028301):
>+- disk/cryptodisk: When cheatmounting, use the sector info of the cheat
>+ device
>+- osdep/devmapper/getroot: Have devmapper recognize LUKS2
>+- osdep/devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM
>+ parameters
>+
>+ -- Ben Hutchings Fri, 03 Mar 2023 19:21:28 +0100
>+
> grub2 (2.06-8.1) experimental; urgency=medium
>
> * Non-maintainer upload.
>diff -Nru
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
>
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
>---
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
> 1970-01-01 01:00:00.0 +0100
>+++
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
> 2023-03-03 19:21:28.0 +0100
>@@ -0,0 +1,72 @@
>+From: Fabian Vogt
>+Date: Thu, 12 Jan 2023 17:05:07 -0600
>+Subject: disk/cryptodisk: When cheatmounting, use the sector info of the cheat
>+ device
>+Origin:
>https://git.savannah.gnu.org/cgit/grub.git/commit/?id=efc9c363b2aab222586b420508eb46fc13242739
>+Bug-Debian: https://bugs.debian.org/1028301
>+
>+When using grub-probe with cryptodisk, the mapped block device from the host
>+is used directly instead of decrypting the source device in GRUB code.
>+In that case, the sector size and count of the host device needs to be used.
>+This is especially important when using LUKS2, which does not assign
>+total_sectors and log_sector_size when scanning, but only later when the
>+segments in the JSON area are evaluated. With an unset log_sector_size,
>+grub_device_open() complains.
>+
>+This fixes grub-probe failing with
>+"error: sector sizes of 1 bytes aren't supported yet.".
>+
>+Signed-off-by: Fabian Vogt
>+Reviewed-by: Patrick Steinhardt
>+Tested-by: Glenn Washburn
>+Reviewed-by: Glenn Washburn
>+Reviewed-by: Patrick Steinhardt
>+Reviewed-by: Daniel Kiper
>+---
>+ grub-core/disk/cryptodisk.c | 20 ++--
>+ 1 file changed, 18 insertions(+), 2 deletions(-)
>+
>+--- a/grub-core/disk/cryptodisk.c
> b/grub-core/disk/cryptodisk.c
>+@@ -694,16 +694,31 @@ grub_cryptodisk_open (const char *name,
>+ if (!dev)
>+ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No such device");
>+
>+- disk->log_sector_size = dev->log_sector_size;
>+-
>+ #ifdef GRUB_UTIL
>+ if (dev->cheat)
>+ {
>++ grub_uint64_t cheat_dev_size;
>++ unsigned int cheat_log_sector_size;
>++
>+ if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
>+ dev->cheat_fd = grub_util_fd_open (dev->cheat, GRUB_UTIL_FD_O_RDONLY);
>+ if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
>+ return grub_error (GRUB_ERR_IO, N_("cannot open `%s': %s"),
>+ dev->cheat, grub_util_fd_strerror ());
>++
>++ /* Use the sector size and count of the cheat device.
Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
Control: tag -1 upstream fixed-upstream patch
On Mon, 09 Jan 2023 12:12:19 +0100 Laurent Bigonville
wrote:
> Package: grub-common
> Version: 2.06-7
> Severity: serious
> File: /usr/sbin/grub-probe
>
> Hello,
>
> On a newly installed laptop, it seems that grub-probe is not able to
> detect that files are on an encrypted FS.
>
> New laptop:
>
> $ sudo grub-probe -t abstraction
> /usr/share/images/desktop-base/desktop-grub.png
> lvm
>
> $ sudo lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> nvme0n1 259:0 0 476,9G 0 disk
> ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
> ├─nvme0n1p2 259:2 0 488M 0 part /boot
> └─nvme0n1p3 259:3 0 476G 0 part
> └─nvme0n1p3_crypt 254:0 0 475,9G 0 crypt
> ├─new_laptop--vg-root 254:1 0 27,9G 0 lvm /
> ├─new_laptop--vg-swap_1 254:2 0 976M 0 lvm [SWAP]
> ├─new_laptop--vg-home 254:3 0 40G 0 lvm /home
> └─new_laptop--vg-libvirt 254:4 0 60G 0 lvm /var/lib/libvirt
[...]
I can reproduce this. What changed is that we now use LUKS2 instead of
LUKS1. Although GRUB has some LUKS2 support, it doesn't probe LUKS2
volumes automatically.
I found the 3 upstream commits that are enough to make the "grub-probe
..." line work and am attaching a debdiff with those. I don't know
whether this is enough to completely fix the problem.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog
--- grub2-2.06/debian/changelog 2023-02-25 21:16:55.0 +0100
+++ grub2-2.06/debian/changelog 2023-03-03 19:21:28.0 +0100
@@ -1,3 +1,15 @@
+grub2 (2.06-8.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix probing of LUKS2 devices (Closes: #1028301):
+- disk/cryptodisk: When cheatmounting, use the sector info of the cheat
+ device
+- osdep/devmapper/getroot: Have devmapper recognize LUKS2
+- osdep/devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM
+ parameters
+
+ -- Ben Hutchings Fri, 03 Mar 2023 19:21:28 +0100
+
grub2 (2.06-8.1) experimental; urgency=medium
* Non-maintainer upload.
diff -Nru grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
--- grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch 1970-01-01 01:00:00.0 +0100
+++ grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch 2023-03-03 19:21:28.0 +0100
@@ -0,0 +1,72 @@
+From: Fabian Vogt
+Date: Thu, 12 Jan 2023 17:05:07 -0600
+Subject: disk/cryptodisk: When cheatmounting, use the sector info of the cheat
+ device
+Origin: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=efc9c363b2aab222586b420508eb46fc13242739
+Bug-Debian: https://bugs.debian.org/1028301
+
+When using grub-probe with cryptodisk, the mapped block device from the host
+is used directly instead of decrypting the source device in GRUB code.
+In that case, the sector size and count of the host device needs to be used.
+This is especially important when using LUKS2, which does not assign
+total_sectors and log_sector_size when scanning, but only later when the
+segments in the JSON area are evaluated. With an unset log_sector_size,
+grub_device_open() complains.
+
+This fixes grub-probe failing with
+"error: sector sizes of 1 bytes aren't supported yet.".
+
+Signed-off-by: Fabian Vogt
+Reviewed-by: Patrick Steinhardt
+Tested-by: Glenn Washburn
+Reviewed-by: Glenn Washburn
+Reviewed-by: Patrick Steinhardt
+Reviewed-by: Daniel Kiper
+---
+ grub-core/disk/cryptodisk.c | 20 ++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/grub-core/disk/cryptodisk.c
b/grub-core/disk/cryptodisk.c
+@@ -694,16 +694,31 @@ grub_cryptodisk_open (const char *name,
+ if (!dev)
+ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No such device");
+
+- disk->log_sector_size = dev->log_sector_size;
+-
+ #ifdef GRUB_UTIL
+ if (dev->cheat)
+ {
++ grub_uint64_t cheat_dev_size;
++ unsigned int cheat_log_sector_size;
++
+ if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
+ dev->cheat_fd = grub_util_fd_open (dev->cheat, GRUB_UTIL_FD_O_RDONLY);
+ if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
+ return grub_error (GRUB_ERR_IO, N_("cannot open `%s': %s"),
+ dev->cheat, grub_util_fd_strerror ());
++
++ /* Use the sector size and count of the cheat device. */
++ cheat_dev_size = grub_util_get_fd_size (dev->cheat_fd, dev->cheat, _log_sector_size);
++ if (cheat_dev_size == -1)
++{
++ const char *errmsg = grub_util_fd_strerror ();
++ grub_util_fd_close (dev->cheat_fd);
++ dev->cheat_fd
Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
Hi, Is anything happening about this?? I am currently in a limbo with a broken EFI that does not want to boot my debian installation on an encrypted LVM. I can manually load the config. But I would like the grub install to rebuild it correctly. But this is maybe the reason why it is broken in the first place. Not finding what to boot. Jens
Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
Package: grub-common Version: 2.06-7 Severity: serious File: /usr/sbin/grub-probe Hello, On a newly installed laptop, it seems that grub-probe is not able to detect that files are on an encrypted FS. New laptop: $ sudo grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png lvm $ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:00 476,9G 0 disk ├─nvme0n1p1 259:10 512M 0 part /boot/efi ├─nvme0n1p2 259:20 488M 0 part /boot └─nvme0n1p3 259:30 476G 0 part └─nvme0n1p3_crypt 254:00 475,9G 0 crypt ├─new_laptop--vg-root254:10 27,9G 0 lvm / ├─new_laptop--vg-swap_1 254:20 976M 0 lvm [SWAP] ├─new_laptop--vg-home254:3040G 0 lvm /home └─new_laptop--vg-libvirt 254:4060G 0 lvm /var/lib/libvirt Old laptop: $ sudo grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png cryptodisk luks gcry_rijndael gcry_rijndael gcry_sha256 lvm $ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda8:01 0B 0 disk nvme0n1 259:00 476,9G 0 disk ├─nvme0n1p1 259:10 512M 0 part /boot/efi ├─nvme0n1p2 259:20 244M 0 part /boot └─nvme0n1p3 259:30 476,2G 0 part └─nvme0n1p3_crypt 254:00 476,2G 0 crypt ├─old_laptop--vg-root254:10 27,9G 0 lvm / ├─old_laptop--vg-swap_1 254:20 31,7G 0 lvm [SWAP] ├─old_laptop--vg-home254:30 120G 0 lvm /home ├─old_laptop--vg-sid_amd64_sbuild254:40 5G 0 lvm ├─old_laptop--vg-flatpak 254:5050G 0 lvm /var/lib/flatpak ├─old_laptop--vg-libvirt 254:6075G 0 lvm /var/lib/libvirt ├─old_laptop--vg-docker 254:7010G 0 lvm /var/lib/docker ├─old_laptop--vg-acng254:8010G 0 lvm /var/cache/apt-cacher-ng └─old_laptop--vg-buster_amd64_sbuild 254:90 5G 0 lvm Setting this as serious as this seems to be a regression, this at least breaks grub ability to display the theme wallpaper. Kind regards, Laurent Bigonville
