#1769 Issue `closed`: BUG Unknown Bootloader - Centos 7.4¶

Labels: waiting for info, support / question, fixed / solved / done

refrain opened issue at 2018-04-06 20:14:¶

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"): 2.00
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): CentOS 7.4.1708
ReaR configuration files ("cat /etc/rear/site.conf" or "cat /etc/rear/local.conf"):
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://10.105.25.108/export/backups"
BACKUP_PROG_CRYPT_ENABLED=1
BACKUP_PROG_CRYPT_KEY="secret"
System architecture (x86 compatible or POWER and/or what kind of virtual machine): x86_64
Are you using BIOS or UEFI or another way to boot?
Brief description of the issue: Cannot get bootloader from "/usr/share/rear/layout/save/default/450_check_bootloader_files.sh"

myBOOTloader=$( cat $VAR_DIR/recovery/bootloader )

Work-around, if any:

gozora commented at 2018-04-08 11:36:¶

Can you share log file created by rear -d -D mkrescue ?

V.

refrain commented at 2018-04-10 21:14:¶

Here you go

rear-gpu1.log

gdha commented at 2018-04-11 06:21:¶

I found the following reason of failure:

++ cat /tmp/rear.bJdwyiQdEmhyZ5F/tmp/bootloader
++ Log 'Displaying the raw bootloader info of device /dev/sda:'
LUKS
xts-plain64
sha256
d95d59ad-3d40-4529-873a-f5c81f0434e4
...
++ Log 'Displaying the raw bootloader info of device /dev/sdb:'
++ cat /tmp/rear.bJdwyiQdEmhyZ5F/tmp/bootloader
LUKS
xts-plain64
sha256
d95d59ad-3d40-4529-873a-f5c81f0434e4
...
+ source /usr/share/rear/layout/save/default/450_check_bootloader_files.sh
+++ cat /var/lib/rear/recovery/bootloader
cat: /var/lib/rear/recovery/bootloader: No such file or directory
++ myBOOTloader=
++ case $myBOOTloader in
++ BugError 'Unknown bootloader () - ask for sponsoring to get this fixed'

Your disks are encrypted with LUKS and our detection procedure does not work in that case (it seems).
The best advise I can give you at this moment is to define BOOTLOADER= in the /etc/rear/local.conf file.

jsmeix commented at 2018-04-11 10:26:¶

@gdha
if easily possible we should add a test for such a LUKS encrypted boot device
and error out with an explicit meaningful Error() message in this known case
instead of the fallback BugError() when we do not know the reason why.

refrain commented at 2018-04-11 19:08:¶

@gdha thanks, I'll declare it explicitly in the conf.

refrain commented at 2018-04-11 19:15:¶

Apparently defining BOOTLOADER="GRUB2" in the local.conf doesn't bypass the bootloader check, and it still fails for the same reason...

jsmeix commented at 2018-04-12 08:03:¶

@refrain
you have ReaR version 2.00 which is too old for that.

My first attempt to implement BOOTLOADER support was
https://github.com/rear/rear/pull/1262
that happened in March 2017
but ReaR 2.00 was released in January 2017 according to
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt

Try out if a more current version works better for you, cf.
http://relax-and-recover.org/download/

I would also recommend to try out our current
ReaR upstream GitHub master code as follows:

Basically "git clone" it into a separated directory and then
configure and run ReaR from within that directory like:

# git clone https://github.com/rear/rear.git

# mv rear rear.github.master

# cd rear.github.master

# vi etc/rear/local.conf

# usr/sbin/rear -D mkbackup

Note the relative paths "etc/rear/" and "usr/sbin/".

I recommend to try out our current ReaR upstream GitHub master code
because that is the only place where we fix bugs - i.e. bugs in older
ReaR versions are not fixed by us (i.e. by ReaR upstream).
Bugs in older ReaR versions that got fixed in current ReaR upstream
GitHub master code might be fixed (if the fix can be backported)
by the Linux distributor wherefrom you got your older ReaR version.

refrain commented at 2018-04-12 18:08:¶

@jsmeix thank you, I will try working with the latest version

gdha commented at 2018-04-17 06:18:¶

@refrain If you can give us feedback on the results of your tests with the latest github master that would be splendid.

jsmeix commented at 2018-04-19 13:44:¶

Via https://github.com/rear/rear/pull/1779
LUKS encrypted disks are skipped when guessing bootloader
so that it could still detect (guess) the bootloader on other
non-LUKS-encrypted (i.e. unencrypted) disks and if nowhere
one could be guessed it fails in the same way as before.

Furthermore I enhanced the "Hah!IdontNeedEFI" case
cf. https://github.com/rear/rear/issues/1752
so that now it also detects other non-EFI bootloaders
(in particular also GRUB2).

jsmeix commented at 2018-04-20 09:28:¶

With https://github.com/rear/rear/pull/1779 merged
I consider this issue to be sufficiently fixed.

@refrain
because I cannot test myself if https://github.com/rear/rear/pull/1779
really works (because I do not use LUKS)
please test our latest ReaR upstream GitHub master code
for both cases

1.)
without BOOTLOADER="GRUB2" in local.conf
where "rear -D mkrescue" should fail for you with messages like

Cannot autodetect bootloader on LUKS encrypted disk (found 'LUKS' in first bytes on /dev/sda)
Cannot autodetect bootloader on LUKS encrypted disk (found 'LUKS' in first bytes on /dev/sdb)
Cannot autodetect what is used as bootloader, see default.conf about 'BOOTLOADER'

2.)
with BOOTLOADER="GRUB2" in local.conf
where "rear -D mkrescue" should work for you with a message like

Using specified bootloader 'GRUB2'

and provide feedback whether or not ReaR actually behaves this way for you.

[Export of Github issue for rear/rear.]

#1769 Issue closed: BUG Unknown Bootloader - Centos 7.4¶