usrmerge changes path of iptables - please update libvirt on a merge of 1.8.1-x

Bug #1832297 reported by Christian Ehrhardt  on 2019-06-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Cloud Archive
iptables (Ubuntu)
libvirt (Ubuntu)

Bug Description

Libvirt has now the paths for ip-/ip6-/eb-tables set in d/rules (by Debian)

But those paths are changing over time, most liikely due to usermerge activities.

Bionic (as common backport target)
iptables 1.6.1-2ubuntu2 => /sbin
ebtables => /sbin

iptables 1.6.1-2ubuntu3 => /sbin
ebtables => /usr/sbin

iptables 1.8.2-4 => all in /usr/sbin
ebtables (bin merged into the above)

Due to that while merging libvirt I adapted to the current situation in Eoan for now.
But this is only catched in build time tests and even there only listed as skip (binary not found) not as fail.
Further at least the autopkgtests won't excercise this path, so once someone is merging the more recent iptables to Eoan this will somewhat silently break.

For awareness I opened this bug against libvirt & iptables so that the one merging the latter is aware to drop [1] of the former for a rebuild.


For further awareness I added a UCA task as back in Bionic the paths are again different.
There also ebtables (which means all three binaries) are in /sbin/

That means on backports to Bionic this path needs to be adapted to match.

tags: added: libvirt-19.10

Hmm things seem to have raced in my build envs and containers.
Fortunately Eoan is already completed

# which ebtables iptables ip6tables

Ok then I can make libvirt to use these now, but this is still important to know for backports to Bionic.

Changed in libvirt (Ubuntu):
status: New → Invalid
Changed in iptables (Ubuntu):
status: New → Fix Released

Hmm interesting ...

/usr/sbin/ebtables is managed by update alternatives.
But iptables continues to surprise.

In an sbuild build env of Eoan I get:
# which ebtables iptables ip6tables

While in an Eoan container I have:
# which ebtables iptables ip6tables

Let me recycle the container as it might have some old crap.
No it stays the same...

Both are on / 1.6.1-2ubuntu3.

To make that three a Eoan VM as of today has the same as the container.

All of them (sbuild+lxd+vm) have the non usr path in the package itself.
dpkg -L iptables | grep 'bin\/iptables$'

And the /usr/sbin path that exists in the container
Hmm, something in the container and the VM brings that /usr/sbin mapping to work which fails in the build environment, maybe because it is "just" a chroot?

/var/lib/dpkg/info/iptables.* has no further magic maintscripts that would explain.

For now in libvirt lets set the real paths as carried by iptables packages.
This will keep us on the safe side.

But that also means we are back at my initial assumption that on an iptables 1.8.1 merge one might want to remove that (unless /sbin/iptables is kept as compat, then I can clear it next cycle).

Changed in libvirt (Ubuntu):
status: Invalid → Triaged
Changed in iptables (Ubuntu):
status: Fix Released → New
Launchpad Janitor (janitor) wrote :
Download full text (9.3 KiB)

This bug was fixed in the package libvirt - 5.4.0-0ubuntu1

libvirt (5.4.0-0ubuntu1) eoan; urgency=medium

  * Merged with Debian git 5.3.0-1~1.gbp7b1637 and upstreams 5.4 release
    Among many other new features and fixes this includes fixes for:
    LP: #1759509 - virsh dompmwakeup fails to wake VM from dompmsuspend state
    Remaining changes:
    - Disable libssh2 support (universe dependency)
    - Disable firewalld support (universe dependency)
    - Set qemu-group to kvm (for compat with older ubuntu)
    - Additional apport package-hook
    - Autostart default bridged network (As upstream does, but not Debian).
      In addition to just enabling it our solution provides:
      + do not autostart if subnet is already taken (e.g. in guests).
      + iterate some alternative subnets before giving up
    - d/p/ubuntu/Allow-libvirt-group-to-access-the-socket.patch: This is
      the group based access to libvirt functions as it was used in Ubuntu
      for quite long.
      + d/p/ubuntu/daemon-augeas-fix-expected.patch fix some related tests
        due to the group access change.
      + d/libvirt-daemon-system.postinst: add users in sudo to the libvirt
    - ubuntu/parallel-shutdown.patch: set parallel shutdown by default.
    - Update Vcs-Git and Vcs-Browser fields to point to launchpad
    - Xen related
      - d/p/ubuntu/ubuntu-libxl-qemu-path.patch: this change was split. The
        section that adapts the path of the emulator to the Debian/Ubuntu
        packaging is kept.
      - d/p/ubuntu/ubuntu-libxl-Fix-up-VRAM-to-minimum-requirements.patch: auto
        set VRAM to minimum requirements
      - d/p/ubuntu/xen-default-uri.patch: set default URI on xen hosts
      - Add libxl log directory
      - Automatically switch default libvirt URI for users on
        Xen dom0 via user profile (was missing on changelogs before)
    - d/p/ubuntu/apibuild-skip-libvirt-common.h: drop libvirt-common.h from
      included_files to avoid build failures due to duplicate definitions.
    - Update README.Debian with Ubuntu changes
    - Enable some additional features on ppc64el and s390x (for arch parity)
      + systemtap, zfs, numa and numad on s390x.
      + systemtap on ppc64el.
    - d/t/control, d/t/smoke-qemu-session: fixup smoke-qemu-session by making
      vmlinuz available and accessible (Debian bug 848314)
    - d/t/control, d/t/smoke-lxc: fix up lxc smoke test isolation
    - d/p/ubuntu/ubuntu_machine_type.patch: accept ubuntu types as pci440fx
    - Further upstreamed apparmor Delta, especially any new one
      Our former delta is split into logical pieces and is either Ubuntu only
      or is part of a continuous upstreaming effort.
      Listing related remaining changes in debian/patches/ubuntu-aa/:
      + 0001-apparmor-Allow-pygrub-to-run-on-Debian-Ubuntu.patch: apparmor:
        Allow pygrub to run on Debian/Ubuntu
      + 0003-apparmor-libvirt-qemu-Allow-read-access-to-overcommi.patch:
        apparmor, libvirt-qemu: Allow read access to overcommit_memory
      + 0007-apparmor-libvirt-qemu-Allow-owner-read-access-to-PRO.patch:
        apparmor, libvirt-qemu: Allow owner read acc...


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

Other bug subscribers