Uh… That’s weird. #

While trying to sort out some problems with my gitlab runners, I noticed a peculliar error message I’d not seen before:

Dec 14 21:41:09 somehostname systemd-udevd[111]: vethd123bdc: Could not generate persistent MAC: No data available

After a spot of searching, and some googling, I stumbled upon this SUSE KnowledgeBase Article¹ from June 02, 2021

I paraphrased it below, but the following tldr should get you the needful.

TLDR #

What #

This is a harmless error, caused by a missed expectation of systemd when creating virtual interfaces.

Why #

To ensure consistency of ethernet address names, the systemd attribute MACAddressPolicy=persistent is selected by default. The feature expects the net driver to provide an attribute to seed the random-but-consistent device name… However the necessary attribute isn’t present, thus the error.

Where #

The MAC address policy is specified in the /lib/systemd/network/99-default.link file (on my nodes)

#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Match]
OriginalName=*

[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path
MACAddressPolicy=persistent

For HOW MANY jellybeans?! #

The fix is to add a systemd policy entry, excluding certain network drivers from the default mac address policy behavior.

I did this on my ubuntu hosts with the following file:

/etc/systemd/network/02-wpl-disable-MAC-policy.link
[Match]
Driver=bonding bridge veth

[Link]
MACAddressPolicy=none

Now What? #

• Reboot yer node.
• examine journal output to verify the noise is no longer generated
• get on with your life.

my summary of The SUSE KB Article #

Situation #

When a system is setup with bridges and bonds, the following may be written to the journal.log.

May 11 11:09:16 server15 systemd-udevd[1030]: Could not generate persistent MAC address for br0: No such file or directory
May 11 11:09:16 server15 systemd-udevd[1028]: Could not generate persistent MAC address for bond1: No such file or directory

This can be observed by: journalctl -b0 -u systemd-udevd | grep MAC

Cause #

For interfaces that doesn’t have a persistent MAC address (most hardware should) a new MAC address is generated which is guaranteed to be the same on > every boot for the given machine and the given device, but which is otherwise random. The option MACAddressPolicy=persistent enables this by default in
/usr/lib/systemd/network/99-default.link. This feature depends on ID_NET_NAME_* properties to exist for the link. On virtual interfaces (such as bridges, bonds, etc…) these properties are not set hence the generation of a persistent MAC address will fail with: Could not generate persistent MAC address for $name: No such file or directory

Resolution #

The message is harmless, it will not break anything. But to make the system not write the messages anymore. The following workaround can be used.

• Create a systemd link² file called /etc/systemd/network/98-default.link.
  • Which matches on drivers and set the MACAddressPolicy to none.
• Use ethtool -i <device> to expose the driver.

server15:~ # ethtool -i br0
driver: bridge
version: 2.3
firmware-version: N/A
expansion-rom-version:
bus-info: N/A
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

server15:~ # ethtool -i bond1
driver: bonding
version: 3.7.1
firmware-version: 2
expansion-rom-version:
bus-info:
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

In this example the file will look as follows: server15:~ # cat /etc/systemd/network/98-default.link [Match] Driver=bonding bridge

[Link] MACAddressPolicy=none