@gdha
please have a look in particular at this change in
usr/share/rear/rescue/GNU/Linux/31_network_devices.sh
Before it was:

# Skip netscript if noip is configured on the command line:
cat <<EOT >> $netscript
if [[ -e /proc/cmdline ]] ; then
    if grep -q 'noip' /proc/cmdline ; then
        return
    fi
fi
EOT
# Add a line at the top of netscript to skip if dhclient will be used:
cat - <<EOT > $netscript
# if USE_DHCLIENT=y then use DHCP instead and skip 60-network-devices.sh
[[ ! -z "\$USE_DHCLIENT" && -z "\$USE_STATIC_NETWORKING" ]] && return
...
EOT

Therin the > $netscript was plain wrong because
it made the above >> $netscript useless.
I fixed that but that is not my actual question here.

Now it is

# When DHCP is used via 58-start-dhclient.sh do not mess up the existing networking setup
# here by possibly conflicting network devices setup via 60-network-devices.sh:
if test $USE_DHCLIENT -a -z $USE_STATIC_NETWORKING ; then
    Log "No network devices setup via 60-network-devices.sh because that happens via DHCP in 58-start-dhclient.sh."
    # To be on the safe side remove network_devices_setup_script if it somehow already exists:
    rm $v -f $network_devices_setup_script >&2
    return
fi

This changes the behaviour becaus now it evaluates
the USE_DHCLIENT and USE_STATIC_NETWORKING
variables during "rear mkbackup" and not during booting
in the recovery system.

But I think now it is still correct and much simpler
because I cannot imagine how the values of the
USE_DHCLIENT and USE_STATIC_NETWORKING
variables could be changed between "rear mkbackup"
and booting in the recovery system.

I know that after the recovery system has booted
(i.e. after one has logged in ther as root) one
can change /etc/rear/local.conf but then
/etc/scripts/system-setup.d/60-network-devices.sh
was already run so that changes of the
USE_DHCLIENT and USE_STATIC_NETWORKING
variables in the recovery system have no effect on
/etc/scripts/system-setup.d/60-network-devices.sh

@jsmeix issue #819 is also linked to this I think. Will check it tomorrow.

Ah!
your
#819 (comment)
shows a real behavioural difference / regression
because with my change there is no longer a
/etc/scripts/system-setup.d/60-network-devices.sh
in case of DHCP.

Therefore I will change my change so that even in case of DHCP
the /etc/scripts/system-setup.d/60-network-devices.sh is
generated as usual so that it is available in the recovery system.

@gdha
many thanks for pointing out that regression to me!

UEFI starts to be pretty boring, so here I am messing a bit with networking :-) (hope nobody minds).
My first stop was 58-start-dhclient.sh and I was a bit surprised here.

I have three basic questions (most probably for @gdha):

1. Did I understood it well, that once original system have DHCP enabled on at least one interface, rear recover will start $DHCLIENT_BIN and stop processing with remaining network configuration?
2. Is it desired behavior to try to start $DHCLIENT_BIN on first interface only?
   e.g. since I had eth0 connected to DHCP (network 10.0.2.0) and eth1 to static setup (network 192.168.0.0) all was "fine", (eth0 was started with DHCP and eth1 left down)
   but as soon as I "switch cables" and connected eth0 to network 192.168.0.0 and eth1 to (10.0.2.0 - DHCP network) none of the interfaces went up :-( (network addresses are here only for illustration)
3. do you have some documents/issues/comments/anything describing how you intended to setup network in rear recover phase?

I personally don't mind setting up network manually (I've used recovery solution where I needed to load firmware to NIC prior driver loading not talking about pure happiness when I was able to successfully finish PXE boot without kernel panic or hang, so for me ReaR is real RELAX and RECOVER :-)), but I've understood that your policy is to bring rear recover to point where everything is ready.

@gozora
I guess you mean since you fixed basically all UEFI issues
in Relax-and-Recover UEFI starts to be pretty boring
but you like to avoid to get over-relaxed so that now
you intend to fix basically all networking issues ;-)
I have great plans for you:
After you had fixed basically all networking issues
you could fix all systemd issues which nowadays
include all udev issues ;-)

Seriously:
I have to do some major changes here
see #960 (comment)
that I (hopefully) commit today...

@jsmeix actually working on ReaR gave a the reason to study UEFI and boot loaders in more detail (there is nothing like a good motivation). And yes, couple days ago I've started to dig into systemd, so I hope this knowledge will become useful one day.

When talking about network automatic configuration, I'd like to know what is ReaR policy:

• would you like to have network configured exactly same way as on original system when in recovery mode (including all potentional networks / bonds / taps / tuns ...)
• or having minimal network configuration that is sufficient for restore

?

Thanks for that link!

I replaced support for NETWORKING_SETUP_COMMANDS
with support for NETWORKING_PREPARATION_COMMANDS
see default.conf for description.

I still need to test it...

Regarding
#960 (comment)
what network config should be set up in the recovery system:

Personally I would prefer to do only a simple
minimal network setup that is sufficient for restore.

But I fear enterprise users love to have complicated
network setups where there is no such thing as a
simple network setup that is sufficient for restore.

Cf. #951 (comment)

Unfortunately in our env we do not have DHCP assigned
IP addresses and we MUST use VLAN tagging.

and I also remember a SUSE customer where there
was no simple network setup that is sufficient for restore
because he can only access his server where his backup is
after a complicated networking setup.

Because I think it is hopeless to try to make the
network setup automatism in Relax-and-Recover
"just work" for any kind of complicated networking setup,
I implemented here the new support for the
NETWORKING_PREPARATION_COMMANDS
so that users can - if needed - specify whatever they need
in their particular case to set up networking in the recovery system.

Well, VLAN is definitely a must have. I was rather talking about luxury things like bonding that could be dropped in theory (during recovery phase).
Ok, so if we would have network in state where we car run rear recover and it would work, everybody is happy. Hope I get it right ...

My current fixes and the new support for the
NETWORKING_PREPARATION_COMMANDS
work perfectly well for me according to my test.

When I have only

USE_DHCLIENT="yes"

nothing changed for me - i.e. I get only networking setup
via DHCP via 58-start-dhclient.sh and 60-network-devices.sh
skips with 'return'.

When I have only

NETWORKING_PREPARATION_COMMANDS=( 'ip addr add 10.160.4.255/16 dev eth0' 'ip link set dev eth0 up' 'ip route add default via 10.160.255.254' 'return' )

I get networking setup only with that commands.

When I have (same as before but without the 'return'):

NETWORKING_PREPARATION_COMMANDS=( 'ip addr add 10.160.4.255/16 dev eth0' 'ip link set dev eth0 up' 'ip route add default via 10.160.255.254' )

I get networking setup via the
NETWORKING_PREPARATION_COMMANDS
plus the other commands in in 60-network-devices.sh - i.e. I
get two IP addresses for 'eth0'.

When I have

USE_DHCLIENT="yes"
NETWORKING_PREPARATION_COMMANDS=( 'ip addr add 10.160.4.255/16 dev eth0' 'ip link set dev eth0 up' 'ip route add default via 10.160.255.254' 'return' )

I get first networking setup via DHCP via 58-start-dhclient.sh and
additionally via the NETWORKING_PREPARATION_COMMANDS
in 60-network-devices.sh - i.e. I get two IP addresses for 'eth0'.

When I have

USE_DHCLIENT="yes"
NETWORKING_PREPARATION_COMMANDS=( 'ip addr add 10.160.4.255/16 dev eth0' 'ip link set dev eth0 up' 'ip route add default via 10.160.255.254' 'USE_STATIC_NETWORKING="yes"' )

I get first networking setup via DHCP via 58-start-dhclient.sh and
then via the NETWORKING_PREPARATION_COMMANDS
plus the other commands in in 60-network-devices.sh - i.e. I get
three IP addresses for 'eth0'.

Not that it makes much sense to have many IP addresses
but I only liked to test if it works as intended.

I think I will merge it soon if there is no furious objection...

I merged it because I like it so much now ;-)

I would very much apprerciate feedback if the new
NETWORKING_PREPARATION_COMMANDS
is really helpful to get problems with recovery system
networking setup more easily fixed - or at least to get
more easily a quick and dirty workaround in case of
issues with recovery system networking setup.