Could not generate persistent MAC address for vethXXXXX: No such file or directory

Question

I'm starting to use CoreOS (on AWS ECS). After having it launch my first container, I see this in journalctl:

Could not generate persistent MAC address for vethXXXX: No such file or directory

Here's more context. I've removed the time and instance information, but this is all within the same second. Note there are two distinct veth entries. I don't know if that means anything.

systemd[1]: Started docker container 1234
systemd[1]: Starting docker container 1234
dockerd[595]: time="2015-07-23T23:30:52Z" level=info msg="GET /v1.17/containers/1234/json"
dockerd[595]: time="2015-07-23T23:30:52Z" level=info msg="+job container_inspect(1234)"
systemd-timesyncd[473]: Network configuration changed, trying to establish connection.systemd-udevd[7501]: Could not generate persistent MAC address for vethYYYY: No such file or directory
kernel: device vethXXXX entered promiscuous mode
kernel: IPv6: ADDRCONF(NETDEV_UP): vethXXXX: link is not ready
systemd-udevd[7508]: Could not generate persistent MAC address for vethXXXX: No such file or directory
systemd-networkd[497]: vethXXXX: Configured
kernel: eth0: renamed from vethYYYY
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethXXXX: link becomes ready
kernel: docker0: port 2(vethXXXX) entered forwarding state
kernel: docker0: port 2(vethXXXX) entered forwarding state
systemd-networkd[497]: vethXXXX: Gained carrier

I found a discussion of this error on Ubuntu and it comes down to removing a udev rule, which doesn't seem to exist on CoreOS. There's a discussion about iptables with OpenVPN, which again doesn't seem to apply. Here's a bridge rule for LXC on Ubuntu. Again, I don't see how to apply that.

I haven't done anything with the networkd or flannel configuration. If the problems are in that area, I need specific steps on how to fix it for use in AWS ECS.

Ladd

Why do you need a persistent mac address on an ephemeral resource (a Docker container)? – Schlegel

I don't need a persistent mac. It's a scary error though. – Ladd

Have you had a chance to find a solution for this problem? I am having the same one with the latest update of lxd – Yancey

Seems to be a bug in systemd: github.com/systemd/systemd/issues/3374 – Lasalle

Did you ever figure out the fix to this? – Ranice

Answer 1

I had similar issue with a systemd service which creates a dev, then I figured out service type was "simple" fixed by changing this to "forking" (Type=forking)

Superposition

whose name has this systemd service ? – Brisling

Answer 2

I found this problem at own ubuntu 18.4 at 2021 year.

Problem was: /etc/docker/daemon.json { "iptables" : false }

after changing to { "iptables" : true } and restart docker - no more problems.

Mystique