#2076 PR merged
: Ignore broken resolv conf in case of use dhclient issue 2018¶
Labels: enhancement
, fixed / solved / done
, minor bug
jsmeix opened issue at 2019-03-11 10:32:¶
-
Type: Minor Bug Fix / Enhancement
-
Impact: Low
-
Reference to related issue (URL):
https://github.com/rear/rear/pull/2018#issuecomment-470968951 -
How was this pull request tested?
By me on my openSUSE Leap 15.0 system -
Brief description of the changes in this pull request:
Now build/GNU/Linux/630_verify_resolv_conf_file.sh does no longer error out
when etc/resolv.conf has no nameserver or only loopback addresses
and USE_DHCLIENT has a true value
(and USE_STATIC_NETWORKING does not have a true value)
because then etc/resolv.conf in the recovery system
is generated anew by /bin/dhclient-script
so that its content before does not matter.
jsmeix commented at 2019-03-11 11:01:¶
@OliverO2 @rear/contributors
if there are no objections I would like to "just merge" it today
afternoon.
OliverO2 commented at 2019-03-11 11:26:¶
@jsmeix As noted here https://github.com/rear/rear/pull/2018#issuecomment-471499805, this change would still require configuration change to resolve the issue. With this change, I would have the option of setting
USE_RESOLV_CONF="no"
, orUSE_DHCLIENT="yes"
while ReaR was working without any network-related configuration before.
jsmeix commented at 2019-03-11 12:57:¶
@OliverO2
do you perhaps use DHCP on your original system
and that gets detected by "rear mkrescue" so that
you also get networking setup via DHCP in the recovery system?
Could you run rear -D mkrescue
without USE_RESOLV_CONF="no"
and USE_DHCLIENT="yes"
and attach the debug log file?
I would like to see what goes on in your particular case.
OliverO2 commented at 2019-03-11 13:30:¶
@jsmeix Yes, as I've written elsewhere, I use DHCP, and I've briefly checked that this is what happens:
2019-03-11 13:30:43.525267622 Including prep/GNU/Linux/210_include_dhclient.sh
2019-03-11 13:30:43.536177518 Running DHCP client found, enabling USE_DHCLIENT
I'm sorry, it was my understanding that this PR would only work if
USE_DHCLIENT
were set in the local configuration. As it now looks like
that it would work with the above auto-setting of USE_DHCLIENT
, it
would resolve the case. I'll test that and report. (I'm a bit reluctant
about posting debug logs because of sensitive information and I'm a bit
short on available time this month.)
jsmeix commented at 2019-03-11 13:36:¶
As far as I could find out
prep/GNU/Linux/210_include_dhclient.sh
is the only place where ReaR automatically determines
to use DHCP for networking setup in the recovery system
and if DHCP should be used it sets USE_DHCLIENT=y
via its dhcp_interfaces_active() function.
As far as I understand networking setup in the recovery system
skel/default/etc/scripts/system-setup.d/58-start-dhclient.sh
is the only recovery system setup script that dals with DHCP
and that script tests for USE_DHCLIENT being non-empty.
Accordingly I can currently not see how DHCP could be used
for networking setup in the recovery system without USE_DHCLIENT=y
so that I can currently not see how this pull request that does no
longer
error out if is_true "$USE_DHCLIENT"
could still error out when
DHCP is used on the original system...
jsmeix commented at 2019-03-11 13:45:¶
@OliverO2
ah! - right now I noticed your
https://github.com/rear/rear/pull/2076#issuecomment-471538771
which matches my investigation result in
https://github.com/rear/rear/pull/2076#issuecomment-471540880
so that I also think this pull request should make it "just work"
again
when DHCP is used on the original system.
For the "fun" of it:
On my openSUSE Leap 15.0 system I also use DHCP
but SUSE uses it's own kind of networking setup tool:
# ps -e | grep -Es 'dhc'
... wickedd-dhcp4
... wickedd-dhcp6
that is rightfully not detected by define_dhclients_variable() in
prep/GNU/Linux/210_include_dhclient.sh - rightfully because
we do not have Wicked support in ReaR, cf.
https://www.suse.com/media/presentation/wicked.pdf
OliverO2 commented at 2019-03-11 20:22:¶
@jsmeix I have just tested it and can confirm that the rescue system generated from an auto-detected DHCP configuration on Ubuntu 18.04.2 LTS now works out of the box (i.e. no additional configuration required). Thank you, well done!
jsmeix commented at 2019-03-12 08:11:¶
@OliverO2
I have to thank you because your testing and your information
made me better understand how nameserver setup works in
the recovery system so that I could improve things.
Now we have (hopefully) a better behaviour in this area
where things work by explicit code (and not in a somehow
vague and obscure looking way which at least looked to me
as if things had worked before more by luck than by intention).
[Export of Github issue for rear/rear.]