| 2021-09-30 08:54:32 |
Christian Ehrhardt |
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-${at_group_normalized} sh <<-"HERE"
{ { { { 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.dir/at-groups/1/stderr 2021-09-07 17:30:19.138802912 +0000
@@ -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-0b5d-4a74-82e3-a68b9c65a50f) successfully deleted.
1. rhbz1773809.at:1: 1. NM overrides interface on reload (rhbz1773809.at:1): FAILED (rhbz1773809.at:9)
Example log:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/f/firewalld/20210907_173449_632a0@/log.gz
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://paste.ubuntu.com/p/9HC4M3x7cH/
<LocutusOfBorg> we are also not alone in that managed issue https://tracker.ceph.com/issues/45459
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.14/NM=1.22.10-1ubuntu2.2, the test doesn't do what it appears to do. That is, the nmcli commands executed in the netns DO NOT create the dummy interface in the netns, it is created in the HOST namespace. Verify with "ip
<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://paste.ubuntu.com/p/8Vj59v9YBB/
<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)
Thanks to TJ and Gianfranco!
... tagging update-excuse |
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-${at_group_normalized} sh <<-"HERE"
{ { { { 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.dir/at-groups/1/stderr 2021-09-07 17:30:19.138802912 +0000
@@ -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-0b5d-4a74-82e3-a68b9c65a50f) successfully deleted.
1. rhbz1773809.at:1: 1. NM overrides interface on reload (rhbz1773809.at:1): FAILED (rhbz1773809.at:9)
Example log:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/f/firewalld/20210907_173449_632a0@/log.gz
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://paste.ubuntu.com/p/9HC4M3x7cH/
<LocutusOfBorg> we are also not alone in that managed issue https://tracker.ceph.com/issues/45459
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.14/NM=1.22.10-1ubuntu2.2, the test doesn't do what it appears to do. That is, the nmcli commands executed in the netns DO NOT create the dummy interface in the netns, it is created in the HOST namespace. Verify with "ip
<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://paste.ubuntu.com/p/8Vj59v9YBB/
<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 |
|
