systemd warning on logs

[juniper]

Hi,

every time i migrate or restart a VM i see in logs:

Oct 30 07:16:31 *****srv1 systemd-udevd[33305]: Could not generate persistent MAC address for tap107i0: No such file or directory

Oct 30 07:15:53 *****srv1 systemd-udevd[32939]: Could not generate persistent MAC address for tap104i0: No such file or directory

i think because MACAddressPolicy=persistent does not really make sense for "virtual devices"

probably is better set MACAddressPolicy=none?

Someone with the same warning?

 

[fabian]

long-standing systemd bug, but can be safely ignored:
https://github.com/systemd/systemd/issues/3374

 

[hvisage]

Yes, I think that's not the only one outstanding that's a pain for people, but then I like Poetring's answer: "We prioritize differently"...

 

[wbumiller]

You can, however, get rid of it by adding an /etc/systemd/network/XY-default.link (XY being a number < 99 and > your own (if you have any) with:

[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=none

 

[hvisage]

You can, however, get rid of it by adding an /etc/systemd/network/XY-default.link

May I ask why this isn't a default in ProxMox?

 

[Rhinox]

May I ask why this isn't a default in ProxMox?

Probably because it is not fix, just workaround...

 

[djace]

You can, however, get rid of it by adding an /etc/systemd/network/XY-default.link (XY being a number < 99 and > your own (if you have any) with:

[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=none

Sorry to dig up an old thread, but I've noticed that this issue (which I remember fixing some time ago by reading this thread), reappeared and this workaround no longer works.

By reading around I understand that is actually a non-issue, since it is simply the result of a race condition trying to set a persisent MAC on devices that disappear. In any case, it is still not ideal because it clutters the syslog unnecessarily.

On my install of proxmox 6.1 with kernel 5.3.13, tested with an Ubuntu 16.04 and 18.04 LTS LXC containers, and both of them generate similar error messages. Is there any new workaround that can be applied?

Feb  2 12:41:39 proxmox systemd-udevd[14700]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb  2 12:41:39 proxmox systemd-udevd[14700]: Using default interface naming scheme 'v240'.
Feb  2 12:41:39 proxmox systemd-udevd[14700]: Could not generate persistent MAC address for vethTC744K: No such file or directory
Feb  2 12:41:39 proxmox systemd-udevd[14724]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb  2 12:41:39 proxmox systemd-udevd[14724]: Using default interface naming scheme 'v240'.
Feb  2 12:41:40 proxmox systemd-udevd[14700]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb  2 12:41:40 proxmox systemd-udevd[14700]: Could not generate persistent MAC address for fwbr114i0: No such file or directory
Feb  2 12:41:40 proxmox systemd-udevd[14724]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb  2 12:41:40 proxmox systemd-udevd[14724]: Could not generate persistent MAC address for fwpr114p0: No such file or directory
Feb  2 12:41:40 proxmox systemd-udevd[14725]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb  2 12:41:40 proxmox systemd-udevd[14725]: Using default interface naming scheme 'v240'.
Feb  2 12:41:40 proxmox systemd-udevd[14725]: Could not generate persistent MAC address for fwln114i0: No such file or directory
Feb  2 12:41:40 proxmox kernel: [2837705.444902] fwbr114i0: port 1(fwln114i0) entered disabled state
Feb  2 12:41:40 proxmox kernel: [2837705.445230] fwbr114i0: port 1(fwln114i0) entered blocking state
Feb  2 12:41:40 proxmox kernel: [2837705.460741] fwbr114i0: port 2(veth114i0) entered blocking state
Feb  2 12:41:40 proxmox kernel: [2837705.460877] device veth114i0 entered promiscuous mode