#2505 Issue closed: Rear recovery fails to install boot loader on recovered system

Labels: waiting for info, support / question, no-issue-activity

illmaticone opened issue at 2020-10-26 19:00:

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"):

Relax-and-Recover 2.6-git.0.0.unknown / 2018-08-08

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
NAME="Red Hat Enterprise Linux"
VERSION="8.2 (Ootpa)"
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
[root@ess3200b3 local]# cat /etc/rear/local.conf
# Default is to create Relax-and-Recover rescue media as ISO image
# set OUTPUT to change that
# set BACKUP to activate an automated (backup and) restore of your data
# Possible configuration values can be found in /usr/share/rear/conf/default.conf
#
# This file (local.conf) is intended for manual configuration. For configuration
# through packages and other automated means we recommend creating a new
# file named site.conf next to this file and to leave the local.conf as it is. 
# Our packages will never ship with a site.conf
OUTPUT=ISO
OUTPUT_URL=nfs://x.x.x.x/home/iso
BACKUP=NETFS
BACKUP_URL=nfs://x.x.x.x/home/iso
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash')
NETFS_KEEP_OLD_BACKUP_COPY=n
SSH_ROOT_PASSWORD="cluster"
BACKUP_OPTIONS="nfsvers=3,nolock"
  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    BareMetal

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

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI BIOS but in Legacy mode for storage

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

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

OINT@ess3200b3 local]# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTP
NAME             KNAME          PKNAME      TRAN   TYPE FSTYPE   SIZE MOUNTPOINT
/dev/nvme0n1     /dev/nvme0n1               nvme   disk        894.3G 
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1
|                                           nvme   part vfat       2G /boot/efi
|-/dev/nvme0n1p2 /dev/nvme0n1p2 /dev/nvme0n1
|                                           nvme   part ext4   117.2G /
|-/dev/nvme0n1p3 /dev/nvme0n1p3 /dev/nvme0n1
|                                           nvme   part ext4      82G /home
|-/dev/nvme0n1p4 /dev/nvme0n1p4 /dev/nvme0n1
|                                           nvme   part ext4    81.1G /var/log
|-/dev/nvme0n1p5 /dev/nvme0n1p5 /dev/nvme0n1
|                                           nvme   part ext4    80.1G /var
|-/dev/nvme0n1p6 /dev/nvme0n1p6 /dev/nvme0n1
|                                           nvme   part ext4    79.1G /tmp
|-/dev/nvme0n1p7 /dev/nvme0n1p7 /dev/nvme0n1
|                                           nvme   part ext4    24.4G /serv
|-/dev/nvme0n1p8 /dev/nvme0n1p8 /dev/nvme0n1
|                                           nvme   part ext4     7.9G /boot
|-/dev/nvme0n1p9 /dev/nvme0n1p9 /dev/nvme0n1
|                                           nvme   part swap     7.8G [SWAP]
`-/dev/nvme0n1p10
                 /dev/nvme0n1p10
                                /dev/nvme0n1
  • Description of the issue (ideally so that others can reproduce it):
WARNING:
For this system
RedHatEnterpriseServer/8.2 on Linux-i386 (based on Fedora/8.2/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
for PC architectures like x86 and x86_64 see the script
/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
and for POWER architectures like ppc64le see the script
/usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh
---------------------------------------------------
|  IF YOU DO NOT INSTALL A BOOT LOADER MANUALLY,  |
|  THEN YOUR SYSTEM WILL NOT BE ABLE TO BOOT.     |
---------------------------------------------------
You can use 'chroot /mnt/local bash --login'
to change into the recovered system and
manually install a boot loader therein.
  • Workaround, if any:
    None. Tired to manually extract the tarball from rear shell based on this article but didnt seem to work

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/ch-relax-and-recover_rear

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

jsmeix commented at 2020-10-27 13:38:

@illmaticone
to have a chance to understand what goes on on your particular system we need your
rear -D mkrescue/mkbackup and your matching rear -D recover debug log files
plus your var/lib/rear/layout/disklayout.conf file.
See in particular the section "Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
(I recommend to read through that whole long article).

Ony as a blind shot into the dark:
Does perhaps specifying GRUB2_INSTALL_DEVICES help, cf.
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2918
perhaps together with specifying BOOTLOADER?
See also the other bootloader and [U]EFI related config variables in default.conf.

By the way:
I do not unserstand what "UEFI BIOS but in Legacy mode" means
in particular not together with a "/boot/efi" EFI System Partition (ESP).
When UEFI firmware is used in Legacy BIOS mode I would expect
a 'bios_grub' partition and/or a 'legacy_boot' partition but no ESP.
With a ESP it looks as if the UEFI firmware is used in its native EFI mode.
But I may misunderstand or confuse things here because
I am not at all a bootloader expert.

FYI:
There is no such thing as "UEFI BIOS", cf.
https://github.com/rear/rear/issues/2276#issuecomment-558641223

gdha commented at 2020-12-02 17:24:

@illmaticone Noticed you were running ReaR on RHEL 8.2 - you can open an incident report at RedHat so they can investigate it further, but therefore use the official rear-2.4 from RHEL itself. It is benificial for all parties to have a clear understanding what goes on? Is the issue a RHEL one or a ReaR one. RH can help you with this if you have an official subscription with RH.

github-actions commented at 2021-02-01 02:17:

Stale issue message

Hardcore-fs commented at 2022-08-18 22:13:

Just adding a note here for anyone else.....

This can be caused if you are using a VM /setup and you set the WRONG boot system when you init the disk
if the system you came from was UEFI and you set your VM as "legacy BIOS"
or visa versa.

it can also happen on older systems that get erased then reinited to a different boot standard.

Then at the very last stage of rear bootloader creation it will error , and you get the message....

REAR cannot put right incorrect settings in hardware or VM below the stage at which it operates.

Simply switching boot systems when you init the VM or system , gives a successful result.


[Export of Github issue for rear/rear.]