See upstream bug in URL, reported and seconded by others (with me now CCed). IPv4-only systems break with systemd-219's networkd, altho they worked fine with systemd-218. Hopefully upstream will have a patch we can add in good time, but meanwhile, other gentooers might find this filing helpful. FWIW, I've been trying every 219-rX bump and now 219_p112 as well, but I actually had time to look into it with the p112 update tonite.
Please try the following patch: http://cgit.freedesktop.org/systemd/systemd/commit/?id=fe0272999c8ef7961a446a7743f824ba4cfe0918
(In reply to Alexander Tsoy from comment #1) > Please try the following patch: Tested with 219_p112. Didn't work. With the patch applied I no longer see a forwarding error, and systemd-networkd.service seems to start fine (it doesn't return an error), but the interface never-the-less doesn't come up. systemctl status systemd-networkd.service shows these messages (I have interface renaming turned off as eth0 /is/ the stable name on a decade-plus old system that has gone thru multiple mobos and thus ethernet devices and associated pcie slot positionings in that time; also, the timestamp, networkd prefix and extra whitespace trimmed for posting): eth0: eth0: could not bring up interface: Address family not supported by protocol eth0: eth0: could not set route: Network is unreachable eth0: link configured But, taking a hint from the upstream bug, I can ifconfig eth0 up, and it'll come up, configured appropriately. Networkd does apparently find and configure the interface; it just refuses to bring it up, as apparently it thinks IPv6 is all there is, despite configuring only an IPv4 address. (Meanwhile, 220 is out upstream now. I'll test it when gentoo has an ebuild for it to test. In the mean time, with a different tmpfiles.d on btrfs bug patched that I reported upstream but not here, I can live with either doing a manual ifconfig up, or setting up yet another service to do it for me, if necessary, and thus believe I'll stick with 219_p112 for now, instead of reverting to 218-r3 again.)
Well, I finally stole time from sleep to bisect it over nite, and (as I already updated the upstream bug to reflect), the culprit commit is: commit 7f77697 networkd: add support for IPv6 tokens Other commits build on that one and it's too complex to simply revert, or for me to easily figure out from there, but at least we have a culprit commit now, which should make finding the problem much easier. =:^) Maybe I can make sense of it after some sleep; I certainly can't ATM, but there it is in case anyone wants to surprise me and have a fix by the time I can look at it again. =:^)
Created attachment 404008 [details, diff] upstream patch: networkd-test-for-ipv6-b4-ipv6-opts.patch (In reply to Duncan from comment #3) > [Bisected and] the culprit commit is: > > commit 7f77697 > networkd: add support for IPv6 tokens Upstream committed patch, commit 01d28f81, confirmed fix, attached. =:^) Fast fix once bisected! =:^) Unfortunately not fast enough to make 220, which was out before I could bisect, but it's in upstream git and tested to fix 220 for me, now. =:^) As the commit note says, IFF_UP fails when IPv6 options are passed (even if they'd be noops) but IPv6 is disabled. So the patch tests for IPv6 availability before passing such options, thus allowing the link_up function to continue to success instead of erring out, when IPv6 isn't there to use. Please add this patch to 220, and 219 if there's any more revisions. It should be in 221. Thanks. Duncan
we now have 225 in the tree
