Description of problem: After upgrading from F7 to F8, NetworkManager fails to bring up eth0 on boot - it doesn't run dhclient until after logging in. Version-Release number of selected component (if applicable): 0.7.0-0.5.svn3030.fc8 How reproducible: 100% of the time. Steps to Reproduce: 1. Laptop network configured to use DHCP, and start eth0 interface on boot (although NM would normally do it anyway). 2. NM and NM-Dispatcher running for levels 3,4,5. 3. eth wire connected, running happily, reboot. Actual results: No wired-network until login. Expected results: Wired-network should be available immediately. Additional info: I would usually set the wired lan eth0 NOT to start on boot, and let NM handle it. So to verify there's nothing wrong with the network here and it's NM doing something funky, I have tried: Logging in to the text-only terminal (rather than a window-manger) - I can run dhclient etc. and obtain an IP address (for sshd ntpd etc) quite happily. Setting eth0 to start on boot - in this case the interface comes up and obtains an IP address etc. so is reachable for a period of time, then NM brings down eth0 and fails to bring it back up. Setting eth0 to start on boot and disabling NM completely - everything works fine!
Created attachment 260521 [details] From /var/log/messages - slightly sanitised for public consumption.
I have this problem, too. I noticed that I can ping my laptop while it's booting for a few seconds: between S10network and S98NetworkManager. I can also ssh in after S55sshd runs, but the connection dies when NetworkManager starts. Looking at /var/log/messages, I can see that NetworkManager is shutting down eth0 as it starts to manage it: NetworkManager: <info> Bringing down device eth0 NetworkManager: <info> Deactivating device eth0. NetworkManager: <info> eth0: canceled DHCP transaction, dhclient pid 3208 NetworkManager: <info> Deactivating device eth0. NetworkManager: <info> eth0: Device is fully-supported using driver 'e1000'. NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'. NetworkManager: <info> Bringing down device eth0 dhclient: receive_packet failed on eth0: Network is down NetworkManager: <info> Bringing up device eth0 NetworkManager: <info> Deactivating device eth0. NetworkManager: <info> (eth0) supplicant interface is now in state 1 (from 0). NetworkManager: <info> (eth0) supplicant interface is now in state 2 (from 1). eth0 is now disconnected until someone logs in and nm-applet runs. If you log out, which kills nm-applet, eth0 goes down again. (Actually, the interface is up, it just drops its IP address.) How can I keep eth0 up with an IP address at all times regardless if someone is logged in or not?
I'm using the latest NetworkManager packages: NetworkManager-0.7.0-0.6.6.svn3138.fc8.x86_64 NetworkManager-glib-0.7.0-0.6.6.svn3138.fc8.x86_64 NetworkManager-gnome-0.7.0-0.6.6.svn3138.fc8.x86_64 NetworkManager-openvpn-0.7.0-2.svn3047.fc8.x86_64 NetworkManager-vpnc-0.7.0-0.6.3.svn3109.fc8.x86_64
Yeah, I updated to the svn3138 packages and still have this problem.
Same problem here.
This causes real problems when people are using autofs and nfs home directories. Noone can effectively log in. As soon as nm-applet runs, networkmanager connects to the wired network.
Can you try the latest NM packages in f8-updates? should be svn3235 or later.
I have NetworkManager-0.7.0-0.6.7.svn3235.fc8.x86_64 and I still see the same behavior as in comment #2: 1. the network works after /etc/rc5.d/S10network but before /etc/rc5.d/S98NetworkManager (i.e., the network stops when NetworkManager starts) 2. after login, and nm-applet is fired up, the network works again I added 'NM_CONTROLLED=yes' (as recommended by bug 441596) to my /etc/sysconfig/network-scripts/ifcfg-eth0 but that didn't help.
Yeah, I've been using the svn3235.i386 packages for a while now. No change. Same behavior as Jeff sees.
And, just to be sure, I ran system-config-network and re-generated my network config. My /etc/sysconfig/network-scripts/ifcfg-{eth0,wlan0} files have a lot more lines in them now, but the behavior is the same.
This *finally* appears to have been fixed in the latest updates drop for Fedora 8. 1:0.7.0-0.6.7.svn3370.fc8