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
command:
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?

Hello,

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

Hi

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 http://apt.osmc.tv 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:

Thanks

Sam

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.

/var/run/connman/resolv.conf
/etc/resolvconf/run/resolv.conf

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.