From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
Ifup for eth0 brings up the interface but fails to set the ip address.
This happens with either dhcp or static addressing. On my test system
eth0 gets a 10.11.12.x address from dhcp (should be .2) and setting a
static address of 10.11.12.2 doesn't work either.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.boot rawhide install (20040906)
2.check interface with ifconfig
Actual Results: interface is up but without an IP address assigned!
Expected Results: should have an IP (v4) address of 10.11.12.2
eth0 is a tulip based on-board 10/100 ethenet adapter (ASUS P5A-B)
that has been working as expected until the rawhide update of 20040902
Seems that the NetworkManager has broken something in the boot
sequence. Note that an "ifup eth0" after boot and root login sets
I'm a bit mystified that there are no other errors showing as a result
of this one, the NIS ypbind appears to successfully run (it get an OK)
and then the logins fail because there is no route to the NIS domain
on the 10.x.x.x subnet.
Can you elaborate on the process here? I take it you've installed
NetworkManager, and you are using the service? What is the exact
sequence of steps during system bootup, and where does the stuff go wrong?
Note that at this time, use of NetworkManager _and_ initscripts like
'ifup/ifdown' at the same time is not supported, and using ifup when
running NetworkManager will not work (since NetworkManager will just
take over the interface again). Currently, NM is all-or-nothing,
thought this will change to support static IP addresses in the future.
I'm using a pure development/rawhide install and NetworkManager was
installed and started by default. I let anaconda configure eth0 as a
dhcp device and did the usual setup. When the system booted,
everything seems to proceed normally (there are no network related
[FAILED] notices in the details) including NIS and NTP startup. But,
when I try to use network services after booting completes, I get
ypbind Domain Not Bound errors and examination of the interface with
/sbin/ifconfig shows it as up and running but no IPV4 address is
given! I used system-config-network to change from dhcp to static
and rebooted to see if it made any difference (it didn't.)
I did several variations on ifup and ifconfig to see what happens
and they all set the address, but on reboot it starts all over again.
Where is the documentation on NetworkManager? Is there a config
file I need to set/edit so that NM takes care of things properly?
Actually, NM is config-less :) Eventually it will pull from the
/etc/sysconfig/network-scripts/ifcfg-* files (edited by
However, for your problem, can you boot to single-user, and then do
service messagebus start
service haldaemon start
And post the output here? (you can kill it after about a minute and
grab the output).
then, also post the result of:
I just found out through the test list that this problem happens for
the eth0 interface. I have two NICs, eth1 gets a DHCP address. I
noticed that on booting up the machine, I get an OK prompt during the
initializing portion. On the level 6 shutdown messages, I get a failed
message prompt for eth0.
The excerpt from posting. The alias info is from /etc/modprobe.conf
I could not find a shutdown log. Where would shutdown errors be
Realtech - alias eth0 ne2k-pci
> eth0 Link encap:Ethernet HWaddr 52:54:05:E4:A4:39
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:9 errors:0 dropped:0 overruns:0 frame:0
> TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2694 (2.6 KiB) TX bytes:1938 (1.8 KiB)
> Interrupt:10 Base address:0xdf80
> The "Other" Tornado - alias eth1 3c59x
> eth1 Link encap:Ethernet HWaddr 00:01:02:FA:69:F3
> inet addr:192.168.1.103 Bcast:192.168.1.255
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:302 errors:0 dropped:0 overruns:0 frame:0
> TX packets:261 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:254994 (249.0 KiB) TX bytes:27932 (27.2 KiB)
> Interrupt:11 Base address:0xdc00
*** Bug 132156 has been marked as a duplicate of this bug. ***
I booted the system single user and did as requested....
Couldn't grab the output, but it was shockingly normal. Nothing was
wrong with eth0. It was up and running with an address. I
chkconfig'd NetworkManager "off" and rebooted into runlevel 5. Things
went fine and a root login on vt01 showed eth0 as working.
I then did a "service NetworkManager start" and waited about 1 minute.
Then an ifconfig eth0 showed up with the IP address missing! This is
what NM logged:
Sep 9 19:00:06 tembo NetworkManager: Setting network parameters:
Sep 9 19:00:07 tembo NetworkManager: starting...
Sep 9 19:00:07 tembo NetworkManager:
nm_create_device_and_add_to_list(): adding device 'eth0' (wired)
Sep 9 19:00:07 tembo NetworkManager: NetworkManager startup succeeded
Sep 9 19:00:08 tembo NetworkManager: AUTO: Best wired device = (null)
Sep 9 19:00:08 tembo NetworkManager: AUTO: Best wireless device =
The conclusion is that when NM starts up after eth0 is already
configured by the initscripts it manages to remove the IP address from
the interface's configuration. It is a bad interaction between the
mainline code and the NM code. For now I'm just going to run without
NM activated except to test for this bug as new versions come along.
Still have to deactivate NM for correct behaviour with a fresh install
from development/rawhide snapshot of 2004-09-10.
Built this morning, will be off by default in new installs now.
Can you do this too?
service NetworkManager stop
And post the output? It should be similar to what you've posted
above, but it might help more. We need to figure out why NM doesn't
seem to be told about eth1. Part of the problem here is that the
ne2k-pci driver doesn't support link checking, hence NM always thinks
the link is off.
If NetworkManager doesn't know about eth1 (which it doesn't seem to
from your log above), and it doesn't detect a link on eth0 (the
ne2k-pci card), then it would decide that there are no suitable
devices it can use.
Can you make sure that hal-gnome is installed and run
'hal-device-manager' and see what it says about your 3c59x card, and
whether that card has a "net.ethernet" property in the "Advanced" tab?
I think, until the ne2k-pci driver gets link-checking capability, you
might be out of luck with NM. Can you post the output of:
FWIW, I'm running into a problem that appears to not be quite the
same, but possibly related. Several hours after a reboot, hours
during which networking worked perfectly well, I got the following in
Sep 11 19:16:02 livre kernel: e100: eth0: e100_watchdog: link down
Sep 11 19:16:07 livre NetworkManager: AUTO: Best wired device = (null)
Sep 11 19:16:07 livre NetworkManager: AUTO: Best wireless device =
Sep 11 19:16:07 livre NetworkManager: nm_state_modification_monitor():
beginning activation for device '(null)'
Sep 11 19:16:08 livre kernel: e100: eth0: e100_watchdog: link up,
and from then on eth0 was missing an IP address. Even when the time
came for dhcp to renew the lease, it failed:
Sep 11 19:41:43 livre dhclient: DHCPREQUEST on eth0 to 172.31.160.5
Sep 11 19:41:43 livre dhclient: send_packet: Network is unreachable
Sep 11 19:41:43 livre dhclient: send_packet: please consult README
file regarding broadcast address.
I've run chkconfig NetworkManager off for now, but, oddly, when I ran
service NetworkManager stop, it [FAILED]. Let's see how this goes...
I'm pretty sure the real error is in NetworkManager, not ifup /
initscripts. I've posted more commentary at #132348
Alexandre: there is a bug in the FC3 version of network manager that
would cause NM to defeference a NULL pointer and die when there are no
suitable network devices, which is what happened to you most likely.
Been fixed in CVS for a while, just waiting for things to settle down
a bit until the next drop.
This particular bug (NM/initscripts conflict) is fixed in rawhide,
where NM is no longer enabled by default when installed.
Confirmed fixed. After a full install, it is no longer enabled by