NetworkManager renderer sometimes requires networkd
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Netplan |
Triaged
|
Medium
|
Unassigned |
Bug Description
On an Armbian trixie box, with netplan.io 0.107-5, I've found that `renderer: NetworkManager` can still require systemd-networkd. That's a problem for me since networkd causes the NICs on this box to disappear [1].
Here's my basic working config:
$ sudo netplan get
network:
version: 2
renderer: NetworkManager
ethernets:
enP4p65s0:
dhcp4: true
If I add things like `mtu: 9000` that affect the device config, netplan writes a .link unit to /run/systemd/
As a result of that file existing, `netplan apply` makes some bad decisions:
- it wants to restart systemd-networkd (that fails because the unit is masked)
- it stops NetworkManager.
IMO netplan shouldn't generate any .link files if it isn't using the networkd renderer - there might be some reason that network is not desirable. In this case, if NM cannot e.g. set the mtu, netplan should reject the configuration.
If that's not possible, the docs should be updated to explain when networks is required, even when other renderers are in use.
Full output of apply:
$ sudo netplan --debug apply
** (generate:3604): DEBUG: 20:19:03.977: starting new processing pass
** (generate:3604): DEBUG: 20:19:03.978: We have some netdefs, pass them through a final round of validation
** (generate:3604): DEBUG: 20:19:03.978: enP4p65s0: setting default backend to 2
** (generate:3604): DEBUG: 20:19:03.978: Configuration is valid
** (generate:3604): DEBUG: 20:19:03.979: Generating output files..
** (generate:3604): DEBUG: 20:19:03.979: networkd: definition enP4p65s0 is not for us (backend 2)
** (generate:3604): DEBUG: 20:19:03.979: Open vSwitch: definition enP4p65s0 is not for us (backend 2)
DEBUG:netplan generated networkd configuration changed, reloading networkd
WARNING:Cannot call Open vSwitch: ovsdb-server.
DEBUG:netplan generated NM configuration changed, restarting NM
** (process:3603): DEBUG: 20:19:04.605: starting new processing pass
** (process:3603): DEBUG: 20:19:04.605: We have some netdefs, pass them through a final round of validation
** (process:3603): DEBUG: 20:19:04.605: enP4p65s0: setting default backend to 2
** (process:3603): DEBUG: 20:19:04.605: Configuration is valid
DEBUG:Merged config:
b''
DEBUG:Link changes: {}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for lan1
DEBUG:netplan triggering .link rules for lan2
** (process:3603): DEBUG: 20:19:04.813: starting new processing pass
** (process:3603): DEBUG: 20:19:04.813: We have some netdefs, pass them through a final round of validation
** (process:3603): DEBUG: 20:19:04.813: enP4p65s0: setting default backend to 2
** (process:3603): DEBUG: 20:19:04.813: Configuration is valid
** (process:3603): DEBUG: 20:19:04.813: starting new processing pass
** (process:3603): DEBUG: 20:19:04.813: We have some netdefs, pass them through a final round of validation
** (process:3603): DEBUG: 20:19:04.813: enP4p65s0: setting default backend to 2
** (process:3603): DEBUG: 20:19:04.813: Configuration is valid
DEBUG:Merged config:
b''
systemd-networkd is not running, output might be incomplete.
Failed to reload network settings: Unit dbus-org.
WARNING:Falling back to a hard restart of systemd-
Failed to restart systemd-
Traceback (most recent call last):
File "/usr/share/
utils.
File "/usr/share/
subproces
File "/usr/lib/
raise CalledProcessEr
subprocess.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/
netplan.
File "/usr/share/
self.
File "/usr/share/
self.func()
File "/usr/share/
self.
File "/usr/share/
self.func()
File "/usr/share/
utils.
File "/usr/share/
subproces
File "/usr/lib/
raise CalledProcessEr
subprocess.
[1] - Yea really. On subsequent reboots, the PCIe links never come up, so the interfaces can't become active. I'm still trying to track that down.
The .link files are actually udev configuration, not systemd-networkd (https:/ /www.freedeskto p.org/software/ systemd/ man/latest/ systemd. link.html).
But you're right that we should not try to attempt to reload systemd-networkd if no .network configuration was changed (but only .link configuration). Therefore, avoiding the crash.