Problem with resolv.conf on NFS root install since march update

Since the march update I have the following problem:

/etc/resolv.conf is a symlink to /var/run/connman/resolv.conf
/var/run/connman/resolv.conf doesn’t exist

Restarting connman doesn’t help of itself, but if I first add /var/run/connman/resolv.conf (even if it is empty) and then restart connman it does get populated. But after a reboot /var/run/connman/resolv.conf is missing again.

Anyone got a solution? Other than running

touch /var/run/connman/resolv.conf
systemctl restart connman

after each boot.

Problem might have to do with the fact that i’m using a root-on-nfs setup and that needs a dhcp lease before connman can be started. I’ve had a similar problem in the novermber 2016 update where an empty /etc/resolv.conf would be created each time the dhcp lease was renewed. But that was fixed, I think in the januari update.

This is a known connman bug that we are aware of. It only affects nfsroot uses. Sam has advised he would try to look at the issue soon.

As @actiona wrote already detected yesterday and limited to NFS root.
Maybe you can change the title to include NFS root so maybe people with the problem find it faster

Changed title.

Is there a public bug tracker I can search before reporting issues in the future? I searched this forum on problems with resolv.conf but nothing seemed to match the problem I encounter.

There is a bug tracker but actually this one isn’t on there as I just found it last night and just told Sam in a chat.
So no worries will update you here as soon as there is a development.

I have just updated my Pi to the latest 2017-03. After that, OSMC stopped scrapping new content. I have looked into it and it appears that it can’t resolve DNS addresses. I had a little test after SSH
osmc@osmcsypialnia:~$ ping PING ( 56 data bytes 64 bytes from seq=0 ttl=47 time=43.017 ms 64 bytes from seq=1 ttl=47 time=47.849 ms 64 bytes from seq=2 ttl=47 time=51.143 ms 64 bytes from seq=3 ttl=47 time=49.038 ms 64 bytes from seq=4 ttl=47 time=38.104 ms


osmc@osmcsypialnia:~$ ping ping: bad address

Here’s my log

Last thing… When I go into MyOSMC and Network settings Wired adapter is off. When I turn it on there’s some error (bottom of the log) and status stays on Configuring.

ifconfig return this
osmc@osmcsypialnia:~$ ifconfig eth0 Link encap:Ethernet HWaddr b8:27:eb:94:e8:fd inet addr: Bcast: Mask: inet6 addr: fe80::ba27:ebff:fe94:e8fd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:482491 errors:0 dropped:0 overruns:0 frame:0 TX packets:183854 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:603297049 (575.3 MiB) TX bytes:30293430 (28.8 MiB) lo Link encap:Local Loopback inet addr: Mask: inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:1668 errors:0 dropped:0 overruns:0 frame:0 TX packets:1668 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:128868 (125.8 KiB) TX bytes:128868 (125.8 KiB)

My network is working properly as I watch everything from my NAS (also I have NFS install). So it looks like only DNS is screwed somehow.

Are you by anychance use a NFS root installation?

Yes, I do use a NFS installation.

Well than a quick serarch should have brought you here where I now moved your posts :wink:

I did have a look at last posts. Missed that :frowning: Apologies.

No worries, stay tuned for solution. In the meantime you may just copy from /proc/net/pnp to /etc/resolv.conf

Thanks for that. I will check it when I get back home.
One question: is it permanent solution or will I have to do this every time I turn on Pi?

Might not be permanent but anyhow how often do you reboot OSMC?

I have /etc/resolv.conf linked to /proc/net/pnp
ln -s /proc/net/pnp /etc/resolv.conf
This is a persistent/permanent solution over reboots.
But not always over upgrades:-)
But I am fully convinced Sam will come up with the best solution!

1 Like

Too bad that this doesn’t work for me. When I write a command you provide I have @resolv.conf in my /etc and everything works fine. I can scrap and get posters/fanart/other stuff. But after a restart it’s gone. I mean there’s another resolv.conf in red and ! in front (in midnight commander). When I try to open it, it says the file is missing.

I hate to just +1 a thread with nothing of value to add, but i’m also in this same boat. Just like @XiMMiX, I had the same problem back in November which I put a manual symlink in place to work around. Unfortunately, since the March update, every reboot relinks /etc/resolv.conf to a non-existent /var/run/connman/resolv.conf so a manual hack is required at every boot of the pi. A more permanent solution (or at least something that doesn’t get clobbered by a bounce) would be greatly appreciated.

Many thanks.

Same problem also. Using openvpn resolfv.conf works with vpn dns after reboot Resolv.conf get overwritten to connman. Is there a reason for this?


I, too have the same issue on an DHCP NFS install.

Confirm that any linking or overwriting of /etc/resolv.conf will end up after reboot into a link to /var/run/connman/resolv.conf

Tried also a bit of script into rc.local thinking it will be the last script executed during the init phase but did not work as expected because systemd-tmpfiles is executed way before we had a chance to create the real resolv.conf. Besides there is no content yet so the link is dangling. Any writes to it will fail. A ‘touch’ to create an empty file is needed

A sort of a hack/tempfix until someone finds a better/cleaner solution to this problem.

  1. copy /usr/lib/tmpfiles.d/connman_resolvconf.conf into /etc/tmpfiles.d/ in order to override the default
  2. comment out the second line, the one starting with ‘L+’ (the + forces the recreation of the link)
  3. unlink/delete /etc/resolv.conf
  4. copy /proc/net/pnp into /etc/resolv.conf (as per /usr/bin/start-network)

Probably playing withe the content of /etc/tmpfiles.d/connman_resolvconf.conf such that even if the link is recreated a real empty file has to be created too for start-network to be able to populate it.

I know that this might not be the right way but it will solve it but hope that helps a bit.

I ended up creating a file /etc/tmpfiles.d/resolvconf-temporary.conf containing:

f /run/connman/resolv.conf 0755 root root - -

All this does is create /run/connman/resolv.conf (empty) after boot if it doesn’t exist yet. Once it exists connman will properly populate the file.

+1 XiMMiX