#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:¶
Hi,
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
ERROR:
====================
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
Terminated
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
then
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
https://github.com/rear/rear/issues/1038
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
https://github.com/rear/rear/wiki/Coding-Style
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)
fab800108ed0bc00b0b800008ed88ec0fbbe007cbf0006b90002f3a4ea21060000bebe073804750b83c61081fefe0775f3eb16b402b001bb007cb2808a74018b4c02cd13ea007c0000ebfe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090b5070000008002030083feffff8000000080ff3f1f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055aa
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_RESTORE_MOVE_AWAY_FILES =
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 =
/usr/share/rear/lib/validated/RedHatEnterpriseServer/6/i386.txt
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
Comment:
Saving /var/log/rear/rear-toronto2.log.lockless as /var/log/rear/rear-toronto2.log
cat /etc/rear/os.conf
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=6
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.|
00000200
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 ...
V.
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.
@gdha
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:¶
Regarding
https://github.com/rear/rear/issues/1159#issuecomment-271835134
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:¶
Regarding
https://github.com/rear/rear/issues/1159#issuecomment-271851852
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:¶
@gdha
perfectly o.k. for me to keep that BugError.
jsmeix commented at 2017-01-11 12:29:¶
@gozora
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:¶
@gdha
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.]