[PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin via Grub-devel]

Hi. I propose changing "efi" to "EFI" in grub-mkrescue, because this is needed for secure boot. Please, apply patch below. Here is why.

First of all, iso9660 file system is case sensitive from GRUB point of view. I. e. if you have directory named "efi" in iso9660, then GRUB command "ls /EFI" will not work.

Second, it seems that "EFI", as opposed to "efi", is standard among Linux CDs. I examined the following .iso files:

- Debian installer
- Debian live image
- Ubuntu live image
- Fedora network install

All they have "EFI", as opposed to "efi".

And main argument: I'm aware of one example when "EFI" is hard-coded in signed secure boot GRUB binary. Debian has 4 signed GRUB binaries. All they are generated here: https://sources.debian.org/src/grub2/2.12-5/debian/build-efi-images/ . One of them, grubx64.efi is created using "grub-mkimage ... -p /EFI/debian". The binary is signed, so I cannot change it if I want secure boot support. So if I want to use this binary, I should have directory named exactly "EFI".

You may say: "But grub-mkrescue doesn't support secure boot". Yes, it doesn't support it. But I think this patch will simplify adding secure boot support by distributions.

Now let me describe in detail why I need all this. Also I will show you results of additional experiments.

I attempted to create bootable GRUB disk using grub-mkrescue. I wanted the disk to support secure boot. I failed. I don't remember why. It is possible that this EFI vs efi issue was one of the problems. So I resorted to writing script, which replaces grub-mkrescue. This is simplified version of that script. Note: this is simplification written specially for presenting here. So I intentionally dropped things I would not drop in real code.

====
#!/bin/bash
# This script is merely demonstration created specially to present on GRUB mailing list. So it intentionally drops some important things
# This script can be run on any Linux distro
# This script creates isohybrid disk, which supports UEFI booting
# The disk can be used both as CD image and as USB disk image
# So, in total 2 boot modes are supported: UEFI-CD and UEFI-USB
# Secure boot is supported
# This script can be run on any Linux distro (but was tested on Debian only).
# The script doesn't rely on specific files present in specific places, it downloads all its dependencies
# This script doesn't support "EFI file system transposition" ( https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00024.html ). This is intentional, because this is just a demo
# The script was tested in Qemu only. Also secure boot was not tested
{
  # This is just boilerplate I insert to all my bash scripts
  set -e
  set -u
  set -o pipefail
  shopt -s inherit_errexit
  shopt -s nullglob
  export LC_ALL=C.UTF-8

  if [ $# != 1 ]; then
    echo "Usage: ${0##*/} OUT" >&2
    exit 1
  fi

  OUT="$1"

  DIR="$(mktemp -d /tmp/grub-XXXXXX)"

  mkdir -p "$DIR/esp/EFI/boot" "$DIR/esp/EFI/debian" "$DIR/main-root/EFI/debian" "$DIR/main-root/boot/grub"
  wget -O "$DIR/esp/EFI/boot/bootx64.efi" 'https://sources.debian.org/src/shim-signed/latest/shimx64.efi.signed/'
  wget -O "$DIR/grub-efi-amd64-signed.deb" 'https://deb.debian.org/debian/pool/main/g/grub-efi-amd64-signed/grub-efi-amd64-signed_1+2.12+5_amd64.deb'
  ar p "$DIR/grub-efi-amd64-signed.deb" data.tar.xz > "$DIR/data.tar.xz"
  tar -xf "$DIR/data.tar.xz" --to-stdout ./usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed > "$DIR/esp/EFI/boot/grubx64.efi"
  cat << "EOF" > "$DIR/esp/EFI/debian/grub.cfg"
echo "This is /EFI/debian/grub.cfg from ESP"
echo "Testing shows that this file is loaded during UEFI-USB"
sleep 10
EOF
  mkfs.vfat -C "$DIR/main-root/boot/grub/efi.img" 10000
  mcopy -s -i "$DIR/main-root/boot/grub/efi.img" "$DIR/esp/EFI" ::/
  cat << "EOF" > "$DIR/main-root/EFI/debian/grub.cfg"
echo "This is /EFI/debian/grub.cfg from main file system (iso9660)"
echo "Testing shows that this file is loaded during UEFI-CD"
sleep 10
EOF
  # I don't know why this "$DIR/main-root/zero" is needed. Anyway this is just a demo
  dd if=/dev/zero of="$DIR/main-root/zero" bs=1M count=1
  xorriso -as mkisofs -b /zero -no-emul-boot --efi-boot /boot/grub/efi.img -efi-boot-part --efi-boot-image -o "$OUT" -r "$DIR/main-root"
  rm -r "$DIR"
  exit 0
}
====

While testing this script I noticed this: if I boot from disk (i. e. using "-drive" Qemu option), then "grub.cfg" is read from ESP, i. e. FAT. But if I boot from CD (i. e. using "-cdrom" Qemu option), then "grub.cfg" is read from main .iso partition, i. e. iso9660. I don't know whether this is expected behavior or just a bug.

FAT is case insensitive from GRUB point of view. But iso9660 is case sensitive. So, the file (in case of CD boot) must be named exactly /EFI/debian/grub.cfg. Name /efi/debian/grub.cfg will not work, I tested this. I. e. I replaced "EFI" with "efi" everywhere in the script above and I saw that in case of UEFI-CD file /efi/debian/grub.cfg is not read anymore. (Again: I checked in my experiments nearly all statements I made in this letter.)

So, grub-mkrescue is incompatible with Debian's signed GRUB image "grubx64.efi". So, if someone tries to create their custom .iso using grub-mkrescue with secure boot support with that grubx64.efi, they will likely fail. And they will have to resort to reimplementing grub-mkrescue (this is what I did with script above). For this reason I suggest replacing "efi" with "EFI" in grub-mkrescue.

You may say: "But why choose this signed binary? Debian has 3 other signed binaries". Yes, it has. But all these 3 binaries contain complicated logic for finding config. I don't like this. So I choose grubx64.efi for my personal GRUB disk. Yes, I can choose from other 3 binaries. But I still think that this patch is good thing. It allows one to choose grubx64.efi. I. e. this patch allows new uses without removing existing ones.

Also, I kindly ask for making new GRUB release after applying this patch. This is because I possibly will try to add secure boot support to Debian version of GRUB. So I need GRUB to be released first. Of course, if I do this, I will again think about what of these 4 binaries I should choose.

I send this letter to grub-devel. Also I CC Pete Batard, because it seems my work is somehow related to his work on grub-mkrescue ( https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00024.html ). I CC Thomas Schmitt, because my work seems to be related to xorriso. I CC Adrian, because I think the problem I talk about is the problem, which prevented supergrubdisk from making image for CD with secure boot support ( https://github.com/supergrub/supergrub/commit/25414fcbbcb47c1d8616fa18d20409d570145b8f ).

Signed-off-by: Askar Safin <safinaskar@zohomail.com>
---
 util/grub-mkrescue.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
index 6dc71a8a1..c78647ebe 100644
--- a/util/grub-mkrescue.c
+++ b/util/grub-mkrescue.c
@@ -771,8 +771,12 @@ main (int argc, char *argv[])
       || source_dirs[GRUB_INSTALL_PLATFORM_RISCV64_EFI])
     {
       FILE *f;
-      char *efidir_efi = grub_util_path_concat (2, iso9660_dir, "efi");
-      char *efidir_efi_boot = grub_util_path_concat (3, iso9660_dir, "efi", "boot");
+
+      /* This directory should be named "EFI", not "efi". See September 2024 grub-devel discussion for details
+         ( https://lists.gnu.org/archive/html/grub-devel/2024-09/index.html )
+       */
+      char *efidir_efi = grub_util_path_concat (2, iso9660_dir, "EFI");
+      char *efidir_efi_boot = grub_util_path_concat (3, iso9660_dir, "EFI", "boot");
       char *imgname, *img32, *img64, *img_mac = NULL;
       char *efiimgfat, *iso_uuid_file, *diskdir, *diskdir_uuid;
       grub_install_mkdir_p (efidir_efi_boot);
-- 
2.43.0


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Thomas Schmitt via Grub-devel]

Hi,

Askar Safin <safinaskar@zohomail.com> wrote:
> I CC Thomas Schmitt, because my work seems to be related to xorriso.

I checked that grub-mkrescue variables efidir_efi and efidir_efi_boot
are not leading to arguments of the xorriso run.
Insofar this change is transparent from the view of xorriso.

I can confirm that many distro ISOs have a copy of the file tree of their
EFI system partition as file tree "/EFI/boot" in the ISO 9660 filesystem.
Nobody seems to complain about the mixed case.
This copy normally plays no role in booting but is present for reference
and for copying out by e.g. Rufus. This is convenient because else one
has to search and mount the EFI system partition.

(I cannot judge whether "grub-mkimage -p /EFI/debian" has any relation
to the names in the ISO 9660 filesystem or whether the filesystem where
it matters is case sensitive.)


> iso9660 file system is case sensitive from GRUB point of view.

That's probably because grub-core/fs/iso9660.c has support for Rock Ridge.

One would have to use xorrisofs option --norock to keep xorriso from
producing Rock Ridge. Omitting -R, -rock, -r, or -rational-rock would
not suffice, other than with mkisofs and genisoimage.


> Signed-off-by: Askar Safin <safinaskar@zohomail.com>
> ---
>  util/grub-mkrescue.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
> index 6dc71a8a1..c78647ebe 100644
> --- a/util/grub-mkrescue.c
> +++ b/util/grub-mkrescue.c
> @@ -771,8 +771,12 @@ main (int argc, char *argv[])
>        || source_dirs[GRUB_INSTALL_PLATFORM_RISCV64_EFI])
>      {
>        FILE *f;
> -      char *efidir_efi = grub_util_path_concat (2, iso9660_dir, "efi");
> -      char *efidir_efi_boot = grub_util_path_concat (3, iso9660_dir, "efi",
> "boot");
> +
> +      /* This directory should be named "EFI", not "efi". See September
> 2024 grub-devel discussion for details
> +         ( https://lists.gnu.org/archive/html/grub-devel/2024-09/index.html
> )
> +       */
> +      char *efidir_efi = grub_util_path_concat (2, iso9660_dir, "EFI");
> +      char *efidir_efi_boot = grub_util_path_concat (3, iso9660_dir, "EFI",
> "boot");
>        char *imgname, *img32, *img64, *img_mac = NULL;
>        char *efiimgfat, *iso_uuid_file, *diskdir, *diskdir_uuid;
>        grub_install_mkdir_p (efidir_efi_boot);
>

Reviewed-by: Thomas Schmitt <scdbackup@gmx.net>


Have a nice day :)

Thomas


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Pascal Hambourg]

On 06/09/2024 at 15:15, Askar Safin wrote:
> 
> While testing this script I noticed this: if I boot from disk (i. e.
> using "-drive" Qemu option), then "grub.cfg" is read from ESP, i. e.
> FAT. But if I boot from CD (i. e. using "-cdrom" Qemu option), then
> "grub.cfg" is read from main .iso partition, i. e. iso9660. I don't know
> whether this is expected behavior or just a bug.

I do not know either, but it matches my previous observation. When 
booting from a EFI partition on a regular disk, then $root is set to the 
EFI partition (hdX,Y). When booting from a EFI El Torito image on a CD, 
then $root is set to the whole CD (cdX), and the El Torito image is not 
visible.

> FAT is case insensitive from GRUB point of view. But iso9660 is case
> sensitive. So, the file (in case of CD boot) must be named exactly
> /EFI/debian/grub.cfg. Name /efi/debian/grub.cfg will not work,
I faced a similar issue when trying to use $cmdpath instead of the 
hardcoded prefix /EFI/debian; the case in $cmdpath is variable and 
depends on the UEFI firmware and boot method (from EFI boot entry, 
select boot device, select EFI file). I have seen "/EFI/BOOT" most often 
but also "/EFI/Boot" and "/efi/boot".

On 06/09/2024 at 20:09, Thomas Schmitt wrote:
>
> I can confirm that many distro ISOs have a copy of the file tree of their
> EFI system partition as file tree "/EFI/boot" in the ISO 9660 filesystem.
> Nobody seems to complain about the mixed case.
> This copy normally plays no role in booting

It plays a role in Debian ISOhybrid images when booting from CD with a 
monolithic signed GRUB image which fetches an early grub.cfg in the EFI 
partition, because GRUB does not see the El Torito image and can read 
the early grub.cfg only from the ISO 9660 filesystem.

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 2242 bytes --]

Le sam. 7 sept. 2024, 00:51, Pascal Hambourg <pascal@plouf.fr.eu.org> a
écrit :

> On 06/09/2024 at 15:15, Askar Safin wrote:
> >
> > While testing this script I noticed this: if I boot from disk (i. e.
> > using "-drive" Qemu option), then "grub.cfg" is read from ESP, i. e.
> > FAT. But if I boot from CD (i. e. using "-cdrom" Qemu option), then
> > "grub.cfg" is read from main .iso partition, i. e. iso9660. I don't know
> > whether this is expected behavior or just a bug.
>
It's intended. ESP in El Torito is just an artifact of the spec. We always
use entire iso9660 to store our files on all the platforms

>
> I do not know either, but it matches my previous observation. When
> booting from a EFI partition on a regular disk, then $root is set to the
> EFI partition (hdX,Y). When booting from a EFI El Torito image on a CD,
> then $root is set to the whole CD (cdX), and the El Torito image is not
> visible.
>
> > FAT is case insensitive from GRUB point of view. But iso9660 is case
> > sensitive. So, the file (in case of CD boot) must be named exactly
> > /EFI/debian/grub.cfg. Name /efi/debian/grub.cfg will not work,
> I faced a similar issue when trying to use $cmdpath instead of the
> hardcoded prefix /EFI/debian; the case in $cmdpath is variable and
> depends on the UEFI firmware and boot method (from EFI boot entry,
> select boot device, select EFI file). I have seen "/EFI/BOOT" most often
> but also "/EFI/Boot" and "/efi/boot".
>
> On 06/09/2024 at 20:09, Thomas Schmitt wrote:
> >
> > I can confirm that many distro ISOs have a copy of the file tree of their
> > EFI system partition as file tree "/EFI/boot" in the ISO 9660 filesystem.
> > Nobody seems to complain about the mixed case.
> > This copy normally plays no role in booting
>
> It plays a role in Debian ISOhybrid images when booting from CD with a
> monolithic signed GRUB image which fetches an early grub.cfg in the EFI
> partition, because GRUB does not see the El Torito image and can read
> the early grub.cfg only from the ISO 9660 filesystem.
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #1.2: Type: text/html, Size: 3108 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 422 bytes --]

>
>
>
> And main argument: I'm aware of one example when "EFI" is hard-coded in
> signed secure boot GRUB binary. Debian has 4 signed GRUB binaries. All they
> are generated here:
> https://sources.debian.org/src/grub2/2.12-5/debian/build-efi-images/ .
> One of them, grubx64.efi is created using "grub-mkimage ... -p /EFI/debian".


Why do they use /EFI if it doesn't even work? The question is who needs to
change this.

[-- Attachment #1.2: Type: text/html, Size: 798 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Thomas Schmitt via Grub-devel]

Hi,

Pascal Hambourg wrote:
> When
> booting from a EFI partition on a regular disk, then $root is set to the
> EFI partition (hdX,Y). When booting from a EFI El Torito image on a CD,
> then $root is set to the whole CD (cdX), and the El Torito image is not
> visible.

That's a surprise to me.

I wrote (before knowing this information):
> > I can confirm that many distro ISOs have a copy of the file tree of their
> > EFI system partition as file tree "/EFI/boot" in the ISO 9660 filesystem.
> > This copy normally plays no role in booting

Pascal Hambourg wrote:
> It plays a role in Debian ISOhybrid images when booting from CD with a
> monolithic signed GRUB image which fetches an early grub.cfg in the EFI
> partition, because GRUB does not see the El Torito image and can read
> the early grub.cfg only from the ISO 9660 filesystem.

I was disbelieving enough to make a DVD+RW from
debian-12.7.0-amd64-netinst.iso with /EFI/debian/grub.cfg removed from
the ISO filesystem:

  xorriso -indev debian-12.7.0-amd64-netinst.iso \
          -outdev /dev/sr3 \
          -blank as_needed \
          -rm /EFI/debian/grub.cfg -- \
          -boot_image any replay \
          -assess_indev_features replay

Indeed when booting this DVD on real iron, i end up at a "grub>" prompt.
The original debian-12.7.0-amd64-netinst.iso put later on the same DVD
boots to the installer menu.

There remains my curiosity why this difference between booting via
El Torito and via partition table from the same FAT filesystem exists
and whether this is a bug.
(Well, by tradition it probably is a feature now.)


Have a nice day :)

Thomas


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin via Grub-devel]

---- On Sat, 07 Sep 2024 11:53:15 +0400 Vladimir 'phcoder' Serbinenko  wrote ---
 > > And main argument: I'm aware of one example when "EFI" is hard-coded in signed secure boot GRUB binary. Debian has 4 signed GRUB binaries. All they are generated here:https://sources.debian.org/src/grub2/2.12-5/debian/build-efi-images/ . One of them, grubx64.efi is created using "grub-mkimage ... -p /EFI/debian".
 > Why do they use /EFI if it doesn't even work?

I will repeat: I tried to create GRUB .iso for my own uses. And I noticed that grub-mkrescue is incompatible with GRUB EFI binaries signed by Debian for reasons explained in my previous letter. But official Debian .iso images seem to be created without grub-mkrescue, and for this reason creators of official images didn't get these problems. So, /EFI *does* work for people who create official ISOs, they just don't use grub-mkrescue.

 > The question is who needs to change this

You mean should Debian change "EFI" to "efi" or GRUB change "efi" to "EFI"?

Of course, I want whole Linux ecosystem to converge to some single name, "efi" or "EFI". What should we choose? As I said in first letter, major distros (Debian, Ubuntu and Fedora) already use "EFI" in their ISOs. And at least one of them (Debian) hardcode "EFI" to signed binary. So, of course, GRUB should be changed, not distros. Because it is easier.

--
Askar Safin
https://types.pl/@safinaskar



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Pascal Hambourg]

On 07/09/2024 at 10:30, Thomas Schmitt via Grub-devel wrote:
> Pascal Hambourg wrote:
>> When
>> booting from a EFI partition on a regular disk, then $root is set to the
>> EFI partition (hdX,Y). When booting from a EFI El Torito image on a CD,
>> then $root is set to the whole CD (cdX), and the El Torito image is not
>> visible.
(...)
> There remains my curiosity why this difference between booting via
> El Torito and via partition table from the same FAT filesystem exists
> and whether this is a bug.

 From what I can see in EFI shell, UEFI maps El Torito images as block 
devices, like partitions, but I suppose that GRUB uses only block 
devices which map to entire drives and maps partitions with its own 
partition table drivers (and has no El Torito driver).

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[adrian15sgd]

El 6/9/24 a las 15:15, Askar Safin escribió:
> Hi. I propose changing "efi" to "EFI" in grub-mkrescue, because this is needed for secure boot. Please, apply patch below. Here is why.

(...)


> I send this letter to grub-devel. Also I CC Pete Batard, because it seems my work is somehow related to his work on grub-mkrescue ( https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00024.html ). I CC Thomas Schmitt, because my work seems to be related to xorriso. I CC Adrian, because I think the problem I talk about is the problem, which prevented supergrubdisk from making image for CD with secure boot support ( https://github.com/supergrub/supergrub/commit/25414fcbbcb47c1d8616fa18d20409d570145b8f ).

Would you please remove the btactic email CC when answering? Thank you.

adrian15

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[adrian15sgd]

El 6/9/24 a las 15:15, Askar Safin escribió:
> Hi. I propose changing "efi" to "EFI" in grub-mkrescue, because this is needed for secure boot. Please, apply patch below. Here is why.
(...)
>
> I CC Adrian, because I think the problem I talk about is the problem, which prevented supergrubdisk from making image for CD with secure boot support ( https://github.com/supergrub/supergrub/commit/25414fcbbcb47c1d8616fa18d20409d570145b8f ).

No, I did not disable the SecureBoot support in Super Grub2 Disk because 
of this "efi" to "EFI" supposed problem that you describe.

Back in the day I added that commit on the supergrub history because I 
wasn't proud enough of the SecureBoot implementation or I messed up in 
which branch I was pushing those changes.
Right now the SecureBoot build is turned on on the main supergrub codebase.

It is based on the Debian binaries and, if I'm being honest, I might 
remove it (and suggest people to boot Super Grub2 Disk while SecureBoot 
is disabled) in the future because of two main reasons:

- Not being able to keep up with Debian updates in order to avoid 
problems with revoked SecureBoot-enabled shims/grubs .
- Nobody seem to be asking for any Fedora / RedHat / SusE, you-name-it 
SecureBoot support for Super Grub2 Disk.

Alternatively I could try to embed supergrub scripts onto an official 
Debian grub-related package and... just recommend that when you cannot 
turn off SecureBoot on your UEFI Firmware.
You want SecureBoot's SuperGrub in SusE ? Just port that package onto 
SusE yourself.

Note: In this message: SuperGrub = Super Grub Disk = Super Grub2 Disk .

adrian15


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Tobias Powalowski via Grub-devel]

> Back in the day I added that commit on the supergrub history because I 
> wasn't proud enough of the SecureBoot implementation or I messed up in 
> which branch I was pushing those changes.
> Right now the SecureBoot build is turned on on the main supergrub 
> codebase.
>
> It is based on the Debian binaries and, if I'm being honest, I might 
> remove it (and suggest people to boot Super Grub2 Disk while 
> SecureBoot is disabled) in the future because of two main reasons:
>
> - Not being able to keep up with Debian updates in order to avoid 
> problems with revoked SecureBoot-enabled shims/grubs .
> - Nobody seem to be asking for any Fedora / RedHat / SusE, you-name-it 
> SecureBoot support for Super Grub2 Disk.
>
> Alternatively I could try to embed supergrub scripts onto an official 
> Debian grub-related package and... just recommend that when you cannot 
> turn off SecureBoot on your UEFI Firmware.
> You want SecureBoot's SuperGrub in SusE ? Just port that package onto 
> SusE yourself.
>
> Note: In this message: SuperGrub = Super Grub Disk = Super Grub2 Disk .
>
> adrian15
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Sorry to chime in, but it does not matter which distro you have as base.

The shim needs to be signed by Microsoft, any built grub can then be 
used afterwards.

With a MOK setup you can pretty boot anything then.

The matter with grub-mkrescue not performing correct might be the case 
for me too.

I was not able to use virtualbox on my project until I put the kernel 
also to the ISO fs I think,

cause efi fs was not acceptable by virtualbox. (Maybe virtualbox efi 
implementation is just too limited, I don't know the exact reason.)

Best regards

tpowa

-- 

Tobias Powalowski
Arch Linux Developer (tpowa)
https://www.archlinux.org
tpowa@archlinux.org

Archboot Developer
https://archboot.com

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
info@st-martin-apo.de


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[adrian15sgd]

El 11/9/24 a las 12:38, Tobias Powalowski via Grub-devel escribió:
>
>> Back in the day I added that commit on the supergrub history because 
>> I wasn't proud enough of the SecureBoot implementation or I messed up 
>> in which branch I was pushing those changes.
>> Right now the SecureBoot build is turned on on the main supergrub 
>> codebase.
>>
>> It is based on the Debian binaries and, if I'm being honest, I might 
>> remove it (and suggest people to boot Super Grub2 Disk while 
>> SecureBoot is disabled) in the future because of two main reasons:
>>
>> - Not being able to keep up with Debian updates in order to avoid 
>> problems with revoked SecureBoot-enabled shims/grubs .
>> - Nobody seem to be asking for any Fedora / RedHat / SusE, 
>> you-name-it SecureBoot support for Super Grub2 Disk.
>>
>> Alternatively I could try to embed supergrub scripts onto an official 
>> Debian grub-related package and... just recommend that when you 
>> cannot turn off SecureBoot on your UEFI Firmware.
>> You want SecureBoot's SuperGrub in SusE ? Just port that package onto 
>> SusE yourself.
>>
>> Note: In this message: SuperGrub = Super Grub Disk = Super Grub2 Disk .
>>
>> adrian15
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
> Sorry to chime in, but it does not matter which distro you have as base.
>
> The shim needs to be signed by Microsoft, any built grub can then be 
> used afterwards.
>
> With a MOK setup you can pretty boot anything then.


This is what it usually happens in a Secure Boot scenario:

- UEFI Firmware loads up /BOOT/BOOTX64.EFI
- BOOTX64.EFI (shim) is loaded. (Signed by Microsoft)
- GRUBX64.EFI (Grub) is loaded. (Signed by Debian)
- Kernel is loaded. (Signed by Debian)

... if any of the previous signatures are not valid... Secure Boot 
refuses to boot everything.

So when I say that SuperGrub SecureBoot support is based on Debian 
binaries I'm actually saying that I'm using their signed binaries for 
shim and grub.
I'm also using the Ubuntu ones. So... with SG2D you can boot SecureBoot 
signed Debian kernels and SecureBoot signed Ubuntu kernels on a
SecureBoot enabled UEFI Firmware. (As long as those shim and grub 
binaries signatures are not revoked according to the UEFI's SBAT)

For me it **does matter** which distro I'm basing my binaries...
   You see... I'm not concerned on the very first boot part where shim 
boots in a SecureBoot enabled UEFI because Debian has managed to sign 
its shim by Microsoft.
   That works with no problem.
   I'm concerned about not being able to boot Fedora kernels, Suse 
kernels and so on from let's say "Debian's shim + Debian's grub" which 
it's later on on the boot process.
   I actually know that I could boot those Fedora / SusE kernels if I 
shipped:
     - Fedora's SecureBoot signed by Microsoft shim and its associated 
grub image.
     - SusE's SecureBoot signed by Microsoft shim and its associated 
grub image.
   but it's too much work for the little interest that regular users of 
Super Grub2 Disk are having onto this.

Also... regarding the original email from Askar be aware that he could 
be interested in Microsoft signing-in his grub binary (or in signing 
with his own keys) even if it's not the advised/usual way to go.

adrian15

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Tobias Powalowski via Grub-devel]

> This is what it usually happens in a Secure Boot scenario:
>
> - UEFI Firmware loads up /BOOT/BOOTX64.EFI
> - BOOTX64.EFI (shim) is loaded. (Signed by Microsoft)
> - GRUBX64.EFI (Grub) is loaded. (Signed by Debian)
> - Kernel is loaded. (Signed by Debian)
>
> ... if any of the previous signatures are not valid... Secure Boot 
> refuses to boot everything.
>
> So when I say that SuperGrub SecureBoot support is based on Debian 
> binaries I'm actually saying that I'm using their signed binaries for 
> shim and grub.
> I'm also using the Ubuntu ones. So... with SG2D you can boot 
> SecureBoot signed Debian kernels and SecureBoot signed Ubuntu kernels 
> on a
> SecureBoot enabled UEFI Firmware. (As long as those shim and grub 
> binaries signatures are not revoked according to the UEFI's SBAT)
>
You can boot any system with a MOK Machine Owner Key that is added to 
the EFI variables by mok manager tool.

In your scenario, shim launches mokmanager in which you can add any 
kernel and any boot manager to efi variables.

At least for my Arch Linux setup this works fine with fedora's shim. I 
think Ventoy also uses this method for booting anything.

Best regards

tpowa

-- 
Tobias Powalowski
Arch Linux Developer (tpowa)
https://www.archlinux.org
tpowa@archlinux.org

Archboot Developer
https://archboot.com

St. Martin-Apotheke
Herzog-Georg-Str. 25
89415 Lauingen
https://www.st-martin-apo.de
info@st-martin-apo.de


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin via Grub-devel]

 ---- On Wed, 11 Sep 2024 14:23:05 +0400  adrian15sgd  wrote --- 
 > No, I did not disable the SecureBoot support in Super Grub2 Disk because 
 > of this "efi" to "EFI" supposed problem that you describe.

I'm not talking about secure boot support in super grub disk. I'm talking about secure boot support on CD (as opposed to USB stick) in super grub disk.

Currently it seems from release page ( https://www.supergrubdisk.org/2024/07/30/super-grub2-disk-2-06s4-released/ ), that secure boot downloads come as USB stick images only, not as CD. Note: I don't ASK for adding support for CDs, I'm not super grub disk user, i. e. this is not feature request. I'm just pointing that CDs are not supported, and I still suspect that that "EFI vs efi" problem is the reason.

Anyway, I know how to create bootable GRUB CDs with secure boot support, so ask me if you have any questions.

You can use script in my first letter ( https://lore.kernel.org/grub-devel/20240906132914.27842-1-safinaskar@zohomail.com/ ) as starting point.

--
Askar Safin
https://types.pl/@safinaskar


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin via Grub-devel]

 ---- On Wed, 11 Sep 2024 14:38:31 +0400  Tobias Powalowski via Grub-devel  wrote --- 
 > I was not able to use virtualbox on my project until I put the kernel 
 > also to the ISO fs I think,

I suspect this is exactly same behaviour I'm talking about in my first letter. It is behaviour called "GRUB searches for files in ISO fs when booted from CD (in UEFI mode) and in ESP when booted from USB stick (in UEFI mode)". You seem to connect .iso to virtualbox as virtual CD as opposed to virtual USB stick. This is simply how GRUB works. This is exactly behaviour discussed in these letters in this thread:
- https://lore.kernel.org/grub-devel/20240906132914.27842-1-safinaskar@zohomail.com/
- https://lore.kernel.org/grub-devel/85fba0d5-de51-4736-9252-13576664cbc2@plouf.fr.eu.org/
- https://lore.kernel.org/grub-devel/29963309928969934189@scdbackup.webframe.org/
- https://lore.kernel.org/grub-devel/bcd9e556-9fe7-46ac-bc6f-68225b0fe444@plouf.fr.eu.org/

And this behaviour was surprise to author of xorriso. Anyway I would not call it a bug.

--
Askar Safin
https://types.pl/@safinaskar


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[adrian15sgd]

El 14/9/24 a las 12:47, Askar Safin escribió:
>   ---- On Wed, 11 Sep 2024 14:23:05 +0400  adrian15sgd  wrote ---
>   > No, I did not disable the SecureBoot support in Super Grub2 Disk because
>   > of this "efi" to "EFI" supposed problem that you describe.
>
> I'm not talking about secure boot support in super grub disk. I'm talking about secure boot support on CD (as opposed to USB stick) in super grub disk.
>
> Currently it seems from release page ( https://www.supergrubdisk.org/2024/07/30/super-grub2-disk-2-06s4-released/ ), that secure boot downloads come as USB stick images only, not as CD. Note: I don't ASK for adding support for CDs, I'm not super grub disk user, i. e. this is not feature request. I'm just pointing that CDs are not supported, and I still suspect that that "EFI vs efi" problem is the reason.
>
> Anyway, I know how to create bootable GRUB CDs with secure boot support, so ask me if you have any questions.
>
> You can use script in my first letter ( https://lore.kernel.org/grub-devel/20240906132914.27842-1-safinaskar@zohomail.com/ ) as starting point.
>
> --
> Askar Safin
> https://types.pl/@safinaskar
Well, it seems I overlooked the 'cd' part. I thought that the commit was 
only about SecureBoot and that's it.
I actually don't remember what problems I had trying to make a Super 
Grub2 Disk SecureBoot CD.
I guess that I actually decided not to build a SG2D SecureBoot CD after all.

I was surprised myself a few moments early not finding one specific 
download for that.

Not sure if it would be worth to create an SG2D SecureBoot CD but now I 
know that it's not there. So thank you!

adrian15

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[adrian15sgd]

El 14/9/24 a las 13:04, Askar Safin via Grub-devel escribió:
>   ---- On Wed, 11 Sep 2024 14:38:31 +0400  Tobias Powalowski via Grub-devel  wrote ---
>   > I was not able to use virtualbox on my project until I put the kernel
>   > also to the ISO fs I think,
>
> I suspect this is exactly same behaviour I'm talking about in my first letter. It is behaviour called "GRUB searches for files in ISO fs when booted from CD (in UEFI mode) and in ESP when booted from USB stick (in UEFI mode)". You seem to connect .iso to virtualbox as virtual CD as opposed to virtual USB stick. This is simply how GRUB works. This is exactly behaviour discussed in these letters in this thread:
> - https://lore.kernel.org/grub-devel/20240906132914.27842-1-safinaskar@zohomail.com/
> - https://lore.kernel.org/grub-devel/85fba0d5-de51-4736-9252-13576664cbc2@plouf.fr.eu.org/
> - https://lore.kernel.org/grub-devel/29963309928969934189@scdbackup.webframe.org/
> - https://lore.kernel.org/grub-devel/bcd9e556-9fe7-46ac-bc6f-68225b0fe444@plouf.fr.eu.org/
>
> And this behaviour was surprise to author of xorriso. Anyway I would not call it a bug.

 > GRUB searches for files in ISO fs when booted from CD (in UEFI mode)

Well, that needs more detailed explanation. There are two steps involved.
A Debian live cd as you have pointed out reuses a gcdx64.efi file.
That gcdx64.efi file has an embedded memdisk with an special grub.cfg. 
Then that special grub.cfg finds those CD files and configfiles to there.

As I want to be able to read the ElTorito image contents somehow I am 
actually trying to build a barebones Grub ElTorito image for UEFI CD 
boot in my Rescatux development streams.
I want to check what actually happens in that scenario without an 
embedded memdisk.

adrian15


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin via Grub-devel]

Hi, Adrian.

 ---- On Sat, 14 Sep 2024 17:56:17 +0400  adrian15sgd  wrote --- 
 > Well, that needs more detailed explanation.

Debian has 4 signed GRUB images ( https://salsa.debian.org/grub-team/grub/-/blob/master/debian/build-efi-images?ref_type=heads ) (I will refer to this file as "build-efi-images"):

- gcdx64.efi
- grubx64.efi
- grubnetx64.efi
- grubnetx64-installer.efi

(Note that in this letter I will use the latest version of "build-efi-images", available at link above.)

(Again: versions of involved software matter. For example, as well as I understand, bookworm version of "build-efi-images" differs from the git version. So, when reading this letter use versions I use.)

So far when I wrote my previous letters I kept in mind grubx64.efi, not gcdx64.efi . And I wrote about boot process of debian installer, not debian live. Debian installer uses grubx64.efi and debian live uses gcdx64.efi . So, again: all I wrote in my previous letters applies to debian installer with grubx64.efi, not to debian live with gcdx64.efi .

Okay, now let me describe how boot process works. First I will talk about debian installer, and then about debian live. I got all this information from experiments.

Also: I suggest grubx64.efi as opposed to gcdx64.efi for super grub disk for reasons explained below.

Part 1. Debian installer.

I will use this image https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso .

Note that this image (specially: iso fs) contains file /.disk/mkisofs, which contains the exact xorriso invocation, which created this image.

Iso fs contains file /boot/grub/efi.img , which is ESP partition (EFI System Partition). This partition (i. e. fat fs) contains these 3 files: /efi/boot/bootx64.efi , /efi/boot/grubx64.efi and /efi/debian/grub.cfg . (Yes, we see /efi here, not /EFI, but this is not important, because this is a FAT filesystem, and so it is case-insensitive.)

Main fs, i. e. iso fs, contains exactly the same files (but with EFI, not efi).

Part 1.1. UEFI CD boot

Firmware executes /efi/boot/bootx64.efi from ESP (which is shim). The shim executes /efi/boot/grubx64.efi from ESP (which is grubx64.efi , not gcdx64.efi). grubx64.efi loads /EFI/debian/grub.cfg from iso fs (not from ESP). grubx64.efi does this, because this path is hardcoded in the binary. It is hardcoded, because "build-efi-images" builds grubx64.efi using 'grub-mkimage -p "/EFI/$efi_vendor" ...', and $efi_vendor is "debian". grubx64.efi has no "early config". Also grubx64.efi has memdisk, but the memdisk doesn't have any configuration, so memdisk doesn't affect boot logic.

Okay, so /EFI/debian/grub.cfg from iso fs is loaded. This is a short file, which finds iso fs root using "search --file --set=root /.disk/id/dae2967f-d173-4909-90fd-7cb26e6945dc". In this particular case this is not needed, because $root is already set to iso fs. So this "search" is no-op. Then /EFI/debian/grub.cfg sets $prefix and loads /boot/grub/x86_64-efi/grub.cfg from iso fs, which is "real" grub config.

Part 1.2. UEFI USB boot

Exactly the same thing happens as we know from UEFI CD boot. With the following changes. grubx64.efi loads /EFI/debian/grub.cfg from ESP, not from iso fs. (But these two files are same anyway.) Then this /EFI/debian/grub.cfg performs "search --file --set=root /.disk/id/dae2967f-d173-4909-90fd-7cb26e6945dc", and this time this "search" is not no-op. It actually matters. Because it changes $root from ESP to iso fs. Then /EFI/debian/grub.cfg sets $prefix and loads /boot/grub/x86_64-efi/grub.cfg from iso fs, which is "real" grub config.

Part 2. Debian live

I will use https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-standard.iso

This image also contains /.disk/mkisofs , which contains xorriso invocation.

This image (i. e. iso fs) contains /boot/grub/efi.img , which is ESP partition.

ESP contains 3 files: /EFI/boot/bootx64.efi (shim), /EFI/boot/grubx64.efi (this is actually gcdx64.efi , as opposed to debian installer) and /boot/grub/grub.cfg .

These 3 files are NOT identical to corresponding files on iso fs (as opposed to debian installer). I. e. bootx64.efi and grubx64.efi seem to be identical. But /boot/grub/grub.cfg is not.

Part 2.1. UEFI CD boot

Firmware executes /EFI/boot/bootx64.efi from ESP. bootx64.efi executes /EFI/boot/grubx64.efi from ESP.

grubx64.efi (which is actually gcdx64.efi), as opposed to real grubx64.efi , contains so-called early config. I know this, because in "build-efi-images" I see that gcdx64.efi is generated using "grub-mkimage -c ... ...". Option "-c" means early config. That early config loads grub.cfg from memdisk. Memdisk's grub.cfg is a complicated "if"-based script. You can see it in "build-efi-images". I will not explain in detail how this "grub.cfg" works. (But if you want, I can explain it.) Anyway, this "grub.cfg" loads /boot/grub/x86_64-efi/grub.cfg from iso fs (we booted using UEFI CD, so $root is already set to iso fs).

/boot/grub/x86_64-efi/grub.cfg from iso fs loads /boot/grub/grub.cfg from iso fs, which is the main config.

Part 2.2. UEFI USB boot

Everything is the same as part 2.1 with the following changes. When grub.cfg from memdisk is executed, $root is set to ESP, not to iso fs. So grub.cfg from memdisk executes differently. (Again, I will not get into details about how it is executed, but you can ask me.) This time grub.cfg from memdisk loads /boot/grub/grub.cfg from ESP. This /boot/grub/grub.cfg executes "search --set=root --file /.disk/info". This command finds the real root, i. e. iso fs. I. e. this command changes $root from ESP to iso fs. Of course, this is very fragile, because we simply switch to whatever disk, which contains /.disk/info . This will not work if our system has multiple live debian disks inserted. I think this is a bug, so I reported it to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081041 . So I suggest using grubx64.efi as opposed to gcdx64.efi for super grub disk.

Okay, so /boot/grub/grub.cfg from ESP executed "search" and set $root. Then this /boot/grub/grub.cfg sets $prefix and loads /boot/grub/grub.cfg from iso fs, which is the main config.

Small note: I'm 100% sure about how debian installer boot process works. Because I did a lot of experiments. And I'm 90% sure about how debian live boot process works. Because I didn't perform any experiments with debian live. I simply applied my knowledge, gained from debian installer experiments, to debian live boot process. So, we get 90% only, not 100%. My main doubt about debian live boot process is how grub.cfg from memdisk is executed. I didn't do any experiments with this grub.cfg, I simply have read it and executed in my head. printf-debugging would be certainly better. I. e. what I really should do is to insert "echo" commands to this grub.cfg, then regenerate gcdx64.efi (using code from "build-efi-images") (unsigned, of course), then regenerate debian live image (for example, by reexecuting command from /.disk/mkisofs ) and then run it in qemu. I did not do this, you can do this if you want. I can explain in more detail how to do this, this is easy.

But again: I'm 90% sure about how debian live boot process works. 90% is a high probability.

Okay, so hopefully I explained everything.

If you have any questions, ask me.

Also: when I said "GRUB searches for files in ISO fs when booted from CD (in UEFI mode)", I meant that GRUB itself (not any kind of configs) sets $root to iso fs, when booted as UEFI-CD. This is how GRUB itself works, this is not related to Debian GRUB images or any particular configs. It is even possible that reasons are even deeper, i. e. reason is not GRUB, but UEFI itself or something.

Anyway, when we boot using UEFI-CD, $root is set to iso fs, and when we boot using UEFI-USB, $root is set to ESP. This applies to all GRUB images, not necessary to Debian GRUB images. And we should keep this in mind when we execute any kind of GRUB configs in our heads.

But there is a note here: this applies in these two situations:
1. GRUB image was generated without memdisk
2. GRUB image was generated with memdisk, but when generating -p option (to grub-mkimage) was set after -m option

In these two situations $root will be set as I described above (I know this from experiments). There is also 3rd situation:
3. GRUB image was generated with memdisk, and there was no -p option after -m

Well, I don't know what will happen in this case, I didn't do experiments on this.

Also, my algorithm on determining $root applies if prefix set using -p option to grub-mkimage starts with "/", for example, /boot/grub. I don't know what will happen if it starts from "(" or anything else.

 > A Debian live cd as you have pointed out reuses a gcdx64.efi file.

Yes.

 > That gcdx64.efi file has an embedded memdisk with a special grub.cfg. 

Yes. As I explained above, first early config is executed, then it executes grub.cfg from memdisk.

 > Then that special grub.cfg finds those CD files and configfiles to there.

Yes. I explained above how this happens. Also, it "sources", not "configfiles", according to "build-efi-images" from current git.

 > As I want to be able to read the ElTorito image contents somehow

I don't know terminology here well. What do you mean by ElTorito image? You mean ESP partition? And you want to extract ESP partition from official debian live image? This is easy. Mount iso image. You will see xorriso command in /.disk/mkisofs . That command mentions /boot/grub/efi.img . So this is ESP. Just mount it.

 > I am 
 > actually trying to build a barebones Grub ElTorito image for UEFI CD 
 > boot in my Rescatux development streams.

I can help. Just tell exactly what you are trying to build. GRUB image? I. e. what is generated by grub-mkimage? Or .iso? Or both? Or ESP?! Tell in detail what you want to build and I will give you commands to do this.

 > I want to check what actually happens in that scenario without an 
 > embedded memdisk.

Again: tell in details what you want to check. I will try to give you commands.

--
Askar Safin
https://types.pl/@safinaskar

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin via Grub-devel]

So, what about my patch? I will repeat: my patch doesn't remove any existing use cases and adds new use cases. It enables distros to implement secure boot in grub-mkimage. As I already told with examples in my first letter, Linux distros already converged to "EFI", not "efi". Current solution by Debian is not to use grub-mkimage. My patch will allow Debian to use grub-mkimage

--
Askar Safin
https://types.pl/@safinaskar



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Change "efi" to "EFI" in grub-mkrescue for secure boot

[Askar Safin via Grub-devel]

Oops, I meant grub-mkrescue, not grub-mkimage, in this mail.


 ---- On Fri, 27 Sep 2024 20:10:30 +0400  Askar Safin  wrote --- 
 > So, what about my patch? I will repeat: my patch doesn't remove any existing use cases and adds new use cases. It enables distros to implement secure boot in grub-mkimage. As I already told with examples in my first letter, Linux distros already converged to "EFI", not "efi". Current solution by Debian is not to use grub-mkimage. My patch will allow Debian to use grub-mkimage
 > 
 > --
 > Askar Safin
 > https://types.pl/@safinaskar
 > 
 > 
 > 

--
Askar Safin
https://types.pl/@safinaskar



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel