Autopkgtest fail of 1.0.1-2ubuntu3 - Activation failed because the device is unmanaged
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| firewalld (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Hi,
while I unfortunately didn't find the time to work on it, at least I wanted to document the information I've got from various people as it will give anyone working on this a head start.
The test fails like:
/rhbz1773809.at:9: ip netns exec fwd-test-
{ { { { nmcli connection up dummy0; echo $? >&3; } | sed -e 's/^[ \t]*//' -e 's/[ \t]*$//' | sed -e '/^[ \t]*$/d' | sed -e 's/[ \t]\+/ /g' | { printf "%s" "$(cat /dev/stdin)"; echo; } >&4; } 3>&1; } | { read RC; exit $RC; } } 4>&1
HERE
--- /dev/null 2021-09-07 17:29:45.592000000 +0000
+++ /tmp/testsuite.
@@ -0,0 +1 @@
+Error: Connection activation failed: Activation failed because the device is unmanaged
stdout:
/rhbz1773809.at:9: exit code was 4, expected 0
Connection 'dummy0' (f7940f13-
1. rhbz1773809.at:1: 1. NM overrides interface on reload (rhbz1773809.at:1): FAILED (rhbz1773809.at:9)
Example log:
https:/
While asking if anyone looked at it already Gianfranco had some context already:
<LocutusOfBorg> cpaelzer, please go ahead
<LocutusOfBorg> even upstream is not able to figure that one out
<LocutusOfBorg> its a new test iirc
<LocutusOfBorg> 1: NM overrides interface on reload FAILED (rhbz1773809.at:9)
<LocutusOfBorg> something related to network-manager default config
<LocutusOfBorg> and seems to be not failing in Debian
<LocutusOfBorg> cpaelzer, https:/
<LocutusOfBorg> we are also not alone in that managed issue https:/
And a bit later it became clear that TJ has looked into it even a bit further:
<TJ-> cpaelzer: LocutusOfBorg: have you experimented with issuing the firewalld/NM rhbz1773809.at test manually? Unless I've for something really weird here, on 20.04 with linux=5.
<TJ-> link show/ip netns exec $ns ip link show" after the "nmcli con add ..." command. The commands all succeed (in the parent namespace!) so maybe this test failure now is due to some change in namespace handling? See https:/
<TJ-> cpaelzer: this looks like someone misunderstood things; running nmcli on the namespace doesn't seem to affect NetworkManager daemon running on the host. They communicate over Dbus. So unless nmcli is aware and passes its parent namespace it makes sense. So then the question is, why the change. Look at the NM source-code around the "Activation failed because the device is unmanaged" message -
<TJ-> it suggests some reasons/avenues for investigation (udev is one)
And later:
<LocutusOfBorg> TJ-, cpaelzer looking at the diff, the test previously was exporting some DBUS_SOCKET so maybe it was meant to communicate with the host?
Thanks to TJ and Gianfranco for all the work, all I managed to do on this so far is writing this up :-/
... tagging update-excuse
| tags: | added: update-excuse |
| description: | updated |
| Dan Bungert (dbungert) wrote | #2 |
| Changed in firewalld (Ubuntu): | |
| status: | New → Confirmed |
| Ubuntu Foundations Team Bug Bot (crichton) wrote | #3 |
| tags: | added: patch |
| Launchpad Janitor (janitor) wrote | #4 |
| Changed in firewalld (Ubuntu): | |
| status: | Confirmed → Fix Released |
Here's the reproducer that shows that dummy0 is being created in the host network namespace. This is an upstream bug (oversight) so far as I can tell from its purpose.
At the outset I should say this is not related to the actual cause of the autopkgtest failure - explanation of that at the end of this comment.
# what the host sees initially
root@t300chi:~# nmcli con
NAME UUID TYPE DEVICE
USB3hub 85f05002-
soggy b9e78bf8-
virbr0 b09a6211-
# add the new network namespace
root@t300chi:~# ip netns add test
# run nmcli in the network namespace
root@t300chi:~# ip netns exec test nmcli connection add type dummy con-name dummy0 ifname dummy0 ip4 10.0.0.2 gw4 10.0.0.1
Connection 'dummy0' (2bdfbb93-
# check if the interface has been added - strange, it lists dummy0 and the host interfaces!!
root@t300chi:~# ip netns exec test nmcli con
NAME UUID TYPE DEVICE
dummy0 2bdfbb93-
USB3hub 85f05002-
soggy b9e78bf8-
virbr0 b09a6211-
# activate - note this succeeds on my system for a reason explained below
root@t300chi:~# ip netns exec test nmcli con up dummy0
Connection successfully activated (D-Bus active path: /org/freedeskto
ection/7)
# lets check what interfaces exist in the network namespace
root@t300chi:~# ip netns exec test ip link show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# aha! so dummy0 isn't in the namespace.
# interface is created on the parent network namespace where NetworkManager daemon is
oot@t300chi:~# nmcli con
NAME UUID TYPE DEVICE
dummy0 2bdfbb93-
USB3hub 85f05002-
soggy b9e78bf8-
virbr0 b09a6211-
---
So the expectation that dummy0 is being created in the network namespace is incorrect. nmcli is talking to NetworkManager over DBus which is a daemon in the parent namespace.
Why is it failing on Ubuntu (but not on my system) ?
Due to my override of 10-globally-
root@t300chi:~# ls -l /usr/lib/
-rw-r--r-- 1 root root 80 Sep 27 16:07 /usr/lib/
/etc/NetworkMan
total 4
-rw-r--r-- 1 root root 0 Oct 31 04:48 10-globally-
-rw-r--r-- 1 root root 32 Sep 27 16:07 default-
root@t3...