#1159 Issue closed: On externally booted VM with empty MBR ReaR fails with "Unknown bootloader" BugError

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

maximvolgin opened issue at 2017-01-10 12:25:


Not always but happens on some systems, for now I have it on centos6/cloud Linux and on Debian 7.11. As far as I figured problem was always but became fatal since 1.19. It cannot detect bootloader so no /var/lib/rear/recovery/bootloader file than fail. Example:

rear -d -D mkrescue
Relax-and-Recover 2.00 / Git
Using log file: /var/log/rear/rear-toronto2.log
Creating disk layout
BUG in /usr/share/rear/layout/save/default/450_check_bootloader_files.sh:
'Unknown bootloader () - ask for sponsoring to get this fixed'
Please report this issue at https://github.com/rear/rear/issues
and include the relevant parts from /var/log/rear/rear-toronto2.log
preferably with full debug information via 'rear -d -D mkrescue'
Aborting due to an error, check /var/log/rear/rear-toronto2.log for details
You should also rm -Rf /opt/bacula/bacula4hosts/rear/tmp/rear.EfqwRdTCr9dM8ss

if I do
echo "GRUB" > /var/lib/rear/recovery/bootloader

works well

grub --version
grub (GNU GRUB 0.97)

lsb_release -a
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CloudLinuxServer
Description:    CloudLinux Server release 6.8 (Oleg Makarov)
Release:        6.8
Codename:       OlegMakarov

As far as I figured non of rules in /usr/share/rear/prep/default/500_guess_bootloader.sh works.

file -s /dev/sda
/dev/sda: x86 boot sector; partition 1: ID=0x83, active, starthead 2, startsector 128, 524287872 sectors, code offset 0xb8


dd if=/dev/sda bs=512 count=4 | strings
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 6.456e-05 s, 31.7 MB/s

noting and no /var/lib/rear/recovery/bootloader as result.

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       247G  143G   91G  62% /
tmpfs            16G   42M   16G   1% /dev/shm
/usr/tmpDSK     4.0G  139M  3.7G   4% /tmp

jsmeix commented at 2017-01-10 14:30:

Ah - it seems
is back - now with centos6/cloud Linux and Debian 7.11

Perhaps instead of the default case (*) BugError
we should use (GRUB|GRUB2) as default case in
layout/save/default/450_check_bootloader_files.sh ?

On the other hand "rear mkbackup/mkrescue" should
better abort to be on the safe side in case of doubt
about the used bootloader than to blindly proceed
hoping for the best that GRUB/GRUB2 is acually used,
cf. "Try to care about possible errors" at

maximvolgin commented at 2017-01-10 14:37:

no there it see GRUB2 for my case it's empty. Let me know if I need to provide anything else to investigate.

gdha commented at 2017-01-11 08:41:

@maximvolgin Could you run dd if=/dev/sda bs=512 count=8 | strings ?
And what does rear dump display? And out of curiosity what is the content of /etc/rear/os.conf?

maximvolgin commented at 2017-01-11 09:12:

Noting :(

dd if=/dev/sda bs=512 count=8 | strings
8+0 records in
8+0 records out
4096 bytes (4.1 kB) copied, 0.000110388 s, 37.1 MB/s

echo $(hexdump -v -n 2 -e '/1 "%02x"' /dev/sda) fab8

according all docs I able to found "fab8" means no boot loader, but it's bootable and active:

file -s /dev/sda
/dev/sda: x86 boot sector; partition 1: ID=0x83, active, starthead 2, startsector 128, 524287872 sectors, code offset 0xb8

and definitely that VM booting some how :)

full MBR:

echo $(hexdump -v -n 512 -e '/1 "%02x"' /dev/sda)

really strange maybe related that it's VM.

maximvolgin commented at 2017-01-11 09:17:

rear dump
Relax-and-Recover 2.00 / Git
Using log file: /var/log/rear/rear-toronto2.log.lockless
Dumping out configuration and system information
This is a 'Linux-x86_64' system, compatible with 'Linux-i386'.
System definition:
                                    ARCH = Linux-i386
                                      OS = GNU/Linux
                        OS_MASTER_VENDOR = Fedora
                       OS_MASTER_VERSION = 6
                   OS_MASTER_VENDOR_ARCH = Fedora/i386
                OS_MASTER_VENDOR_VERSION = Fedora/6
           OS_MASTER_VENDOR_VERSION_ARCH = Fedora/6/i386
                               OS_VENDOR = RedHatEnterpriseServer
                              OS_VERSION = 6
                          OS_VENDOR_ARCH = RedHatEnterpriseServer/i386
                       OS_VENDOR_VERSION = RedHatEnterpriseServer/6
                  OS_VENDOR_VERSION_ARCH = RedHatEnterpriseServer/6/i386
Configuration tree:
                         Linux-i386.conf : OK
                          GNU/Linux.conf : OK
                             Fedora.conf : missing/empty
                        Fedora/i386.conf : missing/empty
                           Fedora/6.conf : missing/empty
                      Fedora/6/i386.conf : missing/empty
             RedHatEnterpriseServer.conf : missing/empty
        RedHatEnterpriseServer/i386.conf : missing/empty
           RedHatEnterpriseServer/6.conf : missing/empty
      RedHatEnterpriseServer/6/i386.conf : missing/empty
                               site.conf : missing/empty
                              local.conf : OK
Backup with BACULA4
                  BACKUP_INTEGRITY_CHECK = 
                         BACKUP_MOUNTCMD = 
                     BACKUP_ONLY_EXCLUDE = no
                     BACKUP_ONLY_INCLUDE = no
                          BACKUP_OPTIONS = 
      BACKUP_RESTORE_MOVE_AWAY_DIRECTORY = /var/lib/rear/moved_away_after_backup_restore/
                    BACKUP_RSYNC_OPTIONS = --sparse --archive --hard-links --numeric-ids --stats
                  BACKUP_SELINUX_DISABLE = 1
                             BACKUP_TYPE = 
                        BACKUP_UMOUNTCMD = 
                              BACKUP_URL = 
Output to ISO
                             ISO_DEFAULT = boothd
                                 ISO_DIR = /opt/bacula/bacula4hosts/rear/iso/
                               ISO_FILES = 
                        ISO_ISOLINUX_BIN = 
                            ISO_MAX_SIZE = 
                         ISO_MKISOFS_BIN = /usr/bin/mkisofs
                              ISO_PREFIX = rear-toronto2
                               ISO_VOLID = RELAXRECOVER
                           RESULT_MAILTO =

Your system is validated with the following details:
Relax-and-Recover Version 1.13.0 / $Date$
Validation:     RedHatEnterpriseServer/6/i386
Submitted:      tdec0909@yahoo.com, Marcel Keil <marcelk@tim.de>
Date:           2013-05-21, 2014-03-18
Features:       LVM, VMware guest, ISO, NETFS, NSR
Saving /var/log/rear/rear-toronto2.log.lockless as /var/log/rear/rear-toronto2.log

cat /etc/rear/os.conf

gozora commented at 2017-01-11 09:26:

what about dd if=/dev/sda1 bs=512 count=1 | hexdump -C ?

maximvolgin commented at 2017-01-11 09:34:

dd if=/dev/sda1 bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
512 bytes (512 B) copied00000200
, 0.000144735 s, 3.5 MB/s

gozora commented at 2017-01-11 09:47:

CloudLinux Server release 6.8 (Oleg Makarov) hmm, isn't that one of those custom made cloud images used by VPS (virtual private servers) ?

maximvolgin commented at 2017-01-11 10:10:

I not sure about kernel but it's onapp VM under KVM hypervisor

gdha commented at 2017-01-11 10:14:

@maximvolgin where is the BACKUP=BACULA4 coming from? That is not supported within ReaR.

maximvolgin commented at 2017-01-11 10:16:

It's something supported by me but it's not important for that error.

gozora commented at 2017-01-11 10:17:

@maximvolgin so you are running VM guest http://onapp.com/ ?

maximvolgin commented at 2017-01-11 10:20:

@gozora yes

gozora commented at 2017-01-11 10:24:

Sorry for maybe stupid question, but I'm not much into all these fancy cloud things ...
The thing is that for example my virtual server provider is using custom linux images, which matches his needs. So MBR on my server looks empty too:

gozora:(/root)(root)# dd if=/dev/xvda bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000541046 s, 946 kB/s
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  b7 39 01 5a 00 00 00 00  |.........9.Z....|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

maximvolgin commented at 2017-01-11 10:36:

Ok just got confirmation from onapp devs: there some vms booting from some floppy image onapp/tools/grub.img and I do not see it inside VM. So maybe I force set /var/lib/rear/recovery/bootloader to grub then where REAR able to detect it it redefine. At list will not be fatal error.

Thanks for help!

gozora commented at 2017-01-11 10:39:

@maximvolgin One more question, did you ever made successful restore of your onapp servers with ReaR?
I'm asking because once ReaR finishes its operation one of the thing that it does is installation of boot loader. So I was wondering if everything booted fine for you ...

maximvolgin commented at 2017-01-11 10:45:

It's my pain, I have no way to try by myself. But my boss premised me to provide me with staging onapp where I'll have full access to play with it soon. But that problem is on only a few VM of hungers.

gozora commented at 2017-01-11 10:54:

Well, boss is boss no arguing here:-).
My humble guess would be that only benefit you have from ReaR is backed up data.
For my virtual server all i do for backup is simple tar and in case of disaster, I just deploy new VM from vendor provided image and restore data from tarball ...


maximvolgin commented at 2017-01-11 10:59:

We used REAR cause it much more stable and usable than BMR provided by bacula Enterprise and it's open for customization for our needs.

gozora commented at 2017-01-11 11:04:

:-) Nice to hear that!
Anyhow, good luck with solving your problem!

jsmeix commented at 2017-01-11 12:02:

I think this issue is not actually a bug in ReaR
but in contrast ReaR is right to error out when it
cannot determine the used bootloader.

perhaps we should change this
default case (*) BugError
into a
default case (*) Error

maximvolgin commented at 2017-01-11 12:03:

yes it's not really bug

jsmeix commented at 2017-01-11 12:07:


It sems this VM is booted via a method that is outside of the VM.

I wonder when a system is booted with a method outside of
that system, does then ReaR need to install any bootloader
inside that system?

For example if a traditional system is booted form an external
removable medium (e.g. a rescue system on a CDROM),
does then ReaR need to install a bootloader inside that system?

jsmeix commented at 2017-01-11 12:09:


But perhaps it is a minor bug in ReaR when ReaR aborts with a
message about a bug in ReaR when it is not a bug in ReaR.

gozora commented at 2017-01-11 12:10:

From experience with my provider, I'm not even allowed to boot my own ISO image into machine, all I can use are vendor provided images ...

maximvolgin commented at 2017-01-11 12:11:

yes but it often is used for VM migration

gdha commented at 2017-01-11 12:25:

@jsmeix I would keep the BugError so at least we are getting informed of weird setups by some vendors. We could add this variant to the not supported list (by default)?

gdha commented at 2017-01-11 12:26:

@maximvolgin concerning your BACULA mods - are these worth sharing?

jsmeix commented at 2017-01-11 12:27:

perfectly o.k. for me to keep that BugError.

jsmeix commented at 2017-01-11 12:29:

strange, I use QEMU/KVM virtual machines on my workstation
and I am allowed to do what I want there because I am 'root' ;-)

gozora commented at 2017-01-11 12:34:

Lucky you :-), I'd wish I can become root one day :-D at least on one server.

jsmeix commented at 2017-01-17 09:33:

should we just close this issue as a very special corner case
or should we document it or should we perhaps implement
some autodetection of this special case and error out then?

gdha commented at 2017-01-17 12:37:

@jsmeix Good idea to close this issue - we do not need to do anything as it is not listed as a supported OS anyhow.

[Export of Github issue for rear/rear.]