Bug 628219

Summary: error : virRunWithHook:857 : internal error '/sbin/iptables --table mangle --insert POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' exited with non-zero status 2
Product: [Fedora] Fedora Reporter: Tom London <selinux>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: aquini, berrange, clalance, crobinso, itamar, jforbes, laine, mjevans1983, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-27 12:36:39 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Tom London 2010-08-28 12:53:37 EDT
Description of problem:
Notice the following spew in /var/log/messages.

Not sure its a problem, but thought I would log it....

Aug 28 07:03:38 tlondon libvirtd: 07:03:38.639: error : virRunWithHook:857 : internal error '/sbin/iptables --table mangle --insert POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' exited with non-zero status 2 and signal 0: iptables v1.4.9: unknown option `--checksum-fill'#012Try `iptables -h' or 'iptables --help' for more information.#012
Aug 28 07:03:38 tlondon libvirtd: 07:03:38.641: warning : networkAddIptablesRules:850 : Could not add rule to fixup DHCP response checksums on network 'default'.
Aug 28 07:03:38 tlondon libvirtd: 07:03:38.641: warning : networkAddIptablesRules:851 : May need to update iptables package & kernel to support CHECKSUM rule.

Version-Release number of selected component (if applicable):

How reproducible:
Appears every boot/libvirtd start

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Michael J Evans 2010-09-18 01:28:20 EDT
On my (generic linux) system this combines with an issue in creating any kind of routed network to preclude /any/ networking of virtual systems.

Severity should be increased proportionately since this is the default use case.

(Error when creating a network 'bridged', DHCP disabled, forwarding route to eth0)

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/createnet.py", line 357, in finish
  File "/usr/share/virt-manager/virtManager/connection.py", line 742, in create_network
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 866, in create
    if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
libvirtError: internal error '/sbin/iptables --table filter --delete INPUT --in-interface virbr1 --protocol udp --destination-port 69 --jump ACCEPT' exited with non-zero status 1 and signal 0: iptables: Bad rule (does a matching rule exist in that chain?).
Comment 2 Laine Stump 2010-10-27 12:36:39 EDT
One bug report, two separate issues.

The original reported message (by Tom London) is just informational - see Bug 642355. I'm closing this bug as a duplicate of Bug 642355. Basically the answer is that it's harmless, and will go away if, as the warning log suggests, you update iptables.

As for the error listed in Comment 1 (by Michael J Evans), it is unrelated to the original report, is most likely an ancillary error encountered during the cleanup of a failure to start the network, and thus is obscuring the actual error. See:


which was added to upstream libvirt in this commit:

commit d68bb70a2d606b7206e78c360cbd4cf62b070493
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Tue Oct 26 11:17:25 2010 +0100

    Avoid squashing errors during network startup cleanup path
    When failing to start a virtual network, we have to cleanup,
    tearing down any iptables rules. If the iptables rules were
    not present yet though, this raises an error, which squashes
    the original error we were handling.
    * src/network/bridge_driver.c: When failing to start a virtual
      network, don't squash the original error in cleanup

You maybe get more complete information with your current libvirt from "grep libvirtd /var/log/messages". Or, if you're able to build from source, grab the latest libvirt source from git (or the upcoming 0.8.5 release), build and install, and the *real* error should show up in the logs.

After you've collected that information, rather than filing a bug against Fedora, it would probably be more productive to either file a bug against the Linux distro you are using (you say "generic Linux", leading me to believe it's not Fedora), or if there is no appropriate bug tracker for that, against upstream libvirt (since it's not a Fedora-specific problem); the latter can be done in bugzilla.redhat.com, by filing under "Other" / "Virtualization Tools" / "libvirt". (when you do so, don't forget to attach your domain and network config XML files)

(BTW, since a total failure of networking to work is something that would likely be noticed by regression testing prior to release, it's highly likely you have a configuration problem that could be solved by getting help from the people on libvirt's IRC channel - see libvirt.org for details).

*** This bug has been marked as a duplicate of bug 642355 ***