#1258 Issue `closed`: In recovery system HOSTNAME is 'localhost' which is not the name of the original system¶

Labels: enhancement, bug, fixed / solved / done

ProBackup-nl opened issue at 2017-03-21 22:13:¶

rear version: 2.00 git / branch #1214
OS version: Arch Linux
rear configuration files:
OUTPUT=USB
USB_DEVICE=/dev/disk/by-label/REAR-000
BACKUP=NETFS
BACKUP_PROG=rsync
BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/var/cache/' '/var/log/journal/' )
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
Are you using legacy BIOS or UEFI boot? UEFI
Brief description of the issue: rear recover -> Error: No 'backup' detected in .../localhost/...

...
Running workflow recover...
...
/usr/share/rear/verify/NETFS/default/070_set_backup_archive.sh = ../prep/NETFS/default/070_set_backup_archive.sh
Using backup archive '/tmp/rear.xyz/outputfs/rear/<hostname>/20170320.2106/backup'
/usr/share/rear/verify/NETFS/default/090_set_readonly_options.sh
/usr/share/rear/verify/GNU/linux/230_storage_and_network_modules.sh = ../rescue/GNU/Linux/230_storage_and_network_modules.sh
/usr/share/rear/verify/GNU/linux/260_recovery_storage_drivers.sh
/usr/share/rear/verify/USB/NETFS/default/540_choose_backup_archive.sh
ERROR: No 'backup' detected in '/tmp/rear.xyz/outputfs/rear/localhost/*'
Aborting due to an error, ...

In 070 the archive path is build from: $BUILD_DIR/outputfs/$NETFS_PREFIX/$backup_file_name

In 540 the archive path is looking in: $BUILD_DIR/outputfs/rear/$HOSTNAME/* and build from $rear_run/${BACKUP_PROG_ARCHIVE}${BACKUP_PROG_SUFFIX}${BACKUP_PROG_COMPRESS_SUFFIX}
Where 540 error location is build from: $BUILD_DIR/outputfs/rear/$HOSTNAME/*

In my recovery environment $HOSTNAME resolves to localhost.

Which is not the name of the directory where backups are stored.

On the other hand in /prep/NETFS/default/070_set_backup_archive the correct location is chosen, /verify/USB/NETFS/default/540_choose_backup_archive needs some fixing to handle the localhost case correctly for USB/NETFS.

jsmeix commented at 2017-03-24 11:04:¶

As far as I remember ReaR's default behaviour
for backup on USB is "strange", cf.
https://github.com/rear/rear/issues/1164
and follow the links therein.

What worked for me is using USB_SUFFIX.
I never got used to use ReaR's default way
for backup on USB.

jsmeix commented at 2017-03-24 11:55:¶

@ProBackup-nl
I think the root cause of the issue here is that
in your recovery system $HOSTNAME='localhost'.

I think a lot of things would fail when in the
recovery system $HOSTNAME='localhost'.

In contrast to you I have in my recovery system

RESCUE e205:~ # echo $HOSTNAME
e205

As far as I can imagine this is basically a mandatory
precondition so that "rear recover" can work normally.

jsmeix commented at 2017-03-24 12:25:¶

Regarding how HOSTNAME is set in the recovery system see
usr/share/rear/skel/default/etc/scripts/boot

# set hostname
export HOSTNAME="$(cat /etc/HOSTNAME)" # set hostname in THIS shell
hostname "$HOSTNAME" # set hostname in the system

echo Hostname set to $(uname -n)

In my recovery system I have

RESCUE e205:~ # cat /etc/HOSTNAME 
e205

and /etc/HOSTNAME in the recovery system is created by
usr/share/rear/rescue/default/100_hostname.sh

jsmeix commented at 2017-03-24 12:30:¶

@ProBackup-nl
I think you shoud do some debugging with "rear -d -D mkrescue"
and KEEP_BUILD_DIR="yes" what happens during
"rear mkrescue/mkbackup" in your case and what that results
as /etc/HOSTNAME in the recovery system in your case.

ProBackup-nl commented at 2017-03-24 23:36:¶

@jsmeix

/etc/HOSTNAME in the recovery system is correctly set to "d2".

usr/share/rear/skel/default/etc/scripts/boot is there and seems to set the hostname.

I don't see any usr/share/rear/skel/default/etc/scripts/boot script output in the recovery boot process. The file exists on the recovery medium.

jsmeix commented at 2017-03-28 11:35:¶

@ProBackup-nl
what is the content of /etc/rear/rescue.conf in the recovery system
or with KEEP_BUILD_DIR="yes" after "rear mkbackup"
in /tmp/rear.$TMPDIR/rootfs/etc/rear/rescue.conf ?

I have in rescue.conf in particular

NETFS_PREFIX="e205"

where "e205" is the hostname of my original system
where I run "rear mkbackup".

ProBackup-nl commented at 2017-04-12 11:06:¶

@jsmeix I am back from a cycling trip through the south of the Netherlands and Flanders and some hedge trimming at the soon to-be solar farm location.

My rescue.conf lists:

...
USE_DHCLIENT=y
DHCLIENT_BIN=dhcpcd
DHCLIENT6_BIN=

NETFS_KEEP_OLD_BACKUP_COPY=""
NETFS_PREFIX="rear/d2/20170324.2344"
NETFS_RESTORE_CAPABILITIES="n"
...
unset TMPDIR
USING_UEFI_BOOTLOADER=1
UEFI_BOOTLOADER="/boot/EFI/systemd/systemd-bootx64.efi"

Where "d2" is the hostname of my original system (backup source).

jsmeix commented at 2017-04-12 12:18:¶

I think the root cause is still that somehow in your recovery system
HOSTNAME is not set to the hostname of the original system.

I assume when you do in your recovery system manually
what usr/share/rear/skel/default/etc/scripts/boot
does to set the right HOSTNAME, i.e.

export HOSTNAME="$(cat /etc/HOSTNAME)"
hostname "$HOSTNAME"

or something like that, then it should work.

I added some debugging stuff to my
usr/share/rear/skel/default/etc/scripts/boot
and I also think that script is not run at all.

That script is listed in usr/share/rear/skel/default/etc/inittab
but /etc/inittab is only for the sysv-compatible init process
and nowadays we have - hooray - systemd!

I guess in your particular case systemd does not
do "the right things" in your recovery system
to setup the HOSTNAME.

Fortunately ;-) I am not at all a systemd expert
so that I cannot really help further - if the root cause
is really related to systemd.

FWIW:
It seems there are three systems unit files
that run /etc/scripts/system-setup in the recovery system:

$ find usr/share/rear/skel | xargs grep -l 'ExecStart=/etc/scripts/system-setup'

usr/share/rear/skel/default/usr/lib/systemd/system/multi-user.target.wants/sysinit.service
usr/share/rear/skel/default/usr/lib/systemd/system/run-system-setup.service
usr/share/rear/skel/default/usr/lib/systemd/system/sysinit.service

I will never ever understand systemd...

ProBackup-nl commented at 2017-04-12 12:33:¶

@jsmeix Also strange is that recover script /usr/share/rear/verify/USB/NETFS/default/540_choose_backup_archive.sh tries to detect backup in a non-existing outputfs directory '/tmp/rear.xyz/outputfs/'.

# ls /tmp/rear.xyz
rootfs  tmp

Where ./rootfs is empty and ./tmp contains a file named storage_drivers.

jsmeix commented at 2017-04-12 12:52:¶

I had some trouble with 540_choose_backup_archive.sh
and the root cause is that the default ReaR behaviour
for BACKUP_URL=usb is incompatible with other
BACKUP_URLs for BACKUP=NETFS, see my
https://github.com/rear/rear/issues/1258#issuecomment-288993939
and you may have a look at
https://github.com/rear/rear/issues/1166
in particular see
https://github.com/rear/rear/issues/1166#issuecomment-272857089
that explains why 'USB' behaves strange.

I would recommend to use the compliance mode via USB_SUFFIX.

But even USB_SUFFIX would not fix the root issue here
that in your recovery system $HOSTNAME somehow
contains a value that does not work with ReaR.

ProBackup-nl commented at 2017-04-12 13:00:¶

@jsmeix Thanks for the manual hostname setup. The first export step runs fine. The hostname command does not exist (hostname: command not found) in the recovery system.

At least the only result of find / -name hostname is: /proc/sys/kernel/hostname

My lean source (Arch Linux) system hasn't got a hostname command on board:

# find / -name hostname
/etc/hostname
/proc/sys/kernel/hostname
/usr/share/bash-completion/completions/hostname
/usr/lib/gettext/hostname

I think these are the issues here:

the recover filesystem needs to have a lower case /etc/hostname instead of /etc/HOSTNAME file for Arch Linux systems
the usr/share/rear/skel/default/etc/scripts/boot need to have an alternative way to set the hostname on Arch Linux systems using hostnamectl, for example # hostnamectl set-hostname myhostname; and /usr/bin/hostnamectl should be copied to the recovery medium.
there should be some kind of warning when neither hostname nor hostnamectl commands are available during the mkrescue phase.

ProBackup-nl commented at 2017-04-12 13:21:¶

@jsmeix I can confirm that on Arch Linux the lower case /etc/hostname, instead of upper case /etc/HOSTNAME, correctly sets the hostname in the recovery environment.

jsmeix commented at 2017-04-12 15:10:¶

@ProBackup-nl
there are tons of missing tests during "rear mkbackup/mkrescue"
for things which would fail later during "rear recover", cf.
https://github.com/rear/rear/issues/1233

Any additional test during "rear mkbackup/mkrescue"
that makes the result of "rear recover" more predictable
is much appreciated.

In general regarding "warning" messages see
http://blog.schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html
and for some reason behind see
https://github.com/rear/rear/issues/564
starting at
https://github.com/rear/rear/issues/564#issuecomment-86188528

gdha commented at 2017-04-12 16:51:¶

@jsmeix @ProBackup-nl We could foresee a symbolic link from /etc/hostname to /etc/HOSTNAME in our skeleton directory structure, wouldn't this solve it?

ProBackup-nl commented at 2017-04-12 17:26:¶

@gdha I can't find any reason why a symbolic in the recovery environment wouldn't solve this issue. Where should I create the symbolic link to test the symbolic link solution?

In rear/usr/share/rear/skel/default/etc/ ?

I did revert my changes that created a lowercase /etc/hostname. Then I did this:

# cd usr/share/rear/skel/default/etc/
# ln -s HOSTNAME hostname
# cd ~/rear
# usr/sbin/rear mkrescue

That made the hostname appear in the (Arch Linux based) recovery environment.

jsmeix commented at 2017-04-13 07:24:¶

I think
usr/share/rear/rescue/default/100_hostname.sh
is the right place to create all needed stuff in the
recovery system so that setting HOSTNAME works
during startup of the the recovery system.

I would prefer to do all what belongs to the
"set HOSTNAME in the recovery system" functionality
in the 100_hostname.sh script instead of splitting that
functionality over several places i.e. have it partially
in 100_hostname.sh plus a symbolic link in
usr/share/rear/skel/default/etc/
Furthermore one cannot provide any comment in such a
symbolic link in usr/share/rear/skel/default/etc/ that
could tell about why that symbolic link is there, cf.
https://github.com/rear/rear/wiki/Coding-Style
in contrast to creating that link in 100_hostname.sh

ProBackup-nl commented at 2017-04-13 08:37:¶

For the lack of documentation capabilities, and the symbolic link pointing to a not-yet-existing file, I wouldn't prefer the symbolic link solution.

Instead modify usr/share/rear/rescue/default/100_hostname.sh to first try to detect whether there is /etc/hostname or /etc/HOSTNAME on the source system and use that name. In case both are not available, use /etc/HOSTNAME.

In usr/share/rear/skel/default/etc/scripts/boot I would make the "set hostname" section conditional to the existence of /etc/HOSTNAME. For Arch Linux the hostname will still be set as long as /etc/hostname is available, it doesn't need this scripted setting of the host name.

jsmeix commented at 2017-04-13 09:38:¶

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

@ProBackup-nl
many thanks for your valuable contribution to ReaR!

[Export of Github issue for rear/rear.]

#1258 Issue closed: In recovery system HOSTNAME is 'localhost' which is not the name of the original system¶