#2275 Issue `closed`: "rear recover" cannot install GRUB2-EFI on CentOS 7 minimal installation¶

Labels: enhancement, documentation, cleanup, no-issue-activity

franciscohosting opened issue at 2019-11-11 20:34:¶

Relax-and-Recover (ReaR) Issue Template¶

ReaR version ("/usr/sbin/rear -V"):

Relax-and-Recover 2.5 / 2019-05-10

OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):

OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=7

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

COPY_AS_IS_BAREOS=( "${COPY_AS_IS[@]}" /etc/bareos /usr/src/kernels/3.10.0-1062.4.1.el7.x86_64 )
BACKUP=BAREOS
BAREOS_CLIENT=labobject2-fd
BAREOS_FILESET=LinuxAll
BAREOS_RESTORE_JOB=restoreLabobject2-fdIso
OUTPUT_URL=file:///tmp/bareos-restores
#KEEP_BUILD_DIR="yes"
SSH_ROOT_PASSWORD=********

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):

PC

System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):

x86_64

Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

UEFI and Grub2

Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):

local disk

Description of the issue (ideally so that others can reproduce it):

Restoring with bareos and rear fails to install grub on Centos 7 minimal installation

Workaround, if any:

Reinstalling GRUB2 with Centos 7 install CD in recovery mode, following:
[(https://www.thegeekdiary.com/centos-rhel-7-how-to-reinstall-grub2-from-rescue-mode/)]

Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

WARNING:
For this system
RedHatEnterpriseServer/7 on Linux-i386 (based on Fedora/7/i386)
there is no code to install a boot loader on the recovered system
or the code that we have failed to install the boot loader correctly.
Please contribute appropriate code to the Relax-and-Recover project,
see http://relax-and-recover.org/development/
Take a look at the scripts in /usr/share/rear/finalize,
for example see the scripts
/usr/share/rear/finalize/Linux-i386/630_install_grub.sh
/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh

jsmeix commented at 2019-11-12 14:13:¶

@franciscohosting
I am not a CentOS user so that I cannot reproduce such issues.

Therefore some generic questions and information:

Does it perhaps work with a "normal" CentOS installation?

I ask because "rear recover" installs GRUB2 by 'chroot' into
the restored system and run 'gub-install' therein, cf.
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
https://github.com/rear/rear/blob/master/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh

But perhaps a CentOS minimal installation is so minimal
that one cannot successfully re-install GRUB2 therein?

Perhaps it helps to explicitly specify the BOOTLOADER, cf.
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2608

To analyze your issue we really need both your
"rear -D mkrescue/mkbackup" and your
"rear -D recover" debug log files, cf.
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

franciscohosting commented at 2019-11-12 20:49:¶

First of all thanks for your quick answer!
Then in a fresh Centos 7 minimal installation with all upgraded, bareos configured and rear installed, I get the following warnings:

Broken symlink '/etc/grub2.cfg' in recovery system because 'readlink' cannot determine its link target
Broken symlink '/usr/lib/modules/3.10.0-1062.el7.x86_64/build' in recovery system because 'readlink' cannot determine its link target
Broken symlink '/usr/lib/modules/3.10.0-1062.el7.x86_64/source' in recovery system because 'readlink' cannot determine its link target\
ERROR: grub2-mkimage would not make bootable EFI image of GRUB2 (no /usr/lib/grub*/x86_64-efi/moddep.lst file)

So I configured rear to work bareos and did: yum install grub2-efi-x64-modules (rebooted and deleted the old kernel)
and as u suggested added BOOTLOADER="GRUB2-EFI" to site.conf
that made the warning of Broken symlink '/usr/lib/modules/3.10.0-1062.el7.x86_64/source' disappear
then:
rear -D mkrescue
gave me this log file:
rear-labobject2.log
then booting from the live cd, doing the full restore and finally doing:
rear -D recover
rear-labobject2Recover.log

jsmeix commented at 2019-11-13 10:40:¶

I am not at all an expert in UEFI booting
but think I may have found something:

I think in your
https://github.com/rear/rear/files/3838158/rear-labobject2Recover.log
an interesting part is

+ source /usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
++ is_true 1
++ case "$1" in
++ return 0
++ is_true 1
++ case "$1" in
++ return 0
++ return
+ source_return_code=0
+ test 0 -eq 0
+ test 1
+ Debug 'Leaving debugscripts mode (back to previous bash flags and options settings).'
+ test 1
+ Log 'Leaving debugscripts mode (back to previous bash flags and options settings).'
+ echo '2019-11-12 21:45:43.662378243 Leaving debugscripts mode (back to previous bash flags and options settings).'
2019-11-12 21:45:43.662378243 Leaving debugscripts mode (back to previous bash flags and options settings).
2019-11-12 21:45:43.668776305 Including finalize/Linux-i386/670_run_efibootmgr.sh
2019-11-12 21:45:43.670469868 Entering debugscripts mode via 'set -x'.
+ source /usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
++ is_true 1
++ case "$1" in
++ return 0
++ is_true no
++ case "$1" in
++ return 1
++ test -f /mnt/local//boot/efi/EFI/centos/grubx64.efi
++ return 0
+ source_return_code=0

which shows that
both /usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
and /usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
do basically nothing so that in the end no bootloader is installed.

/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
does nothing because it returns early at

# For UEFI systems with grub2 we should use efibootmgr instead,
# cf. finalize/Linux-i386/670_run_efibootmgr.sh
is_true $USING_UEFI_BOOTLOADER && return

But the subsequent
/usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
that should set up the bootloader "For UEFI systems with grub2"
also returns early at

# When UEFI_BOOTLOADER is not a regular file in the restored target system
# (cf. how esp_mountpoint is set below) it means BIOS is used
# (cf. rescue/default/850_save_sysfs_uefi_vars.sh)
# which includes that also an empty UEFI_BOOTLOADER means using BIOS
# because when UEFI_BOOTLOADER is empty the test below evaluates to
#   test -f /mnt/local/
# which also returns false because /mnt/local/ is a directory
# (cf. https://github.com/rear/rear/pull/2051/files#r258826856):
test -f "$TARGET_FS_ROOT/$UEFI_BOOTLOADER" || return 0

So I think it may help when you also set UEFI_BOOTLOADER
to the right value for your particular system, cf.
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2675

Regarding UEFI_BOOTLOADER there is in your
https://github.com/rear/rear/files/3838140/rear-labobject2.log

+ source /usr/share/rear/rescue/default/850_save_sysfs_uefi_vars.sh
...
++ Print 'Trying to find a '\''well known file'\'' to be used as UEFI bootloader...'
+++ find /boot/efi -name 'grub*.efi'
+++ tail -1
++ UEFI_BOOTLOADER=/boot/efi/EFI/centos/grubx64.efi
++ test -f /boot/efi/EFI/centos/grubx64.efi
++ continue
++ LogPrint 'Using '\''/boot/efi/EFI/centos/grubx64.efi'\'' as UEFI bootloader file'

So it seems on your original system there is a file

/boot/efi/EFI/centos/grubx64.efi

which is no longer there on your recreated system
after your backup was restored into /mnt/local/ as

/mnt/local//boot/efi/EFI/centos/grubx64.efi

In general I suggest to inspect all those bootloader related
config variables in default.conf - perhaps further manual
settings are needed for a CentOS 7 minimal installation?

jsmeix commented at 2019-11-13 14:43:¶

@gozora
could you please have a look here as time permits.

I think we have one more issue in finalize/Linux-i386/670_run_efibootmgr.sh
which looks to me at least as an inconsistency in its following code parts:

# When UEFI_BOOTLOADER is not a regular file in the restored target system
# (cf. how esp_mountpoint is set below) it means BIOS is used
# (cf. rescue/default/850_save_sysfs_uefi_vars.sh)
# which includes that also an empty UEFI_BOOTLOADER means using BIOS
# because when UEFI_BOOTLOADER is empty the test below evaluates to
#   test -f /mnt/local/
# which also returns false because /mnt/local/ is a directory
# (cf. https://github.com/rear/rear/pull/2051/files#r258826856):
test -f "$TARGET_FS_ROOT/$UEFI_BOOTLOADER" || return 0

where we test for $TARGET_FS_ROOT/$UEFI_BOOTLOADER
according to https://github.com/rear/rear/pull/2051/files
and its final implemenmtation
https://github.com/rear/rear/commit/1bba7ff1b832849108ac6a92d313739235727821
BUT
later the code is

BootLoader=$( echo $UEFI_BOOTLOADER | cut -d"/" -f4- | sed -e 's;/;\\;g' )
LogPrint "Creating  EFI Boot Manager entry '$OS_VENDOR $OS_VERSION' for '$BootLoader' (UEFI_BOOTLOADER='$UEFI_BOOTLOADER')"
Log efibootmgr --create --gpt --disk ${Disk} --part ${ParNr} --write-signature --label \"${OS_VENDOR} ${OS_VERSION}\" --loader \"\\${BootLoader}\"
if efibootmgr --create --gpt --disk ${Disk} --part ${ParNr} --write-signature --label "${OS_VENDOR} ${OS_VERSION}" --loader "\\${BootLoader}" ; then
    # ok, boot loader has been set-up - tell rear we are done using following var.
    NOBOOTLOADER=''
    return
fi

where efibootmgr is called with --loader $BootLoader
but here BootLoader is set by using plain $UEFI_BOOTLOADER
instead of $TARGET_FS_ROOT/$UEFI_BOOTLOADER

So from my point of view
either
the current test is wrong and then
https://github.com/rear/rear/pull/2051 was also wrong
or
BootLoader should be set by using $TARGET_FS_ROOT/$UEFI_BOOTLOADER

jsmeix commented at 2019-11-13 15:00:¶

I think how BootLoader is currently set via

BootLoader=$( echo $UEFI_BOOTLOADER | cut -d"/" -f4- | sed -e 's;/;\\;g' )

looks terribly fragile because the result depends in a hardcoded way
how many / characters there are - for example as in

# echo '/mnt/local//boot/efi/EFI/centos/grubx64.efi' | cut -d"/" -f4- | sed -e 's;/;\\;g'
\boot\efi\EFI\centos\grubx64.efi

# echo '/mnt/local/boot/efi/EFI/centos/grubx64.efi' | cut -d"/" -f4- | sed -e 's;/;\\;g'
boot\efi\EFI\centos\grubx64.efi

# echo '/boot/efi/EFI/boot/bootx64.efi' | cut -d"/" -f4- | sed -e 's;/;\\;g'
EFI\boot\bootx64.efi

# echo 'boot/efi/EFI/boot/bootx64.efi' | cut -d"/" -f4- | sed -e 's;/;\\;g'
boot\bootx64.efi

and no comment that tells the reason behind
the hardcoded cut after 3 '/' characters.

@gdha
do you perhaps know about the reason behind the

... | cut -d"/" -f4- | ...

part?

franciscohosting commented at 2019-11-13 15:34:¶

I found a mistake in my backup, I wasn't backing up /boot/efi because it was in fat16 and I was using a LinuxAll File system, I'm not sure if you know about the file-sets in bareos, but here is my updated file-set:
labobject2-test.txt
Now I get this log file with rear -D recover:
rear-labobject2.log
Something about
EFI variables are not supported on this system.

I don't know if its important, but I created the bootable usb doing:

isohybrid -u rear-labobject2.iso
sudo dd if=rear-labobject2.iso of=/dev/sdb bs=4M && syn

jsmeix commented at 2019-11-13 16:09:¶

@franciscohosting
in your new rear -D recover log file
https://github.com/rear/rear/files/3841985/rear-labobject2.log
there is

+ source /usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
...
++ test -f /mnt/local//boot/efi/EFI/centos/grubx64.efi
...
+++ echo /boot/efi/EFI/centos/grubx64.efi
+++ cut -d/ -f4-
+++ sed -e 's;/;\\;g'
++ BootLoader='EFI\centos\grubx64.efi'
...
++ efibootmgr --create --gpt --disk /dev/sdb --part 1 --write-signature --label 'RedHatEnterpriseServer 7' --loader '\EFI\centos\grubx64.efi'
EFI variables are not supported on this system.

so the efibootmgr call fails with

EFI variables are not supported on this system.

but I am not a sufficient UEFI expert to know what that actually means.

What I found by Googling for

efibootmgr "EFI variables are not supported on this system"

is
https://unix.stackexchange.com/questions/91620/efi-variables-are-not-supported-on-this-system
and
https://bbs.archlinux.org/viewtopic.php?id=223874
that both talk about the efivars kernel module.

As far as I understand it the kernel that is used when efibootmgr is run
is the kernel of the ReaR recovery system so I think that kernel has
no efivars kernel module loaded.

To get it loaded run

modprobe efivars

directly after you logged in as root in the ReaR recovery system
(i.e. before you run rear -D recover).

For example on my currently used openSUSE Leap 15.0 UEFI system
I have the efivars kernel module loaded

# lsmod | grep -i efi
efivarfs               16384  1

Because since ReaR 2.5. there is by default MODULES=( 'all_modules' ), cf.
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-5.md
you should have all kernel modules available in the
ReaR recovery system so that modprobe efivars therein
should work.

In general regarding issues with third party backup tools:
Usually there is nothing at all what we at ReaR upstream
could do in case of issues with third-party backup tools
because usually we neither have nor use such software
so that we can neither test nor reproduce anything.
Therefore in case of issues with third party backup tools
you shoud also ask for help and support where
you got your particular third party backup tool.

gozora commented at 2019-11-13 19:02:¶

Hello @jsmeix

So from my point of view
either
the current test is wrong and then
#2051 was also wrong
or
BootLoader should be set by using $TARGET_FS_ROOT/$UEFI_BOOTLOADER

Actually non of above is true ;-)

test -f "$TARGET_FS_ROOT/$UEFI_BOOTLOADER" || return 0 is executed in finalize stage after restore is over. As the description of #2051 says (allow me narcissistically quote my self):

When system is set for UEFI boot, finalize/Linux-i386/630_run_efibootmgr.sh script should create boot menu entry via efibootmgr. This however never happens because script is looking for $UEFI_BOOTLOADER outside chroot (/mnt/local) environment, where we unlikely find $UEFI_BOOTLOADER. This leads to messages like shown in #2035 (comment) (despite system might still boot without any problem).
This patch changes condition mentioned earlier and looks for $UEFI_BOOTLOADER inside of chrooted environment (/mnt/local).

efibootmgr --create ... --loader "\\${BootLoader}" on the other hand creates UEFI boot entry (similar to entry in grub.cfg) where we can't prefix $TARGET_FS_ROOT because such path simply doesn't exist when system is restored and rebooted.

So from my point of view, current ReaR code is totally fine.

V.

franciscohosting commented at 2019-11-13 19:55:¶

in Centos 7 running normally, the following commands give no output:

# modprobe efivars
# smod | grep -i efi

but if I do:

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
mount: efivarfs is already mounted or /sys/firmware/efi/efivars busy
       efivarfs is already mounted on /sys/firmware/efi/efivars

In rear doing the first two commands don't give an output too, but mount -t efivarfs efivarfs /mnt/local/sys/firmware/efi/efivars gives:
mount: unknown filesystem type 'efivarfs'

gozora commented at 2019-11-13 21:01:¶

@franciscohosting I don't see this as a problem,
If you have efivarfs mounted and don't see any module loaded, it is most probably direct part of your kernel.

This however does not explain your message EFI variables are not supported on this system. in ReaR recovery system.

Are you restoring your original system to same HW or to new one ?
Are you 100% sure that your destination HW is UEFI compatible at the time of restore ?

V.

franciscohosting commented at 2019-11-13 22:59:¶

I did it! It seems that the bios forced legacy when booting with the usb (didn't have an option to force UEFI or disable legacy support), I burned the image to a DVD and worked without an issue, Thanks every one!

jsmeix commented at 2019-11-14 08:57:¶

@gozora
thank you so much for your help and your explanation
how things are meant to work!

I will add explanatory comments to the efibootmgr call in
usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
because that part was obscure to me (as a non UEFI expert).

I still have a question because we still have a possibly severe
issue in the code that belongs to the efibootmgr call, see
https://github.com/rear/rear/issues/2275#issuecomment-553440847

BootLoader=$( echo $UEFI_BOOTLOADER | cut -d"/" -f4- | sed -e 's;/;\\;g' )
...
... efibootmgr ... --loader "\\${BootLoader}" ...

where that cut -d"/" -f4- cuts away the fist hardcoded two or three
directories (depending on whether or not there is a leading /)
so that all depends on that there are always two or three leading
directories (and that there is or is not a leading /) that need
to be cut away to get the right value for --loader.

My question is:
What is the generically right value for the efibootmgr --loader option?

My man efibootmgr does not tell anything useful about what the
right value for --loader is.

What I need to learn is:
When some leading directories need to be cut away from the
path to the efibootmgr loader file in the currently running system
what trailing part of the system's efibootmgr loader file path is right
so that things work for the UEFI firmware during booting?

jsmeix commented at 2019-11-14 09:28:¶

@franciscohosting
thank you for your prompt feedback what made things working for you.

I think I vaguely remember that a colleague had told me
it depends on the boot medium whether or not the firmware
goes into UEFI mode or falls back to BIOS mode.

I think he told me to install a Linux system where
UEFI should be used to boot the installed Linux system
the installation system boot medium must let the firmware
boot in UEFI mode - otherwise (i.e. when the firmware boots
the installation system in BIOS mode) the installed system
can use only BIOS mode to set up its bootloader.

Because the ReaR recovery system is a Linux installation system,
cf. "Disaster recovery means installation (reinstalling from scratch)"
and "How disaster recovery with ReaR basically works" in
https://en.opensuse.org/SDB:Disaster_Recovery
you need to boot the ReaR recovery system in UEFI mode
to be able to reinstall your Linux system with ReaR
when UEFI should be used to boot the reinstalled system.

Regarding how to create a UEFI bootable ReaR recovery system on USB
see the USB_* variables in default.conf in particular USB_UEFI_PART_SIZE
and you need to prepare your USB device with "rear format" where you
need to explicitly specify the '--efi' option like

rear -v format -- --efi /dev/sdX

Note the mandatory -- before the format workflow specific options, cf.
https://github.com/rear/rear/pull/2172#issuecomment-508376871

franciscohosting commented at 2019-11-14 14:05:¶

Ok, so I checked again default.conf, and it shows a way of creating raw bootable images, that can be easily used with usb sticks:
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L792
I updated my site.conf to:

BACKUP=BAREOS
BAREOS_CLIENT=labobject2-fd
BAREOS_FILESET=labobject2-test
BAREOS_RESTORE_JOB=restoreLabobject2-fdIso
SSH_ROOT_PASSWORD=*******
OUTPUT_URL=file:///tmp/bareos-restores
OUTPUT=RAWDISK
RAWDISK_IMAGE_COMPRESSION_COMMAND=''
RAWDISK_BOOT_EXCLUDE_SYSLINUX_LEGACY='yes'
RAWDISK_BOOT_EXCLUDE_SYSLINUX_EFI='yes'
RAWDISK_BOOT_EXCLUDE_GRUB2_EFI='no'

but when doing rear -D mkrescue it gives me the following error:
ERROR: Creating a raw disk image requires an EFI bootloader or syslinux
with this log:
rear-labobject2.log

Which is weird, because rear has detected my EFI bootloader as it can be seen here:

[root@labobject2 ~]# rear -D mkrescue
Relax-and-Recover 2.5 / 2019-05-10
Running rear mkrescue (PID 8259)
Using log file: /var/log/rear/rear-labobject2.log
Found EFI system partition /dev/sdb1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using autodetected kernel '/boot/vmlinuz-3.10.0-1062.4.1.el7.x86_64' as kernel in the recovery system
Creating disk layout
Using guessed bootloader 'EFI' (found in first bytes on /dev/sda)
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct ...
Creating root filesystem layout
Handling network interface 'enp6s0'
enp6s0 is a physical device
Handled network interface 'enp6s0'
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/centos/grubx64.efi' as UEFI bootloader file
Copying logfile /var/log/rear/rear-labobject2.log into initramfs as '/tmp/rear-labobject2-partial-2019-11-14T15:01:14+0100.log'
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/3.10.0-1062.4.1.el7.x86_64 (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Skip copying broken symlink '/etc/mtab' target '/proc/16412/mounts' on /proc/ /sys/ /dev/ or /run/
Broken symlink '/usr/lib/modules/3.10.0-1062.4.1.el7.x86_64/build' in recovery system because 'readlink' cannot determine its link target
Broken symlink '/usr/lib/modules/3.10.0-1062.4.1.el7.x86_64/source' in recovery system because 'readlink' cannot determine its link target
Broken symlink '/var/lib/rear/moved_away_after_backup_restore/boot/grub2/grubenv' in recovery system because 'readlink' cannot determine its link target
Testing that the recovery system in /tmp/rear.i1BncSvGFMrsL5d/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (253401523 bytes) in 25 seconds
DISABLED: Using syslinux to create a BIOS Legacy bootloader
ERROR: Creating a raw disk image requires an EFI bootloader or syslinux
Some latest log messages since the last called script 280_create_bootable_disk_image.sh:
  2019-11-14 15:01:57.988092527 Including output/RAWDISK/Linux-i386/280_create_bootable_disk_image.sh
  2019-11-14 15:01:57.990264151 Entering debugscripts mode via 'set -x'.
  2019-11-14 15:01:57.997809976 DISABLED: Using syslinux to create a BIOS Legacy bootloader
Aborting due to an error, check /var/log/rear/rear-labobject2.log for details
Exiting rear mkrescue (PID 8259) and its descendant processes ...
Running exit tasks
You should also rm -Rf /tmp/rear.i1BncSvGFMrsL5d
Terminated

franciscohosting commented at 2019-11-14 14:36:¶

I found the mistake, in 270_create_grub2_efi_bootloader.sh, it looks if binary grub-mkimage exists, but it should be grub2-mkimage, should I make a pull request?

jsmeix commented at 2019-11-14 14:56:¶

@franciscohosting
we appreciate all contributions that improve ReaR
in particular GitHub pull requests.

Regarding how to make a GitHub pull request
you may have a look at the section "Contributing" in
http://relax-and-recover.org/development
and the section "How to contribute to Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

In this particular case regarding GRUB2 program names
like grub-something versus grub2-something:

Both kind of names exist "out there in the wild"
so special code is needed so that ReaR works everywhere,
cf. the section "Maintain backward compatibility" in
https://github.com/rear/rear/wiki/Coding-Style

Fortunately in other scripts this issue is already solved
so that you can reuse the matching code e.g. from
https://github.com/rear/rear/blob/master/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh#L57
where in particular a variable grub_name is set to grub2 or grub
depending if boot/grub2 or boot/grub exists - it even shows an error
if neither exist, cf. "Try hard to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style
so that later GRUB2 programs can be called as $grub_name-...

franciscohosting commented at 2019-11-14 15:41:¶

Ok! will do!

gozora commented at 2019-11-14 18:55:¶

Hello @jsmeix

I think that cut -d"/" -f4- is just some kind of leftover from good old times, when it was expected that UEFI bootloader will be on fixed location (/boot/efi/EFI/<some_directory>/bootx64.efi). I agree that it is not very safe, but it seems to cover most of the cases. There might be several reasons why it was not reported so far.

many people still use UEFI in legacy mode just because this mode make more sense for them, or because of historical reasons.
If people use UEFI they don't mess with bootloader and keep it on default location (many distros use variant of location I've mentioned earlier.
if people use UEFI and recover server with ReaR they don't even need to notice that something went wrong with efibootmgr because boot entry is already there and system boots OK.
even if it might not appear at first glance, UEFI have some very reasonable defaults when looking for boot loader and many times it finds some working boot loader during its fallback trip ...

What is the generically right value for the efibootmgr --loader option?

--loader value is working path to bootloader binary (e.g. bootx64.efi) but this value relative to ESP.
I'll take my home computer as an example:
I have following entry in /etc/fstab

UUID=B4EF-728C  /boot/efi       vfat    umask=0077      0       1

and following UEFI entry:

root@hugo:~# efibootmgr -v
...
Boot0004* debian    HD(3,GPT,bcd3c68d-6b4b-4f50-af18-cbc7ca9d77e6,0x121800,0x32000)/File(\EFI\DEBIAN\GRUBX64.EFI)
...

Full path to boot loader when normally booted inside LInux looks something like: /boot/efi/EFI/boot/bootx64.efi
\EFI\DEBIAN\GRUBX64.EFI is --loader value. To construct this value, you most probably need to take value of $UEFI_BOOTLOADER and remove string representing ESP, from the beginning of the string (/boot/efi in my case) and maybe flip forward slashes to back slashes (I think this flipping slashes is not needed any more ...).
UEFI doesn't know about other filesystems types that vfat, hence when in UEFI all you can see is partition represented by UUID=B4EF-728C in this example, hence from UEFI shell point of view your boot loader is located under \EFI\DEBIAN\GRUBX64.EFI.

Hope it helps!

V.

jsmeix commented at 2019-11-15 08:48:¶

@gozora
no need to "hope" you helped because as always
your help helped me more than anything had helped before
( huh! - it even became a rhyme - perhaps the beginning
of a future glorious "Hymn of Praise to @gozora" ;-)
cf. https://en.wikipedia.org/wiki/Vogon#Poetry

Don't worry!
You won't get a hymn from me but a pull request for review.
( phew! - almost again a rhyme - but fortunately only almost ;-)

jsmeix commented at 2019-11-15 09:02:¶

@gozora
some spontaneous (perhaps crazy) offhanded ideas
based on your above 'mount' and efibootmgr -v info.

FYI
what I have on my openSUSE Leap 15.0 system
where I use UEFI but no secure boot:

# mount | grep vfat
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

# efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0016,0017,0014,001A,0012,0013,0015,0010
Boot0000* opensuse-secureboot   HD(1,GPT,841a03d5-4e52-4634-b21a-43935c88f5af,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)
Boot0010  Diskette Drive        BBS(Floppy,Diskette Drive,0x0)..BO
Boot0012* SAMSUNG SSD SM951 M.2 256G    BBS(HD,P0: SAMSUNG SSD SM951 M.2 256G,0x0)..BO
Boot0013* USB Storage Device    BBS(USB,USB Storage Device,0x0)..BO
Boot0014* CD/DVD/CD-RW Drive    BBS(CDROM,P0: PLDS DVD+/-RW DH-16AES    ,0x0)..BO
Boot0015* Onboard NIC   BBS(Network,IBA GE Slot 00C8 v1550,0x0)..BO
Boot0016* Onboard NIC(IPV4)     PciRoot(0x0)/Pci(0x19,0x0)/MAC(64006a64c006,0)/IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)..BO
Boot0017* Onboard NIC(IPV6)     PciRoot(0x0)/Pci(0x19,0x0)/MAC(64006a64c006,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot001A* WDC WD10EZEX-75M2NA0          BBS(HD,P0: WDC WD10EZEX-75M2NA0      ,0x0)..BO

# find /boot/efi | grep shim.efi
/boot/efi/EFI/opensuse/shim.efi

My ideas:

1.)
In finalize/Linux-i386/670_run_efibootmgr.sh
we already determine the ESP mount point in $TARGET_FS_ROOT
so I think this is the leading part that actually needs to be cut
from the loader's full path name on the Linux system
to get the loader's path name inside the ESP.

2.)
Perhaps it works to run efibootmgr -v inside chroot $TARGET_FS_ROOT
(I don't know what environment efibootmgr -v needs to work properly).
If this works we could "grep" the loader's path name inside the ESP
from the efibootmgr -v output.

jsmeix commented at 2019-11-26 08:05:¶

I think with https://github.com/rear/rear/pull/2278 merged
the part of this issue https://github.com/rear/rear/pull/2277
is now fixed.

But the other parts (basically some UEFI booting cleanup)
are not yet fixed.

github-actions commented at 2020-06-29 01:37:¶

Stale issue message

[Export of Github issue for rear/rear.]

#2275 Issue closed: "rear recover" cannot install GRUB2-EFI on CentOS 7 minimal installation¶