Red Hat Bugzilla – Bug 151099
NetworkManager blanks /etc/resolv.conf and looses its ip
Last modified: 2008-02-06 20:13:32 EST
Description of problem:
When being started, NetworkManager clears the /etc/resolv.conf file and
then looses its ip
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.run service NetworkManager start
NetworkManager: NetworkManager startup succeeded
nifd: nifd shutdown failed
NetworkManager: eth0: Driver support level for 'tulip' is fully-supported Mar 14
nm_device_new(): waiting for device's worker thread to start.
NetworkManager: nm_device_new(): device's worker thread started, continuing. Mar
NetworkManager: Now managing wired device 'eth0'.
NetworkManager: Clearing nscd hosts cache.
No More entries .. no dhcp attempt nothing
connect: Network is unreachable
contents of /etc/resolv.conf
; generated by NetworkManager, do not edit!
blank line 1
blank line 2
blank line 3
I used to have to restart the network with the previous cvs release installed
0.3.3 1.cvs20050119.2.fc3 right after the NetworkManager start
and that would work, but this time it does nothing after I restart the network
I tried recently NetworkManager with 'madwifi' card (DWL-G650 from D-Link).
There is really no documentation I can find so it looks that the only way
to see what it may be doing is to try. OK, so it did not work at all.
Gnome icon is forever in "scanning" and there is really no way to get out
othen then killing all these process. But it started from destroying my
current /etc/resolv.conf while it had nothing else to propose instead.
Not a very nice behaviour.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
Fedora Core 3 is not maintained anymore.
Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release please reopen this bug and assign it to the corresponding