Network problem on fresh OSMC install

Hello all,

I have a problem with the network connection of 2 Rpi’s with OSMC. ONe is a recent fresh OSMC install(November 2016). The other is a very old install, maybe 18 months old.

Both get their initial network connection OK and all is well. But now I discovered that I can’t reach any internet server from OSMC after a while. No DNS is specified anymore . IP based connections/pings work fine. After a fresh reboot it works fine again for a while The duration might be the DHCP lease time of my router (12 hours), but I haven’t verified this.

On my router the PI with OSMC shows up with an active lease and all looks well.
When the problem occures, /etc/resolve.conf only has the line # Generated by Connection Manager, but no nameserver is configured. After a reboot, I see a nameserver again in this file.

I have no idea how long this has been going on on the old install. Connecting to it from outside works correctly and the NAS is reached by IP address, so I never had much reason to discover this problem till now.

Additionally on the new PI, from the beginning it claimed it can’t configure the wired network. It stays at the status “Configuring…”.
As mentioned, I didn’t pay much attention at first because the network connectivity looked all-right. I could log in and connect to my NAS without problem.

As an complicating factor, the Pi is running over nfs root. So it picks up some network parameters at boot time as well. (No idea if that can be related, so I mention it to be sure)

Any advice/suggestions?



Are you running a VPN?

This is a symptom of some less than stellar providers unfortunately.

Edit: old versions of OSMC won’t renew their DHCP lease properly with nfsroot. New versions should, but we’ve seen some issues with this.


Hi Sam,

No VPN. But the nameserver should be my own router, internally. Somehow it looses this after a while.

Oops, Missed the 2nd part of your reply:-(
What is the issue, and can I verify somehow that I am facing this as well?
The OSMC configuration manager doesn’t seem happy with setting up wired network.
Is there some log I can check for this?



If you use NFS, then ConnMan can’t handle the Wired Network. So you won’t be able to configure it via My OSMC. Instead you have to configure it via /boot/cmdline.txt. This is expected (but perhaps not very documented) behaviour.

I can’t suggest much for lookups, but check /proc/net/pnp. When you boot via NFS, the kernel is handling the network. It will expose the nameservers via /proc/net/pnp. This wasn’t being updated in the past, only at boot, but in an internal network I wouldn’t expect nameservers to ever really change, so it was a non-issue.

If you are on the latest update, you should read the comments here:

Hi Sam,

After reading throught the discussion connected to the git commit, I have to assume that connman doesn’t pick up on my nfsroot as well.
The connmand process is indeed following the commit. So i can cofirm I am on the latest version.
root 255 0.0 0.5 6496 4152 ? Ss Jan03 0:00 /usr/sbin/connmand -n --nodnsproxy

I checked if I could have the problem indicated by FST777 where he thought the root=/dev/nfs option should be specified before nfsroot. But that is already the case here:
root=/dev/nfs nfsroot= ip=::::kodiliving::dhcp rootwait quiet osmcdev=rbp2

I checked /proc/net/pnp and it has all the right information:
root@kodiliving:/boot# cat /proc/net/pnp

However, resolv.conf is overwritten by connman:
root@kodiliving:/boot# cat /etc/resolv.conf

Generated by Connection Manager

I also checked the timing. It is not conclusive, but resolve.conf has been overwritten at least 15 minutes ago…
root@kodiliving:/boot# ls -al /etc/resolv.conf
-r–r--r-- 1 root root 34 Jan 4 19:15 /etc/resolv.conf
root@kodiliving:/boot# uptime
19:30:59 up 1 day, 13 min, 1 user, load average: 0.51, 0.30, 0.25

I don’t think I am using a “borderline case”. Also since no dns lookup is working, I should have noticed it earlier as at least my youtube and subtitle add-onns are also reliant on internet connections. So the december update seems to be the start of the problem

Any ideas?


Seems the hastags in the lines I copied in are causing large fonts
#oops :slight_smile:

Use the preformatted text </> option in the post editor.

Thx ActionA. Indeed. I found out afterwards. But I was too fast in posting and didn’t notice. I hope the content of the message is still clear.


The number of OSMC users (outside of dev) using NFS is approx 1 in 120,000. This is based on cmdline posts to the pastebin. It’s very borderline. We want to improve it but need feedback.

Not from this post, but it seems that your resolv.conf is empty. Does adding a symlink to /proc/net/pnp work? Perhaps this is the best solution.

Also, can you confirm there are no other active network interfaces?

It’s quite simple to edit your posts and format them correctly. Would take seconds

Hello Sam,

Resolve.conf is indeed empty, but only after a couple of hours. After reboot, it is filled correctly:
tail /etc/resolv.conf
# Generated by Connection Manager nameserver
As far as I’m aware no other interfaces are active.
Attached is the content of connman.conf and ifconfig

more /etc/connman.conf
[General] PreferredTechnologies=ethernet,wifi SingleConnectedTechnology=false AllowHostnameUpdates=false TetheringTechnologies=ethernet,wifi PersistentTetheringMode=true NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth

root@kodiliving:~# ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:bb:8a:e7 inet addr: Bcast: Mask: inet6 addr: fe80::ba27:ebff:febb:8ae7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:684296 errors:0 dropped:0 overruns:0 frame:0 TX packets:372821 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:879647495 (838.8 MiB) TX bytes:109703887 (104.6 MiB) lo Link encap:Local Loopback inet addr: Mask: inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

I have now added eth0 to the blacklist in connman.conf Lets see if it helps.

And I seem to be indeed a borderline case with 1 in 120.000! How much is that in absolute numbers? :slight_smile: What I meant was that FST777 mentions he used even his own method of installing nfsroot, whil I used the OSMC installer to do this.

Still I am surprised by the low number. I’m a big fan of nfsroot. all my files are safely stored on the NAS, and backed up from there. Putting an extra file on the or movie is just a copy statement on my nas. And I used to have regular problems with corrupted SD cards on my Raspberry. that is all gone.
Ah and for experimenting, changing distribution is also just copying and moving directories on my NAS! :slight_smile:



Try using a symlink and see if this resolves the issue

Is /proc/net/pnp writable? The last thing I want is for connman to overwrite that one when it thinks it is updating resolv.conf.


I have found the issue now and it will be resolved in the next update.


Hi Sam

Great news. I was just making advertisement for OSMC to run Kodi over nfs and usb on the dutch kodi forum:-) So it is good to know that if they try it, they wont get aquanted with this problem.

For now the symlink to /proc/net/pnp seems to hold as a workaround.



They will until the January update.

But yes, the solution is scheduled for inclusion in the next OSMC update. Thanks for the report.

Since a couple of days I have quite the same problem:

  • Every service which includes network calls from osmc doesn’t work anymore
  • Nevertheless osmc is connected in ethernet, has an IP address and is always reachable through ssh
  • Also all the other services using internet outside osmc still work.

It’s on RPI3, last update done. Here you are some conf:

   $ cat /etc/resolv.conf 
   # Generated by Connection Manager
   search lan 

eth0      Link encap:Ethernet  HWaddr b8:27:eb:26:ba:2d  
          inet addr:  Bcast:  Mask:
          RX packets:471114 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1998938 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:56018194 (53.4 MiB)  TX bytes:223478704 (213.1 MiB)

Rebooting yesterday it resolved the issue for a while.
Do you need other info to investigate the problem?