After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660454 - NetworkManager creates ifcfg scripts for auto wireless networks as "ONBOOT=yes"
NetworkManager creates ifcfg scripts for auto wireless networks as "ONBOOT=yes"
Status: RESOLVED WONTFIX
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2011-09-29 12:09 UTC by Paolo Bonzini
Modified: 2012-07-25 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to add NM_AUTOCONNECT and instead force ONBOOT=no for wireless networks (7.78 KB, patch)
2011-09-29 12:09 UTC, Paolo Bonzini
none Details | Review

Description Paolo Bonzini 2011-09-29 12:09:22 UTC
Created attachment 197748 [details] [review]
patch to add NM_AUTOCONNECT and instead force ONBOOT=no for wireless networks

When you click on a network in nm-applet, the profile is created with ONBOOT=yes, so it can be activated automatically nexttime.  While this requires user interaction (apart from bug 650494), the profiles created this way are absolutely useless at boot time:

- some of them may be protected, some of them may be for airports or cafeterias where I go once a year---I'm definitely okay with NM trying to reconnect to them, but _not_ with wasting 3 seconds of boot time on those.

- in all likelihood the wireless card hasn't even finished scanning at the time /etc/init.d/network runs

The attached patch adds a new item NM_AUTOCONNECT and, for wireless connections, tries to keep ONBOOT=no.  For wired connections NM_AUTOCONNECT and ONBOOT will be the same, but it is still possible for the user to manually override one or the other.
Comment 1 Dan Williams 2011-10-12 23:53:35 UTC
I don't think we want to do this, because it's a pretty big behavior change.  I also think we can deal with the problem in a different way.  One thing you can do is to "chkconfig network off" so that the old network service doesn't attempt to start these connections.  In the end, this is more an issue with the startup system instead of what things are set up to start automatically and which aren't.  We should explore those first.
Comment 2 Paolo Bonzini 2011-10-13 07:48:00 UTC
Yeah, disabling the network service is what I'm doing now.  However, I can do that only because my configuration is simple.  If for example I wanted to have a bridge on eth0, I would need to use NM for wireless and /etc/init.d/network for wired.

However, I disagree that it's a big behavior change.  For wired networks there is no change without manual override from the user; for wireless networks the change is really fixing bugs. :)  Of course, it's possible that it is a bug in the network service, and that /etc/init.d/network simply shouldn't honor ONBOOT at all for wireless.
Comment 3 Pavel Simerda 2012-07-25 14:22:25 UTC
I mostly agree with Paolo but... it's been some time and currently NetworkManager doesn't head for continuous compatibility with network-scripts but to replace them and provide all the features of network-scripts.

“and that /etc/init.d/network simply shouldn't honor ONBOOT
at all for wireless.”

This is out of NetworkManager's scope and but would fix the problem.

Hopefully we're checking in bridging support soon.