#2595 Issue closed
: Can't restore EFI system with Software Raid¶
Labels: enhancement
, bug
, fixed / solved / done
rmetrich opened issue at 2021-04-02 11:58:¶
Relax-and-Recover (ReaR) Issue Template¶
Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):
-
ReaR version ("/usr/sbin/rear -V"): Latest
-
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): N/A
-
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"): N/A
-
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): KVM or physical
-
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
-
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): Software RAID
-
Description of the issue (ideally so that others can reproduce it):
Restoring a system having a software raid for /boot/efi, ReaR doesn't create the EFI entry.
ReaR output:
# rear recover
[...]
Creating EFI Boot Manager entry 'RedHatEnterpriseServer 7.9' for 'EFI\redhat\shimx64.efi' (UEFI_BOOTLOADER='/boot/efi/EFI/redhat/shimx64.efi')
efibootmgr failed to create EFI Boot Manager entry for 'EFI\redhat\shimx64.efi' (UEFI_BOOTLOADER='/boot/efi/EFI/redhat/shimx64.efi')
[...]
Log: (showing an error)
# grep -w efibootmgr /var/log/rear/rear-*.log
2021-04-02 13:34:58.284377507 efibootmgr --create --gpt --disk /dev/md --part 125 --write-signature --label "RedHatEnterpriseServer 7.9" --loader "\EFI\redhat\shimx64.efi"
2021-04-02 13:34:58.287082916 efibootmgr failed to create EFI Boot Manager entry for 'EFI\redhat\shimx64.efi' (UEFI_BOOTLOADER='/boot/efi/EFI/redhat/shimx64.efi')
The issue is due to the code
/usr/share/rear/finalize/Linux-i386/670_run_efibootmgr.sh
not
supporting Software Raid at all:
30 BootEfiDev="$( mount | grep "$esp_mountpoint" | awk '{print $1}' )"
31 # /dev/sda1 or /dev/mapper/vol34_part2 or /dev/mapper/mpath99p4
32 Dev=$( get_device_name $BootEfiDev )
33 # 1 (must anyway be a low nr <9)
34 ParNr=$( get_partition_number $Dev )
35 # /dev/sda or /dev/mapper/vol34_part or /dev/mapper/mpath99p or /dev/mmcblk0p
36 Disk=$( echo ${Dev%$ParNr} )
- Workaround, if any:
Execute efibootmgr command manually on one of the members of the Software Raid.
pcahyna commented at 2021-04-05 20:19:¶
Interesting. How can one create this RAID? I suppose only the two EFI
partitions (or the two whole disks) are RAID members and have superblock
format 1.0 (so that the superblock is at the end of the partition and
does not confuse the firmware)? If just the partitions are RAID members,
is the partition type the same as it would be without the RAID? Or is
the firmware actually aware of the RAID?
(The question is, how does the layout look like exactly and how can one
install such a system in order to reproduce the problem)
rmetrich commented at 2021-04-06 05:54:¶
It's enough to select RAID in Anaconda (on RHEL or Fedora). The
installer knows it's a EFI partition so will create it in 1.0 format.
I guess the firmware must be RAID capable to fully work in the future
(e.g. in case of modification of the UEFI partition) but that's not the
problem here.
pcahyna commented at 2021-04-13 14:39:¶
@rmetrich or @gdha or @jsmeix , you can assign the issue to me, I am
working on it, , unless Renaud already has a fix.
Here is a kickstart snippet to install such a system:
part raid.3325 --fstype="mdmember" --ondisk=vda --size=1024
part raid.3527 --fstype="mdmember" --ondisk=vdb --size=157
part raid.3331 --fstype="mdmember" --ondisk=vdb --size=1024
part raid.3155 --fstype="mdmember" --ondisk=vdb --size=3937
part raid.3521 --fstype="mdmember" --ondisk=vda --size=157
part raid.3149 --fstype="mdmember" --ondisk=vda --size=3937
raid pv.3161 --device=pv00 --fstype="lvmpv" --level=RAID1 raid.3149 raid.3155
raid /boot --device=boot --fstype="xfs" --level=RAID1 raid.3325 raid.3331
raid /boot/efi --device=boot_efi --fstype="efi" --level=RAID1 --fsoptions="umask=0077,shortname=winnt" raid.3521 raid.3527
volgroup centos --pesize=4096 pv.3161
logvol / --fstype="xfs" --size=2908 --name=root --vgname=centos
logvol swap --fstype="swap" --size=1023 --name=swap --vgname=centos
rmetrich commented at 2021-04-13 15:31:¶
@pcahyna Thanks a lot! I'm in PTO and additionally extremely busy with other stuff ...
gdha commented at 2021-04-13 15:33:¶
@pcahyna It is yours now.
jsmeix commented at 2021-05-05 12:36:¶
With
https://github.com/rear/rear/pull/2608
merged
this issue should be fixed.
@pcahyna @rmetrich
thank you for all your work to get this missing functionality properly
implemented!
[Export of Github issue for rear/rear.]