#1821 Issue `closed`: iso boot failure¶

Labels: support / question, fixed / solved / done

NevLawrence opened issue at 2018-05-31 12:37:¶

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"): RHEL 7.3
ReaR configuration files ("cat /etc/rear/site.conf" or "cat /etc/rear/local.conf"):

GRUB_RESCUE=
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=nfs://10.100.11.61/backups
BACKUP_PROG=tar
BACKUP_OPTIONS="nfsvers=4,nolock"
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/var/crash')

System architecture (x86 compatible or POWER and/or what kind of virtual machine): HyperV
Are you using BIOS or UEFI or another way to boot? BIOS
Brief description of the issue:

Boot from recovery ISO fails! See screen shot...
hvxdevrt019 - rear recovery iso fails to boot.docx

Also the rear mkbackup unexpectedly includes libraries from the application that is installed on the server, installed in file system /opt/Axway. Entries from rear-hvxdevrt019.log...

2018-05-31 11:39:09 Adding required /opt/Axway/apigateway/platform/lib/libpcre.so.1 to LIBS
2018-05-31 11:39:09 Adding required /opt/Axway/apigateway/platform/lib/libpcre.so.1.2.4 to LIBS
2018-05-31 11:39:09 Adding required /opt/Axway/apigateway/platform/lib/libz.so.1 to LIBS
2018-05-31 11:39:09 Adding required /opt/Axway/apigateway/platform/lib/libz.so.1.2.5 to LIBS

Is the iso boot failure and the above connected?

Also /opt/Axway which in NOT a file system in vg_root, is included in the tar backup! Again which I did not expect. Other none vg_root files are not included in the backup. From the log...

2018-05-31 13:26:06 Include list:
2018-05-31 13:26:06 /opt/Axway
2018-05-31 13:26:06 /data
2018-05-31 13:26:06 /home
2018-05-31 13:26:06 /opt
2018-05-31 13:26:06 /
2018-05-31 13:26:06 /tmp
2018-05-31 13:26:06 /usr/local
2018-05-31 13:26:06 /var
2018-05-31 13:26:06 /var/log
2018-05-31 13:26:06 /var/log/audit
2018-05-31 13:26:06 /boot
2018-05-31 13:26:06 Exclude list:
2018-05-31 13:26:06 /tmp/*
2018-05-31 13:26:06 /dev/shm/*
2018-05-31 13:26:06 /var/lib/rear/output/*
2018-05-31 13:26:06 /var/crash

Work-around, if any:

Unable to work around the boot from iso failure.

Adding "ONLY_INCLUDE_VG=( vg_root )" into local.conf stops the /opt/Axway file system being included in the tar backup. Didn't expect to have to do this!

jsmeix commented at 2018-06-06 13:37:¶

@NevLawrence
I know nothing at all about HyperV.

In general regarding Virtual machines
and Recovery medium compatibility
you may have a look at those sections in
https://en.opensuse.org/SDB:Disaster_Recovery

Regarding your hvxdevrt019 - rear recovery iso fails to boot.docx:

It contains (excerpt):

/init: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
... Kernel panic ... Attempting to kill init!

This indicates your issue is same or similar as
https://github.com/rear/rear/issues/1494
which is fixed since the ReaR 2.3 release.

Simply put:
With ReaR before the ReaR 2.3 release
as soon as some special libraries configuration is used,
the libraries in the recovery system had been likely inconsistent
and when a library is involved or missing where init is linked with,
the recovery system fails to boot with kernel panic because init fails.

For a possible workaround with your ReaR version 2.00 see
https://github.com/rear/rear/issues/1494#issuecomment-330192635
i.e. specify an appropriate

COPY_AS_IS=( "${COPY_AS_IS[@]}" /directory/of/missing/libraries/ )

to get missing libraries into the recovery system
for example something like

COPY_AS_IS=( "${COPY_AS_IS[@]}" /lib64/ )

gets the whole /lib64/ content into the recovery system
(which makes the recovery system ISO image bigger).

I recommend to use 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.

To use our current ReaR upstream GitHub master code
do the following:

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/".

A request for the future:
Normally I will not even try to read any kind of proprietary data format like doc or docx
(even if it is possible with "monstrous" desktop applications like LibreOffice).
If possible provide information in simple and commonly usable file formats,
preferably plain ASCII for text only information and JPEG or PNG for images
up to even PDF if needed for complex documents.

jsmeix commented at 2018-06-11 13:00:¶

Accoding to "no news is good news" I assume
my above analysis was right and this issue is fixed
when using current ReaR upstream GitHub master code.

NevLawrence commented at 2018-06-12 08:52:¶

Hi Johannes

Thanks for the analysis and apologies for not replying sooner with an update.
I have passed the testing of the 2.3 code to a colleague (cc’d) to prove it fixes our issue.
We will confirm once tested.

Rgds
Nev Lawrence

NevLawrence commented at 2018-06-12 16:39:¶

Hi Johannes

we have successfully tested 2.3 and it has resolved the issue.

Thanks for your help.

Rgds

Nev Lawrence

jsmeix commented at 2018-06-13 07:14:¶

@NevLawrence
thanks for your explicit positive feedback.
It helps (at least me) a lot to have an explicit feedback
that there is no possibly other still unknown issue in ReaR.

[Export of Github issue for rear/rear.]

#1821 Issue closed: iso boot failure¶