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) 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 before running “rear recover”:
# touch /etc/rear/mappings/mac
 – $CONFIG_DIR is a variable used in Relax and Recover, but note that your $CONFIG_DIR might not be /etc/rear