#1206 Issue `closed`: ReaR for Ubuntu 16.04 needs syslinux-common (and pxelinux) otherwise it cannot boot the recovery system¶

Labels: enhancement, fixed / solved / done

Trefex opened issue at 2017-02-23 10:48:¶

Relax-and-Recover (rear) Issue Template¶

rear version (/usr/sbin/rear -V): Latest from git
OS version (cat /etc/rear/os.conf or lsb_release -a): Ubuntu 16.04
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

root@vagrant:~# more /etc/rear/local.conf
# Default is to create Relax-and-Recover rescue media as ISO image
# set OUTPUT to change that
# set BACKUP to activate an automated (backup and) restore of your data
# Possible configuration values can be found in /usr/share/rear/conf/default.conf
#
# This file (local.conf) is intended for manual configuration. For configuration
# through packages and other automated means we recommend creating a new
# file named site.conf next to this file and to leave the local.conf as it is.
# Our packages will never ship with a site.conf.
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=cifs://atlas.uni.lux/users/sarah.diehl
BACKUP_OPTIONS="cred=/etc/rear/cifs"

Are you using legacy BIOS or UEFI boot? Legacy
Brief description of the issue:

vagrant init bento/ubuntu-16.04
vagrant up
vagrant ssh
apt-get update
apt-get upgrade
reboot
git clone https://github.com/rear/rear.git
cd rear
apt-get install debhelper
make deb
cd ..
apt-get install syslinux xorriso iproute isolinux attr mtools libisoburn1 libburn4 libisofs6 libjte1
dpkg -i rear_2.00-1_amd64.deb

apt-get install cifs-utils
rear -v mkrescue
logout
vagrant halt
In VirtualBox attach ISO to CD drive
Start VM from VirtualBox
Hit F12 on startup and select CD drive
ISOLINUX 6.03 20151222 ETCD Copyright (C) 1994-2014 H. Peter Anvin et al

Failed to load ldlinux.c32
Boot failed: press a key to retry...

Work-around, if any: none

Trefex commented at 2017-02-23 10:51:¶

Adding @diehlsa for reference

gozora commented at 2017-02-23 10:52:¶

Hello, could you plese provide output from rear -d -D mkrescue

gozora commented at 2017-02-23 10:53:¶

Sorry, not output but whole log from /var/log/rear

sarah-peter commented at 2017-02-23 11:00:¶

Here's the log file

rear-mkrescue-log.txt

sarah-peter commented at 2017-02-23 11:12:¶

Above I put the log from the original run, here's the one with -d -D:

rear-vagrant.txt

gozora commented at 2017-02-23 11:55:¶

Hi @diehlsa, hi @Trefex,

I can see you are running syslinux-6.03. Can you have a look on following bug and see if this is not source of your trouble?

V.

Trefex commented at 2017-02-23 13:36:¶

@gozora potentially. However, where do we copy the file since we don't use PXE in this simple test setup?

gozora commented at 2017-02-23 13:43:¶

@Trefex that is a good question :-).

I'll try to reproduce this problem with my Ubuntu 16.04 later today.

V.

sarah-peter commented at 2017-02-23 13:43:¶

Actually the file /usr/lib/syslinux/modules/bios/ldlinux.c32 was not present at all. It is provided by the syslinux-common package, which is not part of the dependencies of the rear deb package.

After installing syslinux-common (and pxelinux) it worked fine without copying the file.

gozora commented at 2017-02-23 13:47:¶

@diehlsa and once you've installed it, is ReaR recovery working?

V.

sarah-peter commented at 2017-02-23 13:49:¶

@gozora yes, I did not have to copy the file

gozora commented at 2017-02-23 14:10:¶

Hello @gdha, hello @jsmeix,

This one is a bit more different of the previous "dependency issues".
This time backup went well, but restore not so good.

I think that following code might be the troublemaker:

bootloader-functions.sh

# Add needed libraries for syslinux v5 and hdt
    if [[ -r "$SYSLINUX_DIR/ldlinux.c32" ]]; then
        cp $v "$SYSLINUX_DIR/ldlinux.c32" "$BOOT_DIR/ldlinux.c32" >&2
    fi
    if [[ -r "$SYSLINUX_DIR/libcom32.c32" ]]; then
        cp $v "$SYSLINUX_DIR/libcom32.c32" "$BOOT_DIR/libcom32.c32" >&2
    fi
    if [[ -r "$SYSLINUX_DIR/libgpl.c32" ]]; then
        cp $v "$SYSLINUX_DIR/libgpl.c32" "$BOOT_DIR/libgpl.c32" >&2
    fi
    if [[ -r "$SYSLINUX_DIR/libmenu.c32" ]]; then
        cp $v "$SYSLINUX_DIR/libmenu.c32" "$BOOT_DIR/libmenu.c32" >&2
    fi
    if [[ -r "$SYSLINUX_DIR/libutil.c32" ]]; then
        cp $v "$SYSLINUX_DIR/libutil.c32" "$BOOT_DIR/libutil.c32" >&2
    fi
    if [[ -r "$SYSLINUX_DIR/vesamenu.c32" ]]; then
        cp $v "$SYSLINUX_DIR/vesamenu.c32" "$BOOT_DIR/vesamenu.c32" >&2
    fi

If i'm not mistaken, we just try to copy files that might be crucial for syslinux/ReaR recovery system boot, but don't enforce them to be existing. (like ldlinux.c32).
My idea would be to use StopIfError after each cp, that could at lest warn user that something is wrong.

jsmeix commented at 2017-02-23 14:24:¶

In general regarding ReaR issues
that are specific for Debian and Ubuntu see
https://github.com/rear/rear/issues/1163

@frediz
FYI you may have a look at this issue here.

@gozora
my idea would be to use before a critical section
(i.e. a section where any error is severe)

# Try to care about possible errors
# see https://github.com/rear/rear/wiki/Coding-Style
set -e -u -o pipefail

and afterwards one can use

# Restore the ReaR default bash flags and options (see usr/sbin/rear):
apply_bash_flags_and_options_commands "$DEFAULT_BASH_FLAGS_AND_OPTIONS_COMMANDS"

to go back to usual careless or "bona fide" behaviour ;-)

When I read the current code without expert knowledge
its meaning must be that all those files are just optional ;-)

Perhaps in some cases some of those files are optional
while some others of those files are needed in any case?

jsmeix commented at 2017-02-23 14:29:¶

Only as an example of optional stuff see
"menu.c32" versus "vesamenu.c32" in
https://github.com/rear/rear/issues/1135#issuecomment-268963600
i.e. "vesamenu.c32" is optional because
ReaR uses always menu.c32.

gozora commented at 2017-02-23 14:34:¶

Ok, so maybe not all cp failure should mean an error. But ldlinux.c32 looks to be mandatory ...

Btw my idea is totally wrong; If file is not readable by current process, no cp code will be executed, hence no error will occur :-).
(Bravo Vladimir!!!)

V.