USE_DHCLIENT=y but get the static ip-address when booting from iso

[RolfWeilen]

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):
  OS_VENDOR=RedHatEnterpriseServer
  OS_VERSION=7
• rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

AUTOEXCLUDE_MULTIPATH=N
OUTPUT=ISO
#OUTPUT_URL=file:/var/lib/rear/output/
OUTPUT_URL=null
ISO_DEFAULT=manuel
TIMESYNC=NTP
BACKUP=TSM
TSM_RESULT_SAVE=n
TSM_RESULT_FILE_PATH=
USE_DHCLIENT=y
USE_STATIC_NETWORKING=n
# Include only rootvg
ONLY_INCLUDE_VG=(res9901vg00)
# Add an group Entry
GRUB_RESCUE=n
# Warten wir mal 360Tage
WAIT_SECS=31104000
SSH_ROOT_PASSWORD=****

• Are you using legacy BIOS or UEFI boot?
  BIOS
• 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]

[gdha]

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

[RolfWeilen]

Hi

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

SHARE_DIR="/usr/share/rear"
CONFIG_DIR="/etc/rear"
VAR_DIR="/var/lib/rear"
LOG_DIR="/var/log/rear"

# The following 3 lines were added through 210_include_dhclient.sh
USE_DHCLIENT=y
DHCLIENT_BIN=dhclient
DHCLIENT6_BIN=

# 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
Rolf

[jsmeix]

@RolfWeilen

I see several of your config variables set as

VARIABLE=n

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

USE_STATIC_NETWORKING=n

there is in
usr/share/rear/skel/default/etc/scripts/system-setup.d/58-start-dhclient.sh

# 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

USE_DHCLIENT=y
USE_STATIC_NETWORKING=

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):
USE_STATIC_NETWORKING=

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.

Cf.
#1177 (comment)

[RolfWeilen]

Hi
This config works
USE_DHCLIENT=y
USE_STATIC_NETWORKING=

Thanks a lot.
regards
Rolf

[jsmeix]

@RolfWeilen
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]

@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]

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.