Bug 1958222

+++ This bug was initially created as a clone of Bug #1945869 +++

Description of problem:

Restoring a system having a software raid for /boot/efi, ReaR doesn't create the EFI entry, nor prints an error, even though an error pops up.

ReaR output:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# rear recover
[...]
Patching file 'boot/efi/EFI/redhat/grub.cfg'
Running mkinitrd...
Updated initrd with new drivers for kernel 3.10.0-1160.21.1.el7.x86_64.
Running mkinitrd...
Updated initrd with new drivers for kernel 3.10.0-1160.el7.x86_64.
Finished recovering your system. You can explore it under '/mnt/local'.
Exiting rear recover (PID 445) and its descendant processes
Running exit tasks
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Log: (showing an error)
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# grep -w efibootmgr /var/log/rear/rear-*.log
2021-04-02 12:34:48.092498680 efibootmgr --create --gpt --disk /dev/md --part 125 --write-signature --label "RedHatEnterpriseServer 7" --loader "\EFI\redhat\shimx64.efi"
2021-04-02 12:34:48.096125963 Problem occurred with creating an efibootmgr entry
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The issue is due to the code /usr/share/rear/finalize/Linux-i386/630_run_efibootmgr.sh not supporting Software Raid at all:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  9 Dev=$( get_device_name $BootEfiDev )    # /dev/sda1 or /dev/mapper/vol34_part2 or /dev/mapper/mpath99p4
 10 ParNr=$( get_partition_number $Dev )  # 1 (must anyway be a low nr <9)
 11 Disk=$( echo ${Dev%$ParNr} ) # /dev/sda or /dev/mapper/vol34_part or /dev/mapper/mpath99p
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Here above we have $BootEfiDev == /dev/md125. This ends up trying to open /dev/md (which doesn't exist).

With Software Raid, one of the members should be used instead, e.g. /dev/vda2.

The fact that no log is displayed is very problematic, it may end up in a Can't boot case.


Version-Release number of selected component (if applicable):

2.4 and Upstream one


How reproducible:

Always


Steps to Reproduce:
1. Install a VM with 2 disks in Software Raid
2. Take a backup
3. Try recovering

--- Additional comment from Renaud Métrich on 2021-04-02 11:59:59 UTC ---

See also https://github.com/rear/rear/issues/2595.
On ReaR 2.6, the error is detected, because of *LogPrintError* being used instead of *LogIfError*

--- Additional comment from RHEL Program Management on 2021-04-05 13:43:49 UTC ---

This bug does not have Internal Target Release set. It was set to 7.9.z (zstream) to ensure compliance with the process.

--- Additional comment from RHEL Program Management on 2021-04-05 13:43:49 UTC ---

This bug was reopened or transitioned from a non-RHEL to RHEL product.  The stale date has been reset to +6 months.

--- Additional comment from Pavel Cahyna on 2021-04-09 15:59:51 UTC ---

Hello Renaud,

I suppose this affects RHEL 8 as well? If so I will clone the bug.

--- Additional comment from Renaud Métrich on 2021-04-09 18:10:16 UTC ---

Indeed, but we didn't get any customer report for this.

--- Additional comment from Pavel Cahyna on 2021-04-21 09:05:53 UTC ---

(In reply to Renaud Métrich from comment #1)
> See also https://github.com/rear/rear/issues/2595.
> On ReaR 2.6, the error is detected, because of *LogPrintError* being used
> instead of *LogIfError*

With ReaR 2.6 and CentOS 7, I noticed another strange behavior though: ReaR wants to use \EFI\centos\grubx64.efi as the bootloader, although the system is currently using \EFI\centos\shimx64.efi

--- Additional comment from Renaud Métrich on 2021-04-21 09:34:05 UTC ---

Yes, it's because ReaR doesn't take care of Secure Boot possibility at all.
You need to set SECURE_BOOT_BOOTLOADER manually.

--- Additional comment from Pavel Cahyna on 2021-04-21 09:36:06 UTC ---

Can you please attach the configuration file (or at least the parts that are relevant for booting, like SECURE_BOOT_BOOTLOADER ? )

--- Additional comment from Renaud Métrich on 2021-04-21 09:47:48 UTC ---

/etc/rear/local.conf:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/redhat/shimx64.efi"
BACKUP=NETFS
OUTPUT_URL=nfs://192.168.122.1/home/rmetrich/REAR
BACKUP_URL=nfs://192.168.122.1/home/rmetrich/REAR

PROGS+=( strace )
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Kickstart used to create the system in softraid attached.

--- Additional comment from Renaud Métrich on 2021-04-21 09:48:16 UTC ---



--- Additional comment from Pavel Cahyna on 2021-04-28 18:23:25 UTC ---

Here's my attempt at a fix: https://github.com/rear/rear/pull/2608. Please review.

Note though that I haven't tested with the SECURE_BOOT_BOOTLOADER setting yet, and finalize/Linux-i386/610_EFISTUB_run_efibootmgr.sh needs the same fix.