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: | libvirt | Assignee: | Daniel Veillard <veillard> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | aquini, berrange, clalance, crobinso, itamar, jforbes, laine, mjevans1983, veillard, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-10-27 16:36:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tom London
2010-08-28 16:53:37 UTC
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' 10.255.255.0/24, DHCP disabled, forwarding route to eth0) Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/createnet.py", line 357, in finish self.conn.create_network(xml) File "/usr/share/virt-manager/virtManager/connection.py", line 742, in create_network net.create() 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?). 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: https://www.redhat.com/archives/libvir-list/2010-October/msg00997.html which was added to upstream libvirt in this commit: commit d68bb70a2d606b7206e78c360cbd4cf62b070493 Author: Daniel P. Berrange <berrange> 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 *** |