[gentoo-amd64] Re: Systemd migration: opinion and questions

[Duncan]

Marc Joliet posted on Wed, 20 May 2015 10:01:13 +0200 as excerpted:

> A few days ago I finally got around to giving systemd-networkd a whirl,
> as I said I would in the sub-thread started by Rich.  It turns out that
> it fulfils the needs of my computers just fine, and has (together with
> systemd-resolved) fully replaced netctl.  The only thing I'm not sure of
> is how extensive IPv6 support is.  The man page suggests that only
> DHCPv6 is supported, but not stateless configuration.  Not that my LAN
> has IPv6, but it'd be nice to know how future proof it is.

I don't recall whether you mentioned whether you're running stable or 
~arch, and I didn't see mention of the version of systemd you're running 
now, but FWIW...

I'm ~arch, but am still on systemd-218 (-r3), while 219 is latest ~arch.  
This is for two reasons you may find interesting, one of which pertains 
to networkd and thus to the quoted bit, above:

Networkd: 219's networkd apparently breaks at least some (maybe static-IP-
only?) IPv4 only setups.  There's a complaint about lack of IPv6 support 
(duh! it's disabled on purpose as I don't use it, to avoid having to 
worry about securing it!), and the interface is not brought up.  The 
upstream bug (filed by someone else, with another report as well before 
mine, making me the third person reporting being affected) and gentoo bug 
(mine) are:

https://bugs.freedesktop.org/show_bug.cgi?id=90103

https://bugs.gentoo.org/show_bug.cgi?id=548380

So far no comment from upstream, but at least I know others are seeing it 
too.  The original reporter had disabled IPv6 with a kernel boot 
parameter, which hints at a more mainstream distro with a prebuilt binary 
kernel and modules shipped, while I have CONFIG_IPV6 unset in my of 
course custom-configured-and-built kernel here on gentoo.

So contrary to your wondering, IPv4 support in the present and near-
future may actually be a rather more pressing concern than IPv6 in the 
longer-term future. =:^(

Hopefully that bug will be fixed for 220, as broken network connectivity 
is rather critical, but the lack of even a developer comment in the month 
since filing isn't particularly encouraging.  But I have a static IP 
assigned and since I switched to systemd a version or two before the 
introduction of networkd, and was using a simple custom network.service 
unit at that time (not too difficult and easily enough googled, with a 
static IP), I figure worst-case, I simply dig that up again...  Tho I 
really can't imagine them leaving IPv4 broken, even if it's only for 
people who don't have IPv6 enabled.

One reporter did say he was able to bring up his network manually.  I 
didn't try that; I simply reverted to 218 and have masked succeeding 219+ 
versions after trying them and not finding a fix.  But that does indicate 
that my alternative network.service approach should work.


Meanwhile, the second bug affecting me in systemd-219...

Btrfs and tmpfiles.d: systemd-219 was supposed to add better btrfs 
support, since btrfs and in particular its subvolume support figures so 
strongly in the systemd "big picture" plan.  Unfortunately, systemd's 
first rollout of btrfs specific features has a few bugs, the one I ran 
across involving the new tmpfiles.d btrfs specific features.

In 219, systemd/tmpfiles.d introduces support for a new type key-letter, 
"v".  On "legacy" filesystems, "v" is supposed to act just like "d", 
create the given directory if it doesn't exist yet.  On btrfs, however, 
"v" creates a subvolume at that location instead, relying on the fact 
that btrfs subvolumes normally function much like directories, except 
with a few btrfs-specific features that normal directories don't have.

And 219 ships a couple tmpfiles.d dropin files that make use of "v" in 
place of "d", creating subvolumes on new btrfs where they (or 
directories) don't already exist, while it creates directories on 
"legacy" filesystems.

The problem?  An attempted directory-create of an existing directory, on 
a read-only filesystem (my / is kept read-only by default, I only mount 
it read-write to update it), succeeds.  An attempted subvolume create, 
where there's an existing (normal) directory, on a read-only (btrfs) 
filesystem, fails.

With that failure, systemd-tmpfiles-setup.service, run at boot (pulled in 
by sysinit.target), fails.

https://bugs.freedesktop.org/show_bug.cgi?id=90281

Status: resolved/fixed, with the git commit listed/linked, less than two 
weeks after filing.  =:^) Tho of course a release with the fix hasn't yet 
been made, and a fix in under two weeks there without even a comment in 
over a month on the IPv4-only bug doesn't bode so well for the latter.
=:^(

Of course a quick edit of the affected tmpfiles.d files, turning "v" to 
"d" where appropriate, would work around this issue, and now there's a 
patch-fix I could apply pretty easily as well, but I haven't bothered due 
to the above networkd bug.  I've simply masked each new 219+ ebuild after 
trying it to see if the two bugs are fixed yet, and thus remain on 218 
for now.

So while 218 worked well for me, 219 has been rough and remains masked, 
here.  We'll see how 220 turns out, when it's released and a gentoo ebuild 
for it becomes available...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman