[Bug 1945596] Re: Autopkgtest fail of 1.0.1-2ubuntu3 - Activation failed because the device is unmanaged

Ubuntu Foundations Team Bug Bot 1945596 at bugs.launchpad.net
Sat Nov 6 00:25:38 UTC 2021


The attachment "firewalld-1_1.0.1-2ubuntu3_1.0.1-2ubuntu4.debdiff" seems
to be a debdiff.  The ubuntu-sponsors team has been subscribed to the
bug report so that they can review and hopefully sponsor the debdiff.
If the attachment isn't a patch, please remove the "patch" flag from the
attachment, remove the "patch" tag, and if you are member of the
~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]

** Tags added: patch

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1945596

Title:
  Autopkgtest fail of 1.0.1-2ubuntu3 - Activation failed because the
  device is unmanaged

Status in firewalld package in Ubuntu:
  Confirmed

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-${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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1945596/+subscriptions




More information about the Ubuntu-sponsors mailing list