#861 Issue closed: mac address not changed on recover

Labels: waiting for info, discuss / RFC, support / question, fixed / solved / done

Wsaibot opened issue at 2016-06-03 20:22:

  • rear version (/usr/sbin/rear -V): 1.17.2
  • OS version RHEL 7.2
  • I did a backup from a virtual machine. I recovered the backup in a different machine (with other mac-address from eth0). finalize/GNU/Linux/30_create_mac_mapping.sh seem not to be working, because on the rear-ISO no /etc/rear/mappings directory is present.

Should be the the last echo line really $CONFIG_DIR/mappings?

---- code 30_create_mac_mapping.sh ----

for file in "${PATCH_FILES[@]}"; do
    grep -q HWADDR $file || continue
    dev=$(echo $file | cut -d- -f3)
    old_mac=$(grep HWADDR $file | cut -d= -f2)
    new_mac=$(cat /sys/class/net/$dev/address)
    [[ -z "$new_mac" ]] && continue
    [[ "$(echo $old_mac | sed -e 'y/abcdef/ABCDEF/')" = "$(echo $new_mac | sed -e 'y/abcdef/ABCDEF/')" ]] && continue
    echo "$old_mac $new_mac $dev" >> $CONFIG_DIR/mappings/mac
done
  • Work-around, if any: create /etc/rear/mappings after booting with CD before starting "rear recover"

gdha commented at 2016-06-07 12:44:

@Wsaibot To answer your first question - during the boot of the rescue image script /etc/scripts/system-setup.d/55-migrate-network-devices.sh should be called which creates the /etc/rear/mappings/ directory if a mac mapping should be done.
For the second question: Also check the rear.log file (on the recovery side) if there is any notion of SED_SCRIPT?
The writing in script 30_create_mac_mapping.sh to $CONFIG_DIR/mappings/mac is correct as script 42_migrate_network_configuration_files.sh is kicked of a bit later which uses the mac file as input.

Wsaibot commented at 2016-06-07 15:41:

@gdha Thanks for the explanation. Maybe I found my problem:

  • The script 55-migrate-network-devices.sh test for RULE_FILES that aren't present on RHEL. mac-addresses are only in /etc/sysconfig/network-scripts/ifcfg-ethx. Does this mean, that the script exits after this line test "$RULE_FILES" || return 0 ?. This would explain, that after boot from revocery-ISO, no /etc/rear/mappings are present and not created in the boot-process. And the script 30_create_mac_mapping.sh can't create the file /etc/rear/mappings/mac because /etc/rear/mappings are missing.

Thanks!

gdha commented at 2016-06-07 17:28:

Well , script ./finalize/GNU/Linux/30_create_mac_mapping.sh would replace mac addresses if /etc/rear/mappings/mac would exist of course. The 55-migrate-network-devices.sh script only deals with udev rules and therefore, /etc/sysconfig/network-scripts/ifcfg-ethx and alike are out of scope (at least in that script). But, perhaps, you are right, the next time I'll pay close attention (myself) to this behaviour. If needed, I'll create a new script to deal with it.
@jsmeix What do you think of it? Experienced this already?

Wsaibot commented at 2016-06-07 20:55:

@gdha : Thanks for your answer. Maybe I misunderstood the script. In my case - restoring a system on a different hardware with different mac - the script 30_create_map_mapping.sh recognizes different macs, but can't write the mapping-output, because the directory/etc/rear/mappings don't exists. Isn't that script written for this automatic conversion of mac-addresses? When I create this directory (/etc/rear/mappings) manually before starting "rear recover", the script 30_create_map_mapping.sh can write the file /etc/rear/mappings/mac and mac-addresses will be changed in the /etc/sysconfig/network-scripts/ifcfg-ethx correctly (in the following scripts) and everything would be fine. So my intention is creating the /etc/rear/mappings directory before 30_create..-script is running.

jsmeix commented at 2016-06-08 07:24:

I did not experience any such issue.
For my tests I always use DHCP
and in /etc/rear/local.conf I use

USE_DHCLIENT="yes"

gdha commented at 2016-07-07 16:37:

@Wsaibot If you would be so kind to verify our fix works for you with the latest snapshot?

Wsaibot commented at 2016-07-18 16:08:

@gdha Thanks for this patch :-)

It works for me.


[Export of Github issue for rear/rear.]