Bug 489398

Hmm, can you grab the bits of /var/log/messages that contain "NetworkManager" that show NM starting up and trying to establish a connection?  Something like the following executed in a terminal:

sudo cat /var/log/messages | grep > ~/Desktop/nm-log.txt

should put a file called "nm-log.txt" on your desktop that contains the relevant information.

Created attachment 334573 [details]
NetworkManager does not connect automatically

Created attachment 334574 [details]
NetworkManager connects automatically again after changing network settings

OK, attached two files, one in the broken state and one after I made the
following change:

In the meantime I figured out that going to "System >> Administration >> Network" and selecting "[x] Activate device when computer starts" and "[x] Allow all users to enable and disable the device" gets the old behaviour back.

I don't know why these options were unchecked, but this F10 installation is pretty new and I am sure I never changed any network settings, since DHCP worked out of the box.

The log file entries in both cases are identical, apart from the 1 minute
delay before "Activation (eth0) starting connection 'System eth0'" at 20:57:07 in the 1st case (this is when I manually activated the connection).

I am also having this problem with the new update.

Same here. I just ran today's updates, rebooted, and NetworkManager was broken. When the machine came back up I had no network connection. The only way I can get back online after a reboot now is to click the network manager icon on the upper right and select "System eth0". Any chance we can go back to the old behavior where it connects automatically? 

I'm running:

NetworkManager-0.7.0.99-3.fc10.i386

-3 should fix the issue; can you attach your /etc/sysconfig/network-scripts/ifcfg-eth0 if you have problems with -3?

I can ack the problem, and the problem is _NOT_ solved with -3.

# tail -n 500 /var/log/messages | grep NetworkManager | cut -c 27-
NetworkManager: <info>  starting...
NetworkManager: <WARN>  nm_generic_enable_loopback(): error -17 returned from rtnl_addr_add():#012Sucess#012
NetworkManager: <info>  (eth0): new Ethernet device (driver: 'e1000e')
NetworkManager: <info>  (eth0): exported as /org/freedesktop/Hal/devices/net_00_0f_fe_db_5c_c0
NetworkManager: <info>  Trying to start the supplicant...
NetworkManager: <info>  Trying to start the system settings daemon...
nm-system-settings: Loaded plugin ifcfg-rh: (c) 2007 - 2008 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
NetworkManager: <info>  (eth0): device state change: 1 -> 2
NetworkManager: <info>  (eth0): bringing up device.
NetworkManager: <info>  (eth0): preparing device.
NetworkManager: <info>  (eth0): deactivating device (reason: 2).
NetworkManager: <info>  (eth0): carrier now ON (device state 2)
NetworkManager: <info>  (eth0): device state change: 2 -> 3
# rpm -qi NetworkManager | grep -i version
Version     : 0.7.0.99                          Vendor: Fedora Project
# rpm -qi NetworkManager | grep -i releas
Release     : 3.fc10                        Build Date: Die 10 Mär 2009 04:43:26 CET

At least not solved w/o manual changes. I'm getting the iface up with dhclient eth0. Problem first seen on Monday (on two independent workstations / hw)

(In reply to comment #8)
> I can ack the problem, and the problem is _NOT_ solved with -3.

Please attach your /etc/sysconfig/network-scripts/ifcfg-eth0 file then...

ONBOOT=no...
looks like the problem. But as I said, it worked last week (didn't changed any configs). Thats the (default)-cfg of the 4month old F10 Installation.

--snip--
# Intel Corporation 82566DM-2 Gigabit Network Connection
DEVICE=eth0
HWADDR=00:0f:fe:db:5c:c0
ONBOOT=no
--snap--

(In reply to comment #10)
> ONBOOT=no...
> looks like the problem. But as I said, it worked last week (didn't changed any
> configs). Thats the (default)-cfg of the 4month old F10 Installation.
> 
> --snip--
> # Intel Corporation 82566DM-2 Gigabit Network Connection
> DEVICE=eth0
> HWADDR=00:0f:fe:db:5c:c0
> ONBOOT=no
> --snap--  

It was actually a bug that ONBOOT=no *wasn't* respected.  That bug has been fixed...

I think this is actually a fairly serious bug, that ought to be fixed before too many people update. It could be really confusing to some users that "Firefox stopped working" and they can't even use google to find the solution, and they can't receive any more updates unless they notice the icon with the red warning symbol and click on it in the right way.

Most people won't have ONBOOT in their config, however.  Anaconda writes out a minimal device file with just DEVICE and HWADDR on install, and does not write out ONBOOT.

Here's my ifcfg-eth0 file:

# nVidia Corporation MCP61 Ethernet
DEVICE=eth0
HWADDR=00:1a:a0:4e:b1:0e
ONBOOT=no
SEARCH="ncc.com"


Hmmm... I have a standard Fedora 10 install. I didn't do anything unusual and I'm sure I didn't manually edit a config file and remove an "ONBOOT" directive. I just installed Fedroa 10 on an off the shelf Dell machine and the installer did whatever it did. All the previous versions of Fedora I've used on the machine connected to the network automatically and this version of Fedora connected to the network automatically up until the recent Network Manager update, so I have trouble not thinking of this as a bug. If it's not a Network Manager bug, maybe it's a bug with whatever program (the installer?) failed to add (or removed) the ONBOOT directive?

The fact that SEARCH="ncc.com" is there means its not just a stock anaconda install AFAICT.

Anaconda in F-10 will only set ONBOOT=no for interfaces that are not used as the installation interface.  Since anaconda doesn't do install-over-wifi, that means at least one of your ifcfg files should have ONBOOT=yes.

The livecd should be writing out files without ONBOOT at all, which means ONBOOT=yes.

problem still present. afaict it's a clean f10 install (_maybe_ coming from preview?)

$ rpm -q NetworkManager
NetworkManager-0.7.0.99-3.fc10.i386

$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
HWADDR=00:0d:87:64:08:da
ONBOOT=no

Doesn't Anaconda set SEARCH= line based on the FQDN set by the user during the install dialogs?

As a test of the ONBOOT issue, I just ran updates to Fedora 10 on my Dell Inspiron Laptop this morning and the same thing happened, Network Manager no longer connects automatically after a boot. Here are the ifcfg-eth files from my laptop:

# Broadcom Corporation BCM4401 100Base-T
Device=eth0
HWADDR=00:12:3f:d7:26:1a
ONBOOT=no

# Intel Corporation PRO/Wireless 2200BG Network Connection
Device=eth1
HWADDR=00:0e:35:c8:f8:2b
ONBOOT=no

My laptop includes both a hardwired ethernet port and a wifi card, so it makes sense to me that NetworkManager would set all the onboots to no and then figure out dynamically which one to use based on availability. So I'm still suspicious that it's NetworkManager messing with the ONBOOT setting.

As with my desktop, I'm 100% certain that I've never manually edited the files and set ONBOOT to no. So it seems there is still some sort of breakage going on here. If it's user error during the install, I'm not certain what it could be as both installations were done pretty much the same as I've always installed Fedora. I don't recall any point in the install being offered an option that could be even remotely interpreted as "don't connect to the network at bootup".

Did you do the initial install from a DVD, netboot, or livecd?

Note that NM has never had write support for ifcfg files, so either the ONBOOT=no was there to begin with, or was added later on by system-config-network or you.  If you used the DVD install, it could have been anaconda.

*** Bug 489739 has been marked as a duplicate of this bug. ***

I installed from the DVD image on both the laptop and desktop box. I still have the DVD lying around somewhere if there's a version number or something on it that would help.

I have exactly the same issue. I already reported it here:
http://bugzilla.gnome.org/show_bug.cgi?id=574803

Just want to add something more:
----------------------------------------------------------------------------------
[username@hostname ~]$ ll /etc/sysconfig/network-scripts/ifcfg-eth0 
-rw-r--r-- 3 root root 124 2008-11-28 03:26 /etc/sysconfig/network-scripts/ifcfg-eth0
[username@hostname ~]$

[username@hostname ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Intel Corporation 82562EZ 10/100 Ethernet Controller
DEVICE=eth0
HWADDR=00:20:ed:7e:83:ea
ONBOOT=no
SEARCH="example.com"
[username@boyan7640 ~]$ 

[root@hostname ~]# ll
total 60
-rw------- 1 root root  1265 2008-11-28 03:26 anaconda-ks.cfg
-rw-r--r-- 1 root root 45475 2008-11-28 03:26 install.log
-rw-r--r-- 1 root root  4754 2008-11-28 03:25 install.log.syslog
[root@hostname ~]# 
----------------------------------------------------------------------------------

Look at the modified date of the file: 2008-11-28 - from last year. I updated NetworkManager twice - yesterday (11 March 2009) to 0.7.0.99-3 and the day before yesterday (10 March 2009) to 0.7.0.99-1. The eth0 NIC config file was not modified after the Fedora 10 installation.

So, as I understood ONBOOT should be set to "yes" to fix the issue:
ONBOOT=yes

Let me try...

Yes, I can confirm that it (ONBOOT=yes) solved the issue on my PC.

Best Regards,
Boyan Boychev

ONBOOT=yes fixed my desktop box but I'm unsure how to set up my laptop. 

Do I add the ONBOOT=yes to both the eth0 hardwired ethernet and eth1 wifi ? I don't want to get in a situation where Fedora spits out a bunch error messages during bootup saying it can't connect to this it or that port depending on whether there's an ethernet cable plugged in or a wifi network present. I'd like to have NetworkManager continue to figure that stuff out after the bootup. 

I don't suppose we could create an option like ONBOOT=NetworkManger or something that would delay the decision until after bootup but still connect automatically? Essentially what the ONBOOT=no setting used to do until this bug, er, I mean fix was added :)

According to Dan Williams's comment 11 (https://bugzilla.redhat.com/show_bug.cgi?id=489398#c11) it is not a bug but normal behaviour with the new
version.

I cannot be sure regarding the Wireless NIC behaviour and ONBOOT option because I don't have Wireless NIC.

Best Regards,
Boyan Boychev

*** Bug 489844 has been marked as a duplicate of this bug. ***

*** Bug 489735 has been marked as a duplicate of this bug. ***

This bug has been triaged.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Have you tried removing eth0 completely using system-config-network?
I have a box with the same disturbing effect for eth0.

But, if I boot the same system (which is on an external disk) on a different box then the new network card is configured dynamically as eth1 (different mac address), and NM activates the interface automatically, just like it did for eth0 last week.

I haven't removed my eth0 yet, but comments here seem to imply that this is considered a feature, so I guess this is the only solution.

Common sense would tell me:
ONBOOT=no: Don't activate at boot-up
NM-Managed: Allow NM to manage it once NM runs, including activating it automatically.

But that's not what's happening. Maybe it's the NM-managed setting that's not observed any more?

>> Have you tried removing eth0 completely using 
>> system-config-network? I have a box with the same
>> disturbing effect for eth0.

No, but part of what I think is a bug here is that the average user shouldn't have to be doing this sort of stuff at all. On previous versions of Fedora NeworkManager was able to get my box connected an Ethernet or WiFi automatically without me having to edit config files. Sure, I could edit that stuff myself but the average user isn't going to think of doing that. To them, it's going to look broken because it no longer connects automatically. 

In fact, I sort of thought that was the whole point of creating NetworkManager. I could get online by editing config files, typing "network restart", or changing the ONBOOT stuff before NetworkManager existed. What made NetworkManager so cool was that it did all that stuff automatically and made getting online easy enough that the average user could do it.

(In reply to comment #30)
> >> Have you tried removing eth0 completely using 
> >> system-config-network? I have a box with the same
> >> disturbing effect for eth0.
> 
> No, but part of what I think is a bug here is that the average user shouldn't
> have to be doing this sort of stuff at all. On previous versions of Fedora

Sure. What I meant was: There may be other possible ways to resolve this bug. Either restore the previous behaviour, which (according to #11) would amount to restoring to a buggy state. Or remove those devices which should be NM managed altogether. That sounds like a nightmare to implement safely. Or restore the function of the "NM managed" setting, which seems to be broken now, at least the interplay between NM managed and booton.

Michael

I'm going to revert the "fix" for F9 & F10 and treat ONBOOT as 'yes' when the ifcfg file only contains DEVICE and HWADDR.  F11/rawhide will continue to have the correct behavior.  We'll have to figure something out in the installer for the live-dvd case so that your network comes up by default after a DVD install.

>> figure something out in the installer for the live-dvd case 

Are there multiple Fedora DVDs? I didn't think the one I installed was a live DVD. I used bittorrent to retrieve the one called Fedora-10-i386-DVD. Maybe that's the same thing? I didn't try running it live from the DVD, I just installed it.

No, there aren't multiple dvds.  I mis-spoke.  There's only one official install DVD.

The issue is that anaconda (the installer) will only set ONBOOT=yes for a network device that *was used to download packages* when you're installing over the network using boot.iso or PXE.  Thus, DVD installs may have ONBOOT set to no.

(In reply to comment #32)
> I'm going to revert the "fix" for F9 & F10 and treat ONBOOT as 'yes' when the
> ifcfg file only contains DEVICE and HWADDR.  F11/rawhide will continue to have
> the correct behavior.  We'll have to figure something out in the installer for
> the live-dvd case so that your network comes up by default after a DVD install.  

I'm sorry but I don't think that will help much. Unless people installed over the net all network devices will have been marked ONBOOT=no by anaconda. If only the default (with ONBOOT unset) changes then this doesn't help the majority of users (who install from DVD or CD).

I still think the real issue is not ONBOOT. Noone here seems to want their device on on boot. The issue is whether NM brings up a wired connection automatically after login when a device

- is marked or defaulted to ONBOOT=no
and
- NM is allowed to manage the device.

In fact, ONBOOT should influence *only* the behaviour during boot, not after login when NM takes over. Or am I misreading the meaning of ONBOOT?

Michael

When I changed in /etc/sysconfig/network-scripts/ifcfg-eth0 value ONBOOT=no to ONBOOT=yes, then NM have same behavior as before update. I don't know, which value was ONBOOT before update of NM, but I think that last two updates of NM broke correct behavior NM.

> In fact, ONBOOT should influence *only* the behaviour during boot,
> not after login when NM takes over. Or am I misreading the meaning
> of ONBOOT?

I agree completely. The principle of least surprise seems to suggest that a value called "ONBOOT" would affect what happens to the network connection when the computer boots and NOT affect what NetworkManager does after the computer is running.

(In reply to comment #37)
> > In fact, ONBOOT should influence *only* the behaviour during boot,
> > not after login when NM takes over. Or am I misreading the meaning
> > of ONBOOT?
> 
> I agree completely. The principle of least surprise seems to suggest that a
> value called "ONBOOT" would affect what happens to the network connection when
> the computer boots and NOT affect what NetworkManager does after the computer
> is running.  

The traditional 'network' service had no way to re-activate a connection when it went down, and required user intervention to re-establish a network connection.  Thus, the traditional 'network' service had no possible way to implement autoconnection.  It did, however, automatically connect devices marked ONBOOT=yes at bootup, when it actually runs automatically.

NetworkManager actively manages the network connections in a way that the static network scripts can't.  Thus it treats ONBOOT as the flag for "connect automatically".

In what situations would you want your network connection to come up at boot time automatically, but not at other times automatically?  It seems like "I want it up on boot but after that if it goes down I want to manually re-activate it" is kind of a pointless behavior...

(In reply to comment #38)
> (In reply to comment #37)
> > > In fact, ONBOOT should influence *only* the behaviour during boot,
> > > not after login when NM takes over. Or am I misreading the meaning
> > > of ONBOOT?
> > 
> > I agree completely. The principle of least surprise seems to suggest that a
> > value called "ONBOOT" would affect what happens to the network connection when
> > the computer boots and NOT affect what NetworkManager does after the computer
> > is running.  
> 
> The traditional 'network' service had no way to re-activate a connection when
> it went down, and required user intervention to re-establish a network
> connection.  Thus, the traditional 'network' service had no possible way to
> implement autoconnection.  It did, however, automatically connect devices
> marked ONBOOT=yes at bootup, when it actually runs automatically.
> 
> NetworkManager actively manages the network connections in a way that the
> static network scripts can't.  Thus it treats ONBOOT as the flag for "connect
> automatically".
> 
> In what situations would you want your network connection to come up at boot
> time automatically, but not at other times automatically?  It seems like "I
> want it up on boot but after that if it goes down I want to manually
> re-activate it" is kind of a pointless behavior...  

Hmm, how do I achieve the following then:

- leave eth0 alone on boot
- have NM acticate it after logon

The point is that the typical notebook user will switch between eth and wifi, and NM handles this nicely: activate eth when a connection is available, trying wifi otherwise. There's no point in trying eth on boot in this situation.

I can work around, no problem, but the main issue is still breaking existing default F9 and F10 installations by the update.

NM *won't* activate your eth0 on boot if ONBOOT=yes and there's no cable plugged in.  Do you by any chance have the 'network' service enabled?

/sbin/chkconfig --list | grep network

if there's an "on" in that list, then you've got the traditional 'network' service on.  You don't need it on.  So do:

/sbin/chkconfig network off

and you should be fine.

i think the way it should be is like this:

if onboot=yes then
nm should try to activate iterface onboot asap.
this way, the servers should be fine with nm.

after user login, the applet may allow the user to change networks etc.

if onboot=no then
nm should ignore the interface and try to connect after login.

if after login there are more networks available,
either choose the default network (if there is a default network) or ask user what networks he wants to connect to.

of course, if there are static configs for interfaces, they shopuld be used. else ,try dhcp. if it fails, ask user if he wants to configure static ...

is there a scenario forgoten?

(In reply to comment #41)
> i think the way it should be is like this:
> 
> if onboot=yes then
> nm should try to activate iterface onboot asap.
> this way, the servers should be fine with nm.

Yes, this is how NM will currently work.

> after user login, the applet may allow the user to change networks etc.

Also how NM currently works.

> if onboot=no then
> nm should ignore the interface and try to connect after login.

Currently, if ONBOOT=no, the user needs to manually activate the connection.  I don't see how before/after login makes sense here; you can log out and log back in long after bootup.  Hence why ONBOOT gets mapped to autoconnect.

> if after login there are more networks available,
> either choose the default network (if there is a default network) or ask user
> what networks he wants to connect to.

NM shouldn't really be asking the user what to connect to; that's pretty intrusive.  NM has enough information to automatically try the last-connected autoconnect network, which is what it currently does.

> of course, if there are static configs for interfaces, they shopuld be used.
> else ,try dhcp. if it fails, ask user if he wants to configure static ...

NM will select the last-used available network, and try that.  If that fails, NM will then use the next-last-used network, and  so on down the list of used networks until they have all failed.

NetworkManager-0.7.0.99-4.git20090324.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.99-4.git20090324.fc10

NetworkManager-0.7.0.99-4.git20090324.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.99-4.git20090324.fc9

NetworkManager-0.7.0.99-4.git20090324.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

NetworkManager-0.7.0.99-5.git20090326.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.99-5.git20090326.fc9

NetworkManager-0.7.0.100-2.git20090408.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.100-2.git20090408.fc9

NetworkManager-0.7.1-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.1-1.fc9

NetworkManager-0.7.1-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.