can't use NM for ethernet device on 20.04 LTS because it is 'strictly unmanaged'

Bug #1951653 reported by Steve Langasek
This bug affects 6 people
Affects Status Importance Assigned to Milestone (Ubuntu)
Fix Released
Lukas Märdian
network-manager (Ubuntu)

Bug Description

I have tried to tell netplan to let my ethernet device be managed by NetworkManager, so that I can then configure a pppoe connection on top of this device.

This fails with:

# nmcli c up netplan-wan
Error: Connection activation failed: No suitable device found for this connection (device lo not available because device is strictly unmanaged).

I don't know why it mentions 'lo' in that message, but the wan interface is unmanaged (as are all devices on the system, but this one is supposed to be managed):

# nmcli d status | grep wan
wan ethernet unmanaged --

After much searching, I've figured out that this comes from /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf:


Even though I've told netplan to use the NM renderer for this device, the configuration emitted by netplan is insufficient to override this.

Using the workaround from (sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf) doesn't work, but if I set NetworkManager as the toplevel renderer in /etc/netplan, /run/NetworkManager/conf.d/10-globally-managed-devices.conf is emitted, which evidently DOES work. But I only have one device that I want rendered by NM, so I shouldn't have to declare NM at the top level of the yaml with a lot of duplication in order to get this result.

I would argue that the 10-globally-managed-devices.conf should not be there at all. But if it is going to be, then netplan needs to consistently override it whenever there is any use of the NetworkManager backend.

Tags: fr-1888
Steve Langasek (vorlon)
Changed in (Ubuntu):
importance: Undecided → High
Changed in network-manager (Ubuntu):
importance: Undecided → High
Revision history for this message
Lukas Märdian (slyon) wrote :

Yes, indeed. NetworkManager tries to control all interfaces that are available by default and netplan implemented some quirks in the past to avoid this. But we should review those quirks and rather implement a per-interface/netdef deny- or accept-list.

tags: added: fr-1888
Changed in (Ubuntu):
status: New → Triaged
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

I have some less technical questions, more from the 20.04.4 POV: is this a regression from previous behavior? Did the netplan-generated configuration work before for this case, when only a single device was to be managed by the NM renderer? It looks to me like something that wasn't quite working since long.

As this is not a installation-blocker or regression, but more of a disability of netplan, I would say we should have it more like a 'nice to have' for .4 than hard requirement. It would be useful of course, since I can imagine situations where this could prevent certain sysadmins from easily configuring their networking after performing an offline installation (as they won't be able to get the netplan fix without it being on the images). But I think this is not too common.

Revision history for this message
Lukas Märdian (slyon) wrote :

This is not a regression for what I understand. It has been broken for a long time and should be fixed eventually. So I agree with your assessment!

Revision history for this message
Lukas Märdian (slyon) wrote (last edit ):

We want to implement an explicit allow- and denylist for NM to handle certain device (or not). NM’s own matching engine is not powerful enough to handle all of netplan’s matching needs, but it can also be implemented with udev matching rules, using ENV{NM_UNMANAGED}="1"

We also want to discuss with the desktop team if we really need/want /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf (this is a change in Ubuntu's default behavior)

See also:

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Lukas Märdian (slyon) wrote :

I agree that the /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf should be deleted from Ubuntu's network-manager package.

Especially, as it is being overwritten in any normal Ubuntu Desktop installation, using the following netplan YAML:
  version: 2
  renderer: NetworkManager

If we use a global "renderer: NetworkManager" stanza (as is the default on Ubuntu Desktop, where NM is part of the default installation) netplan will create an empty file in /run/NetworkManager/conf.d/10-globally-managed-devices.conf, to override that file anyway.

But we should be aware that it could introduce a change of default behavior on Ubuntu server where network-manager is being installed additionally. But netplan generates /run/NetworkManager/conf.d/netplan.conf to specifically ignore devices that are not supposed to be handled by NM, so we should be fine there, too.

I've recently updated the allow- and deny-list logic in netplan to be more generic and instruct NetworkManager to ignore/manage devices based on specific udev rules. With this PR I'm also changing the 10-globally-managed-devices.conf logic to override Ubuntu's default anytime a NetworkManager interface is being defined in netplan YAML (not just if it's defined as the global renderer).

Changed in (Ubuntu):
assignee: nobody → Lukas Märdian (slyon)
status: Triaged → In Progress
Revision history for this message
Lukas Märdian (slyon) wrote :

network-manager's default /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf file also produces other issues, see LP: #1615044

Lukas Märdian (slyon)
Changed in (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package - 0.105-0ubuntu1

--------------- (0.105-0ubuntu1) kinetic; urgency=medium

  * New upstream release: 0.105
    - Add support for VXLAN tunnels (#288), LP: #1764716
    - Add support for VRF devices (#285), LP: #1773522
    - Add support for InfiniBand (IPoIB) (#283), LP: #1848471
    - Allow key configuration for GRE tunnels (#274), LP: #1966476
    - Allow setting the regulatory domain (#281), LP: #1951586
    - Documentation improvements & restructuring (#287)
    - Add meson build system (#268)
    - Add abigail ABI compatibility checker (#269)
    - Update of Fedora RPM spec (#264)
    - CI improvements (#265, #282)
    - Netplan `set` uses the consolidated libnetplan YAML parser (#254)
    - Refactor ConfigManager to use the libnetplan YAML parser (#255)
    - New `netplan_netdef_get_filepath` API (#275)
    - Improve NetworkManager device management logic (#276), LP: #1951653
    Bug fixes:
    - Fix `apply` netdev rename/create race condition (#260), LP: #1962095
    - Fix `try` timeout (#271), LP: #1967084
    - Fix infinite timeouts in ovs-vsctl (#266), Closes: #1000137
    - Fix offload options using tristate setting (#270), LP: #1956264
    - Fix rendering of NetworkManager passthrough WPA (#279), LP: #1972800
    - Fix CLI crash on LibNetplanException (#286)
    - Fix NetworkManager internal DHCP client lease lookup (#284), LP: #1979674
  * Update symbols file for 0.105
  * d/patches/: Drop patches, applied upstream
  * d/p/autopkgtest-fixes.patch: Refresh
  * d/control: bump Standards-Version, no changes needed
  * d/control, d/tests/control: suggest/add iw for setting a regulatory domain
  * d/control: merge with Debian, dropping deprecated versioned depends
  * d/control: Update Vcs-* tags for Ubuntu
  * d/watch: sync with Debian
  * d/u/metadata: sync with Debian
  * d/tests: partially merge with Debian

 -- Lukas Märdian <email address hidden> Thu, 18 Aug 2022 14:53:33 +0200

Changed in (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.