Description of problem: I use Fedora as a vmware player guest. For some reason, my network interface is called "ens33". NetworkManager does not connect it automatically. However, if I run "ifup ens33", the network works correctly. Version-Release number of selected component (if applicable): $ rpm -qi NetworkManager Name : NetworkManager Epoch : 1 Version : 0.9.9.0 Release : 23.git20131003.fc20 Architecture: x86_64 Install Date: Tue 14 Jan 2014 02:57:59 PM CET Group : System Environment/Base Size : 4925397 License : GPLv2+ Signature : RSA/SHA256, Mon 06 Jan 2014 07:42:14 PM CET, Key ID 2eb161fa246110c1 Source RPM : NetworkManager-0.9.9.0-23.git20131003.fc20.src.rpm Build Date : Mon 06 Jan 2014 06:20:15 PM CET Build Host : buildvm-18.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://www.gnome.org/projects/NetworkManager/ Summary : Network connection manager and user applications How reproducible: Always. Steps to Reproduce: 1. Boot the fedora virtual machine 2. Log into gdm 3. No internet connection is available Actual results: ifconfig doesn't show the interface. The network is disconnected. Expected results: The ens33 is automatically activated upon boot and internet access works as expected.
Following the advice from this forum thread (http://forums.fedoraforum.org/showthread.php?t=295988), I enabled the "network" service with chkconfig. The interface is now up upon boot, but networkManager still shows the network as disconnected, doesn't show the interface in the gnome network settings dialog, and so applications such as Firefox start in offline mode.
Something I failed to mention: I still need to run "sudo dhclient ens33" manually to get network access.
Hi Joël, I stumbled onto this researching an unrelated issue, and just have a few comments: An interface can be managed by NetworkManager, or the network service, not both. Simply enabling the network service with `chkconfig` should have no discernable impact unless you have explicitly declared "NM_CONTROLLED=no" in /etc/sysconfig/network-scripts/ifcfg-whatever . If ifcfg-ens33 declares "ONBOOT=no", the network service will also not bring up the interface at boot. ifcfg-ens33, nm-cli, nm-connection-editor, and the GNOME settings network panel each offer a way to set the interface to be on at boot. You haven't indicated if you have attempted to check or verify this setting.
Some additional info: The network interface does not show at all in the Gnome network settings (regardless of the status of the "network" service. nm-connection-editor shows the interface and everything seems normal. NM is set to bring it up automatically and all users are allowed to use it. I've been able to bring up the interface manually with nmcli. However now I've added "NM_CONTROLLED="no"" in ifcfg-ens33 and it doesn't work anymore (says Error: Connection activation failed: Device not managed by NetworkManager or unavailable, I guess that makes sense). Now that I've added "NM_CONTROLLED="no"" to ifcfg-ens33, dhcp is done automatically which is a plus. However applications such as firefox or thunderbird seem not to be aware of the interface, so they start in offline mode. My guess is that they rely on network manager to get the state of the connection.
NM_CONTROLLED=no says NetworkManager not to touch/manage the interface. In most case you don't need this. NetworkManager and legacy network.service should cooperate quite well. Actually, if NM runs ifup/ifdown passes the requests to nmcli. Can you get the following data for us to look at: $ nmcli con show active $ nmcli device $ ip link $ ip addr NM logs (journalctl -u NetworkManager) As for the interface name, now systemd-udevd make interface renames at early boot, search for "renamed network interface <old-name> to <new-name>" in the journal. Would you first update to newest NM package for F20?
Created attachment 876038 [details] NetworkManager logs journalctl -u NetworkManager -b > nm.log
Here are the requested outputs. [joel@fedora-joel ~]$ nmcli con show active NAME UUID DEVICES DEFAULT VPN MASTER-PATH [joel@fedora-joel ~]$ nmcli device DEVICE TYPE STATE ens33 ethernet unmanaged lo loopback unmanaged [joel@fedora-joel ~]$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:0c:29:fa:e9:7d brd ff:ff:ff:ff:ff:ff I can run the same after removing NM_CONTROLLED="no" if you think that's useful.
Joël, you can't demonstrate NetworkManager's handling of the connection if you have configured the system so that NetworkManager ignores that connection. You've demonstrated that NetworkManager does not control your connection if you set NM_CONTROLLED="no", which is expected and not a bug. The log files and output you share should reflect the system's state while you are experiencing the bug, so yes, it would be useful to show logs and output after commenting out NM_CONTROLLED=no.
Sorry, I had forgotten about this bug. It's been fixed for a while, but I don't know what fixed it.