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

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


Hopefully the issue is now addressed with the following commit:

I’d appreciate it if you could test this and provide feedback before we release this as an update to other users. To test this update:

  1. Login via the command line
  2. Edit the file /etc/apt/sources.list
  3. Add the following line: deb jessie-devel main
  4. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  5. Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.

Doesn’t work for me unfortunately. After reboot /etc/resolv.conf is still a symlink to /var/run/connman/resolv.conf which doesn’t exist. Restarting connman doesn’t help.

This is with connman 1.3.3-3 and not 1.3.3-2 like the patch you linked:

$ dpkg -l | grep connman
ii  armv7-connman-osmc                   1.3.3-3                            armhf        connman for OSMC

Deleting /etc/resolv.conf now fixes the problem. Once that symlink is gone connman creates (after a restart) a proper /etc/resolv.conf. This does survive a connman restart and full reboot.

This is an interisting finding because that didn’t work for me. Let me check again so that I can update Sam.
But also as a message to others please delete the old symlink before reboot.

Maybe you are using 1.3.3-2?
I just checked and I think 1.3.3-3 removes /usr/lib/tmpfiles.d/connman-resolv.conf which is responsible for recreating the /etc/resolv.conf symlink on reboot.

No I am on 1.3.3-3 and I just rechecked, deleted /etc/resolv.conf and rebooted. And now all good!
Maybe it was a mirror not updated earlier.
@sam_nazarko all good your quick fix works.

The need to delete the symlink should also be fixed in this commit:



Will this commit fix issue I’m having with openvpn see below. Also what’s difference between these two Resolv.conf. Seems openvpn uses the second one.


If it’s an issue caused by the symlink then yes

@sam_nazarko 1.3.3-4 fixes it for me. Thanks!

I have updated my RPi few days ago. So far so good.