On 6/30/25 12:31 AM, ProgAndy wrote:
Do you still have problems if you disable the resolved.conf update?
Downgrading openresolv 3.17 => 3.16.5 fixes the problem.
The crux of the issue for me is that the
/etc/netctl/examples/ethernet-static example included a DNS entry which
I filled in as the example expected.
The openresolv code was changed between 3.16.5 and 3.17.0 so that if
that DNS entry is in your netctl config file and thee signature at the
top of /etc/resolv.conf isn't one that openresolv recognized, or
openresolv couldn't write to /etc/resolv.conf -- the 3.17 version marked
that network startup unit as FAILED and took down the running network.
This also impacted users or wiregruard.
On suggestion by the openresolv maintainer, I removed, the DNS entry
from the netctl configuration file, and that caused openresolv to ignore
the fact it couldn't write to /etc/resolv.conf. So I can use 3.17.0 now.
There are a couple solutions being considered, but simply having some
documentation explaining the side-effect of the DNS entry in the netctl
config would have been sufficient for my issue.
The big issue is there is no clearly documented way to turn off
modification of /etc/resolv.conf for those who self-admin that file on
servers and the like. I'm pushing for the solution to include that
option as well.
If you have a netctl config file in /etc/netctl and you don't want
resolvconf to treat your network startup as FAILED, you can try removing
the DNS entry. It worked fine for me with my fixed-IP setup for the
server. It should work fine for all type of network configs as long as
you proper set your DNS domains /etc/resolv.conf.
All of the "nanny" dynamic update of resolv.conf is supposed to help
with boxes that move between different networks, different WiFi
locations, etc... It is trying to apply what works there are a "one size
fits all" solution and that has caused issues for servers in fixed
locations where /etc/resolv.conf is self-adminned. Simply providing a
documented way to turn this behavior off would solve 90% of the issues seen.
openresolv keys off the "signature' at the top of /etc/resolv.conf to
determine who wrote it and whether it can be modified. The problem in my
case was for signatures not know to openresolve, the new update was
marking the network startup used as failed.
A better solutions would be for openresolv to only attempt dynamic
modification and error reporting for /etc/resolv.conf files where the
signature is *known* to it. Otherwise for /etc/resolv.conf file with no
signature or a signature not know to openresolv, it should do nothing
regarding those files and presume they are self-administered. It could
throw a warning if it just had to do something, but not mark the network
startup as failed.
I'm sure they will come up with a workable solutions. Good discussion in
the upstream bug report. For now, just removing the DNS entry from the
config file in /etc/netctl/xyz... allows the unit file startup to succeed.
--
David C. Rankin, J.D.,P.E.
