It looks like the iptables-restore command has been renamed in recent versions of iptables. The systemd unit has not been updated to use the new filename, and so it generates the error: iptables-restore.service: Failed at step EXEC spawning /sbin/iptables-restore: No such file or directory The unit should be updated to reference the correct command. Reproducible: Always
/sbin/iptables-restore should be a symlink created/managed by eselect-iptables. The iptables ebuild should run eselect-iptables in pkg_postinst if there is no implementation set.
Can I see the output of "eselect iptables show"?
(In reply to Patrick McLean from comment #2) > Can I see the output of "eselect iptables show"? # eselect iptables show Current iptables symlinks: iptables (unset) iptables-restore (unset) iptables-save (unset) ip6tables (unset) ip6tables-restore (unset) ip6tables-save (unset) That would certainly explain the issue. Now the question is why wasn't it run in postinst?
Ok, checked the emerge log. It ends with: * Current iptables implementation is unset, setting to xtables-legacy-multi !!! Error: Could not create symlink at /sbin/iptables-xml: path exits and is not a symlink exiting Current iptables symlinks: iptables (unset) iptables-restore (unset) iptables-save (unset) ip6tables (unset) ip6tables-restore (unset) ip6tables-save (unset) >>> net-firewall/iptables-1.8.5 merged. Indeed, I have an orphaned iptables-xml binary. Seems like that wasn't cleaned up at some point. It dates to Dec 2008 so I'm guessing whatever problem caused it is long gone. I'll get rid of it and reinstall.
Ok, looks fine after a reinstall with that missing. Maybe the error handling in the eselect script could be improved a little, but I think as it stands this bug isn't really valid. I'll close but feel free to repurpose.
