Your message dated Fri, 11 Dec 2020 12:50:40 -0500
with message-id <[email protected]>
and subject line Re: missing ebtables dependency
has caused the Debian Bug report #935313,
regarding missing ebtables dependency
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
935313: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935313
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libvirt-daemon
Version: 5.0.0-4
Severity: grave
File: /usr/sbin/libvirtd

Vagrant, using the libvirt backend, started failing me recently, with
something like this:

anarcat@curie:stretch64(master)$ vagrant up --provider libvirt
Bringing machine 'default' up with 'libvirt' provider...
==> default: Checking if box 'debian/stretch64' version '9.9.0' is up to date...
Error while activating network: Call to virNetworkCreate failed: internal 
error: Failed to initialize a valid firewall backend.
[1]anarcat@curie:stretch64(master)$ 

Syslog had more details, but nothing really informative:

aoû 21 09:24:16 curie NetworkManager[819]: <info>  [1566393856.0718] manager: 
(virbr1): new Bridge device (/org/freedesktop/NetworkManager/Devices/5) 
aoû 21 09:24:16 curie systemd-udevd[24139]: Using default interface naming 
scheme 'v240'. 
aoû 21 09:24:16 curie systemd-udevd[24139]: link_config: autonegotiation is 
unset or enabled, the speed and duplex are not writable. 
aoû 21 09:24:16 curie systemd-udevd[24139]: Could not generate persistent MAC 
address for virbr1: No such file or directory 
aoû 21 09:24:16 curie kernel: tun: Universal TUN/TAP device driver, 1.6 
aoû 21 09:24:16 curie NetworkManager[819]: <info>  [1566393856.0795] manager: 
(virbr1-nic): new Tun device (/org/freedesktop/NetworkManager/Devices/6) 
aoû 21 09:24:16 curie systemd-udevd[24144]: Using default interface naming 
scheme 'v240'. 
aoû 21 09:24:16 curie systemd-udevd[24144]: link_config: autonegotiation is 
unset or enabled, the speed and duplex are not writable. 
aoû 21 09:24:16 curie libvirtd[1862]: internal error: Failed to initialize a 
valid firewall backend 
aoû 21 09:24:16 curie kernel: virbr1: port 1(virbr1-nic) entered blocking state 
aoû 21 09:24:16 curie kernel: virbr1: port 1(virbr1-nic) entered disabled state 
aoû 21 09:24:16 curie kernel: device virbr1-nic entered promiscuous mode 
aoû 21 09:24:16 curie kernel: device virbr1-nic left promiscuous mode 
aoû 21 09:24:16 curie kernel: virbr1: port 1(virbr1-nic) entered disabled state 
aoû 21 09:24:16 curie systemd[3139]: Starting pull emails with syncmaildir... 
aoû 21 09:24:16 curie NetworkManager[819]: <info>  [1566393856.1114] device 
(virbr1-nic): released from master device virbr1 
aoû 21 09:24:16 curie libvirtd[1862]: Failed to open file 
'/sys/class/net/virbr1-nic/operstate': Aucun fichier ou dossier de ce type 
aoû 21 09:24:16 curie libvirtd[1862]: unable to read: 
/sys/class/net/virbr1-nic/operstate: Aucun fichier ou dossier de ce type 

Restarting libvirtd, however, did provide some insightful input:

aoû 21 10:10:05 curie systemd[1]: Starting Virtualization daemon...
aoû 21 10:10:05 curie libvirtd[31223]: libvirt version: 5.0.0, package: 4 
(Guido Günther <[email protected]> Mon, 17 Jun 2019 19:05:40 +0200)
aoû 21 10:10:05 curie libvirtd[31223]: hostname: curie
aoû 21 10:10:05 curie libvirtd[31223]: Libvirt doesn't support VirtualBox API 
version 6000010
aoû 21 10:10:05 curie systemd[1]: Started Virtualization daemon.
aoû 21 10:10:05 curie libvirtd[31223]: direct firewall backend requested, but 
/usr/sbin/ebtables is not available: Aucun fichier ou dossier de ce type
aoû 21 10:10:05 curie libvirtd[31223]: internal error: Failed to initialize a 
valid firewall backend

`apt install ebtables` fixed this problem, so I feel this should be
marked as a runtime dependency for the package. Obviously, it would be
better to migrate to nftables, but that's another story...

a.

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon depends on:
ii  libacl1             2.2.53-4
ii  libapparmor1        2.13.2-10
ii  libaudit1           1:2.8.4-3
ii  libavahi-client3    0.7-4+b1
ii  libavahi-common3    0.7-4+b1
ii  libblkid1           2.33.1-0.1
ii  libc6               2.28-10
ii  libcap-ng0          0.7.9-2
ii  libcurl3-gnutls     7.64.0-4
ii  libdbus-1-3         1.12.16-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libfuse2            2.9.9-1
ii  libgcc1             1:8.3.0-6
ii  libgnutls30         3.6.7-4
ii  libnetcf1           1:0.2.8-1+b2
ii  libnl-3-200         3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma1            2.0.12-1
ii  libparted2          3.2-25
ii  libpcap0.8          1.8.1-6
ii  libpciaccess0       0.14-1
ii  libsasl2-2          2.1.27+dfsg-1
ii  libselinux1         2.8-1+b1
ii  libssh2-1           1.8.0-2.1
ii  libudev1            241-5
ii  libvirt0            5.0.0-4
ii  libxenmisc4.11      4.11.1+92-g6c33308a8d-2
ii  libxenstore3.0      4.11.1+92-g6c33308a8d-2
ii  libxentoollog1      4.11.1+92-g6c33308a8d-2
ii  libxml2             2.9.4+dfsg1-7+b3
ii  libyajl2            2.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.195-2
ii  qemu-kvm        1:3.1+dfsg-8~deb10u1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  <none>
pn  libvirt-daemon-driver-storage-rbd      <none>
pn  libvirt-daemon-driver-storage-zfs      <none>
ii  libvirt-daemon-system                  5.0.0-4
pn  numad                                  <none>

-- debconf-show failed

--- End Message ---
--- Begin Message ---
Hum. it's been a while now! :) I don't know what happened, but I can't
reproduce this anymore: i don't have ebtables installed anymore, yet I
can start the VM just right.

I guess this bug can be closed...

a.

On 2020-12-10 12:32:30, Paul Gevers wrote:
> Hi,
>
> @Gabriel, the BTS doesn't automatically forward replies to bugs to the
> submitter, if you want feedback, you need to send it manually.
>
> @Antoine, can you please give the feedback still?
>
> Paul
>
> On Fri, 23 Aug 2019 00:07:29 -0400 Gabriel Filion <[email protected]>
> wrote:
>> Hello,
>> 
>> On Wed, 21 Aug 2019 10:16:26 -0400 Antoine Beaupre <[email protected]>
>> wrote:
>> > Vagrant, using the libvirt backend, started failing me recently, with
>> > something like this:
>> > 
>> > anarcat@curie:stretch64(master)$ vagrant up --provider libvirt
>> > Bringing machine 'default' up with 'libvirt' provider...
>> > ==> default: Checking if box 'debian/stretch64' version '9.9.0' is up to 
>> > date...
>> > Error while activating network: Call to virNetworkCreate failed: internal 
>> > error: Failed to initialize a valid firewall backend.
>> > [1]anarcat@curie:stretch64(master)$ 
>> 
>> > Restarting libvirtd, however, did provide some insightful input:
>> > 
>> > [...]
>> > aoû 21 10:10:05 curie systemd[1]: Started Virtualization daemon.
>> > aoû 21 10:10:05 curie libvirtd[31223]: direct firewall backend requested, 
>> > but /usr/sbin/ebtables is not available: Aucun fichier ou dossier de ce 
>> > type
>> > aoû 21 10:10:05 curie libvirtd[31223]: internal error: Failed to 
>> > initialize a valid firewall backend
>> 
>> fwiw I'm running vagrant + libvirt + vagrant-libvirt in debian sid and I
>> don't have the ebtables package installed. networking is still functioning.
>> 
>> Since buster, nftables is now used by default. the iptables package is
>> now installing nftables wrappers so that one is not mixing nftables with
>> iptables kernel subsystems.
>> 
>> # update-alternatives --list ebtables
>> /usr/sbin/ebtables-nft
>> 
>> $ dpkg -S /usr/sbin/ebtables-nft
>> iptables: /usr/sbin/ebtables-nft
>> 
>> that would explain why the libvirt package does not depend on the
>> ebtables package.
>> 
>> 
>> is it possible that your "alternative" for ebtables was somehow blasted
>> out? e.g. if you try removing the ebtables package and then running:
>> 
>> # update-alternatives --set ebtables /usr/sbin/ebtables-nft
>> 
>> does it make your libvirt setup function properly?
>> 
>> if so, then maybe you might want to check other "alternatives" provided
>> by iptables so that they use the nftables wrappers. Here's what I have
>> on my system:
>> 
>> $ ls -l /etc/alternatives/|grep -- -nft
>> lrwxrwxrwx 1 root root  23 Dec 22  2018 arptables -> /usr/sbin/arptables-nft
>> lrwxrwxrwx 1 root root  31 Dec 22  2018 arptables-restore ->
>> /usr/sbin/arptables-nft-restore
>> lrwxrwxrwx 1 root root  28 Dec 22  2018 arptables-save ->
>> /usr/sbin/arptables-nft-save
>> lrwxrwxrwx 1 root root  22 Dec 22  2018 ebtables -> /usr/sbin/ebtables-nft
>> lrwxrwxrwx 1 root root  30 Dec 22  2018 ebtables-restore ->
>> /usr/sbin/ebtables-nft-restore
>> lrwxrwxrwx 1 root root  27 Dec 22  2018 ebtables-save ->
>> /usr/sbin/ebtables-nft-save
>> lrwxrwxrwx 1 root root  23 Dec 22  2018 ip6tables -> /usr/sbin/ip6tables-nft
>

-- 
Like slavery and apartheid, poverty is not natural. It is man-made and
it can be overcome and eradicated by the actions of human
beings. Overcoming poverty is not a gesture of charity. It is an act
of justice.             - Nelson Mandela

--- End Message ---

Reply via email to