On Tue, Sep 26, 2017 at 04:04:38PM +0200, Ulrich Ölmann wrote:
On Tue, Sep 26, 2017 at 03:23:15PM +0200, Beniamino Galvani wrote:On Tue, Sep 26, 2017 at 09:36:44AM +0200, Ulrich Ölmann wrote:[...] It looks like NetworkManager does not create the devices in the correct order in contrast to what has been done manually before restarting NetworkManager. This behaviour is only seen if the parent is referenced via a UUID. Using an interface name instead ("parent=eth1"), everything is fine.Hi, as it is currently implemented, "parent=$UUID" in the connection file means that the parent device will be the device on which connection $UUID is currently active or, if none, any device compatibile with $UUID; there isn't any sort of temporal dependency implied by the property.Ah, okay. I implicitely assumed that NetworkManager applies some ordering with respect to device creation by this property - thanks for clarifying this.Since connection 7ac61f21-bf59-4c4c-ae38-51ce131b2afc does not specify an interface name, at startup NM can match it with any interface and chooses the wrong (unmanaged) one. This is a bug and should be easy to fix, as in the patch below.I applied your patch and NetworkManager avoids the unmanaged device eth0 to instead create the virtual MAC VLAN device on top of eth1 now. Great! :-) Looking into the journal, however, I still see a warning saying manager: (link-local) can't register the device with manager: A device with ifindex 10 already exists Do we have to expect any side-effects because of this?
This is a bug, however it should be harmless. I'll post some patches to fix this. Thanks for the detailed bug report. Beniamino
Attachment:
signature.asc
Description: PGP signature