Re: No more IPv4 address after boot up since NM 0.9.10

[Pavel Simerda <psimerda redhat com>]

----- Original Message -----
> From: "Thomas Haller" <thaller redhat com>
> To: "Harald Dunkel" <harald dunkel aixigo de>
> Cc: "networkmanager." <networkmanager-list gnome org>, "Pavel Simerda" <psimerda redhat com>
> Sent: Thursday, March 12, 2015 11:54:49 AM
> Subject: Re: No more IPv4 address after boot up since NM 0.9.10
>
> On Thu, 2015-03-12 at 10:32 +0100, Harald Dunkel wrote:
> > On Wed, 04 Mar 2015 18:15:43 +0100
> > Frederik Himpe <frederik frehi be> wrote:
> >
> > > I still think that NM's behaviour not to touch the interface when it's
> > > up already is counter-intuitive. If I start up NM with a configuration
> > > for eth0, then I _do_ want this configuration to be applied, just like
> > > the distro specific init networking scripts would do. If you don't want
> > > NM to touch an existing interface, then it makes more sense to me to
> > > completely disable NM, or to set this specific interface unmanaged in
> > > NM.
> > >
> > > Maybe this behaviour should be configurable?
> >
> > I am affected by exactly the same problem, and I completely agree
> > with Frederik. Some improvement here would be highly appreciated.
>
>
> ok, but what is the concrete suggestion?
>
>
> How about adding a autoconnect-boot argument to a connection.

What about my original suggestion of "onboot" as a separate option
from "auto"[1] plus a new behavior that "onboot" connections would
be enforced even if the device is already configured?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=700651

That would IMO make sense and would solve other issues like
auto connections blocking the boot process when not desired. Ah,
I see you mentioned it down in the e-mail.

Chees,

Pavel

> When NM
> starts and an interface is unconfigured it would do the usual
> autoconnect behavior.
>
> If the interface is already configured, during startup only,
> NetworkManager would consider
>   (autoconnect==TRUE && autoconnect-boot==TRUE)
> connections and forcefully activate them.
>
>
> I remember some discussion about supporting splitting the meaning of
> autoconnect into a autoconnect and on-boot. I am unable to find the
> bug/email now (CC Pavel).
>
>
> Thomas