#3565 PR `merged`: Add GRUB2-BLS support¶

Labels: enhancement, fixed / solved / done

svlv opened issue at 2026-02-13 16:50:¶

Pull Request Details:¶

Type: Enhancement
Impact: Normal
Reference to related issue (URL): Fixes https://github.com/rear/rear/issues/3564
How was this pull request tested?
Manually recovered openSUSE Tumbleweed
Description of the changes in this pull request:

The recovery process for GRUB2-BLS doesn't require
updating grub.cfg, since it is generated on the fly
based on entries defined in /boot/efi/loader/entries.

On openSUSE Tumbleweed, these entries
use the kernel and initrd from the
/boot/efi/opensuse-tumbleweed/6.18.9-1-default/
directory.

The only way I've found to regenerate the initrd is
to run sdbootutil mkinitrd.

It regenerates initrd using dracut under the hood,
places it to the corresponding location
(/boot/efi/opensuse-tumbleweed/6.18.9-1-default/ in my case)
and updates a bootloader entry.

svlv commented at 2026-02-17 11:53:¶

I've additionally tested GRUB2-BLS support on RHEL 10.
Without the patch the bootloader on RHEL 10 is detected as GRUB2-EFI.

pcahyna commented at 2026-02-20 12:58:¶

Sorry for being late - I will have a look.

jsmeix commented at 2026-02-23 14:07:¶

@svlv
please document (if needed with further explanations)
the new 'GRUB2-BLS' in usr/share/rear/conf/default.conf at

# BOOTLOADER
...
# What is currently listed in layout/save/default/450_check_bootloader_files.sh
# is: GRUB2-EFI EFI GRUB2 GRUB ELILO LILO PPC ARM ARM-ALLWINNER ZIPL

https://github.com/rear/rear/blob/rear-2.9/usr/share/rear/conf/default.conf#L3776

pcahyna commented at 2026-02-23 14:18:¶

@svlv please document (if needed with further explanations) the new 'GRUB2-BLS' in usr/share/rear/conf/default.conf at
# BOOTLOADER
...
# What is currently listed in layout/save/default/450_check_bootloader_files.sh
# is: GRUB2-EFI EFI GRUB2 GRUB ELILO LILO PPC ARM ARM-ALLWINNER ZIPL
https://github.com/rear/rear/blob/rear-2.9/usr/share/rear/conf/default.conf#L3776

I will discuss it in more detail later - but before documenting it, please think about why is the new GRUB2-BLS value needed at all and what is it intended to represent - from the PR it is not clear at all to me.

svlv commented at 2026-02-23 14:33:¶

@pcahyna

Because in /etc/sysconfig/bootloader at least Fedora, openSUSE Tumbleweed, Rocky 9 put grub2-bls as their bootloader type (instead of grub2-efi)

At least for openSUSE Tumbleweed the recovery process is not the same as for GRUB2-EFI that is why I introduced GRUB2-BLS type (basically, it is not enough to run dracut, initrd also must be copied to the expected location)

However, currently, for RHEL 8,9,10 GRUB2-EFI can be changed to GRUB2-BLS and vise verse without any issues.
But strictly speaking if distro developers started distinguishing GRUB2-EFI and GRUB2-BLS, software that relies on /etc/sysconfig/bootloader should do it as well.

Does it explain my proposal?

svlv commented at 2026-02-24 12:18:¶

I've mentioned GRUB2-BLS in default.conf and added a brief explanation.

Also, I want to explain in more detail the patch.

With this patch BOOTLOADER is set to GRUB2-BLS in two cases:

/etc/sysconfig/bootloader contains LOADER_TYPE="grub2-bls".
Currently it happens on Fedora 43, openSUSE Tumbleweed and Rocky Linux 9.
grub.cfg contains blscfg
Currently it happens on RHEL 8, 9 and 10.

Please note, that without this patch in RHEL 8, 9 and 10, BOOTLOADER is set to GRUB2-EFI, although these systems use GRUB2-BLS in reality (/etc/sysconfig/bootloader is missing on these systems).

GRUB2-BLS is introduced here because on openSUSE Tumbleweed during recovery sdbootutil is used when BOOTLOADER=GRUB2-BLS. On other systems I tested, GRUB2-EFI can be used instead of GRUB2-BLS without visible issues at the moment.

In /etc/sysconfig/bootloader there is the following information regarding possible LOADER_TYPE values:

## Path:        System/Bootloader
## Description: Bootloader configuration
## Type:        list(grub,grub2,grub2-efi,grub2-bls,systemd-boot,none)
## Default:     grub2
#
# Type of bootloader in use.
# For making the change effect run bootloader configuration tool
# and configure newly selected bootloader
#
#
LOADER_TYPE="grub2-bls"

jsmeix commented at 2026-02-24 14:40:¶

@pcahyna
because of your
https://github.com/rear/rear/pull/3565#issuecomment-3945037642
I dared to assign this pull request to you
so you can decide when it is OK to be merged.

pcahyna commented at 2026-02-24 17:09:¶

@svlv

I think that the original version did not mention /etc/sysconfig/bootloader at all, so the GRUB2-BLS value seemed to appear "out of thin air". Now I see where it comes from, thanks for the explanation.

I however doubt that this value should be put into our $bootloader_file. What is it meant to represent? The file $bootloader_file determines what bootloader should we reinstall at the end of recovery, and GRUB2-BLS is not really a different bootloader, but merely a different way to configure a bootloader. In general transferring values detected at mkrescue time into the recovered system via a file like $bootloader_file or /etc/rear/rescue.conf can be problematic and it is better to make the appropriate decisions dynamically during recovery according to what is actually on the system.
You may ask why to save $bootloader_file at all then - the answer is that many bootloaders are installed into the boot sector which is outside the filesystem itself, so by the time recovery runs this information from the original system would be otherwise irretrievably lost and the only way to obtain the information is by mkrescue time and save it - the information is essentially part of the storage layout (you may see that some bootloaders get detected by analyzing the boot sector, which may seem crude but is the only way to determine what's really there).

The problem with the GRUB2-BLS value is that we need to know where/how to install the bootloader, but the value tells us how to configure it, and these are two very different steps. Think about it: how do we distinguish GRUB2 on BIOS with BLS and GRUB2 on EFI with BLS? Are both represented by the GRUB2-BLS value? But how do we know whether to run grub2-install on the disks (we do with BIOS) or not (we don't with EFI)? Clearly we need the GRUB2 value here and GRUB2-BLS only adds confusion.

You wrote that "in /etc/sysconfig/bootloader at least Fedora ...put grub2-bls" but I don't see that in a fresh Fedora install. How have you determined that? I am curious which package owns that file (rpm -qf /etc/sysconfig/bootloader). I suspect that if you see this, the file actually gets installed via some image generating tool like Kiwi ( https://github.com/OSInside/kiwi/pull/227 ) and I see that it was added by a person of SUSE fame, so I suspect it is a SUSE-specific file that this particular tool injects into other OSes' images without being a standard there.

tl;dr I don't think the possible values of /etc/sysconfig/bootloader should determine the allowed content of $bootloader_file as they serve a different purpose.

I understand your point that "if distro developers started distinguishing GRUB2-EFI and GRUB2-BLS, software that relies on /etc/sysconfig/bootloader should do it as well." It is a valid point and I appreciate your effort at fixing this. But I think that the implementation should look rather different. Namely, we should check that the value we obtained from /etc/sysconfig/bootloader is among the values that we actually support in $bootloader_file (because otherwise next time a new value gets added, it will break again) and either error out or ignore unknown values, while GRUB2-BLS should be mapped to something else or the GRUB autodetection should be attempted (see the next statements in the file).

Note that relying on the /etc/sysconfig/bootloader file is in general quite problematic, so perhaps we should rely on it a bit less than we do now. How do you restore a hybrid bootloader using that? Imagine an image that can boot with both BIOS and UEFI, but the file can contain just a single value - which one? If GRUB2-EFI, then the BIOS bootloader will not be restored and when using BIOS booting the system will be unbootable. See the comment about hybrid bootloader https://github.com/nable-backup/rear/blob/aaa7033aa362b5ce30b0718232ec4d40762f363b/usr/share/rear/layout/save/default/445_guess_bootloader.sh#L134 . (This problem is not new, I noticed the presence of nonstandard /etc/sysconfig/bootloader file in some Fedora images and resulting breakage of hybrid bootloader restore already several years ago when working on the hybrid bootloader save/restore capability, but I do not remember the details.)

svlv commented at 2026-02-25 09:43:¶

@pcahyna

Good point. Let me summarise

Adding GRUB2-BLS is not desirable as it is not a new bootloader but the patched GRUB2 upstream version. Also, adding GRUB2-BLS will add confusion.
GRUB2-BLS detection can be done for openSUSE Tumbleweed at recovery time.
Unknown bootloaders from /etc/sysconfig/bootloader should be ignored.
CHECK_CONFIG_FILES should always include boot entries (to keep the logic simple and since it is allowed to add missing files there).

Please let me know if I've missed something.

You wrote that "in /etc/sysconfig/bootloader at least Fedora ...put grub2-bls" but I don't see that in a fresh Fedora install. How have you determined that? I am curious which package owns that file (rpm -qf /etc/sysconfig/bootloader). I suspect that if you see this, the file actually gets installed via some image generating tool like Kiwi ( https://github.com/OSInside/kiwi/pull/227 ) and I see that it was added by a person of SUSE fame, so I suspect it is a SUSE-specific file that this particular tool injects into other OSes' images without being a standard there.

I've downloaded ISO for Fedora 43 and installed it in VMware. By the way, not only me - https://github.com/rear/rear/issues/3564
The link I've used is Fedora-Workstation-Live-43-1.6.x86_64.iso

pcahyna commented at 2026-02-25 17:27:¶

@pcahyna

Good point. Let me summarise

1. Adding `GRUB2-BLS` is not desirable as it is not a new bootloader but the patched GRUB2 upstream version. Also, adding GRUB2-BLS will add confusion.

I think it does not matter whether it is patched or not, what matters it that it is a way to configure GRUB, not a special bootloader in itself nor a specific location for it (GRUB2 and GRUB2-EFI are also the same bootloader, but with a very different location on disk resulting in different install methods and therefore they need to be treated separately as if they were different bootloaders).

2. `GRUB2-BLS` detection can be done for openSUSE Tumbleweed at recovery time.

Yes, I believe it is cleaner.

3. Unknown bootloaders from `/etc/sysconfig/bootloader` should be ignored.

Now I am not sure about this point. For GRUB2-BLS, it would be the right thing to do (GRUB detection can then proceed normally). But in general an unknown value in /etc/sysconfig/bootloader indicates that we are in an unknown situation and we miss code to handle it. To some extent the BugError "Unknown bootloader ($used_bootloader) - ask for sponsoring to get this fixed" line in layout/save/default/450_check_bootloader_files.sh handles it, but I think that erroring out earlier is safer. If there is an unknown bootloader, but GRUB2 is installed, we would detect GRUB2 and proceed as if the bootloader used is GRUB2, even though we should use that unknown bootloader instead.

(You don't need to add this check yourself, it is already outside the scope of this PR.)

4. `CHECK_CONFIG_FILES` should always include boot entries (to keep the logic simple and since it is allowed to add missing files there).

Yes, at least for bootloaders that are known to support BLS (probably adding it everywhere is the easiest choice).

Please let me know if I've missed something.

No, I think that's it.

You wrote that "in /etc/sysconfig/bootloader at least Fedora ...put grub2-bls" but I don't see that in a fresh Fedora install. How have you determined that? I am curious which package owns that file (rpm -qf /etc/sysconfig/bootloader). I suspect that if you see this, the file actually gets installed via some image generating tool like Kiwi ( OSInside/kiwi#227 ) and I see that it was added by a person of SUSE fame, so I suspect it is a SUSE-specific file that this particular tool injects into other OSes' images without being a standard there.

I've downloaded ISO for Fedora 43 and installed it in VMware. By the way, not only me - #3564 The link I've used is Fedora-Workstation-Live-43-1.6.x86_64.iso

Interesting. I installed Fedora (the Server and Everything variants) 41, 43 and Rawhide via Anaconda (the usual installer), I checked also the cloud images, and I never saw this file. Have you checked which package owns it? Anyway, clearly it is not a standard part of all install, but it can be present, so we must cope both with it existing and not existing.

svlv commented at 2026-02-25 17:37:¶

@pcahyna

I've already started applying your comments. I'll push changes after re-testing tomorrow.

Have you checked which package owns it?

Not yet

pcahyna commented at 2026-02-25 17:45:¶

@pcahyna

I've already started applying your comments. I'll push changes after re-testing tomorrow.

Thanks! I can add the check for unknown bootloaders myself if you have not done it yet.

Have you checked which package owns it?

Not yet

No problem, it is not very important for the actual work, I am just curious how this file originates.

svlv commented at 2026-02-25 17:49:¶

@pcahyna

Thanks! I can add the check for unknown bootloaders myself if you have not done it yet.

Don't worry. Everything has been already done. I just want to look at my changes with fresh head tomorrow

svlv commented at 2026-02-26 07:54:¶

I've re-worked the patch to avoid adding GRUB2-BLS as a new value for the BOOTLOADER variable and detect GRUB2-BLS usage at recovery time for openSUSE Tumbleweed.

I've manually re-tested on RHEL 10 and openSUSE.

svlv commented at 2026-02-26 08:59:¶

@pcahyna

Regarding /etc/sysconfig/bootloader on Fedora 43:

root@fedora:~# uname -a
Linux fedora 6.17.1-300.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Oct  6 15:37:21 UTC 2025 x86_64 GNU/Linux
root@fedora:~# rpm -qf /etc/sysconfig/bootloader
file /etc/sysconfig/bootloader is not owned by any package
root@fedora:~# cat /etc/sysconfig/bootloader
DEFAULT_APPEND="quiet rhgb "
FAILSAFE_APPEND="quiet rhgb  ide=nodma apm=off noresume edd=off nomodeset 3 "
LOADER_LOCATION=none
LOADER_TYPE=grub2-bls
SECURE_BOOT=yes

but I think that erroring out earlier is safer

I would use existing single place to verify the BOOTLOADER value. No need to add checks at different places.

On SUSE possible values for BOOTLOADER_TYPE are
## Type: list(grub,grub2,grub2-efi,grub2-bls,systemd-boot,none)
sysconfig.rb#L64
In the patch, I allowed only grub,grub2,grub2-efi to be used.

jsmeix commented at 2026-02-26 13:51:¶

@svlv
regarding your recent
https://github.com/rear/rear/pull/3565/changes/67c45568354200ba945266af741004fb70a03729
"Improve the check to determine whether the system is in normal or rescue mode"

I don't know but perhaps testing for RECOVERY_MODE
might be what could be actually needed here
when GRUB-BLS support is also intended
for Portable Recovery Mode where "rear -p recover"
is run within a foreign rescue system, see
https://github.com/rear/rear/blob/master/doc/user-guide/17-Portable-Mode.md

Therefore we have in usr/sbin/rear

if test -e "/etc/rear-release" || test "$PORTABLE" ; then
    RECOVERY_MODE=1
fi

https://github.com/rear/rear/blob/master/usr/sbin/rear#L326

I filed
https://github.com/rear/rear/issues/3234
"Replace direct usage of /etc/rear-release with RECOVERY_MODE"
but found no time to implement it
so in current ReaR code we still use /etc/rear-release
at various places instead of testing for RECOVERY_MODE
which could be bugs in several cases for the same reason
as I explained above.

But using /etc/rear-release in
usr/share/rear/init/default/002_check_rear_recover_mode.sh
looks correct because there we skip things for PORTABLE
so we only want to do those checks when we are inside
the ReaR rescue/recovery system.

Phew - how confusing complicated all that has become :-(
I want my good old 8-bit single-user single-task single-core
do-one-thing-at-a-time-and-do-it-well home computer back ;-)

svlv commented at 2026-02-26 14:05:¶

Thanks @jsmeix
I've corrected it

svlv commented at 2026-03-03 17:37:¶

@pcahyna did you have a chance to review the latest changes?

pcahyna commented at 2026-03-04 10:47:¶

@svlv not yet, sorry. I will have a look now.

svlv commented at 2026-03-05 12:32:¶

I've changed the logic to ignore none, grub2-bls and grub2-efi from /etc/sysconfig/bootloader

pcahyna commented at 2026-03-05 18:24:¶

@svlv thanks a lot, I will leave some time for others to also have a look at the final state and them merge it. I will also have a look tomorrow whether it makes sense to squash the commits together (I suppose so).

pcahyna commented at 2026-03-09 17:18:¶

@rear/contributors I would like to merge the PR tomorrow (Tuesday), unless you have further comments.

@svlv I looked at the commits and I think you should squash them all together with an appropriate commit message, because the intermediate steps are not worth preserving. Only one note about the changes to CHECK_CONFIG_FILES: This seems to have appeared "out of thin air" when looking at the final state. Could you please add a comment explaining it and a reference to layout/save/default/450_check_bootloader_files.sh where bootloader files get normally added to CHECK_CONFIG_FILES ? Suggested comment:

# Bootloader files get usually added in layout/save/default/450_check_bootloader_files.sh ,
# but BLS files are common to all bootloaders that support the BLS, so we add them here instead.

jsmeix commented at 2026-03-10 08:08:¶

It should never ever be the the task of
a voluntary ReaR contributor like @svlv
to do additional generic code cleanup work
by the way in his enhancement pull request.
So this enhancement pull request sould be kept
limited to only what it is meant to implement.
Generic code cleanup work could be done via
separated dedicated cleanup pull requests.

schlomo commented at 2026-03-10 08:12:¶

It should never ever be the the task of a voluntary ReaR contributor like @svlv to do additional generic code cleanup work by the way in his enhancement pull request. So this enhancement pull request sould be kept limited to only what it is meant to implement. Generic code cleanup work could be done via separated dedicated cleanup pull requests.

100% which is why I approved the PR

svlv commented at 2026-03-10 09:40:¶

I've squashed commits and added requested comments for CHECK_CONFIG_FILES.
Regarding refactoring, please let me know whether it is necessary or not in this PR. I can do it, but probably later.

jsmeix commented at 2026-03-10 12:54:¶

@svlv
thank you so much for all your time and patience
to fix those rather complicated bootloader issues!

Regarding refactoring or cleanup
see my above
https://github.com/rear/rear/pull/3565#issuecomment-4029463240
with the confirmation from @schlomo
https://github.com/rear/rear/pull/3565#issuecomment-4029480509
and what @pcahyna wrote in
https://github.com/rear/rear/pull/3565#discussion_r2907349693
(quoting because comments to commits sometimes get lost in GitHub)

I don't think that the PR should be required
to clean up and unify preexisting stuff

pcahyna commented at 2026-03-10 17:04:¶

@svlv thank you a lot for this improvement!

[Export of Github issue for rear/rear.]

#3565 PR merged: Add GRUB2-BLS support¶

svlv opened issue at 2026-02-13 16:50:¶

Pull Request Details:¶

svlv commented at 2026-02-17 11:53:¶

pcahyna commented at 2026-02-20 12:58:¶

jsmeix commented at 2026-02-23 14:07:¶

pcahyna commented at 2026-02-23 14:18:¶

svlv commented at 2026-02-23 14:33:¶

svlv commented at 2026-02-24 12:18:¶

jsmeix commented at 2026-02-24 14:40:¶

pcahyna commented at 2026-02-24 17:09:¶

svlv commented at 2026-02-25 09:43:¶

pcahyna commented at 2026-02-25 17:27:¶

svlv commented at 2026-02-25 17:37:¶

pcahyna commented at 2026-02-25 17:45:¶

svlv commented at 2026-02-25 17:49:¶

svlv commented at 2026-02-26 07:54:¶

svlv commented at 2026-02-26 08:59:¶

jsmeix commented at 2026-02-26 13:51:¶

svlv commented at 2026-02-26 14:05:¶

svlv commented at 2026-03-03 17:37:¶

pcahyna commented at 2026-03-04 10:47:¶

svlv commented at 2026-03-05 12:32:¶

pcahyna commented at 2026-03-05 18:24:¶

pcahyna commented at 2026-03-09 17:18:¶

jsmeix commented at 2026-03-10 08:08:¶

schlomo commented at 2026-03-10 08:12:¶

svlv commented at 2026-03-10 09:40:¶

jsmeix commented at 2026-03-10 12:54:¶

pcahyna commented at 2026-03-10 17:04:¶

#3565 PR `merged`: Add GRUB2-BLS support¶