#1601 Issue `closed`: UEFI: Cannot boot rescue image created on "BIOS" system¶

Labels: enhancement, discuss / RFC, needs sponsorship, no-issue-activity

gdha opened issue at 2017-11-28 14:29:¶

rear version (/usr/sbin/rear -V): rear-2.00-3.el7_4.x86_64
OS version (cat /etc/rear/os.conf or lsb_release -a): RHEL 7.4
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf): n/a
Are you using legacy BIOS or UEFI boot? BIOS
Brief description of the issue: UEFI: Cannot boot rescue image created on "BIOS" system

Description of problem:
When creating a rescue image for ReaR on a legacy system (not UEFI), the image doesn't contain the necessary bits to boot it on a pure UEFI system.

Steps to Reproduce:

Create a rescue image on a legacy system
Try booting a pure UEFI system with the image

Actual results:
Image is not bootable

Reported as bz1518241

jsmeix commented at 2017-11-28 15:01:¶

In general I am always in favour of options so that
"rear mkrescue" can (if wanted by the user) create
a huge all in one ReaR recovery system that could
be used "everywhere" to some reasonable extent
i.e. on every (replacement) hardware that matches
sufficiently the original hardware (e.g. not on a
different hardware architecture).

For example currently things like
MODULES=( 'all_modules' )
and
FIRMWARE_FILES=( 'yes' )
are already meant to let "rear mkrescue" create
a more generally usable recovery system.

Regarding
https://bugzilla.redhat.com/show_bug.cgi?id=1518241#c5

Pavel Cahyna
...
But what about the partition layout?
I am afraid that to make a properly
functioning UEFI system one needs more
than to make a bootable ISO.
functioning UEFI system

Yes, that is a second (and separated) step
that requires a bootable ISO as first step.

jsmeix commented at 2017-11-28 15:07:¶

Also RECOVERY_UPDATE_URL is related, cf
https://github.com/rear/rear/issues/841#issue-155289278

... use one same fixed rear recovery system
for various sufficiently similar systems
(i.e. systems where the same rear recovery
system works but the only differences are
in the rear configuration files).
...
Assume one has 100 servers ... of type A
and 200 servers ... of type B, then (I hope)
it is possible to have only one bootable ISO image
for all type A servers and one for all type B servers.

jsmeix commented at 2017-11-28 15:11:¶

I think actually this enhancement request should be named:
"BIOS to UEFI migration" and in this case see also
https://github.com/rear/rear/issues/1437

OliverO2 commented at 2017-11-29 07:54:¶

The suggested RAWDISK output method (https://github.com/rear/rear/issues/1578#issuecomment-346384421 with correction https://github.com/rear/rear/issues/1578#issuecomment-346875484) already supports BIOS/UEFI dual boot for the rescue image. It auto-detects installed bootloaders (syslinux/BIOS, syslinux/UEFI, Grub 2/UEFI) and installs one for each boot method if available.

It's not an ISO, of course. And step 2 (migrating the original system boot, adding an EFI System Partition) would still be required.

jsmeix commented at 2017-11-29 09:56:¶

Wow!
I thought ReaR 2.3 is an unusually great step forward
but now it looks as if ReaR 2.4 could become
an even more unusually great step forward...

jsmeix commented at 2017-11-29 10:02:¶

It seems also
https://github.com/rear/rear/issues/764
could be related to simplify all the bootloader code
so that it is in practice maintainable for the future.

OliverO2 commented at 2017-11-29 10:40:¶

Simplifying bootloader code in ReaR is certainly a good idea. However, settling on Grub 2 (which I had considered) seems problematic:

Documentation is severely lacking (Grub 2 wants to do everything automagically but what you get exactly somewhat remains a mystery unless you dig deeply into the source code - see GRUB 2 on a lower level or Understanding the Various Grub Modules).
grub-mkrescue seems to create a rescue image for the currently active boot method only, which may differ from the one to be used for migration.
Grub 2 boots slowly in certain configurations (I've seen 5-10 second delays compared to syslinux), which may not be an issue for a rescue system but is undesirable for a pre-boot environment to unlock disks (like the upcoming Opal PBA).

gdha commented at 2018-10-05 09:08:¶

@rmetrich Hi Renaud - are you aware of this BZ report?

rmetrich commented at 2018-10-05 09:13:¶

@gdha Sure, I reported the issue myself ;-)

jsmeix commented at 2018-10-05 14:16:¶

In current ReaR the recovery system is specific for the one particular
system where "rear mkrescue/mkbackup" was run.

In particular the recovery system is specific for the used way to boot
on the particular system where "rear mkrescue/mkbackup" was run,
cf. the section "Fully compatible replacement hardware is needed" in
https://en.opensuse.org/SDB:Disaster_Recovery

My own plan for an unspecified future as time permits is
to enhance ReaR so that it can alternatively produce a generally
usable full featured recovery system that runs basically on any hardware
just like the usual Linux installation systems behave that you get
as installation medium from the various Linux distributions,
cf. "My ultimate goal" at https://github.com/rear/rear/issues/1085
and https://github.com/rear/rear/issues/1911#issuecomment-422296361

github-actions commented at 2020-07-01 01:33:¶

Stale issue message

[Export of Github issue for rear/rear.]

#1601 Issue closed: UEFI: Cannot boot rescue image created on "BIOS" system¶