You are not logged in.
Pages: 1
Topic closed
Hello, anyone else running into this problem?
I updated my system today and pacman also updated openresolv:
[2025-06-29T14:52:27+0200] [ALPM] upgraded openresolv (3.16.5-1 -> 3.17.0-1)I usually start my wireguard tunnel with the wg-quick command but today I received this error:
$ wg-quick up wg131
[#] ip link add dev wg131 type wireguard
[#] wg setconf wg131 /dev/fd/63
[#] ip -4 address add 192.168.0.4/32 dev wg131
[#] ip link set mtu 1420 up dev wg131
[#] resolvconf -a wg131 -m 0 -x
resolvconf: signature mismatch: /etc/resolv.conf
resolvconf: run `resolvconf -u` to update
[#] ip link delete dev wg131At this stage /etc/resolv.conf contained the following lines
$ cat /etc/resolv.conf
# Generated by NetworkManager
search fritz.box
nameserver 127.0.0.1
options edns0 trust-adI ran "resolvconf -u" like mentioned in the error message and this changed resolv.conf to this:
# Generated by resolvconf
nameserver 10.0.0.131afterwards I could "wg-quick up" the tunnel however when stopping the tunnel I again received the same error message:
wg-quick down wg131
[#] ip link delete dev wg131
[#] resolvconf -d wg131 -f
resolvconf: signature mismatch: /etc/resolv.conf
resolvconf: run `resolvconf -u` to updateand the content of resolv.conf changed back to:
# Generated by NetworkManager
search fritz.box
nameserver 127.0.0.1
options edns0 trust-adNext I tried to downgrade openresolv to the previous version and this fixed the issue.
[2025-06-29T17:21:10+0200] [ALPM] downgraded openresolv (3.17.0-1 -> 3.16.5-1)Altough resolv.conf gets changed when starting or stopping the tunnel with the downgraded openresolv package, no error messages and the tunnel works fine. Is NetworkManager supposed to write into resolv.conf even if I have dns=dnsmasq in a networkmanager conf file? I set it up ages ago and up until now everything worked fine. Should I file a bug report to openresolv or is this a setup/config issue on my end?
Thanks,
Edit: Oh, I found the offending commit: "libc: Don't update resolv.conf on signature mismatch" https://github.com/NetworkConfiguration … 2814cf2499
2nd Edit: Seems to be that "NetworkManager needs to be built with resolvconf support" according to the maintainer on this github issue
What should be the correct action to do here?
Last edited by gary8588 (2025-06-30 16:00:02)
Offline
I confirm exactly the same errors as you.
Offline
I also get:
resolvconf: signature mismatch: /etc/resolv.conf
resolvconf: run `resolvconf -u` to updateusing OpenConnect with GlobalProtect with the command:
sudo openconnect {VPN} --protocol=gp --user={USER} --csd-wrapper=/lib/openconnect/hipreport.shLast edited by BuZZ-dEE (2025-06-30 08:25:06)
Offline
According to archlinux-general ML thread this is due to a change in openresolv .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Can confirm the same issue, the funny thing is that in my case they are complaining just because of the header as in both cases resolv.conf points to 127.0.0.1 but sometimes is generated by Network manager and others by resolvconf depending on which tool run last.
# Generated by NetworkManager
nameserver 127.0.0.1# Generated by resolvconf
nameserver 127.0.0.1#Solution
Add this file in conf.d of networkmanager
cat /etc/NetworkManager/conf.d/rc-manager.conf
[main]
rc-manager=resolvconfRegenerate the config with resolvconf -u
Reboot the system
Last edited by r0b0t (2025-06-30 11:32:43)
Offline
Yep that fixed it! Thanks all
Offline
Apologies for posting in a [SOLVED] thread, but for posterity a far simpler solution is just removing the
DNS= entry from the wireguard interface configuration file.
For me this solves the problem and checking that the correct DNS-server is used using
traceroute archlinux.orgno DNS-leaks occur even after a machine restart.
I know nothing.
Offline
Apologies for posting in a [SOLVED] thread, but for posterity a far simpler solution is just removing the
DNS=entry from the wireguard interface configuration file.
For me this solves the problem and checking that the correct DNS-server is used usingtraceroute archlinux.orgno DNS-leaks occur even after a machine restart.
For me, only this one worked; the prior solution failed, but this one succeeded.
Also, a note for those who share my aversion to deleting lines in files: the DNS line can be commented out with #, in place of deletion.
Offline
Closing this thread.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Pages: 1
Topic closed