Description of problem: On current Fedora Rawhide, service firewalld appears to run as expected according to command 'systemctl status firewalld', but the behaviour of command 'firewall-cmd' is weird, e.g. no default zone and no active zone is listed even when a wired interface is active, and the log file /var/log/firewalld gets filled with error messages upon running firewall-cmd, e.g. like: "2019-02-05 15:19:51 ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'. 2019-02-05 15:19:51 ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'. 2019-02-05 15:19:51 ERROR: COMMAND_FAILED: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'. 2019-02-05 15:19:53 ERROR: INVALID_ZONE 2019-02-05 10:30:19 ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore: line 11 failed 2019-02-05 10:30:19 ERROR: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore: line 11 failed 2019-02-05 10:30:19 ERROR: COMMAND_FAILED: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore: line 11 failed" Version-Release number of selected component (if applicable): firewalld-0.6.3-1.fc30 How reproducible: Always Steps to Reproduce: 1. Boot current Fedora Rawhide live media. 2. Query default zone and active zones when wired connection is up. 3. Run 'firewall-cmd set --default-zone public'. Actual results: Command 'firewall-cmd' reports errors. Expected results: Command 'firewall-cmd' runs as expected. Additional info: - Despite the error message, 'firewall-cmd get --default-zone public' no returns "public" but still no active zones. - Fedora 29 works as expected.
This was also reported on freenode, but I was unable to reproduce. Can you downgrade ebtables and then retry?
(In reply to Eric Garver from comment #1) 1. In order to reproduce this issue boot a recent live media, e.g. Fedora-Workstation-Live-x86_64-Rawhide-20190204.n.0, on bare metal or in gnome-boxes. After the GNOME desktop has come up (wired connection activated), log file /var/log/firewalld already shows the following entries: .. ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'. .. ERROR: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'. .. ERROR: COMMAND_FAILED: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'. .. ERROR: INVALID_ZONE 2. Downgrading package ebtables from ebtables-2.0.10-29.fc30 to ebtables-2.0.10-28.fc29 and restarting service "firewalld" restores normal operation. The last entry in the corresponding changelog reads: "* Mon Jan 21 2019 David Abdurachmanov <david abdurachmanov gmail com> 2.0.10-29 - Disable --as-needed to resolve segfaults".
*** Bug 1673625 has been marked as a duplicate of this bug. ***
I have no idea _why_ reverting to -28 would fix this, but I can confirm that it does. Searching shows that Ubuntu has this issue open as well: https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1672276 ... which implicate their patch (to disable --as-needed in one place) that we applied in -29. So I got rid of that patch and simply disabled --as-needed everywhere in ebtables (%undefine _ld_as_needed) and that build works again.
Rawhide build with fix: https://koji.fedoraproject.org/koji/taskinfo?taskID=32610662 (keep in mind that rawhide is really slowly tagging builds right now... very slowly)
It's built now, please pull it out of koji and confirm that it fixes things for you.
Build ebtables-2.0.10-31.fc30 restores normal operation of utility firewall-cmd.
*** Bug 1674076 has been marked as a duplicate of this bug. ***
Discussed during the 2019-02-11 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made: "accepted as a blocker per Basic criterion "...Supported install-time firewall configuration options must work correctly."" [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2019-02-11/f30-blocker-review.2019-02-11-17.13.log.txt
All firewall tests passed in last Rawhide compose test in openQA, so closing.