Tag Archives: MAC address

ReaR MAC Address Mix-Up

Relax and Recover (ReaR) is a great tool for facilitating Linux bare-metal recovery. In works really well, however, there is a bug in the 1.14 release (it seems the same issue is present in 1.15, but I didn’t test yet) that effects restores for many bonded Ethernet interface configurations.


After the recovery of an Exadata compute node using ReaR I saw the following message during the boot process:

Bringing up interface bond1:  Device eth2 has different MAC address than expected, ignoring.

Examination of /etc/sysconfig/network-scripts/ifcfg-eth2 and dmesg showed that sure enough the MAC address in /etc/sysconfig/network-scripts/ifcfg-eth2 did not match that of the device… Hmmm.

A quick look in the restore log file revealed:

2013-09-02 20:20:47 Including finalize/GNU/Linux/30_create_mac_mapping.sh
2013-09-02 20:20:48 Including finalize/GNU/Linux/41_migrate_udev_rules.sh
2013-09-02 20:20:48 Including finalize/GNU/Linux/42_migrate_network_configuration_files.sh
2013-09-02 20:20:48 SED_SCRIPT: ';s/<original mac address removed>/<new mac address removed>/g;s/<ORIGINAL MAC ADDRESS REMOVED>/<NEW MAC ADDRESS REMOVED>/g'

Just to be clear the parts in < and > have been removed by me and represent place-holders for the MAC addresses. First in lower case and then upper case.


The cause of the issue is in 30_create_mac_mapping.sh, which is responsible for creating a MAC address mapping file (if needed). The MAC address mapping file ($CONFIG_DIR/mappings/mac) is created to handle situations where the restore is to a different host, or at least one where the MAC addresses for the network cards are different to those on the system that was backed up.

The 30_create_mac_mapping.sh script is really very simple and compares the MAC address in the restored ifcfg-<interface> files (if there are any) with the MAC addresses in /sys/class/net/<interface>/address. If there is a difference then it writes the old and current MAC addresses to the MAC address mapping file ($CONFIG_DIR/mappings/mac[1]) for later use by 42_migrate_network_configuration_files.sh. All good, right? Well, a problem can come about when dealing with bonded interfaces. Specifically, when in active-backup mode with fail_over_mac set to none (0 has the same meaning). In this configuration /sys/class/net/<interface>/address reports the same value for all slaves of a bond.

So, given that when booting into recovery mode ReaR attempts to create the network configuration at the time the ReaR boot ISO was created (via script 60-network-devices.sh), if you had bonded interfaces at the point you created the ReaR boot ISO, then you’ll have them in recovery mode, which means that when 30_create_mac_mapping.sh runs it will write MAC addresses to $CONFIG_DIR/mappings/mac, and then shortly after 42_migrate_network_configuration_files.sh will run and update the ifcfg-<interface> files, setting the MAC address for all interfaces in a given bond to the same value, which is not correct.


After initially thinking that I was going to need to come up with a patch for ReaR that would handle bonded interfaces appropriately, and I thinking that’s more complicate than it might sound, I had another look at 30_create_mac_mapping.sh and realised that if I create an empty $CONFIG_DIR/mappings/mac file (valid in my case as the MAC addresses have not changed when doing a straight restore to the same host) then ReaR will not create a new file, or add records to the existing file, and there will be no attempt to update the MAC addresses in the ifcfg-<interface> scripts.

The above worked and so a fix for the MAC address mix-up with bonded interfaces, when restoring to a host with the same MAC addresses, is to run the following command[1] before running “rear recover”:

# touch /etc/rear/mappings/mac

[1] – $CONFIG_DIR is a variable used in Relax and Recover, but note that your $CONFIG_DIR might not be /etc/rear