#1703 Issue closed: USE_DHCLIENT=y but get the static ip-address when booting from iso

Labels: support / question, fixed / solved / done

RolfWeilen opened issue at 2018-01-23 14:39:

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):
    Relax-and-Recover 2.3 / 2017-12-20
  • OS version (cat /etc/rear/os.conf or lsb_release -a):
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
# Include only rootvg
# Add an group Entry
# Warten wir mal 360Tage
  • Are you using legacy BIOS or UEFI boot?
  • Brief description of the issue:
    When i booting with iso image i get the original ip-address instead of an dhcp address. The original server ip-adress is not in the dhcp address range. I can run on the rescue prompt dhclient -r and dhclient to get an dhcp address.
  • Work-around, if any:

RolfWeilen commented at 2018-01-23 14:45:


gdha commented at 2018-01-24 08:13:

@RolfWeilen What is the content of /etc/rear/rescue.conf when booted in rescue mode?

RolfWeilen commented at 2018-01-25 07:25:


RESCUE res9901:~ # cat /etc/rear/rescue.conf 
# initialize our /etc/rear/rescue.conf file sourced by the rear command in recover mode
# also the configuration is sourced by system-setup script during booting our recovery image


# The following 3 lines were added through 210_include_dhclient.sh

# TMPDIR variable may be defined in local.conf file as prefix dir for mktemp command
# e.g. by defining TMPDIR=/var we would get our BUILD_DIR=/var/tmp/rear.XXXXXXXXXXXX
# However, in rescue we want our BUILD_DIR=/tmp/rear.XXXXXXX as we are not sure that
# the user defined TMPDIR would exist in our rescue image
# by 'unset TMPDIR' we achieve above goal (as rescue.conf is read after local.conf)!
unset TMPDIR

Best reagards

jsmeix commented at 2018-01-25 08:41:


I see several of your config variables set as


which may or may not work as expected
depending on each particular case.

Often config variables that have a boolean meaning
must be set as described in default.conf

# Boolean variables can be set to anything as we only check whether the variable
# is not empty so that both VAR=yes and VAR=no evaluate to boolean 'true'.
# To set a boolean variable to 'false' set it to an empty value.

In particular regarding


there is in

# with USE_STATIC_NETWORKING no networking setup via DHCP must happen
# see default.conf: USE_STATIC_NETWORKING overrules USE_DHCLIENT
test "$USE_STATIC_NETWORKING" && return

Accordingly I think DHCP will work with


or even better without any setting of USE_STATIC_NETWORKING in local.conf
because in default.conf it is

# Say "y", "Yes" (or any not empty string) to enable static networking (overrules USE_DHCLIENT):

In general regarding debugging issues with the start up scripts
that are run initially in the ReaR recovery system:

The basic idea behind is to not let those start up scripts
run automatically and mostly silently but manually
one after the other with 'set -x' bash debugging mode.

Add 'debug' to the ReaR kernel command line
when booting the ReaR recovery/rescue system.

In the ReaR recovery/rescue system boot menue select
the topmost enty of the form "Recover HOSTNAME"
and press the [Tab] key to edit the boot command line
and append the word ' debug' at its end and boot that.

You may found yourself stopped at a blank screen.
In this case press [Enter] which runs the very first of the
start up scripts (/etc/scripts/system-setup.d/00functions.sh).
There is some bug that the initial message is not always
printed so you may need to type the very first [Enter] blindly.

The further start up scripts are run one by one
each one after pressing [Enter].

In 'debug' mode the start up scripts are run with 'set -x'
so that this way you can better see what actually goes on
in each of the start up scripts.


RolfWeilen commented at 2018-01-25 10:37:

This config works

Thanks a lot.

jsmeix commented at 2018-01-25 11:23:

thank you for the confirmation that it works.

Check also your other VAR=n settings in your local.conf
whether or not each one actually works as you expect.

gdha commented at 2018-01-25 12:25:

@jsmeix perhaps we should add an additional check for some variables if they are set to false to define these correctly in the rescue.conf ? Or, is this too much overhead? Just for those vars we are supposed to be empty instead of 'n'?

jsmeix commented at 2018-01-25 13:31:

From my point of view additional checks are more a dirty band-aid hack.

I think we should better implement support for user-friendly boolean variables
by using the is_true() and is_false() functions everywhere.

On the other hand using the is_true() and is_false() functions everywhere
is perhaps too much work for now so that as a band-aid hack to mitigate such issues
we might perhaps implement some "fix_falsely_set_boolean_false_variables.sh"
that is run very early for all relevant workflows where things could get fixed like

is_false "$VAR" && VAR=""

The existing verify/default/040_validate_variables.sh
is not the right script where such things could be implemented
because the 'verify' stage only runs for the 'recover' workflow.

[Export of Github issue for rear/rear.]