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
signature.asc
Description: PGP signature
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
