#3423 Issue closed: GRUB UEFI Secure Boot entry not working, non-secure boot entry works

Labels: bug, fixed / solved / done

schlomo opened issue at 2025-03-11 09:40:

ReaR version

Relax-and-Recover 2.9 / 2025-01-31

Describe the ReaR bug in detail

It seems like we should get rid of the separate boot entries for secure boot and regular.

Image

Image

I'm wondering if this is related to us fixing the automated secure boot detection, and if the separate boot entries are still required.

Booting from the "non Secure Boot" entry works totally fine and mokutil --sb-state also shows secure boot to be enabled. Which is why I'm wondering if we should remove the dual boot entries.

rear mkbackup log: rear-rear-u24.log

Platform

Linux x64

OS version

Ubuntu 24.04

Backup

NETFS

Storage layout

No response

What steps will reproduce the bug?

my site.conf is super simple:

OUTPUT_URL=nfs://pvm/rear-backup
BACKUP_URL=$OUTPUT_URL
BACKUP=NETFS

Workaround, if any

Use the seemingly wrong non-secure-boot boot entry

Additional information

No response

schlomo commented at 2025-03-11 10:13:

BTW, when I switch to BIOS boot then this ISO doesn't even boot because of a ISOLINUX error:

Image

But maybe this is the case of https://github.com/rear/rear/issues/2471#issuecomment-671320189 and not really a problem as we don't support BIOS booting a recovery image created on an UEFI machine.

schlomo commented at 2025-03-11 10:25:

https://projects.theforeman.org/issues/38178 sugests that initrdefi was a temporary solution that has been deprecated, and that GRUB2 in Ubuntu 24.04 doesn't support that any more.

Given that both GRUB2 boot entries seem to be identical and use the exactly same $grub2_kernel except for the efi suffix, maybe we can find out if we still need to support that efi suffix for our currently supported distros?
https://github.com/rear/rear/blob/15e9f9cc3575f31d1347db6559e8fd3f0527a535/usr/share/rear/lib/bootloader-functions.sh#L678-L693

https://github.com/rear/rear/pull/2001 seems to be related to the introduction of the linuxefi commands, but on this Ubuntu 24.04 I got here there is no linuxefi.mod at all.

jsmeix commented at 2025-03-12 13:21:

@schlomo
only a side note FYI:

Since a long time it is known that those two entries
behave somewhat unpredictable / misleading / problematic
in this or that cases so the usual way in practice is to
"just try out which one works in your particular environment".

In general:
I am not at all a sufficient UEFI expert so normally
I can neither actually help with debugging UEFI related issues
nor can I fix UEFI related issues (except exceptions).
What I could do via basically blind trial and error
would be to make things somehow work for my specific system
but this would be certainly not a proper solution for ReaR.
Fortunately things work so far for me with SLE15, cf.
https://github.com/rear/rear/issues/3084#issuecomment-1835773844

github-actions commented at 2025-05-12 03:02:

Stale issue message

schlomo commented at 2025-05-19 07:43:

I'll at least improve the wording in the GRUB menu

lzaoral commented at 2025-06-09 14:10:

I've just checked the situation in Fedora and RHEL.

The support for the linuxefi and initrdefi commands with distinct semantics was introduced in Fedora 17 [1]. The patches were restructured in Fedora 29 and linuxefi and initrdefi became mere aliases for linux and initrd [2]. The same unification can be found in RHEL 8 and newer.

Moreover, these commands were never introduced on non-x86 architectures, e.g. aarch64, so these extra entries will be broken there (when #3440 gets merged).

I can't speak for Ubuntu or SLES but at least on Fedora-based distros, these entries are redundant.

[1] https://src.fedoraproject.org/rpms/grub2/c/58a808c00980b3a2e7d44d8d309e6e6219f100ff
[2] https://src.fedoraproject.org/rpms/grub2/c/ad4aff0c12370a6edc82478d8ca83627f6916e3d

lzaoral commented at 2025-06-16 12:54:

edit: The following is not entirely true.

I've also checked Debian sources and Bullseye [1] and Bookworm [2] have linuxefi and initrdefi commands with distinct semantics (though there is a newer version of grub2 in bookworm-backports).

[1] https://sources.debian.org/src/grub2/2.06-13+deb12u1/debian/patches/linuxefi.patch/
[2] https://sources.debian.org/src/grub2/2.06-13%2Bdeb12u1/debian/patches/linuxefi.patch/

github-actions commented at 2025-08-16 03:00:

Stale issue message

lzaoral commented at 2025-09-05 12:40:

We have looked at this issue again with @pcahyna and the Debian patches I've linked in https://github.com/rear/rear/issues/3423#issuecomment-2976548159 contain additional changes not present in the Fedora original with the following description:

    - Automatically call linuxefi from linux if secure boot is enabled and
      the kernel is signed, to hand over to the kernel without calling
      ExitBootServices.  Otherwise, linux will fall through to previous
      code, call ExitBootServices itself, and boot the kernel normally.

In other words, even though linuxefi and linux are different commands with distinct semantics, it should be safe to always use linux on Debian and Ubuntu.

lzaoral commented at 2025-09-05 12:54:

I've also checked SUSE and openSUSE Leap 15 mimics Fedora and RHEL and linuxefi and linux are equivalent: https://build.opensuse.org/projects/openSUSE:Leap:15.6/packages/grub2.20627/files/0001-efi-linux-provide-linux-command.patch?expand=0

@jsmeix Could you please check if the same holds for SLES as well? Thank you!

jsmeix commented at 2025-09-08 13:34:

@lzaoral
efi-linux-provide-linux-command.patch exists
since SLES15 SP2 and also since openSUSE Leap 15.2
in both introduced via a grub2 RPM update.

lzaoral commented at 2025-09-09 11:55:

Thank you, @jsmeix! Therefore, if it's fine to (possibly) break support for releases older than SLES15 SP2, it should be ok to drop the problematic GRUB 2 menu entry as well.

jsmeix commented at 2025-09-09 12:52:

It is OK to break support for releases older than SLES15 SP2
in the upcoming ReaR 3.0 because

  • there should be no SLES15 user who still uses such an old service pack (SP)
  • even if there is a SLES15 user who still uses SLES15 SP2 he should usually have no reason to update to ReaR 3.0
  • ReaR for SLES is provided via the High Availability Extension (HA) and SUSE support for SLES HA 15 SP2 ended in general on 31 Dec 2021 and Long Term Service Pack Support ended on 31 Dec 2024 see https://www.suse.com/de-de/lifecycle/#suse-linux-enterprise-high-availability-extension-15

ZzenlD commented at 2026-04-02 05:33:

I’m going to try posting my issue here, since I think it’s related to the linked comment.

I want to use Rear (2.7) on a Proxmox host (9.1.6, Debian Trixie 13.3). The system is installed using BIOS.

This and other systems (some UEFI and some BIOS) back up the ISO files to a central drive.
Now I’ve created a VM with UEFI on a Proxmox host, which I want to use to periodically boot the ISO files and restore them for testing purposes. But when I boot the ISO image of the BIOS-installed Proxmox host on the UEFI VM, I get this error message:

No bootfile found for UEFI!
Maybe the image does not support x64 UEFI

I hope that was clear. Is this related, or should I open a new issue for this?

Thanks, you guys are great :)

lzaoral commented at 2026-04-09 08:18:

Hello @ZzenlD! The problem you describe in your comment is something else. This issue only deals with the "secure boot" grub2 menu entry being broken on modern EFI systems.

jsmeix commented at 2026-10-15 12:02:

With https://github.com/rear/rear/pull/3597 merged
this issue should be done.

[Export of Github issue for rear/rear.]