Description of problem: All of a sudden I find myself with an `empty` resolv.conf that a few moments ago was filled and `working`. Version-Release number of selected component (if applicable): 0.7.1.4.git20090414.fc11 How reproducible: I just rebooted. Came up fine. Tried to get usb0 working. No success. Timed out after a while: Jul 16 16:18:55 surfplank2 NET[5232]: /etc/sysconfig/network-scripts/ifdown-post : updated /etc/resolv.conf ifcfg-usb0 has the same dns-info as ifcfg-eth0. Steps to Reproduce: 1. reboot 2. make usb0 active, have that fail 3. wait Actual results: /etc/resolv.conf 'empty' default contents Expected results: /etc/resolv.conf not destroyed Additional info: Jul 16 16:18:55 surfplank2 NET[5232]: /etc/sysconfig/network-scripts/ifdown-post : updated /etc/resolv.conf
I also am experiencing a write-over of /etc/resolv.conf on reboot. happens on both 32 bit and 64 bit Fedora 11. 2.6.29.6-213.fc11.i686.PAE #1 SMP 2.6.29.6-213.fc11.x86_64 #1 SMP NetworkManager is turned OFF and DISABLED in services. Not running DHCP, have a single ethernet interface set up with a static IP address. No reason to suspect USB0, the write-over happened on reboot. Mangled resolv.conf: nameserver 132.236.56.250 Original resolv.conf: nameserver 132.236.56.250 nameserver 192.35.82.50 nameserver 128.253.180.2 domain mbg.cornell.edu search mbg.cornell.edu chess.cornell.edu cornell.edu
Additional details: If I comment out the DNS1 line from /etc/sysconfig/network-scripts/ifcfg-eth0 then the /etc/resolv.conf file is overwritten with a blank file. If I neuter /sbin/dhclient-script then the overwrite does not happen. So it comes to this: why is dhclient-script being run when I am not using HDCP?
dhclient-4.1.0-22.fc11.i586
cat /var/log/messages | fgrep nm: Aug 5 08:50:30 titan nm-system-settings: Loaded plugin ifcfg-rh: (c) 2007 - 2008 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Aug 5 08:50:30 titan nm-system-settings: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... Aug 5 08:50:30 titan nm-system-settings: ifcfg-rh: read connection 'System eth0' Aug 5 08:50:30 titan nm-system-settings: ifcfg-rh: Ignoring connection 'System eth0' and its device because NM_CONTROLLED was false. Aug 5 08:50:30 titan nm-system-settings: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... Since I have NetworkManager turned OFF and DISABLED, why is nm-system-settings running?
(In reply to comment #2) try setting PEERDNS=no in your /etc/sysconfig/network-scripts/ifcfg-eth0 (In reply to comment #4) > Since I have NetworkManager turned OFF and DISABLED, why is nm-system-settings > running? nm-system-settings is a separate daemon that configures system connection. And it can be used by other programs as well (besides NM). BTW, in NM 0.8 nm-system-settings is merged into NM
If you have NetworkManager enabled, you don't need to use ifup/ifdown at all. You can simply allow NetworkManager to handle the device and it should get the configuration right if you use DHCP, otherwise you can configure the device to have a static IP address from the connection editor. Are you trying to ifup/ifdown the device, or use the Network Device Control applet at all while at the same time you have NetworkManager running?
ifup/down I guess, we were at the cli anyway.
(In reply to comment #7) > ifup/down I guess, we were at the cli anyway. Ok, in that case if you prefer to use ifup/ifdown then you should turn NetworkManager off with 'chkconfig NetworkManager off' and then 'service NetworkManager stop'. NetworkManager is intended to control the default route and the DNS information for the machine when it is enabled and running. If you use ifup/ifdown while NetworkManager is running then it's possible that the two can step on each other's toes, especially if you don't have the right DNS1/DNS2 information in the ifcfg files themselves. So I'll mark this NOTABUG for now, and if you continue to have issues when NetworkManager is off (or if you decide to use NetworkManager instead of ifup/ifdown and continue to have issues) then we can figure out the appropriate resolution. Thanks!
We consider it not a bug that we offer two methods to manipulate interfaces which causes problems because one method does it one way and the other method another way? And did you look at the configuration methods within the gui itself for network? Admin- > network is of course a different applet (at least it looks like it) than the one you see after manipulating the tray thingie for eth0. One does ipv6, the other one doesn't. ipv6 values do not take effect. Etc. On the cli stuff doesn work, though. So please fix the gui stuff and make stuff interoperable. It isn't that hard.
Even if you try to use the NM mess, you notice that when you disable and then enable networking via the applet ir behaves diferent from the expected 'service networking stop/start': the applet assigns the wrong IP to eth0, it uses the usb0 number. Also the applet fails to accept ipv6 info for eth0. It does NOT read the info from ifcfg-eth0 which one would expect. If you are serious about NM please FIX it. I consider filing bugs for each of these issues.