#3619 Issue `open`: RHEL 8.10 on HPE Gen11 server (ReaR 2.6): booting the ReaR ISO fails with kernel panic¶

Labels: waiting for info, support / question, special hardware or VM, old version

gabaskingforafriend opened issue at 2026-07-21 03:01:¶

Requesting support or just a question¶

Unable to boot from iso. ReaR version 2.6, OS is Rhel 8.10, ILO 6

Platform¶

Linux x64

Output¶

########################################################################
# ReaR Configuration
########################################################################

# Output image
OUTPUT=ISO
OUTPUT_URL=nfs://10.46.187.6/mnt/rear_backup/STI/iso/

# Backup method
BACKUP=NETFS
BACKUP_URL=nfs://10.46.187.6/mnt/rear_backup/STI/backup/

# TMPDIR
export TMPDIR="/backup/rear/tmp"

#UEFI
#UEFI_BOOTLOADER=/boot/efi/EFI/redhat/grubx64.efi
SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi

########################################################################
# Network Configuration
########################################################################

# Rescue environment network configuration
NETWORKING=yes

# Primary recovery interface
# ReaR will configure this IP in the rescue environment
HOSTNAME=su01005000

IPADDR=10.71.40.82
NETMASK=255.255.254.0
GATEWAY=10.71.40.1

DNS=(10.71.181.13 10.46.181.13 10.71.181.12)

# Preserve current network configuration files
COPY_AS_IS+=(
    /etc/NetworkManager/system-connections
    /etc/hosts
    /etc/resolv.conf
    /etc/modprobe.d

Additional information¶

No response

gabaskingforafriend commented at 2026-07-21 03:03:¶

Rear successfully created the backup files and the iso. However, when booting the iso file in the ilo6 hp machine, it just returns to the one time boot menu.

jsmeix commented at 2026-07-21 07:23:¶

@gabaskingforafriend

I am not a RHEL user so I cannot help with RHEL specific issues
but I can provide generic (hopefully helpful) info:

ReaR version 2.6 is rather old (from more than 6 years ago).
ReaR 2.6 was released in June 2020, see
https://github.com/rear/rear/blob/rear-2.6/doc/rear-release-notes.txt#L195

Some generic boilerplate info:

In general I recommend to try out our latest GitHub master code
because the GitHub master code is the only place where we fix things
and if there are issues it helps when you use exactly the code
where we could fix things.

See the "QUICK START GUIDE" and "INSTALLATION" parts on
https://github.com/rear/rear

Additionally / alternatively see the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.

In general we at ReaR upstream do not support older ReaR versions.
We at ReaR upstream do not plain reject issues with older ReaR versions
(e.g. we may answer easy to solve questions also for older ReaR versions)
but we do not spend much time on issues with older ReaR versions because
we do not (and cannot) fix issues in released ReaR versions.
Issues in released ReaR versions are not fixed by us (by ReaR upstream).
Issues in released ReaR versions that got fixed in current ReaR upstream
GitHub master code might be fixed (if the fix can be backported with
reasonable effort) by the Linux distributor wherefrom you got ReaR.

Our latest release ReaR 2.9
and our current ReaR upstream GitHub master code
still support RHEL 8, see
https://github.com/rear/rear/blob/rear-2.9/doc/rear-release-notes.txt#L126
and still the same in our current
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L126

A side note regarding

export TMPDIR="/backup/rear/tmp"

in a ReaR user config file like etc/rear/local.conf
see our current ReaR config documentation in
usr/share/rear/conf/default.conf
the comment about TMPDIR
therein in particular the part about
how to properly set TMPDIR in general
for any program in a POSIX compliant way,
i.e. export TMPDIR before running the program
and specifically for 'rear':

To have a specific working area directory prefix
for Relax-and-Recover call
    export TMPDIR="/prefix/for/rear/working/directory"
before calling 'rear'
(/prefix/for/rear/working/directory must already exist).

https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L160C1-L162C81

Another side note regarding

NETWORKING=yes
HOSTNAME=su01005000
IPADDR=10.71.40.82
NETMASK=255.255.254.0
GATEWAY=10.71.40.1
DNS=(10.71.181.13 10.46.181.13 10.71.181.12)

Only HOSTNAME is listed in usr/share/rear/conf/default.conf
but none of the other variables is listed there
so I assume setting the other variables may not do
what you expect.
In particular DNS and NETWORKING variables do not appear
in ReaR scripts.
And IPADDR NETMASK GATEWAY get set from the kernel command line
options ip nm gw by the ReaR recovery system startup script
usr/share/rear/skel/default/etc/scripts/system-setup.d/20-check-boot-options.sh
see in usr/share/rear/conf/default.conf
the comment about
"Relax-and-Recover ... special kernel command line parameters"
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L204

jsmeix commented at 2026-07-21 07:50:¶

@gabaskingforafriend

wherefrom did you get that
NETWORKING IPADDR NETMASK GATEWAY DNS
stuff?

Is there perhaps a public accessible URL
where such things are documented?

Or did you get it perhaps from some AI response?

gabaskingforafriend commented at 2026-07-21 08:07:¶

@gabaskingforafriend

wherefrom did you get that NETWORKING IPADDR NETMASK GATEWAY DNS stuff?

Is there perhaps a public accessible URL where such things are documented?

Or did you get it perhaps from some AI response?

To be honest, that's an AI response. Tried asking AI about on how to preserve nic bonded network settings during rear backup creation. The goal is to eliminate the manual setup of the server's network configuration during boot up from the iso generated by rear.

Also, we're using rear 2.6 since it's the only available version inside the repository we use. If this won't work, I might have to raise this and have the repo admin make the latest rear version available.

jsmeix commented at 2026-07-21 08:29:¶

Regarding "setup of the server's network configuration
during boot up from the iso generated by rear":
NETWORKING_PREPARATION_COMMANDS could help for special cases,
see its description in default.conf e.g. for ReaR 2.6 at
https://github.com/rear/rear/blob/rear-2.6/usr/share/rear/conf/default.conf#L2763

Regarding "preserve nic bonded network settings during rear backup creation":
Normally things happen automatically via the script
usr/share/rear/rescue/GNU/Linux/310_network_devices.sh
which mentiones in particular bonding also for ReaR 2.6
https://github.com/rear/rear/blob/rear-2.6/usr/share/rear/rescue/GNU/Linux/310_network_devices.sh

But first and foremost the ReaR recovery system must boot.

gabaskingforafriend commented at 2026-07-21 08:40:¶

Regarding "setup of the server's network configuration during boot up from the iso generated by rear": NETWORKING_PREPARATION_COMMANDS could help for special cases, see its description in default.conf e.g. for ReaR 2.6 at https://github.com/rear/rear/blob/rear-2.6/usr/share/rear/conf/default.conf#L2763

Regarding "preserve nic bonded network settings during rear backup creation": Normally things happen automatically via the script usr/share/rear/rescue/GNU/Linux/310_network_devices.sh which mentiones in particular bonding also for ReaR 2.6 https://github.com/rear/rear/blob/rear-2.6/usr/share/rear/rescue/GNU/Linux/310_network_devices.sh

But first and foremost the ReaR recovery system must boot.

Thanks for your insights.
I'm slowly learning what's wrong with our local.conf.
I was able to make the system boot from iso a few mins ago
but resulted into kernel panic.
I'll try to fiddle around it a bit more and see how it goes.

Really appreciate you taking time sharing your knowledge with me.

jsmeix commented at 2026-07-21 08:41:¶

Regarding "rear 2.6 ... the only available version inside the repository we use":

I assume you cannot and/or you are not allowed to run
software downloaded from the Internet on that RHEL system.

Do you have a separated test system where you can safely try out things?
Cf. in https://en.opensuse.org/SDB:Disaster_Recovery
various sections about testing.

jsmeix commented at 2026-07-21 08:44:¶

In general regarding "learning ReaR"
see my personal recommendation at
https://en.opensuse.org/SDB:Disaster_Recovery#First_steps_with_Relax-and-Recover

Don't worry "slowly learning" is normal, see
https://en.opensuse.org/SDB:Disaster_Recovery#Inappropriate_expectations

jsmeix commented at 2026-07-21 09:12:¶

Because Google AI tells me that

HPE iLO 6 (Integrated Lights-Out 6)
is a remote server management processor found on
Hewlett Packard Enterprise (HPE) Gen11 servers.

my blind guess is that the "kernel panic"
when booting your ReaR recovery system
may depend on that specific server hardware.
Cf. https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6
what we had tested for ReaR 2.6.

Unfortunately in particular dedicated server hardware
causes relatively often special issues with ReaR
compared to usual end-user PC hardware.

I think server management software (like HPE iLO 6)
supports to save bootloader and kernel boot messages
so you may post here those messages
until the kernel panic happens.

Perhaps someone here who knows about HP servers
could spot the root cause of the kernel panic?

gdha commented at 2026-07-24 13:27:¶

@gabaskingforafriend What was the exact kernel panic error message?

pcahyna commented at 2026-07-24 13:49:¶

@gabaskingforafriend also, are there any messages from the bootloader before the kernel starts booting? Are you using EFI? (The line SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi suggests so, but I am asking to be sure.)

SamiSZZzz commented at 2026-09-01 08:20:¶

We had once similar issue. Problem seemed to be then in too large initrd file. Backup creation worked, but booting from iso image failed to kernel panic.

With original config, initrd was close to 1Gb and boot failed:
Created initrd.cgz with gzip default compression (993456331 bytes) in 50 seconds

But when added to /etc/rear/local.conf line:
REAR_INITRD_COMPRESSION="lzma"

Initrd size decreased to ~700M:
Created initrd.xz with xz lzma compression (679592202 bytes) in 304 seconds

And with that size, restore from back seems to work. Maybe you can try if same will help for you.

jsmeix commented at 2026-09-01 09:11:¶

What helps most to decrease the initrd size is specifying
FIRMWARE_FILES
to get only firmware included which is actually needed.
See its description in default.conf
and for some more detailed information see
https://github.com/rear/rear/issues/3270
and
https://github.com/rear/rear/issues/3551
with its current work-in-progress
https://github.com/rear/rear/pull/3553

jsmeix commented at 2026-09-01 09:19:¶

Additionally and/or alternatively we have the new
REAR_INITRD_OVERLAY
functionality in our GitHub master code, see
https://github.com/rear/rear/pull/3614

See the above
https://github.com/rear/rear/issues/3619#issuecomment-5031242034
how one can try out our current ReaR GitHub master code
without conflicts with an already installed ReaR version.

[Export of Github issue for rear/rear.]

#3619 Issue open: RHEL 8.10 on HPE Gen11 server (ReaR 2.6): booting the ReaR ISO fails with kernel panic¶