#3191 Issue closed: x86_64 UEFI system needs GRUB2_IMAGE_FORMAT=x86_64-efi¶
Labels: bug, fixed / solved / done
jsmeix opened issue at 2024-04-03 15:48:¶
This is related to the changes in
https://github.com/rear/rear/pull/3157
On my openSUSE Leap 15.5 x86_64 UEFI system
with current GitHub master code with
https://github.com/rear/rear/commit/3db2724c7860e38fad96ba4d35c8b174616c1496
that makes "rear mkrescue" fail with
++ test
++ LogPrintError 'grub2-mkstandalone may fail to make a bootable EFI image of GRUB2 (no /usr/*/grub*/i386-efi/moddep.lst file)'
...
++ grub2-mkstandalone -v '--modules=cryptodisk ext2 fat gcry_rijndael gcry_sha256 luks part_gpt part_msdos' -O i386-efi -o /var/tmp/rear.t0eFjv7bA3CjENy/tmp/mnt/EFI/BOOT/BOOTX64.efi /boot/
grub/grub.cfg=/var/tmp/rear.t0eFjv7bA3CjENy/tmp/mnt/EFI/BOOT/grub.cfg
grub2-mkstandalone: error: /usr/share/grub2/i386-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
because I have
# uname -m
x86_64
# find /usr -type f | grep 'moddep.lst'
/usr/share/grub2/x86_64-efi/moddep.lst
/usr/share/grub2/i386-pc/moddep.lst
# find /usr -type f | grep 'modinfo.sh'
/usr/share/grub2/x86_64-efi/modinfo.sh
/usr/share/grub2/i386-pc/modinfo.sh
so I need GRUB2_IMAGE_FORMAT=x86_64-efi in
usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh
--- a/usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh
+++ b/usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh
@@ -16,7 +16,8 @@ case "$REAL_MACHINE" in
;;
(x86_64)
EFI_ARCH=x64
- GRUB2_IMAGE_FORMAT=i386-efi
+ # GRUB2_IMAGE_FORMAT=i386-efi
+ GRUB2_IMAGE_FORMAT=x86_64-efi
;;
(*)
BugError "Unknown architecture $REAL_MACHINE"
jsmeix commented at 2024-04-03 15:55:¶
@pcahyna
for now this is just a quick issue report
so that it is not forgotten.
I will have a closer look tomorrow.
At first glance in
usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh
https://github.com/rear/rear/blob/master/usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh
it looks like a typo
(i686|i586|i386)
...
GRUB2_IMAGE_FORMAT=x86_64-efi
(x86_64)
...
GRUB2_IMAGE_FORMAT=i386-efi
to set GRUB2_IMAGE_FORMAT
to x86_64... in case of i686|i586|i386
and to i386... in case of x86_64.
@pcahyna
is this a typo or even intentional?
pcahyna commented at 2024-04-03 16:08:¶
@jsmeix Oops, I must have swapped the two! Really sorry. It is curious how even a simplest change can break things.
jsmeix commented at 2024-04-04 09:11:¶
I am confused when looking at
usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh
because it sets the GRUB2_IMAGE_FORMAT variable
only to grub-mkstandalone --format values
for EFI ('x86_64-efi' and 'i386-efi')
regardless that prep/Linux-i386/330_set_efi_arch.sh
is run for EFI and BIOS systems.
So on a BIOS system GRUB2_IMAGE_FORMAT
is set to a value for EFI systems
which is a contradiction.
The prep/Linux-*/330_set_efi_arch.sh scripts tell [sic!]
# Se the variables even if USING_UEFI_BOOTLOADER empty or no explicit 'true' value
so that is intentional but it does not tell why.
As far as I see it works currently only because
the generic GRUB2_IMAGE_FORMAT variable
is only used in case of EFI
# find usr/sbin/rear usr/share/rear/ -type f | xargs grep -l 'GRUB2_IMAGE_FORMAT'
usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh
usr/share/rear/prep/Linux-arm/330_set_efi_arch.sh
usr/share/rear/prep/Linux-ia64/330_set_efi_arch.sh
usr/share/rear/lib/uefi-functions.sh
usr/share/rear/output/RAWDISK/Linux-i386/270_create_grub2_efi_bootloader.sh
but things will fail if GRUB2_IMAGE_FORMAT
will be also used for BIOS systems in the future.
@pcahyna
could you explain the intent behind why on a BIOS system
GRUB2_IMAGE_FORMAT is set to a value for EFI systems?
jsmeix commented at 2024-04-05 14:16:¶
This issue does not depend on openSUSE Leap 15.5
but (probably) happens on all x86_64 UEFI systems.
pcahyna commented at 2024-04-05 19:43:¶
I am confused when looking at usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh because it sets the GRUB2_IMAGE_FORMAT variable only to
grub-mkstandalone --formatvalues for EFI ('x86_64-efi' and 'i386-efi') regardless that prep/Linux-i386/330_set_efi_arch.sh is run for EFI and BIOS systems.So on a BIOS system GRUB2_IMAGE_FORMAT is set to a value for EFI systems which is a contradiction.
The intent of the variable is to hold the image format for EFI GRUB on
the platform, so the variable is simply misnamed. I should have called
it GRUB2_EFI_IMAGE_FORMAT.
The prep/Linux-*/330_set_efi_arch.sh scripts tell [sic!]
# Se the variables even if USING_UEFI_BOOTLOADER empty or no explicit 'true' valueso that is intentional but it does not tell why.
My bad, I should have indicated why and I don't even recall exactly, but
I believe it has referred to the EFI_ARCH* variables and not to
GRUB2_IMAGE_FORMAT originally. I think I did not want to audit all
uses of EFI_ARCH* whether they are protected by a test of for
USING_UEFI_BOOTLOADER (we don't want to refer to an undefined variable
and to prevent it the easiest way is to define it always). Actually I
see at least some use of EFI_ARCH* that is not conditional on
USING_UEFI_BOOTLOADER:
usr/share/rear/output/RAWDISK/Linux-i386/{270_create_grub2_efi_bootloader.sh,260_create_syslinux_efi_bootloader.sh},
so setting the variable always is the right thing already.
As far as I see it works currently only because the generic GRUB2_IMAGE_FORMAT variable is only used in case of EFI
# find usr/sbin/rear usr/share/rear/ -type f | xargs grep -l 'GRUB2_IMAGE_FORMAT' usr/share/rear/prep/Linux-i386/330_set_efi_arch.sh usr/share/rear/prep/Linux-arm/330_set_efi_arch.sh usr/share/rear/prep/Linux-ia64/330_set_efi_arch.sh usr/share/rear/lib/uefi-functions.sh usr/share/rear/output/RAWDISK/Linux-i386/270_create_grub2_efi_bootloader.shbut things will fail if GRUB2_IMAGE_FORMAT will be also used for BIOS systems in the future.
Another variable will have to be introduced then. You may wonder why not to have just one variable that holds the correct image format for the given situation, regardless of whether it is UEFI or BIOS. I believe it is better to keep it separated for the case when we need to handle a hybrid boot setup. I think we are already creating bootable media with ESP even on BIOS systems and we may be able to create hybrid boot media in the future (maybe we are already able to do that in some situations). We are also already capable of restoring hybrid bootloader setups.
[Export of Github issue for rear/rear.]