NetworkManager: Failed to activate – The name org.freedesktop.NetworkManager was not provided by any .service files
November 5, 2015 1 Comment
Because I need to connect quickly and easily to numerous wired and wireless networks (DHCP or static IP addressing), I use NetworkManager in my Gentoo Linux amd64 installation running OpenRC and KDE 4. My Clevo W230SS laptop has an Intel Dual Band Wireless-AC 7260 Plus Bluetooth adapter card, and my installation uses the
I have left the
netmount service enabled in case I want to use network-attached file shares at home or in one of the various office locations where I work.
Networking works fine on my laptop with the many wired and wireless networks I have used except for one particular public wireless network (it is in an airport, has multiple Access Points, and its Access Points only support 802.11a/b/g, which may or may not be relevant) for which the following message would usually appear in a pop-up window when I tried to connect to the network from the KDE network management GUI after start-up:
Failed to activate
The name org.freedesktop.NetworkManager was not provided by any .service files
This occurred with both
networkmanager-1.0.6, the two Stable Branch releases of NetworkManager currently available in Gentoo Linux.
The wireless network is not the only network at that particular location, and the ‘Failed to activate’ message occurred whichever network (wireless or wired) I tried to access at that location. When this problem occurred, it transpired that the
NetworkManager service was not running (it had crashed):
(I am not bothered that Samba crashes in that particular location. It crashes even if a connection is established, because the public wireless network does not provide network file systems. Samba works fine when I connect the laptop to an office network or to my home network.)
Even if the ‘Failed to activate’ message occurred, sometimes (but not always) the laptop could still connect to networks after I restarted the
NetworkManager service (albeit sometimes it was necessary to restart it more than once):
When it is possible to connect to networks, the
NetworkManager service is of course running:
I searched the Web for the error message and, based on a recommendation on the Web page ‘nm-applet gives errors‘ claiming the problem is due to the
iwlwifi driver when used with an Intel 7260 controller, I created a file
/etc/modprobe.d/iwlwifi.conf containing the following line, and rebooted:
options iwlwifi power_save=0
However, the error message still occurred. So I changed the
iwlwifi module options line to the following, as also recommended on that page, and rebooted:
options iwlwifi 11n_disable=1 power_save=0
However, the error message still occurred.
The default value for OpenRC’s
rc_depend_strict variable is
rc_depend_strict is not declared in the file
/etc/rc.conf, but I do not think that is the cause of the problem:
# Do we allow any started service in the runlevel to satisfy the dependency # or do we want all of them regardless of state? For example, if net.eth0 # and net.eth1 are in the default runlevel then with rc_depend_strict="NO" # both will be started, but services that depend on 'net' will work if either # one comes up. With rc_depend_strict="YES" we would require them both to # come up. #rc_depend_strict="YES"
As already mentioned, sometimes just restarting the
NetworkManager service once or more did enable the laptop to connect to the network. This made me wonder whether the problem had something to do either with the timing of the launch of the
NetworkManager service or with the timing of the service establishing a connection. As
netmount is the only other network-related service enabled at start-up, I checked the
netmount service’s configuration file
/etc/conf.d/netmount to see what it contained (it’s the same in both the latest stable
openrc-0.17 and the latest testing
# You will need to set the dependencies in the netmount script to match # the network configuration tools you are using. This should be done in # this file by following the examples below, and not by changing the # service script itself. # # Each of these examples is meant to be used separately. So, for # example, do not set rc_need to something like "net.eth0 dhcpcd". # # If you are using newnet and configuring your interfaces with static # addresses with the network script, you should use this setting. # #rc_need="network" # # If you are using oldnet, you must list the specific net.* services you # need. # # This example assumes all of your netmounts can be reached on # eth0. # #rc_need="net.eth0" # # This example assumes some of your netmounts are on eth1 and some # are on eth2. # #rc_need="net.eth1 net.eth2" # # If you are using a dynamic network management tool like # networkmanager, dhcpcd in standalone mode, wicd, badvpn-ncd, etc, to # manage the network interfaces with the routes to your netmounts, you # should list that tool. # #rc_need="networkmanager" #rc_need="dhcpcd" #rc_need="wicd" # # The default setting is designed to be backward compatible with our # current setup, but you are highly discouraged from using this. In # other words, please change it to be more suited to your system. # rc_need="net"
As I am using NetworkManager rather than netifrc, I followed the instructions in the file’s comments and changed the file’s contents from:
After making the above change, the console messages at boot-up included a new message:
That message made sense:
rc_need had been set to
"networkmanager" and, obviously,
netmount can only do its job if
NetworkManager is running (AND a network connection has been established). However, notice that the name of the
NetworkManager service initscript is
/etc/init.d/networkmanager. In other words, the instructions in
/etc/conf.d/netmount are wrong: the name of the service is actually ‘
NetworkManager‘, not ‘
networkmanager‘. So I changed
/etc/conf.d/netmount to contain
rc_need="NetworkManager" instead of
rc_need="networkmanager" and, unsurprisingly, the above-mentioned error message no longer occurs. I have filed Gentoo Bugzilla Bug Report No. 564846 requesting that the comment in the configuration file be changed.
Nevertheless, the ‘Failed to activate’ message still occurred when I tried to connect to any network at that location by using the DE’s network management GUI, and therefore I still needed to restart the
NetworkManager service manually in order to be able to connect to any network there. Although I am not yet sure of the root cause and solution, I have found a work-around which avoids me having to manually restart the
NetworkManager service, as explained below.
Although OpenRC correctly launches the
NetworkManager service, that service remains inactive until it actually establishes a network connection. This is not a bug, it is the way OpenRC and NetworkManager work (see the explanation in the Gentoo Forums thread NetworkManager has started, but is inactive). This is why the following console message appears during boot-up:
If you did not configure NetworkManager to connect automatically to a network, after logging-in to the DE you will need to use the DE’s network management GUI (
plasma-nm in the case if KDE,
nm-applet in the case of e.g. Xfce) to tell
NetworkManager to connect to the desired network. However, I found that waiting that long before trying to connect is too late to avoid the ‘Failed to activate’ problem, i.e.
NetworkManager crashes after a while. I do not know why this happens, but it usually happens only when I am at the location covered by one specific wireless network (which is why I wonder if the problem is a result of that network only supporting 802.11a/b/g). By configuring NetworkManager to connect automatically to the wireless network which seemed to trigger the problem, the
NetworkManager service tries to connect earlier. It is possible to configure NetworkManager to do this either by using the DE network GUI and ticking ‘Automatically connect to this network when it is available’ for the relevant network connection, or by directly editing the relevant connection’s file in the directory
Of the various wired and wireless connections I had configured on the laptop, I had named the problematic wireless network’s connection ‘Free_Airport_Internet’. So I edited the file
/etc/NetworkManager/system-connections/Free_Airport_Internet and deleted the line ‘
autoconnect=false‘ in the
[connections] section of the file (the default value of the
autoconnect variable is
TRUE – see
man nm-settings). I could instead have done this by using the DE’s network manager GUI and ticking ‘Automatically connect to this network when it is available’ for that network connection. Now, when the laptop boots,
NetworkManager tries to connect to that network and the ‘Failed to activate’ problem is avoided. This works with or without the
iwlwifi driver options I mentioned above, so, despite the claim on the Web page I referenced above, the root cause of the problem does not appear to be the
iwlwifi driver. What I don’t understand is why the problem only seems to occur with one particular network (a public wireless network which happens to only support 802.11a/b/g), i.e. even if none of the NetworkManager connection files in my installation have been configured to try to establish a connection automatically, with all the other wireless networks I have used in other locations (I believe those all support at least 802.11a/b/g/n) I have been able to establish a connection manually by using the DE’s network management GUI.
The bottom line
If your installation uses NetworkManager and you experience the ‘Failed to activate’ message when trying to connect to networks from the DE’s network management GUI, check if the
NetworkManager service is running. You can check by using the command ‘
nmcli d‘ in a console. If it is not running, try to restart the
NetworkManager service from the command line. If the connection is not already configured to start automatically, configure it to start automatically in order to try to make
NetworkManager become active at an early stage.
POSTSCRIPT (November 6, 2015)
The two links below are to old bug reports regarding earlier versions of NetworkManager having trouble using wireless networks with multiple Access Points. I wonder if the problem I saw with NetworkManager crashing when not configured to connect automatically to the specific network I mentioned above is somehow related to those problems:
Roaming to BSSID “(none)” certainly happens with this particular network too, as shown by the messages in the laptop’s system log from yesterday when I was using the laptop with that network (the laptop was stationary the whole time):
Today I’m using a hotel network in my hotel room, and that does not roam to BSSID “(none)”, but I don’t know if my room is within range of more than one Access Point:
Anyway, with the work-around described in this post I have not had any further trouble accessing the particular network, but it would be interesting to know the root cause.