#2394 Issue `closed`: GRUB2 required as recovery system UEFI bootloader¶

Labels: support / question, fixed / solved / done

dcz01 opened issue at 2020-05-11 07:51:¶

EFI not creating boot image¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"):
rear-2.5-1
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
CentOS/RHEL 6.10 x86_64
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

OUTPUT=ISO
OUTPUT_URL=file:///tmp/rear
#BACKUP=NETFS
BACKUP=TSM
#BACKUP_PROG=tar
#BACKUP_PROG_CRYPT_ENABLED=1
#BACKUP_PROG_CRYPT_KEY=<Verschluesselungskennwort>
#BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl aes256 -salt -k"
#BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl aes256 -d -k"
#BACKUP_URL=nfs://<IP-Adresse oder DNS-Name>/<Freigabepfad>
#BACKUP_URL=cifs://<Server>/<Freigabe>
#BACKUP_OPTIONS="cred=/etc/rear/cifs,sec=ntlmsspi"
#BACKUP_TYPE=incremental
#FULLBACKUPDAY="Sat"
#BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' $VAR_DIR/output/\* '/opt/tivoli/tsm/rear/*' '/mnt/*' '/media/*' '/var/lib/pgsql/*/data/base/*' '/var/lib/pgsql/*/data/global/*' '/var/lib/pgsql/*/data/pg*/*' )
SSH_ROOT_PASSWORD='$1$HGjk3XUV$lid3Nd3k01Kht1mpMscLw1'
NON_FATAL_BINARIES_WITH_MISSING_LIBRARY='/opt/tivoli/tsm/client/ba/bin/libvixMntapi.so.1.1.0'

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
Hardware BareMetal Server
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
UEFI and GRUB 0.97
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Local Disk RAID
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sr0     11:0    1  1024M  0 rom
sda      8:0    0   150G  0 disk
├─sda1   8:1    0   500M  0 part /boot
├─sda2   8:2    0   200M  0 part /boot/efi
├─sda3   8:3    0     4G  0 part [SWAP]
└─sda4   8:4    0 558,8G  0 part /

Description of the issue (ideally so that others can reproduce it):
ReaR won't create the boot image because it can't find grub-mkimage.
Workaround, if any:
None
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
rear-brp-server.log

pcahyna commented at 2020-05-11 09:49:¶

I am afraid this won't work, because ReaR uses GRUB2 on UEFI, but RHEL 6 did not have GRUB2 AFAIK. (In recent development version of ReaR it will be grub-mkstandalone instead of grub-mkimage, but the underlying issue is the same.)

jsmeix commented at 2020-05-11 15:45:¶

@dcz01
only some untested ideas off the top of my head what you might try out:

A generic workaround to boot the ReaR recovery system
is what I described in the section
"Launching the ReaR recovery system via kexec" in
https://en.opensuse.org/SDB:Disaster_Recovery

I mean:
On your replacement hardware boot an arbitrary small and simple system
in UEFI mode and kexec the ReaR recovery system kernel and initrd
from that already running system.

I would hope that this way it is possible to install an UEFI bootloader
for the recreated target system.
As far as I know it is in general not possible to boot an installation system
in BIOS mode (the ReaR recovery system is an installation system)
and then install an UEFI bootloader for the target system.
I think the reason behind is that for a system that was booted in BIOS mode
UEFI related stuff (e.g. EFI variables and things like that) is not accessible.

I don't know if it then works at the end of "rear recover" during
its "finalize" stage to let ReaR install the UEFI bootloader
for the recreated target system.

If the target system UEFI bootloader installation fails for you
it might work to chroot /mnt/local into the recreated target system
and manually install its UEFI bootloader from within the target system.

dcz01 commented at 2020-05-11 16:45:¶

@jsmeix @pcahyna
My only problem now is only that i can't let create an bootable image from ReaR with an UEFI bootloader.
Is there any package or something that i haven't installed yet for GRUB 0.97?
I just want to have an bootable image from ReaR for an bare metal machine without the classic BIOS support (only UEFI boot possible).

pcahyna commented at 2020-05-11 21:19:¶

@dcz01 I think the OUTPUT=USB method could work, if you can use it instead of ISO, it seems that it supports UEFI with legacy GRUB (from a quick look at sources).
@jsmeix would it work to use the OUTPUT=RAWDISK method as an alternative? It seems that it does not require GRUB2 for UEFI, but I never understood what it actually does. (One is supposed to dd the resulting image onto a disk?)
Anyway, to me it seems that OUTPUT=ISO won't work (requires GRUB2 and CentOS 6 uses GRUB 0.97).

jsmeix commented at 2020-05-12 09:08:¶

The OUTPUT=RAWDISK method was implemented by @OliverO2
so he is the authoritative source of information about this area.
See his initial https://github.com/rear/rear/pull/1659
and the related https://github.com/rear/rear/issues/1578
where https://github.com/rear/rear/issues/1578#issuecomment-345254340
mentiones the isohybrid tool that reminds me on
https://github.com/rear/rear/issues/2210 which reads (excerpt)

isohybrid [ISO] converts it to a hybrid ISO.
Option flag -u or --uefi makes it UEFI bootable.

so perhaps using isohybrid with its --uefi option could
make a "normal" non-UEFI-bootable OUTPUT=ISO image
even UEFI bootable?

Unfortunately I never tested the OUTPUT=RAWDISK method myself
nor did I try out using isohybrid.

According to the OUTPUT=RAWDISK section in default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L858
it seems the OUTPUT=RAWDISK method could be a generic alternative
for UEFI booting the ReaR recovery system from any disk device.
Such a disk device would be usually a USB stick or a real USB disk.

Let's hope that modern bare metal machine without BIOS boot support
supports at least to boot from a USB disk (e.g. I think some
blade "machines" won't have a way to connect a USB disk).
In that case it is perhaps somehow possible to provide the
RAWDISK image on whatever other bootable disk for that
bare metal machine?

jsmeix commented at 2020-05-12 09:30:¶

Regarding isohybrid UEFI booting
https://wiki.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
reads (excerpt)

If the ISO 9660 image includes a UEFI bootloader
capable of booting optical media in UEFI mode,
then the isohybrid command can also achieve
an equivalent result for UEFI systems

so isohybrid cannot be used to make a "normal"
non-UEFI-bootable ISO image even UEFI bootable
because isohybrid does not (or cannot) add a whole
UEFI boot infrastructure (EFI system partition plus EFI bootloader).

OliverO2 commented at 2020-05-12 10:11:¶

Quoting from the User Guide - Chapter 3 (emphasis added):

OUTPUT=RAWDISK::
Create a bootable raw disk image on as rear-$(hostname).raw.gz. Supports UEFI
boot if syslinux/EFI or Grub 2/EFI is installed. Supports Legacy BIOS boot if
syslinux is installed. Supports UEFI/Legacy BIOS dual boot if syslinux and one
of the supported EFI bootloaders are installed.

@pcahyna Yes, you're supposed to dd the resulting image onto some boot medium (like an entire raw disk or a USB stick). No previous formatting/partitioning required.

@dcz01 If there is a suitable syslinux/EFI package available (and installed) on RHEL 6, RAWDISK would be an option to try.

pcahyna commented at 2020-05-12 10:26:¶

Yes, you're supposed to dd the resulting image onto some boot medium (like an entire raw disk or a USB stick). No previous formatting/partitioning required.

@chlupnoha this is possibly a viable alternative for your project

dcz01 commented at 2020-05-12 11:00:¶

I now used the OUTPUT=USB method which worked fine with an normal usb stick on the server.
Now i have an UEFI-Boot-Stick to use in an catastrophic case.
Thanks for the code looking and checking.

pcahyna commented at 2020-05-12 11:03:¶

@dcz01 try to recover from your boot stick on a spare hardware before the catastrophic case occurs! There may be other surprises during the recovery process.

jsmeix commented at 2020-05-12 11:37:¶

@dcz01
I fully agree with @pcahyna
You must verify that your recovery procedure actually works for you.

Cf. what I wrote in
https://en.opensuse.org/SDB:Disaster_Recovery
in particular see the section about "Inappropriate expectations".

[Export of Github issue for rear/rear.]

#2394 Issue closed: GRUB2 required as recovery system UEFI bootloader¶