#1242 Issue closed: Some disks need 'dd ... bs=4092' in guess_bootloader.sh and without grub2-efi-modules installed things go wrong on RHEL 7.3 with UEFI

Labels: enhancement, support / question, fixed / solved / done

j100ng opened issue at 2017-03-14 16:31:

Please 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.00 / Git

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

LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 7.3 (Maipo)
Release:        7.3
Codename:       Maipo
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
OUTPUT=ISO
EXCLUDE_BACKUP=("${EXCLUDE_BACKUP[@]}" /tmp /data/rear/* /var/lib/rear)
OUTPUT_URL=cifs://10.106.3.201/rear
OUTPUT_OPTIONS="rw,uid=1003,gid=500,cred=/var/lib/rear/.cifs"
NETFS_RESTORE_CAPABILITIES=y
BACKUP=NETFS
BACKUP_URL=cifs://10.106.3.201/rear
BACKUP_OPTIONS="rw,uid=1003,gid=500,cred=/var/lib/rear/.cifs"
BACKUP_PROG_INCLUDE=("${BACKUP_PROG_INCLUDE[@]}" )
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/data/rear/*' /var/lib/pgsql/96_old '/data/resources/tmp/*' )
TMPDIR="/data/rear/tmp"
export TMPDIR

  • Are you using legacy BIOS or UEFI boot?
    UEFI

  • Brief description of the issue:
    I was previously using rear (v1.17.2) as installed via "yum install rear" on RHEL 7.3. It does not backup/restore capabilities. So I downloaded v2.00 and tried to run this version. It gives me this error. As I looked through the codes & logs, it complained because file, /var/lib/rear/recovery/bootloader, is missing.

I tried running "rear savelayout" and got the same error.

  • Work-around, if any:
    I rolled back to v1.18, and I can now run "rear -v mkbackup"

rear.zip

gdha commented at 2017-03-14 17:11:

I guess this is the same as issue #1203 and #1204 - try the latest snapshot version

BUG in /usr/share/rear/layout/save/default/450_check_bootloader_files.sh:
'\''Unknown bootloader () - ask for sponsoring to get this fixed'\''

j100ng commented at 2017-03-14 17:50:

They looks similar but I couldn't find "BOOTX64.EFI" under /boot/efi.

Would you please elaborate what you mean by "try latest snapshot version"

gdha commented at 2017-03-14 18:23:

@j100ng You can download it from http://download.opensuse.org/repositories/Archiving:/Backup:/Rear:/Snapshot/CentOS_7/x86_64/

j100ng commented at 2017-03-15 12:59:

I tried this snapshot version and still encounter the same error. Attached is the execution log.
rear-macso1_snapshot.zip

gdha commented at 2017-03-18 11:58:

@j100ng Please have a look at script /usr/share/rear/prep/default/50_guess_bootloader.sh. I guess it cannot find the bootloader because it is looking at disks not (yet) known to the script?

j100ng commented at 2017-03-20 16:07:

Here's the output of "dd if=/dev/sda bs=512 count=4 | strings" as called in /usr/share/rear/prep/default/50_guess_bootloader.sh .

[jacksonl@macso1 sda]$ sudo dd if=/dev/sda bs=512 count=4 | strings
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 4.2139e-05 s, 48.6 MB/s
[jacksonl@macso1 sda]$

So it does not show the bootloader type.
I change the command slightly

[jacksonl@macso1 sda]$ sudo dd if=/dev/sda bs=4096 count=4 | strings
4+0 records in
4+0 records out
16384 bytes (16 kB) copied, 8.4453e-05 s, 194 MB/s
EFI PART
5y C
[jacksonl@macso1 sda]$

So I created my own /var/lib/rear/recovery/bootloader to contain EFI. But now I got a different error
"ERROR: Error occurred during grub2-mkimage of BOOTX64.efi"

gozora commented at 2017-03-20 16:18:

Hello @j100ng,

Could you please run rear -d -D mkrescue and upload created log file from /var/log/rear for me?

Thanks

V.

j100ng commented at 2017-03-20 16:44:

rear-macso1_BOOTX64_efi.zip

gozora commented at 2017-03-20 16:49:

@j100ng try to install grub2-efi-modules, that should help ...

j100ng commented at 2017-03-20 16:52:

Is this something new?
I had run rear v1.17.2 successfully before. However, the recovered system does not have the proper SELinux capabilities set. Therefore, I'm using v1.18 & up.

j100ng commented at 2017-03-20 16:54:

"rear -v mkrescue" was successful after I installed grub2-efi-modules.

Now trying to do a full backup & restore

gozora commented at 2017-03-20 16:56:

For me "new" is very relative. But this requirement is in ReaR for 8 months or so ...

jsmeix commented at 2017-03-21 11:30:

https://github.com/rear/rear/issues/1242#issuecomment-287823867
shows that
without grub2-efi-modules installed there is the
'Unknown bootloader ()' error on RHEL 7.3.

I wonder if there could be a reliably working automated test
in ReaR that errors out with a better matching error message like

grub2-efi-modules needs to be installed

@gozora
do you think such an automatism is possible
(with reasonable effort)?

gozora commented at 2017-03-21 11:41:

Hello @jsmeix,

I guess you just overlooked a fact that this issue is not longer about "unknown boot loader". See https://github.com/rear/rear/issues/1242#issuecomment-287808505.

For the second problem, ReaR ended with error: "grub2-mkimage: error: cannot open `/usr/lib/grub/x86_64-efi/moddep.lst': No such file or directory", which is OK to my opinion.

V.

jsmeix commented at 2017-03-21 11:50:

@gozora
Ahh! - a moving target ;-)

j100ng commented at 2017-03-21 17:19:

Please note that the original issue where /usr/share/rear/prep/default/50_guess_bootloader.sh does not find the bootloader info is still there. The root cause is the line

       dd if=$devname bs=512 count=4 | strings > $TMP_DIR/bootloader

had failed. The disk drive on my system needs to use 4092 instead of 512.

I initially used a workaround of manually creating the bootloader file.

I just tried a different solution and seems to work
local block_size=$(get_block_size ${blockd%/*})
dd if=$devname bs=$block_size count=4 | strings > $TMP_DIR/bootloader

jsmeix commented at 2017-03-22 09:56:

@j100ng
when you have a 50_guess_bootloader.sh file
you cannot use "Relax-and-Recover 2.00 / Git"
because the old two-digit files were replaced by
now three-digit files 500_guess_bootloader.sh

Regardless what kind of guesswork you use,
this is just another instance of what hurts us
again and again:
ReaR tries to do things silently and automacically right
without providing final power to the user that he
can - if needed - explicitly specify what ReaR must do, cf.
https://github.com/rear/rear/pull/1204#issuecomment-282252947
and
https://github.com/rear/rear/issues/1213#issuecomment-285618629

I think I will implement support for a BOOTLOADER variable
that is empty by default which means 500_guess_bootloader.sh
is used but if the user specifies BOOTLOADER his decision
is obeyed by ReaR, cf. what I did for UEFI_BOOTLOADER in
https://github.com/rear/rear/pull/1212

@j100ng
for now just keep your change in guess_bootloader.sh
and preferably submit it as GitHub pull request to us, cf.
http://relax-and-recover.org/development/
and "How to contribute to Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

jsmeix commented at 2017-03-24 14:17:

Via https://github.com/rear/rear/pull/1262
I did a first attempt to implement BOOTLOADER support.

jsmeix commented at 2017-03-27 09:01:

@j100ng
with https://github.com/rear/rear/pull/1262 merged
there is now some initial support to specify BOOTLOADER
in /etc/rear/local.conf as follows:

Setting BOOTLOADER is only meant so that the user
can - if needed - (i.e. when autodetection fails for him)
enforce ReaR to set up during "rear recover" one of
the supported bootloaders i.e. one of what is listed in
layout/save/default/450_check_bootloader_files.sh

What is currently listed in
layout/save/default/450_check_bootloader_files.sh

GRUB2-EFI
EFI
GRUB2
GRUB
ELILO
LILO
PPC

Currently there is no validation check for a BOOTLOADER
setting so that with unsupported bootloaders e.g. something like
"BOOTLOADER=grubby"
ReaR would just fail somehow somewhere, cf.
https://github.com/rear/rear/issues/1261

@j100ng
I also tried to implement your "dd .. bs=$block_size" proposal in
https://github.com/rear/rear/issues/1242#issuecomment-288152778

I would appreciate it if you coud test ReaR
with https://github.com/rear/rear/pull/1262 merged
and provide feedback to what extent it now works better
(or even worse) than before and what manual steps you
still need to make it work for your particular case.

Many thanks in advance!

j100ng commented at 2017-03-27 15:39:

I have tested the latest version of rear from git under the following 2 scenarios:

  1. run 'rear -v mkrescue' without any pre-configuration
    500_guess_bootloader correctly detected that system is EFI and created the necessary bootloader file

  2. run 'rear -v mkrescue' with pre-configuration in etc/rear/local.conf
    I manually deleted var/lib/rear/recovery/bootloader. Add "BOOTLOADE=EFI" into etc/rear/local.conf
    Running the command was successful, and the correct bootloader file was created.

jsmeix commented at 2017-03-28 08:04:

@j100ng
many thanks for your prompt feedback!
I assume you actually added "BOOTLOADER=EFI"
to etc/rear/local.conf (with an 'R' at the end) because
otherwise case (2.) would become case (1.).
During "rear mkbackup/mkrescue" it shows you what it uses:
When BOOTLOADER is specified in local.conf it shows
"Using specified bootloader ..."
otherwise it shows
"Using sysconfig bootloader ..." or
"Using PreP boot partition bootloader ..." (only for ppc) or
"Using guessed bootloader ..."

According to
https://github.com/rear/rear/issues/1242#issuecomment-289492981
the BOOTLOADER part of this issue is solved
and according to
https://github.com/rear/rear/issues/1242#issuecomment-288053311
a missing grub2-efi-modules is already sufficiently reported
so that I close the issue.

[Export of Github issue for rear/rear.]