#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):
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 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:¶
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 commented at 2018-01-25 08:41:¶
@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.
https://github.com/rear/rear/issues/1177#issuecomment-274771296
RolfWeilen commented at 2018-01-25 10:37:¶
Hi
This config works
USE_DHCLIENT=y
USE_STATIC_NETWORKING=
Thanks a lot.
regards
Rolf
jsmeix commented at 2018-01-25 11:23:¶
@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 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.]