#2310 Issue closed: Changing IP-addresses via mappings/ip_addresses does not work

Labels: enhancement, bug, cleanup, waiting for info, needs sponsorship, no-issue-activity

tumbajamba opened issue at 2020-01-14 15:32:

Hello dear Devs ;-)

I would like to report a bug(at least it looks like a bug to me) and hopefully contribute to the project and help you guys to make your great project even more polished and stable.

Description:
Netmask suffix E.g. /24 or /16 are ignored when you define them in ip_addresses file on SLES15 SP01 System. After restore the system ends up with ip-configuration like this: 192.168.20.192/32.

Steps to reproduce:
defining ip-addresses in the rescue-system before restore:

vi /etc/rear/mappings/ip_addresses
eth0 192.168.20.192/24
eth1 192.168.21.192/24
eth2 172.20.20.192/16

After restoring my network config files look like this

cat /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.20.192'
MTU=''
NAME='Virtual Ethernet card 1'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

As one can see the netmask value /24 or /16 is ignored/missing.

This is how the config file should look like(note /24 suffix):

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.20.192/24'
MTU=''
NAME='Virtual Ethernet card 1'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

Would you kindly check and fix the issue.

Additional info:

  • Rear Version: Relax-and-Recover 2.5-git.0.ef3febb.unknown.changed / 2019-07-04
  • System architecture: PPC64LE -> Power9 CPU
  • Bootloader: GRUB
  • Hardware: IBM E950 (PowerVM LPAR)
  • OS version: SUSE Linux Enterprise Server 15 SP1

Thank you so much in advance!

jsmeix commented at 2020-01-15 09:18:

@tumbajamba
thank you for your report!

I am not a real networking expert but I think the root cause could be in
usr/share/rear/finalize/GNU/Linux/320_migrate_network_configuration_files.sh
therein the code parts that are related to

# change the ip addresses in the configuration files if a mapping is available

https://github.com/rear/rear/blob/master/usr/share/rear/finalize/GNU/Linux/320_migrate_network_configuration_files.sh#L78
which contains in particular

# TODO: what if NETMASK keyword is not defined?

https://github.com/rear/rear/blob/master/usr/share/rear/finalize/GNU/Linux/320_migrate_network_configuration_files.sh#L95
where that code originates from
https://github.com/rear/rear/commit/8472c46b31de2b748a6f948325101a970c452e61

As far as I understand that code part

        # RHEL 4, 5,... cannot handle IPADDR="x.x.x.x/cidr"
        nmask=$(prefix2netmask ${new_ip#*/})    # ipaddress/cidr (recalculate the cidr)
        if [[ "$nmask" = "0.0.0.0" ]]; then
            nmask=""
            nip="$new_ip"           # keep ipaddress/cidr
        else
            nip="${new_ip%%/*}"     # only keep ipaddress
        fi

        # Fedora/Suse Family
        for network_file in $TARGET_FS_ROOT/etc/sysconfig/*/ifcfg-*${new_mac}* $TARGET_FS_ROOT/etc/sysconfig/*/ifcfg-*${dev}*; do
            # TODO: what if NETMASK keyword is not defined? Should be keep new_ip then??
            sed_script="s#^IPADDR=.*#IPADDR='${nip}'#g;s#^NETMASK=.*#NETMASK='${nmask}'#g;s#^NETWORK=.*#NETWORK=''#g;s#^BROADCAST=.*#BROADCAST=''#g;s#^BOOTPROTO=.*#BOOTPROTO='static'#g
;s#STARTMODE='[mo].*#STARTMODE='auto'#g;/^IPADDR_/d;/^LABEL_/d;/^NETMASK_/d"

I think

nmask=$(prefix2netmask ${new_ip#*/})

results nmask=255.255.255.0 for new_ip=192.168.20.192/24
according to what is described for the prefix2netmask function
https://github.com/rear/rear/blob/master/usr/share/rear/lib/network-functions.sh#L85
and then (because `"$nmask" = "0.0.0.0" is false)

nip="${new_ip%%/*}"

results nip=192.168.20.192
but because in /etc/sysconfig/network/ifcfg-eth0
the NETMASK keyword is not defined
the sed_script replaces the IPADDR only with the
plain new IP 192.168.20.192 without the /24 CIDR suffix.

Accordingly I think what needs to be done is to implement the

# TODO: what if NETMASK keyword is not defined?

part in finalize/GNU/Linux/320_migrate_network_configuration_files.sh

jsmeix commented at 2020-01-15 09:21:

@tumbajamba
to verify if my assumptions in my above
https://github.com/rear/rear/issues/2310#issuecomment-574568493
are true in your case I would need your "rear -D recover" debug log file,
cf. "Debugging issues with Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery
so that I could see what actually happens in your case while
finalize/GNU/Linux/320_migrate_network_configuration_files.sh
is run on your particular system.

tumbajamba commented at 2020-01-15 09:33:

@jsmeix
rear-lin0001.log
Here we are! Thx for the quick response and reaction!
Please let me know what was the root cause of the issue.

jsmeix commented at 2020-01-15 09:33:

Ugh!
It seems there is much more TODO in this area to get things working
sufficiently well with nowadays network ifcfg file syntax because
on my SLES15-like openSUSE Leap 15.0 system
/etc/sysconfig/network/ifcfg.template
shows in particular

## Type:    string
## Default: ""
#
# If using a static configuration you have to set an IP address and a netmask
# or prefix length. The following examples are equivalent:
#
# 1) IPADDR=192.168.1.1/24     # NETMASK and PREFIXLEN will be ignored
# 2) IPADDR=192.168.1.1
#    PREFIXLEN=24              # NETMASK will be ignored
# 3) IPADDR=192.168.1.1
#    NETMASK=255.255.255.0
#
# For multiple addresses use this variable multiple times and extend them with
# different suffixes. For example IPADDR_1=, IPADDR_2=. See section 'Multiple
# addresses' in manpage ifcfg).
#
IPADDR=

## Type:    string
## Default: ""
#
# Set the network mask for the ip address. This variable will be ignored if a
# prefixlength is set in variable PREFIXLEN in IPADDR.
# For multiple addresses use the same suffixes as with IPADDR.
#
# Note: Deprecated IPv4 only variable.
#
NETMASK=

## Type:    integer(0,64)
## Default: ""
#
# Set the prefixlength of the ip address. This variable will be ignored if a
# prefixlength is set in variable IPADDR.
# For multiple addresses use the same suffixes as with IPADDR.
#
PREFIXLEN=

so we would have to add supprt for all combinations of
IPADDR, NETMASK, PREFIXLEN ...

tumbajamba commented at 2020-01-15 09:40:

@jsmeix
To make things complete I would like to suggest you implement the function for changing the hostname of the target machine just like:

vi /etc/rear/mappings/hostname
new-server-name

That is a pretty cool step for the deployment of new machines based on REAR.

Regards
Vadim

jsmeix commented at 2020-01-15 10:07:

@tumbajamba
what "function for changing the hostname of the target machine" do you mean?

I do not find the string hostname in any usr/share/rear/finalize file

# find usr/share/rear/finalize/ -type f | xargs grep -i 'hostname'

results no output for me so I assume there is currently no
"function for changing the hostname of the target machine"
in ReaR?

tumbajamba commented at 2020-01-15 10:18:

@jsmeix
Hahaha I'm sorry for confusing you ;-) It was an idea btw. suggestion for a new feature "changing hostname for target machine". Since you've already implemented features like:

mappings/ip_addresses
mappings/routes
.....

So it would just make sense to implement a function:
mappings/hostname

Which would complete the processes of deploying a new server out of the existing machine based on REAR-Software.

It doesn't have anything to do with the current bug-ticket.

Regards
Vadim

jsmeix commented at 2020-01-15 10:25:

@tumbajamba
your https://github.com/rear/rear/files/4064063/rear-lin0001.log
contains only

  11201 + source /usr/share/rear/finalize/GNU/Linux/320_migrate_network_configuration_files.sh
  11202 ++ PATCH_FILES=($TARGET_FS_ROOT/etc/sysconfig/*/ifcfg-* $TARGET_FS_ROOT/etc/network/inter[f]aces $TARGET_FS_ROOT/etc/network/interfaces.d/*)
  11203 ++ test /mnt/local/etc/sysconfig/network/ifcfg-eth0
  11204 ++ mkdir -v -p /tmp/rear.40WhjaLs5wTQ7Q2/tmp/mappings
  11205 mkdir: created directory '/tmp/rear.40WhjaLs5wTQ7Q2/tmp/mappings'
  11206 ++ for mapping_file in mac ip_addresses routes
  11207 ++ read_and_strip_file /etc/rear/mappings/mac
  11208 ++ local filename=/etc/rear/mappings/mac
  11209 ++ test -s /etc/rear/mappings/mac
  11210 ++ return 1
  11211 ++ for mapping_file in mac ip_addresses routes
  11212 ++ read_and_strip_file /etc/rear/mappings/ip_addresses
  11213 ++ local filename=/etc/rear/mappings/ip_addresses
  11214 ++ test -s /etc/rear/mappings/ip_addresses
  11215 ++ return 1
  11216 ++ for mapping_file in mac ip_addresses routes
  11217 ++ read_and_strip_file /etc/rear/mappings/routes
  11218 ++ local filename=/etc/rear/mappings/routes
  11219 ++ test -s /etc/rear/mappings/routes
  11220 ++ return 1
  11221 ++ LogPrint 'Migrating network configuration files according to the mapping files ...'
  11222 ++ Log 'Migrating network configuration files according to the mapping files ...'
  11223 ++ echo '2020-01-02 11:20:22.238963962 Migrating network configuration files according to the mapping files ...'
  11224 2020-01-02 11:20:22.238963962 Migrating network configuration files according to the mapping files ...
  11225 ++ Print 'Migrating network configuration files according to the mapping files ...'
  11226 ++ test -s /tmp/rear.40WhjaLs5wTQ7Q2/tmp/mappings/mac
  11227 ++ test -s /tmp/rear.40WhjaLs5wTQ7Q2/tmp/mappings/mac
  11228 +++ cut -f 1 -d ' ' /tmp/rear.40WhjaLs5wTQ7Q2/tmp/mappings/ip_addresses
  11229 ++ test -s /tmp/rear.40WhjaLs5wTQ7Q2/tmp/mappings/ip_addresses
  11230 ++ test -s /tmp/rear.40WhjaLs5wTQ7Q2/tmp/mappings/routes
  11231 + source_return_code=0

which shows that finalize/GNU/Linux/320_migrate_network_configuration_files.sh
does not actually change any file.
The return 1 lines come from the read_and_strip_file function
https://github.com/rear/rear/blob/master/usr/share/rear/lib/global-functions.sh#L11
and show that there is none of the mapping files

/etc/rear/mappings/mac
/etc/rear/mappings/ip_addresses
/etc/rear/mappings/routes

in the ReaR recovery system where "rear recover" is running
which contradicts your initial description where you wrote
that you have /etc/rear/mappings/ip_addresses
in your ReaR recovery system:

defining ip-addresses in the rescue-system before restore:

vi /etc/rear/mappings/ip_addresses
eth0 192.168.20.192/24
eth1 192.168.21.192/24
eth2 172.20.20.192/16

tumbajamba commented at 2020-01-15 10:33:

@jsmeix
I'm going to double-check this and make another restore attempt with a new log file.

Aghhh! You right, I recovered the LPAR again without ip_addresses just before I went home yesterday! I'll generate another log

tumbajamba commented at 2020-01-15 11:06:

@jsmeix
Ok got it! here is the proper log-file:
rear-lin0002.log

And I think your assumption about the root cause was correct!

jsmeix commented at 2020-01-15 13:13:

So I will finally have to bite the bullet and cleanup and enhance
finalize/GNU/Linux/320_migrate_network_configuration_files.sh

I had tried to avoid that because its code is "too obsure for me", cf.
https://github.com/rear/rear/commit/d4ee9de5dfd2d4ebdac74b6d496f38518cf63491

tumbajamba commented at 2020-01-15 13:31:

@jsmeix
Well, thx a lot.
Viel Erfolg!

Regards
Vadim

jsmeix commented at 2020-01-15 16:09:

Currently https://github.com/rear/rear/pull/2313
is just an initial incomplete "submit early submit often" part of today
so that you could have an early look at what I am doing
(perhaps you notice already issues by plain looking at my changes,
in particular my comments describe what I think what the code does)
of a general cleanup as a first step which I do primarily
to get some basic understanding of the code.
There is not yet any actual enhancement (that will be the second step).

tumbajamba commented at 2020-01-16 06:15:

@jsmeix
It sounds good that you've already started to polish and comment the code, keep updates coming.

As far as I understand there are several ways of defining netmask on SLES/SUSE 15 in /etc/sysconfig/network/ifcfg-*.

Are you going to process them depending on syntax in initial(source) config files found in source system?

like this:

IF source                            THEN target

1) NETMASK=255.255.255.0             NETMASK=255.255.255.0
2) IPADDR=192.168.1.1/24             IPADDR=192.168.1.2/24 
3) PREFIXLEN=24                      PREFIXLEN=24

According to /etc/sysconfig/network/ifcfg.template the parameter NETMASK= is deprecated:

## Type:    string
## Default: ""
#
# Set the network mask for the ip address. This variable will be ignored if a
# prefixlength is set in variable PREFIXLEN in IPADDR.
# For multiple addresses use the same suffixes as with IPADDR.
#
# Note: Deprecated IPv4 only variable.
#
NETMASK=

So it might be a good idea to always use 192.168.1.2/24 notation since it seems to be compatible with standard yast syntax and according to ifcfg.template is the most "dominant" solution which overwrites all other options. In this case other netmask entries(PREFIXLEN,NETMASK) should be removed from the config file.

jsmeix commented at 2020-01-16 08:36:

@tumbajamba
because finalize/GNU/Linux/320_migrate_network_configuration_files.sh
works on the user's restored files of his target system in /mnt/local
what it does must match what there is on the user's target system.

E.g. when the user has

IPADDR=192.168.1.1
NETMASK=255.255.255.0

cf. example 3) in the /etc/sysconfig/network/ifcfg.template excerpt
in https://github.com/rear/rear/issues/2310#issuecomment-574574414
then finalize/GNU/Linux/320_migrate_network_configuration_files.sh
needs to adapt that existing syntax only to the new values.

It is already somewhat scaring that during "rear recover" finalize stage
some of the user's (normally sacrosanct) config files from
his restored backup get "just modified" in an automated
(and mostly silent) way by ReaR without an explicit confirmation
from the user that he wants ReaR to do that.

I will never ever implement automated modification by ReaR
of the used syntax (or even semantics) in user's own files.

Regarding
https://github.com/rear/rear/issues/2312
I have some first ideas how to provide generic functionality in ReaR
so that the user can manually and explicitly specify the exact things
that he needs to be done during "rear recover" finalize stage how
to adapt and modify his own restored files in his (re)-created
target system.
This follows my general final power to the user principle,
cf. things like
https://github.com/rear/rear/pull/2283#pullrequestreview-322105398
that reads (excerpt):

Because I want "final power to the user"
it is mandatory for me that there are basically
no hardcoded "decisions" in ReaR.

Instead there must be for basically all and everything
a config variable (exceptions are common "hardcoded"
values like etc/fstab) so that the user can - if needed -
specify what he wants and then ReaR has to obey
which means ReaR must error out when the user
specified something plain wrong or impossible.

Usually config variables should be empty by default
which means by default ReaR will try its automated things
or ... config variables have a reasonable default value
when there is no automatism implemented.

or
https://github.com/rear/rear/issues/2010
and some more...

jsmeix commented at 2020-03-02 13:20:

@tumbajamba
I think your initial issue here should now be fixed (hopefully), see
https://github.com/rear/rear/pull/2313#issuecomment-593397109
and I would appreciate it if you could test it.

tumbajamba commented at 2020-03-04 10:42:

Hello @jsmeix,

I tested your script and found at least one bug.
Let me explain:

I have 3 network interfaces in my server. The config of each looks like this:

/etc/sysconfig/network/ifcfg-eth0

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.20.191/24'
MTU=''
NAME='Virtual Ethernet card 0'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

/etc/sysconfig/network/ifcfg-eth1

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.21.191'
NETMASK='255.255.255.0'
MTU=''
NAME='Virtual Ethernet card 1'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'



/etc/sysconfig/network/ifcfg-eth2

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='172.20.20.191'
PREFIXLEN=16
MTU=''
NAME='Virtual Ethernet card 2'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

After a backup, I restored my SLES with the following mappings/ip_addresses config:

/etc/rear/mappings/ip_addresses

eth0 192.168.20.192/24
eth1 192.168.21.192/24
eth2 172.20.20.192/16

The result was like this:

cat /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.20.191/24'
MTU=''
NAME='Virtual Ethernet card 0'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

lin0000:~ # cat /etc/sysconfig/network/ifcfg-eth1
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.21.191'
NETMASK='255.255.255.0'
MTU=''
NAME='Virtual Ethernet card 1'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

lin0000:~ # cat /etc/sysconfig/network/ifcfg-eth2
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='172.20.20.191'
PREFIXLEN=16
MTU=''
NAME='Virtual Ethernet card 2'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

The IP-Address from mappings/ip_addresses doesn't work, instead, the new script is using original IP address which is a bit dangerous, since it may cause IP address conflict in the network.

jsmeix commented at 2020-03-04 14:20:

@tumbajamba
thank you so much for testing it!

I expected that you find issues and I need such testing and feedback
to get to a point where things work OK (to some reasonable extent).

Could you attach here a rear -D recover debug log file
so that I can see what exactly goes on on your system?

Regarding how to get a rear -D recover debug log file
see the section "Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

tumbajamba commented at 2020-03-04 14:33:

@jsmeix
sure! Thx a lot!
rear-lin0000.log

By the way, I found a misconfiguration on my end:

cat /etc/sysconfig/network/ifcfg-eth1

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.21.191/24'
NETMASK='255.255.255.0'
MTU=''
NAME='Virtual Ethernet card 1'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'

This config contains two diffrent netmask notation: /24 and 255.255.255.0, so ignore this issue if you find it in the log file, its not a problem of your script.

jsmeix commented at 2020-03-04 15:16:

@tumbajamba
in your case 320_migrate_network_configuration_files.sh
does basically nothing so it seems the result in your case is still
https://github.com/rear/rear/issues/2310#issuecomment-574595709

As far as I see it seems the root cause is
that you do not have a /etc/mappings/mac file so
320_migrate_network_configuration_files.sh does

Using generated fallback $TMP_DIR/mappings/mac file (/etc/rear/mappings/mac is missing or has no content)

but that fallback seems to not work.

I thought a /etc/mappings/mac file gets automatically generated by
usr/share/rear/skel/default/etc/scripts/system-setup.d/55-migrate-network-devices.sh
and/or by
usr/share/rear/finalize/GNU/Linux/300_create_mac_mapping.sh
so that usually a /etc/mappings/mac file should be there
but it seems that code also does not work
or I misunderstand how that whole stuff is meant to work.

Currently I am confused and I will need sufficient time
to get that whole networking migration code
somewhat sorted out...

tumbajamba commented at 2020-03-05 06:59:

@jsmeix
But wouldn't it be the easiest just to use IP-addresses from /etc/rear/mappings/ip_addresses in case there is no /etc/mappings/mac available or even use them always in general? Why would you need the mac file if you just want to swap the IP-addresses?

jsmeix commented at 2020-03-05 09:16:

@tumbajamba
I tried hard to not change how things work in ReaR
so as a first step for now I only intended to
"Cleanup and enhance 320_migrate_network_configuration_files.sh"
via https://github.com/rear/rear/pull/2313
which is only a general cleanup as first step which I do primarily
to get some basic understanding of the code, see
https://github.com/rear/rear/pull/2313#issue-363216311
because "I am not a real networking expert" see
https://github.com/rear/rear/issues/2310#issuecomment-574568493
and
https://github.com/rear/rear/issues/2310#issuecomment-574654142

Anything more would have to happen via
https://github.com/rear/rear/issues/2312
where currently nothing at all is done.

I added "needs sponsorship" (i.e. I need substantial help) because since
https://github.com/rear/rear/issues/2310#issuecomment-594591924
it does no longer look as if I could do that alone in a reasonable way.

tumbajamba commented at 2020-03-05 09:19:

@jsmeix

Too bad we are not able to get it fixed. Hopefully, someone would fix it someday. Thank you for your effort.

Regards,
Vadim

jsmeix commented at 2020-03-05 10:21:

@tumbajamba
no need to give up right now.
I only meant that I alone won't be able to solve it in a reasonable way.
Therefore I asked for help and because of
https://en.wikipedia.org/wiki/Linus%27s_law
there is hope that things might get solved even sooner than later.
On the other hand ReaR upstream maintainers are often very busy
with other tasks (those stuff what primarily makes their salary)
so solving things might get delayed for a long time, e.g. cf.
https://github.com/rear/rear/issues/799#issuecomment-531247109

In general ReaR is first and foremost meant to recreate
a system as much as possible exactly as it was before, cf.
"Goal: Recreate a destroyed system" in
https://en.opensuse.org/SDB:Disaster_Recovery
and in most cases ReaR is used in this way.

Changing the system via "rear recover" is what we call "migration"
and that is not done so often so that it is neither as well tested
nor as well supported as the "recreating exactly as before" case.
E.g. ReaR does not fully support to migrate the bootloader, cf.
https://github.com/rear/rear/issues/1437

For example personally I only use DHCP when testing ReaR
because it is not so easy for me to get some fixed IP addresses
that I could use in my network (i.e. in SUSE's network)
for testing IP address migration with ReaR and in general
networking stuff is not so much on my personal agenda.

As far as I can imagine the current workaround to migrate
the networking setup on the recreated tartget system is
to do that manually after "rear recover" had finished
but still from inside the running ReaR recovery system
by manually adapting the restored network config files
of the recreated tartget system in /mnt/local/etc/...
or by chroot /mnt/local to manually adapt the networking
setup inside the recreated tartget system while still the kernel
and the networking setup of the ReaR recovery system is used.
To avoid that the networking setup of the ReaR recovery system is
using the IP address of the original system you may use DHCP
in the ReaR recovery system or setup networking of the ReaR
recovery system manually, cf. in "man rear" the section
"RESCUE IMAGE KERNEL COMMAND LINE OPTIONS"
https://github.com/rear/rear/blob/master/doc/rear.8.adoc
and config variables like USE_DHCLIENT USE_RESOLV_CONF
NETWORKING_PREPARATION_COMMANDS in default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf

From my personal perception "system migration with ReaR"
is more and more asked for by ReaR users.
In particular migration from one kind of hardware to another
kind of hardware and here mainly migration from physical
hardware to virtual hardware i.e. "P2V"
https://en.wikipedia.org/wiki/Physical-to-Virtual
but that also does not "just work" with ReaR, cf.
http://lists.relax-and-recover.org/pipermail/rear-users/2018-November/003626.html

@tumbajamba
when you have a sufficient SLE15-HA contract with SUSE, cf.
"SUSE support for Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
it might help to speed up things when you submit
a feature request to SUSE to get something like
https://github.com/rear/rear/issues/2312
implemented. The drwaback in this case is that usually
it is me alone who has to do basically all and everything
for ReaR at SUSE so we could be back in the exact same
situation as now...

jsmeix commented at 2020-03-13 13:39:

@tumbajamba
I merged the new 320_migrate_network_configuration_files.sh via
https://github.com/rear/rear/commit/78d7a519b4700c828544df00763a90886e0847a6
so the new one is now available at
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/finalize/GNU/Linux/320_migrate_network_configuration_files.sh

It contains now in particular a recent fix that @yontalcar found
https://github.com/rear/rear/pull/2313/commits/9277ff22b623a491556cb560b1bcd3d3172475be

The fix is in the code that generates a new mappings/mac file
as fallback when there is none (as in your case) see
https://github.com/rear/rear/blob/master/usr/share/rear/finalize/GNU/Linux/320_migrate_network_configuration_files.sh#L198
and subsequent lines.

So perhaps that fix might even help in your case
so you may try out again how far it works for you.

jsmeix commented at 2020-04-16 13:43:

Only an offhanded unverified idea of a possible reason
why there is none of the mapping files

/etc/rear/mappings/mac
/etc/rear/mappings/ip_addresses
/etc/rear/mappings/routes

in the recovery system when "rear recover" is running its finalizestage
regardless that the user had a /etc/rear/mappings/ip_addresses file
in his recovery system, cf.
https://github.com/rear/rear/issues/2310#issuecomment-574595709

In
skel/default/etc/scripts/system-setup.d/55-migrate-network-devices.sh
there is this code (excerpts):

MAC_MAPPING_FILE=/etc/rear/mappings/mac
...
# Temporary rear_mappings_mac used when interfaces have been renamed
tmp_mac_mapping_file=$(mktemp)
...
# A later script in finalize/* will also go over the MAC mappings file and
# apply them to the files in the recovered system, unless we did the mapping
# automatically, which means some device has been renamed and will probably
# gets its name back upon reboot.
if [ -s $tmp_mac_mapping_file ] ; then
    rm $MAC_MAPPING_FILE $tmp_mac_mapping_file
fi

so it seems at least /etc/rear/mappings/mac can get deleted
during recovery system startup phase under some conditions.
But I do not understand what the comment tries to tell
why /etc/rear/mappings/mac must be deleted.

@rmetrich
as far as I see it seems the code that deletes /etc/rear/mappings/mac
was added by you via
https://github.com/rear/rear/commit/37dbb032c134f5f9777cb733d53024a3fb960cad

Could you have a look here?

Perhaps /etc/rear/mappings/mac is deleted too often here?

Perhaps the current autometed network migration in the recovery system
conflicts with user intended network migration of the recreated system
via user provided network migration files like /etc/rear/mappings/mac ?

This are only offhanded unverified ideas so I could be plain wrong.

github-actions commented at 2020-06-29 01:37:

Stale issue message

[Export of Github issue for rear/rear.]