Bug 1197204

I disagree with this.

Generally I think it would be a wise idea to enforce a clear ownership scheme for /etc/resolv.conf: make it a symlink that points to the file managed by your network managament solution of choice, and ownership is clear.

Secondly, constantly writing to /etc is a really bad idea anyway, hence your network management solution of choice should write to a file in /run or so, and make the version a symlink in /etc a fixed symlinks.

But most importantly, and ignoring all of the above: systemd only creates the symlink as fallback when nothing else created it. This logic is only ever relevant when /etc is entirely unpopulated at boot. This is safe since networking with a non-existing /etc/resolv.conf doesn't really work.

A normal system will never even see this behaviour as /etc is installed populated. An empty /etc is seen only on specialized "state-less" systems where /etc is entirely emptied out.

Sorry, but I don't consider this a bug, and will hence close this WONTFIX.

Note this originated in https://bugzilla.redhat.com/show_bug.cgi?id=1116651

Lennart, the problem isn't quite that simple, because in order to support pre-boot configuration in kickstart (via %post), systemd-tmpfiles ends up being run *before* the system is actually booted.

In the %post environment we do want things to look populated for scripts to be able to run, etc.

And in fact, what's invoking this is `systemd.spec' has a `%post` that runs `systemd-tmpfiles --create >/dev/null 2>&1 || :` among other things.

If we're saying that tmpfiles shouldn't run until the system is actually booted, we could do something like this in systemd.spec's `%post`:

if test -z "${ANACONDA_INSTALL}"; then
  systemd-tmpfiles --create >/dev/null 2>&1 || :
fi

However, this is likely to have large ramifications.

(In reply to Colin Walters from comment #3)
> If we're saying that tmpfiles shouldn't run until the system is actually
> booted, we could do something like this in systemd.spec's `%post`:
> 
> if test -z "${ANACONDA_INSTALL}"; then
>   systemd-tmpfiles --create >/dev/null 2>&1 || :
> fi
> 
> However, this is likely to have large ramifications.
Yeah, this kind of change would most likely have to be propagated "downwards" to other packages which would suddenly encounter a different fs layout than expected. I'd expect this to be a source of annoying bugs.

We really should solve this between systemd and anaconda, without making any changes visible to any other package.

I'm reopening based on comment #3 and comment #4.

So this is still breaking Atomic in Fedora.

I think systemd-tmpfiles needs to grow some knowledge about whether it's being used in an "installroot", or whether it's actually running on boot.

Things like the resolv.conf handling should then only happen on real boots.

But it'd still be better yet for this specific case I think if systemd-networkd took ownership of resolv.conf when it started, not via tmpfiles.

Example failed image build: http://koji.fedoraproject.org/koji/taskinfo?taskID=9816824

(In reply to Colin Walters from comment #6)
> Things like the resolv.conf handling should then only happen on real boots.
OK, what about the following patch:

--- tmpfiles.d/etc.conf.m4
+++ tmpfiles.d/etc.conf.m4
@@ -11,7 +11,7 @@ L /etc/os-release - - - - ../usr/lib/os-release
 L /etc/localtime - - - - ../usr/share/zoneinfo/UTC
 L+ /etc/mtab - - - - ../proc/self/mounts
 m4_ifdef(`ENABLE_RESOLVED',
-L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf
+L! /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf
 )m4_dnl
 C /etc/nsswitch.conf - - - -
 m4_ifdef(`HAVE_PAM',

?

Oh, '!' already exists, I didn't know that.  Looks like it will work to me.  I'll test it now.

Confirmed that patch will fix the bug.

I built a local tree with current systemd and kickstart, verified it failed locally with the same symptom.

Then I built a local systemd with that patch, composed an ostree tree from it, then pointed the rawhide installer at it, and it worked.

OK, thanks for testing. This should land in rawhide shortly: http://cgit.freedesktop.org/systemd/systemd/commit/?id=6921bf11fa.

*** Bug 1203482 has been marked as a duplicate of this bug. ***

This seems to be back in recent Rawhide nightlies. Once again /etc/resolv.conf is a symlink to a systemd location that does not exist, so NetworkManager fails to overwrite it:

Sep 18 15:45:24 localhost NetworkManager[1417]: <info>  DNS: using resolv.conf manager 'none'
Sep 18 15:45:28 localhost NetworkManager[1417]: <warn>  could not commit DNS changes: Could not stat /etc/resolv.conf: No such file or directory

/etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf , which does not exist. See https://bugzilla.redhat.com/show_bug.cgi?id=1264364 .

Note, I'm not sure this fix ever did exactly what we thought it did, as even on Fedora 23 Beta, a systemd-tmpfiles-setup.service that runs early in boot (before NetworkManager) does try and create a /etc/resolv.conf , then immediately tries to remove it(?) But somehow on F23 NetworkManager manages to handle this, while on current Rawhide it doesn't. See https://bugzilla.redhat.com/show_bug.cgi?id=1264364 for more details, I'm still looking into it.

https://github.com/projectatomic/rpm-ostree/pull/1464