#3622 PR open: Support ISO_DEFAULT and ISO_RECOVER_MODE for GRUB2/UEFI

Labels: enhancement

parasjain37 opened issue at 2026-07-31 09:29:

UEFI ISO used GRUB2 without the SYSLINUX automatic/unattended kernel options.
Add automatic menu entries and honor ISO_DEFAULT so unattended recover works like on BIOS.

Fixes #2970

Relax-and-Recover (ReaR) Pull Request Template

Please fill in the following items before submitting a new pull request:

Pull Request Details:

  • Type: Enhancement

  • Impact: Normal

  • Reference to related issue (URL):

https://github.com/rear/rear/issues/2970

  • How was this pull request tested?

Built ISO on UEFI host with ISO_DEFAULT=automatic, ISO_RECOVER_MODE=unattended, GRUB2_TIMEOUT=10 (optional)

Resulting Screenshots :
rear-auto-recover-grub-menu
rear-auto-recover-started

codacy-production commented at 2026-07-31 09:30:

Up to standards ✅

🟢 Issues 0 issues >
> > **Results:** > `0` new issues > > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3622/issues) >

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

lzaoral commented at 2026-07-31 11:21:

Hello! I'm afraid that this won't be as straightforward which is the reason I (or @pcahyna) haven't done that, yet.

The whole situation around ISO_DEFAULT and ISO_RECOVER_MODE variables is a bit of a mess at the moment, e.g. in your case, those variables would be active for any generation of grub config, regardless of the OUTPUT variable.

The ideal solution would be to have a set of variables, that will set the default boot entry, timeout, etc... regardless of the actual bootloader used or the OUTPUT target.

Currently, there are some preparatory PRs that clean-up the bootloader support before we can start with the unification: https://github.com/rear/rear/pull/3597, https://github.com/rear/rear/pull/3520, https://github.com/rear/rear/pull/3527

jsmeix commented at 2026-08-05 14:24:

@lzaoral
perhaps a slow-witted question
(I'm afraid - I can't get all the details in my brain):

In your
https://github.com/rear/rear/pull/3622#issuecomment-5142309746
you wrote

The whole situation around ISO_DEFAULT and ISO_RECOVER_MODE
variables is a bit of a mess at the moment,
e.g. in your case, those variables would be active
for any generation of grub config,
regardless of the OUTPUT variable.

I don't see why the GRUB configuration regarding
ReaR's special auto_recover kernel option
depends on the OUTPUT method?

In general I wonder why kernel options depend on the OUTPUT method
because I think for all OUTPUT methods the same kernel is used
so for all OUTPUT methods the same kernel options should work?

And even if some additional GRUB menu entries
with the additional auto_recover kernel option
won't work for some OUTPUT methods,
what does that matter in practice to the user
compared to not having an auto_recover option at all?

In the end I am wondering if we cannot merge
this pull request for now to provide the
additional auto_recover kernel option
where it is currently missing
regardless that sometimes it may not work?

Cf.
https://en.wikipedia.org/wiki/Worse_is_better

But likely I just misunderstand fundamental things here.

lzaoral commented at 2026-08-05 15:05:

@jsmeix First, I'd like to apologise that my previous reply was worded a bit too strongly.

I don't see why the GRUB configuration regarding
ReaR's special auto_recover kernel option
depends on the OUTPUT method?

Right now, you have a couple of options that are only relevant for specific output and bootloader combinations:

  1. ISO_DEFAULT and ISO_RECOVER_MODE are currently relevant only for OUTPUT=ISO and ISOLINUX.
    • They are ignored when GRUB2 is used.
  2. PXE_RECOVER_MODE which is only relevant for OUTPUT=PXE and PXELINUX
    • They are ignored when GRUB2 is used.
  3. USB_BIOS_BOOT_DEFAULT or GRUB2_TIMEOUT which are only relevant for OUTPUT=USB and EXTLINUX
    • They are ignored when GRUB2 is used.
  4. GRUB2_DEFAULT_BOOT which is only relevant for GRUB2 on BIOS or EFI machines with OUTPUT=ISO and OUTPUT=USB.
    • They are ignored when OUTPUT=PXE is used or when a different firmware is used, e.g. OUTPUT=ISO PowerVM.
  5. No options are applicable for OUTPUT=PXE with GRUB or OUTPUT=ISO on Power.

This PR somewhat improves the state but also introduces an inconsistent and counterintuitive behaviour. Given the current reuse of the GRUB2 menu generation functions in the case 4 mentioned above for OUTPUT=ISO and OUTPUT=USB, both ISO_DEFAULT and ISO_RECOVER_MODE would be effective even when OUTPUT is set to USB.

My (longer-term) goal is to incrementally reach a state where we have only a set of options that are applicable in all the cases above, e.g. BOOTLOADER_TIMEOUT, BOOTLOADER_DEFAULT_ENTRY, ..., and to have the older options deprecated. My plan is to have this work done before 3.0 is released since that will be a major release, thus, bigger/breaking changes would be expected there.

In the end I am wondering if we cannot merge
this pull request for now to provide the
additional auto_recover kernel option
where it is currently missing
regardless that sometimes it may not work?

Of course, you can merge this PR but I suggest that at least https://github.com/rear/rear/pull/3597 should be merged first since it simplifies code this PR touches.

Also, before merging the inconsistency with OUTPUT=USB, GRUB2, ISO_DEFAULT and ISO_RECOVER_MODE should be resolved. Moreover, the change on the first line of usr/share/rear/lib/bootloader-functions.sh seems like a typo that was committed accidentally.

jsmeix commented at 2026-08-06 07:05:

@lzaoral
thank you for your explanations with specific cases!

I will have a closer look when I am back from vacation
as time permits (i.e. as CVEs permit).

jsmeix commented at 2026-08-06 07:17:

Without detailed analysis I think the root cause
why there are such inconsistencies is the same
as for many other inconsistencies in ReaR:

Usually things move forward in ReaR not managed
by some "grand master plan" but mostly "ad hoc"
as needed and limited to solve specific issues
and as far as possible by the contributors
who implement something.

One cannot expect that a contributor
who implements something to solve a specific issue
would be "just capable" to implement that
as a global unified solution for all such use cases.
In particular not when the contributor cannot test
all such use cases with reasonable effort.

Simply put:
I think the root cause of such inconsistencies is
the "worse is better" style how ReaR develops, cf.
https://en.wikipedia.org/wiki/Worse_is_better
This style is the only one which works in practice.

lzaoral commented at 2026-08-06 07:25:

I assume in your
"introduces an inconsistent and intuitive behaviour"
you meant
"introduces an inconsistent and unintuitive behaviour"
or
"introduces an inconsistent and counterintuitive behaviour"
?

Yes, of course. :) I'll fix the typo so it does not confuse more people.

parasjain37 commented at 2026-08-06 07:28:

@jsmeix and @lzaoral ,
I added another #3622 commit 98f65c9 changes
:

  • Typo in first line of bootloader-function.sh
  • Typo in Automatic label
  • Order of grub2_timeout , put local grub2_timeout= before the case for automatic so user set grub2_timeout is effective now for ISO.

I understand to long term goal for BOOTLOADER_* parameters , that would be good for unification.
Meanwhile this is implemented, we have 2 options as I see :
A. Keep the USB surprise behavior as it is and mention ISO_RECOVER* also applies when OUTPUT=USB + UEFI/USB_BOOTLOADER=GRUB in default.conf comments.
B. Add gate for default timeout and for entries may be , a condition to check OUTPUT is ISO or USB and then provide automatic parameter. (I will have to test this logic first )

Any one of option will be there till unified BOOTLOADER_* comes.

Also for #3597 , if this is being implemented first, then I can remove linuxefi options for automatic recovery as well to make this read for merge. Let me know.

lzaoral commented at 2026-08-06 07:51:

AFAIK, your motivation is to have a fix that can be easily backported to RHEL, I'd go for option B. Since A option could be disruptive for current RHEL users, we would have to make extra downstream changes to your patch anyway.

[Export of Github issue for rear/rear.]