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.
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.
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
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.
Hello,
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 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=47 time=43.017 ms 64 bytes from 8.8.8.8: seq=1 ttl=47 time=47.849 ms 64 bytes from 8.8.8.8: seq=2 ttl=47 time=51.143 ms 64 bytes from 8.8.8.8: seq=3 ttl=47 time=49.038 ms 64 bytes from 8.8.8.8: seq=4 ttl=47 time=38.104 ms
BUT
osmc@osmcsypialnia:~$ ping www.google.pl ping: bad address www.google.pl
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.
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!
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.
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.
copy /usr/lib/tmpfiles.d/connman_resolvconf.conf into /etc/tmpfiles.d/ in order to override the default
comment out the second line, the one starting with ‘L+’ (the + forces the recreation of the link)
unlink/delete /etc/resolv.conf
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.
Apologies.