#1954 PR merged: network: Record permanent mac address when device is enslaved in a bond, or else /etc/mac-addresses will record broken information¶
Labels: bug, fixed / solved / done
rmetrich opened issue at 2018-11-06 16:40:¶
Relax-and-Recover (ReaR) Pull Request Template¶
Please fill in the following items before submitting a new pull request:
Pull Request Details:¶
-
Type: Bug Fix
-
Impact: Normal
-
How was this pull request tested? Unit tested + Recovery in migration mode
-
Brief description of the changes in this pull request:
When a physical device is enslaved in a bond, its MAC address is
modified to the first network interface's MAC address of the bond. This
makes /etc/mac-addresses record an invalid information, e.g.:
Broken
eth1-bond0 52:54:00:31:e0:b9
eth2-bond0 52:54:00:31:e0:b9
eth0 52:54:00:a3:97:5b
Expected
eth1-bond0 52:54:00:31:e0:b9
eth2-bond0 52:54:00:86:ec:a8
eth0 52:54:00:a3:97:5b
jsmeix commented at 2018-11-07 07:49:¶
@rmetrich
I have two questions:
What is the reason why it errors out when the second mac=...
assignment failed
but there is nothing when the first mac=... assignment failed?
What is the reason why it errors out with BugError (which means a bug in
ReaR that
should be fixed) and not with Error (which means the root cause is
outside of ReaR)?
jsmeix commented at 2018-11-07 07:52:¶
@rmetrich
how embarrassing - forget my first question - now even I can see it.
Probably too early in the morning - eyes already open but brain still
sleeping ;-)
rmetrich commented at 2018-11-07 08:14:¶
What is the reason why it errors out with BugError (which means a bug in ReaR that
should be fixed) and not with Error (which means the root cause is outside of ReaR)?
It's unexpected to not be able to retrieve the MAC address of the device. In the future, if Linux exposes this differently (e.g. "address" gets renamed), then we should have ReaR abort and be fixed.
jsmeix commented at 2018-11-07 09:28:¶
@rear/contributors
if there are no objections I would like to merge it tomorrow.
jsmeix commented at 2018-11-08 08:42:¶
@rmetrich
as always many thanks for your continuous testing, validating,
fixing, and improving of the networking setup code in ReaR.
[Export of Github issue for rear/rear.]