Bug 442947 - static wired eth0 disabled on boot when NM starts
static wired eth0 disabled on boot when NM starts
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-17 15:17 EDT by Thomas J. Baker
Modified: 2008-04-25 04:34 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-23 15:52:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas J. Baker 2008-04-17 15:17:22 EDT
NetworkManager-0.7.0-0.9.2.svn3566.fc9 stops my static wired eth0 on boot when
NetworkManager itself starts. This has been happening for about a week, not sure
how many NM updates between then and now, but previous to that is has worked
fine, once I got the ifcfg-eth0 set up correctly. (See
https://bugzilla.redhat.com/show_bug.cgi?id=134886).

It doesn't seem to be a problem with the ifcfg-eth0 file because all I need to
do is restart NetworkManager and things are fine.

Pertinent parts of the syslog follow. Here, NM starts, reads and parses ifcfg
files and chooses to stop eth0, even though it was running and is set to onboot=yes:

Apr 17 15:04:59 katratzi NetworkManager: <info>  starting...
Apr 17 15:04:59 katratzi NetworkManager: <info>  Trying to start the supplicant...
Apr 17 15:04:59 katratzi NetworkManager: <info>  eth0: Device is fully-supported
using driver 'e1000'.
Apr 17 15:04:59 katratzi NetworkManager: <info>  Found new Ethernet device 'eth0'.
Apr 17 15:04:59 katratzi NetworkManager: <info>  (eth0): exported as
/org/freedesktop/Hal/devices/net_00_08_74_4f_75_2e
Apr 17 15:04:59 katratzi NetworkManager: <info>  Trying to start the system
settings daemon...
Apr 17 15:04:59 katratzi kernel: [drm] nouveau_fifo_free: freeing fifo 1
Apr 17 15:04:59 katratzi kernel: [drm] nouveau_fifo_free: freeing fifo 0
Apr 17 15:04:59 katratzi nm-system-settings: Loaded plugins:
Apr 17 15:04:59 katratzi nm-system-settings:    ifcfg-fedora: (c) 2007 - 2008
Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Apr 17 15:04:59 katratzi nm-system-settings:    ifcfg-fedora: parsing
/etc/sysconfig/network-scripts/ifcfg-lo ... 
Apr 17 15:04:59 katratzi nm-system-settings:    ifcfg-fedora:     error:
Ignoring loopback device config.
Apr 17 15:04:59 katratzi nm-system-settings:    ifcfg-fedora: parsing
/etc/sysconfig/network-scripts/ifcfg-eth0 ... 
Apr 17 15:04:59 katratzi nm-system-settings:    ifcfg-fedora:     read
connection 'System eth0'
Apr 17 15:05:00 katratzi acpid: client connected from 2705[0:0]
Apr 17 15:05:00 katratzi kernel: agpgart: Found an AGP 3.0 compliant device at
0000:00:00.0.
Apr 17 15:05:00 katratzi kernel: agpgart: Device is in legacy mode, falling back
to 2.x
Apr 17 15:05:00 katratzi kernel: agpgart: Putting AGP V2 device at 0000:00:00.0
into 4x mode
Apr 17 15:05:00 katratzi kernel: agpgart: Putting AGP V2 device at 0000:01:00.0
into 4x mode
Apr 17 15:05:01 katratzi kernel: [drm] Allocating FIFO number 0
Apr 17 15:05:01 katratzi kernel: [drm] nouveau_fifo_alloc: initialised FIFO 0
Apr 17 15:05:01 katratzi kernel: [drm] Allocating FIFO number 1
Apr 17 15:05:01 katratzi kernel: [drm] nouveau_fifo_alloc: initialised FIFO 1
Apr 17 15:05:03 katratzi gconfd (gdm-2761): starting (version 2.22.0), pid 2761
user 'gdm'
Apr 17 15:05:03 katratzi NetworkManager: <info>  Deactivating device eth0.
Apr 17 15:05:03 katratzi avahi-daemon[2454]: Withdrawing address record for
132.177.241.101 on eth0.
Apr 17 15:05:03 katratzi avahi-daemon[2454]: Leaving mDNS multicast group on
interface eth0.IPv4 with address 132.177.241.101.
Apr 17 15:05:03 katratzi avahi-daemon[2454]: Interface eth0.IPv4 no longer
relevant for mDNS.

After logging in, I open a terminal and restart NM. Here's the log of that:

Apr 17 15:06:23 katratzi tjb: Restarting NM now....
Apr 17 15:06:26 katratzi Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to
connect to server: unknown error for: raptor.sr.unh.edu:24800
Apr 17 15:06:59 katratzi NetworkManager: <WARN>  nm_signal_handler(): Caught
signal 15, shutting down normally.
Apr 17 15:06:59 katratzi NetworkManager: <info>  Bringing down device eth0
Apr 17 15:06:59 katratzi avahi-daemon[2454]: Withdrawing address record for
fe80::208:74ff:fe4f:752e on eth0.
Apr 17 15:06:59 katratzi NetworkManager: <info>  starting...
Apr 17 15:06:59 katratzi NetworkManager: <info>  eth0: Device is fully-supported
using driver 'e1000'.
Apr 17 15:06:59 katratzi NetworkManager: <info>  Found new Ethernet device 'eth0'.
Apr 17 15:06:59 katratzi NetworkManager: <info>  (eth0): exported as
/org/freedesktop/Hal/devices/net_00_08_74_4f_75_2e
Apr 17 15:07:03 katratzi NetworkManager: <info>  Bringing up device eth0
Apr 17 15:07:03 katratzi kernel: e1000: eth0: e1000_watchdog: NIC Link is Up
1000 Mbps Full Duplex, Flow Control: RX
Apr 17 15:07:03 katratzi kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Apr 17 15:07:03 katratzi kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Apr 17 15:07:03 katratzi NetworkManager: <info>  Deactivating device eth0.
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) starting
connection 'System eth0'
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 1 of 5
(Device Prepare) scheduled...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 1 of 5
(Device Prepare) started...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) scheduled...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 1 of 5
(Device Prepare) complete.
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) starting...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) successful.
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 3 of 5
(IP Configure Start) scheduled.
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 2 of 5
(Device Configure) complete.
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 3 of 5
(IP Configure Start) started...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 4 of 5
(IP Configure Get) scheduled...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 3 of 5
(IP Configure Start) complete.
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 4 of 5
(IP Configure Get) started...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 5 of 5
(IP Configure Commit) scheduled...
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 4 of 5
(IP Configure Get) complete.
Apr 17 15:07:03 katratzi NetworkManager: <info>  Activation (eth0) Stage 5 of 5
(IP Configure Commit) started...
Apr 17 15:07:03 katratzi avahi-daemon[2454]: Joining mDNS multicast group on
interface eth0.IPv4 with address 132.177.241.101.
Apr 17 15:07:03 katratzi avahi-daemon[2454]: New relevant interface eth0.IPv4
for mDNS.
Apr 17 15:07:03 katratzi avahi-daemon[2454]: Registering new address record for
132.177.241.101 on eth0.IPv4.
Apr 17 15:07:05 katratzi console-kit-daemon[2474]: WARNING: Couldn't read
/proc/3036/environ: Error reading file '/proc/3036/environ': No such process
Apr 17 15:07:05 katratzi NetworkManager: <info>  Policy set (eth0) as default
device for routing and DNS.
Apr 17 15:07:05 katratzi NetworkManager: <info>  Activation (eth0) successful,
device activated.
Apr 17 15:07:05 katratzi NetworkManager: <info>  Activation (eth0) Stage 5 of 5
(IP Configure Commit) complete.
Apr 17 15:07:05 katratzi avahi-daemon[2454]: Registering new address record for
fe80::208:74ff:fe4f:752e on eth0.*.
Comment 1 Zdenek Kabelac 2008-04-18 07:23:07 EDT
I also see this behaviour - to get the network running on eht0 I had to run
/etc/init.d/network restart

After this command the NetworkMananger gets the IP address from DHCP server.
Comment 2 George Billios 2008-04-18 12:09:16 EDT
This also happens to me for over a week as well. 

I also have to either restart network service or right click the nm applet,
untick enable networking and tick it again!
Comment 3 Dan Williams 2008-04-22 10:14:48 EDT
Could you run /usr/bin/nm-tool _before_ restarting NM and stick the output in
this bug?  Feel free to obfuscate any MAC addresses in the output.
Comment 4 Thomas J. Baker 2008-04-22 10:34:04 EDT
Not much to obfuscate:

[root@katratzi ~]# nm-tool

NetworkManager Tool

State: disconnected

- Device: eth0 ----------------------------------------------------------------
  Type:              Wired
  Driver:            e1000
  State:             unavailable
  HW Address:        00:00:00:00:00:00

  Capabilities:
    Supported:       yes
    Carrier Detect:  yes
    Speed:           1000 Mb/s

  Wired Settings


[root@katratzi ~]# exit
Comment 5 Thomas J. Baker 2008-04-22 11:30:54 EDT
Is the 'network' service supposed to be chkconfig'd on or not? I noticed that my
problem system had it on. I just turned it off and rebooted and now the network
came up fine (aside from ypbind).
Comment 6 Zdenek Kabelac 2008-04-22 11:49:49 EDT
I could add these things:

When I start to the system and the applet shows unconnected state I also get
also the output same as tjb.
When I turn the network Off/On

The State: is changed from  unavailable -> unmanaged -> disconnected -> connected


Also when I've placed the nm-tool >/tmp/log  in front of
/etc/init.d/NetworkManager I get this output:

"
** (process:2678): WARNING **: nm_object_get_property: Error getting
'WirelessHardwareEnabled' for /org/freedesktop/NetworkManager: The name
org.freedesktop.NetworkManager was not provided by any .service files



NetworkManager appears not to be running (could not get its state).

NetworkManager Tool

State: unknown
"

And the most interesting fact is - when I put there 'exit 0' as the first line
of this /etc/init.d/NetworkManager script - the network is actually running
properly right after the reboot ;)
Comment 7 Dan Williams 2008-04-22 14:15:23 EDT
Can you try with the latest NM in koji?

http://koji.fedoraproject.org/koji/buildinfo?buildID=46621

Please include the output of both /usr/bin/nm-tool and /var/log/messages for the
time when it does _not_ work.
Comment 8 Thomas J. Baker 2008-04-22 14:23:38 EDT
I'm beginning to think this may be a f9beta + a month of rawhide cruft build-up
problem. I've got another system that had the preview clean installed last
Friday and it works fine in a very similar setup. Unless you want to continue
testing this specific system, I'd like to just install from rawhide and see what
happens with that. I could then try those koji builds.

Comment 9 Thomas J. Baker 2008-04-22 14:55:53 EDT
I tried those NM builds which may have fixed it but I've got another problem now
that is probably cruft related. In tracking down another bug
(https://bugzilla.redhat.com/show_bug.cgi?id=443409) I reset the priorities of
haldaemon and NetworkManager. Now when this system boots haldaemon fails to
start which breaks NM too. After boot, if I log in as root and restart haldaemon
then NM, things work as expected. So I think the problem is fixed for me, but I
won't know for sure until I do a clean install.
Comment 10 Thomas J. Baker 2008-04-23 09:15:04 EDT
With a clean install this morning from rawhide, everything seems to be working
correctly, even with the svn3566 version of NM. Not sure how things got so
messed up. I update to rawhide daily and reboot after each update.
Comment 11 Dan Williams 2008-04-23 15:52:57 EDT
ok; closing
Comment 12 George Billios 2008-04-23 16:30:20 EDT
I don't think this bug should be closed. So a fresh installation doesn't present
this bug, but an older installation *with* the current updates does. Don't you
worry that what caused this problem might still trigger a new bug if the problem
is pinpointed?

For example after a suggestion in this bug, I turned of the network service and
this bug disappeared. Is this the correct solution? Should the network service
be disabled?  
Comment 13 Thomas J. Baker 2008-04-23 16:48:12 EDT
FWIW, on all my preview installed systems, network is turned off by default and
things work as expected.

In terms of closing the bug, I think that if things are working from a current
install (can't say about an update from F8 to F9) then closing it is best. Given
that there are only so many hours in a day, is it really worth holding up F9
chasing down a bug that only happens to beta testers who are updating many
packages everyday for weeks? All it takes is one slightly bad install script
from one testing version of a package to put the system into an unexpected
state. No disrespect intended.
Comment 14 Zdenek Kabelac 2008-04-24 07:06:55 EDT
Personally I still believe there is a bug in Network Manager - thought might be
I do not know how this thing is supposed to work.

Anyway - for me the 'good enough' fix is - to remove:
 ~/.gconf/system/networking/connection directory
and set the parameter   ONBOOT=no  
in the file /etc/sysconfig/network-scripts/ifcfg-eth0

So doing fresh reinstall of the Fedora is an overkill...

Still I'll most probably had to figure out why am I asked many times for the
access key for the wifi WEP key - when the eth0 connection is accessible - but
as I can see, I'll most probably had to figure this all myself, to save many
hours in a day  :)
Comment 15 Dan Williams 2008-04-24 11:45:33 EDT
Zdenek: NM brings up any available device (it supports multiple active netowrk
devices) that's either configured in the user's settings, or marked ONBOOT=yes
in the ifcfg files.  You'll be asked at least for your keyring password so NM
can access your WEP keys and WPA passphrases.  If the AP rejects your connection
or it times out, NM will ask you for the password again.
Comment 16 Zdenek Kabelac 2008-04-25 04:34:13 EDT
Hmm - I'm pretty sure it used to work in a very nice way before - i.e. when it
was connected to Wired network - it was not trying to gain access to WEP
network. When I unplugged my notebook from docking station - it has nicely tried
to get access to rhn - and asked for the password at this time.

At my home where I do not have rhn, but I've home network without any
encryption, it also did not asked for password.

However now - I'm always asked for password for keywallet - and even thought I'm
pretty sure the RHN wep key is properly entered - Network Manager is not able to
access RHN - unless I try several times to variate between 128bit key &
40hex/128bit key (which should be correct - but it's not somehow remembered by
NM) - when I do not want to enter password (i.e. Deny/or cancel via Esc) I'm
asked with the same dialog again for 5 times - most probably to make sure I
really do not want to enter the password ;)

Next point is - I could not actually even turn off  AutoConnect switch in the
EditConnection anyway (I think this GUI is actually not storing its data
properly which might be the whole reason for the bug) 

Next thing would be that whole NM actually eats around 10M - what for ? this
should be also probably fixed.

Also I sais - with ONBOOT=yes for eth0  NM actually unconnects eth0 (as I could
see in the message log)

Simply I'd like to see the good old behaviour ;)

Note You need to log in before you can comment on or make changes to this bug.