Hi,
Thank you for taking the time to report this bug and helping to make Ubuntu better.
From the log:
Mac 30 17:21:18 hostname systemd-udevd[31581]: Could not generate persistent MAC address for docker0: No such file or directory
Mac 30 17:21:18 hostname kernel: aufs au_opts_verify:1597:dockerd[31512]: dirperm1 breaks the protection by the permission bits on the lower branch
Mac 30 17:22:51 hostname systemd-udevd[31804]: Could not generate persistent MAC address for veth9093749: No such file or directory
Mac 30 17:22:51 hostname NetworkManager[988]: <warn> [1490865771.6892] device (veth64ee632): failed to find device 5 'veth64ee632' with udev
Mac 30 17:22:51 hostname systemd-udevd[31803]: Could not generate persistent MAC address for veth64ee632: No such file or directory
Mac 30 17:22:51 hostname NetworkManager[988]: <warn> [1490865771.6907] device (veth9093749): failed to find device 6 'veth9093749' with udev
Mac 30 17:22:52 hostname NetworkManager[988]: <warn> [1490865772.4113] device (veth64ee632): failed to find device 5 'veth64ee632' with udev
Mac 30 17:49:14 hostname systemd[1]: Failed to start Docker Application Container Engine.
Mac 30 17:49:14 hostname systemd[1]: docker.service: Failed with result 'exit-code'.
So the reason it fails is since it can't restart docker for the errors above.
Do the docker containters work before the update?
If so what is the output of:
$ systemctl status docker
$ systemctl status <docker-app-name>.service -l
Given the history on similar bugs it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete for now.
Or if you believe that this is really a bug, please provide the requested extra info as good as possible and set the status back to "new".
On top please share your docker configuration. Since the issue I found seems to depend on the device type you bridge to these are especially important.
Hi,
Thank you for taking the time to report this bug and helping to make Ubuntu better.
From the log: udevd[31581] : Could not generate persistent MAC address for docker0: No such file or directory verify: 1597:dockerd[ 31512]: dirperm1 breaks the protection by the permission bits on the lower branch udevd[31804] : Could not generate persistent MAC address for veth9093749: No such file or directory 988]: <warn> [1490865771.6892] device (veth64ee632): failed to find device 5 'veth64ee632' with udev udevd[31803] : Could not generate persistent MAC address for veth64ee632: No such file or directory 988]: <warn> [1490865771.6907] device (veth9093749): failed to find device 6 'veth9093749' with udev 988]: <warn> [1490865772.4113] device (veth64ee632): failed to find device 5 'veth64ee632' with udev
Mac 30 17:21:18 hostname systemd-
Mac 30 17:21:18 hostname kernel: aufs au_opts_
Mac 30 17:22:51 hostname systemd-
Mac 30 17:22:51 hostname NetworkManager[
Mac 30 17:22:51 hostname systemd-
Mac 30 17:22:51 hostname NetworkManager[
Mac 30 17:22:52 hostname NetworkManager[
Mac 30 17:49:14 hostname systemd[1]: Failed to start Docker Application Container Engine.
Mac 30 17:49:14 hostname systemd[1]: docker.service: Failed with result 'exit-code'.
So the reason it fails is since it can't restart docker for the errors above.
I'm not the biggest docker expert, but I looked a bit around. /github. com/systemd/ systemd/ issues/ 3374
AFAIK the aufs message is ugly but expected, but on the second one I found https:/
Do the docker containters work before the update? app-name> .service -l
If so what is the output of:
$ systemctl status docker
$ systemctl status <docker-
Given the history on similar bugs it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete for now.
Or if you believe that this is really a bug, please provide the requested extra info as good as possible and set the status back to "new".
On top please share your docker configuration. Since the issue I found seems to depend on the device type you bridge to these are especially important.