RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | cloud-init |
Medium
|
Unassigned | ||
Bug Description
2019-01-22 13:58:22,667 - util.py[DEBUG]: failed stage init
Traceback (most recent call last):
File "/usr/lib/
ret = functor(name, args)
File "/usr/lib/
init.
File "/usr/lib/
netcfg, src = self._find_
File "/usr/lib/
if self.datasource and hasattr(
File "/usr/lib/
self.
File "/usr/lib/
known_macs = net.get_
File "/usr/lib/
(name, ret[mac], mac))
RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'
Net config:
2019-01-22 13:56:20,055 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'mtu': 1500, 'type': 'bond', 'subnets': [{'type': 'dhcp4'}], 'params': {'mac_address': '9c:XX:
ns4d1']}, {'type': 'physical', 'mtu': 1500, 'subnets': [{'type': 'dhcp4'}], 'mac_address': 'f4:XX:
OS: Ubuntu 18.04.1 LTS
cloud-init: 18.4-0ubuntu1~
cloud-provider: OpenStack
Datasource: ConfigDrive
Related branches
- Ryan Harper: Approve on 2019-06-21
- Server Team CI bot: Approve (continuous-integration) on 2019-04-22
- Dan Watkins: Needs Information on 2019-03-06
-
Diff: 13 lines (+2/-0)1 file modifiedcloudinit/net/__init__.py (+2/-0)
| summary: |
RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac - '9c:dc:71:46:5d:91' + '9c:XX:XX:46:5d:91' |
| Stanislav Makar (smakar) wrote : | #1 |
| Ryan Harper (raharper) wrote : | #2 |
I think I understand what happened here. If you could please run and attach output of:
journalctl -b 0 -o short-monotonic \
-u cloud-init-
-u systemd-networkd \
-u systemd-
-u cloud-init.service
When first booted, the bonds do not exist. Cloud-init brings up one interface
(physical) and dhcp's for crawling metadata and finds a network_data.json
which includes bonding configuration. cloud-init-
and render this as netplan yaml (writes to /etc/netplan/
and then exit. Next, systemd-networkd will run and apply the network config
which includes a bond0 which enslaves ens4 (and uses the nic's mac). Now that
networking is online, cloud-init.service runs and when it resumes it runs
apply_network_
config) and this is where cloud-init detects the duplicate mac.
I thought we had a bug open that was meant to address applying networking twice
on OpenStack Datasource which would also prevent this issue. I'll see if I can
find that.
All said, I do agree that we should ignore 'mac' duplicates on bonds.
| Changed in cloud-init: | |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
| Stanislav Makar (smakar) wrote : | #3 |
journalctl -b 0 -o short-monotonic -u cloud-init-
[ 69.737278] ubuntu systemd[1]: Starting Initial cloud-init job (pre-networking)...
[ 70.927238] ironic-
[ 70.972962] ironic-
[ 72.721258] ironic-
[ 72.748539] ironic-
[ 72.750697] ironic-
[ 72.751210] ironic-
[ 72.751301] ironic-
[ 72.751351] ironic-
[ 72.751391] ironic-
[ 72.751445] ironic-
[ 72.751489] ironic-
[ 72.751529] ironic-
[ 72.751573] ironic-
[ 72.772300] ironic-
[ 72.843477] ironic-
[ 72.843560] ironic-
[ 72.843597] ironic-
[ 72.843626] ironic-
[ 72.843670] ironic-
[ 72.901979] ironic-
[ 72.971969] ironic-
[ 72.972353] ironic-
[ 72.972447] ironic-
[ 72.972485] ironic-
[ 72.972517] ironic-
[ 73.000549] ironic-
[ 73.024058] ironic-
[ 73.024144] ironic-
[ 73.024429] ironic-
[ 73.024520] ironic-
[ 73.024801] ironic-
| Stanislav Makar (smakar) wrote : | #4 |
@raharper according to logs bond0 exists at the beginning
| Ryan Harper (raharper) wrote : | #5 |
Thanks for the logs. Yes, bond0 as a device exists as soon as bond module is loaded; the critical bit is that the kernel has enslaved one of the interfaces and then takes the underlying device's MAC address. We can see that in the output:
[ 79.185842] ironic-
[ 79.185842] ironic-
| Stanislav Makar (smakar) wrote : | #6 |
It's correct and expected behaviour
It's exactly what I want to have: bond0 uses mac address(
Look at my config:
{'version': 1, 'config': [{'mtu': 1500, 'type': 'bond', 'subnets': [{'type': 'dhcp4'}], 'params': {'mac_address': '9c:XX:
{'type': 'physical', 'subnets': [], 'mac_address': '9c:XX:
{'type': 'physical', 'subnets': [], 'mac_address': '9c:XX:
| Laurent Sauvé (lanord) wrote : | #7 |
Also affected by this bug.
OS: Ubuntu 16.04.6 LTS
cloud-init: 19.1-1-
cloud-provider: OpenStack
Datasource: ConfigDrive
journalctl -b 0 -o short-monotonic \
> -u cloud-init-
> -u systemd-networkd \
> -u systemd-
> -u cloud-init.service
-- Logs begin at Wed 2019-06-05 13:14:19 UTC, end at Wed 2019-06-05 13:26:12 UTC. --
[ 34.378444] bm-ubuntu-16 systemd[1]: Starting Initial cloud-init job (pre-networking)...
[ 35.003685] bm-ubuntu-16 cloud-init[542]: Cloud-init v. 19.1-1-
[ 35.053762] bm-ubuntu-16 systemd[1]: Started Initial cloud-init job (pre-networking).
[ 35.940521] bm-ubuntu-16 systemd[1]: Starting Initial cloud-init job (metadata service crawler)...
[ 36.255549] bm-ubuntu-16 cloud-init[1656]: Cloud-init v. 19.1-1-
[ 36.269838] bm-ubuntu-16 cloud-init[1656]: ci-info: +++++++
[ 36.285065] bm-ubuntu-16 cloud-init[1656]: ci-info: +------
[ 36.309208] bm-ubuntu-16 cloud-init[1656]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
[ 36.326229] bm-ubuntu-16 cloud-init[1656]: ci-info: +------
[ 36.343773] bm-ubuntu-16 cloud-init[1656]: ci-info: | bond0 | False | . | . | . | 0c:xx:xx:6e:ac:18 |
[ 36.361935] bm-ubuntu-16 cloud-init[1656]: ci-info: | bond0.2199 | False | aaa.bbb.ccc.ddd | 255.255.255.0 | global | fa:xx:xx:1a:d4:73 |
[ 36.381006] bm-ubuntu-16 cloud-init[1656]: ci-info: | bond0.3186 | False | aaa.bbb.ccc.ddd | 255.255.255.0 | global | fa:xx:xx:74:b9:aa |
[ 36.400667] bm-ubuntu-16 cloud-init[1656]: ci-info: | enp4s0f0 | False | . | . | . | 0c:xx:xx:6e:ac:18 |
[ 36.420729] bm-ubuntu-16 cloud-init[1656]: ci-info: | enp4s0f1 | False | . | . | . | 0c:xx:xx:6e:ac:18 |
[ 36.441037] bm-ubuntu-16 cloud-init[1656]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
[ 36.461837] bm-ubuntu-16 cloud-init[1656]: ci-info: | lo | True | ::1/128 | . | host | . |
[ 36.482712] bm-ubuntu-16 cloud-init[1656]: ci-info: +------
[ 36.504400] bm-ubuntu-16 cloud-init[1656]: ci-info: +++++++
[ 36.515685] bm-ubuntu-16 cloud-init[1656]: ci-info: +------
[ 36.527134] bm-ubuntu-16 cloud-init[1656]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
[ 36.549497] bm-ubuntu-16 cloud-init[1656]: ci...
This bug is fixed with commit e5f54213 to cloud-init on branch master.
To view that commit see the following URL:
https:/
| Changed in cloud-init: | |
| status: | Confirmed → Fix Committed |
This bug is believed to be fixed in cloud-init in version 19.2. If this is still a problem for you, please make a comment and set the state back to New
Thank you.
| Changed in cloud-init: | |
| status: | Fix Committed → Fix Released |
| Danno B (slikk66) wrote : | #10 |
Hi, we're still being affected by this on Azure with 19.2-24-
Here is the packer config:
````
"provisioners": [
{
"type": "shell",
"inline": [
"while [ ! -f /var/lib/
]
},
{
"type": "ansible",
"user": "packer",
},
{
"type": "shell",
}]
````
Here is the playbook:
````
---
- hosts: all
remote_user: ubuntu
become: yes
become_method: sudo
become_user: root
environment:
DEBIAN_
````
Note: we are applying `enableAccelera
Usually our playbook has more in it (obviously) but Azure kept pointing fingers at us that our image was causing the problem, so I ran this test simply deploying a blank deprovisioned image via our same process.
And here's what happens on the serial console log:
````
[ 20.337603] sh[910]: + [ -e /var/lib/
[ 20.343177] sh[910]: + echo cleaning persistent cloud-init object
[ 20.349027] [ OK ] Started Network Time Synchronization.
[ OK ] Reached target System Time Synchronized.
sh[910]: cleaning persistent cloud-init object
[ 20.361066] sh[910]: + rm /var/lib/
[ 20.412333] sh[910]: + exit 0
[ 34.282291] cloud-init[938]: Cloud-init v. 19.2-24-
[ 34.288809] cloud-init[938]: 2019-09-16 18:02:25,262 - util.py[WARNING]: failed stage init-local
[ 34.423057] cloud-init[938]: failed run of stage init-local
[ 34.437716] cloud-init[938]: -------
[ 34.441088] cloud-init[938]: Traceback (most recent call last):
[ 34.443719] cloud-init[938]: File "/usr/lib/
[ 34.448072] cloud-init[938]: ret = functor(name, args)
[ 34.450532] cloud-init[938]: File "/usr/lib/
[ 34.454849] cloud-init[938]: init.apply_
[ 34.458725] cloud-init[938]: File "/usr/lib/
[ 34.463421] cloud-init[938]: net.wait_
[ 34.466051] cloud-init[938]: File "/usr/lib/
[ 34.470673] cloud-init[93...
| Danno B (slikk66) wrote : | #11 |
I am not able to change the state as requested by Ryan, I see message "Only changeable by a project maintainer or bug supervisor".
I have a Severity A ticket open with Azure now as well, they pointed me here and asked me to update to >= 19.2 as a fix.
| Ryan Harper (raharper) wrote : | #12 |
Hi Danno,
Thanks for updating this bug. While you're seeing a similar issue, the Azure Advanced Networking is slightly different (it's really a bond, but not exposed to userspace as linux bond type). This bug was about regular linux bond devices which needed to be excluded.
Let's move your issue to a new bug where cloud-init will need to sort out how to ignore the duplicate macs between the sriov nic and eth0 (hyperv nic) which get autobonded in the kernel but don't advertise that fact via normal bonding methods).
I've filed https:/
Usually bonds inherit mac address from one of
physical interface
This PR fixes the problem https:/