#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:
    BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/var/cache/' '/var/log/journal/' )
  • 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/GNU/linux/230_storage_and_network_modules.sh = ../rescue/GNU/Linux/230_storage_and_network_modules.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.
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:

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

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

# 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 

and /etc/HOSTNAME in the recovery system is created by

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

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:


/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:

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


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:


unset TMPDIR

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

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'


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
and you may have a look at
in particular see
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

I think these are the issues here:

  1. the recover filesystem needs to have a lower case /etc/hostname instead of /etc/HOSTNAME file for Arch Linux systems
  2. 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.
  3. 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:

there are tons of missing tests during "rear mkbackup/mkrescue"
for things which would fail later during "rear recover", cf.

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
and for some reason behind see
starting at

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

many thanks for your valuable contribution to ReaR!

[Export of Github issue for rear/rear.]