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/
2013-09-02 20:20:48 Including finalize/GNU/Linux/
2013-09-02 20:20:48 Including finalize/GNU/Linux/
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, 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 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 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, 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 runs it will write MAC addresses to $CONFIG_DIR/mappings/mac, and then shortly after 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 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

Leave a Reply

Your email address will not be published. Required fields are marked *