OSMC RC3 RPI B+ /etc/resolv.conf NFS install

Hi,

I’ve just changed from raspbmc to OSMC RC3 with nfs installation. Everything went fine, but unfortunately I have an issue: /etc/resolv.conf has been overwritten by conman (at least this is what written by comments) and there is NO nameserver in it, which means I can’t reach the outside network. After boot the right entry is there (the openwrt rooter address) but after some minutes it is overwritten with empty value. The result is indepened from DHCP of static IP. The most I’ve reached that I protected the /etc/resolv.conf with chmod 444 /etc/resolv.conf, but I do not think it is the right solution. I tried to check other forums where similar issues were comming up:
https://discourse.osmc.tv/t/no-network-after-half-an-hour/4698

but the solution for me was not working (in the preferences setting the dnsproxy to the opposite). With SD card installation the /etc/resolv.conf has not been overwritten.

Do you know what is the problem with my NFS installation? what should I change there?

Thanks and regards

Do you have an additional network interface like a wireless adaptor or is your Ethernet connection used for NFS boot the only interface ?

It sounds like a bug in connman. This is the script in /usr/bin that sets up networking and launches connman in OSMC:

Lines 10-17 and 31 handle DHCP NFS installs, 19-29 and 31 handle Static NFS installs, and 33-37 handle normal non-NFS installs.

You can see on line 31 we pass the option -I eth0 which should tell connman to leave that interface alone and not configure it (as it is already configured by the kernel) but apparently in your case it still interferes with /etc/resolv.conf, but only after a period of time ? (How long ? and is it always the same amount of time ?)

Can you try a couple of things for me please - first try editing line 31 to remove --nodnsproxy and see if that helps, if not, please try commenting out line 31 (put a # in front of it) and see if that helps.

Thanks.

Hello,

I do not have other interface, only eth0. I tried out the things and here are the result.

after boot without the whole 31. line (The result is good for me)

osmc@osmc:~$ ls -al /etc/resolv.conf
-r–r--r-- 1 root root 70 Jun 22 17:53 /etc/resolv.conf
osmc@osmc:~$ cat /etc/resolv.conf
#PROTO: DHCP
domain lan
nameserver 192.168.1.1
bootserver 192.168.1.1

after boot with the line 31, but delete -nodnsproxy (This result is good I guess, but not realy for me)

osmc@osmc:~$ ls -al /etc/resolv.conf
-r–r--r-- 1 root root 70 Jun 22 18:02 /etc/resolv.conf
osmc@osmc:~$ cat /etc/resolv.conf
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1

result with the whole original 31. line after boot and later

a. after the boot imediately:

osmc@osmc:~$ ls -al /etc/resolv.conf
-r–r--r-- 1 root root 70 Jun 22 22:08 /etc/resolv.conf
osmc@osmc:~$ cat /etc/resolv.conf
#PROTO: DHCP
domain lan
nameserver 192.168.1.1
bootserver 192.168.1.1

b. after some minutes(in this case it was only 3 minutes as you can see from the timestamp, I have no clue why)
osmc@osmc:~$ ls -al /etc/resolv.conf
-r–r--r-- 1 root root 46 Jun 22 22:11 /etc/resolv.conf
osmc@osmc:~$ cat /etc/resolv.conf
# Generated by Connection Manager
search lan

and this cause the problem…

Thanks and regards

I have hopefully fixed this issue:

Sam

Hello Sam,

thanks for the fast correction. I’m new in the osmc word and I do not really know your release/update strategy. So what is expected from me now? Do some kind of patching on my local installation or wait for an update (maybe with apt-get)? Can I precheck somehow, if I see it right you have modified connman, so that’s why I’m asking it.

thanks and regards!

We will do some testing of the fix and then push it out to all users as an update, probably in a few days.

Hi,

I can confirm that the correction has arrived and it works as it should. So thanks for it!

Regards

1 Like

Hello,

Maybe another (could be an independent) issue around NFS install and network management. My NFS installation is with DHCP. After the DHCP lease time rpi does not “reconnect” to the rooter. The network is still working from RPI and via IP address I can reach rpi, but not via name. Since the previous message I upgraded to RPI 2, but the previous message was valid for it too. Now I do not know whether it is a RPI 2 problem or general. It is not a big issue for me as I can reach via IP address and I can configure my openwrt rooter to know the address/name pair constantly, but could be important for you.

Thanks and regards

Hi

Do you have any logs for this? It sounds like you’re referring to DNS resolution from other clients. There should be two mechanisms by which clients can resolve the hostname to an IP address:

  • Using Avahi – you will know if clients support this because they will respond on HOSTNAME.local.
  • By informing the DHCP server of the hostname. I am not completely sure of how this would be achieved on your router, but on Windows environments, the client can update its hostname and register it as a DNS entry in Active Directory.

S

Hello Sam,

Ok, I try to reformalize my problem or the issue what I have faced and what I have identified since. So let’s suppose I have 3 machines. 1 is the rooter+nameserver, another is a desktop pc and the last one is the oscm(rpi2). PC and osmc connects to the rooter with DHPC(DHPC will gives back fix ip address). On the rooter I can set up fix ip address to the PC and OSMC and not only the fix IP address but hostname too! When the osmc boots up then until 12 hours(lease time) I can reach it with name(not only with ip address) from the PC or other machnies, because OSMC has connected to the rooter with “right dhcp protocol communication”. But after 12 hours( when dhcp lease time has been reached) OSMC does not refresh itself(or does not do something) and the rooter does not anymore knows about OSMC (in the sence of DHCP) I see it in the rooter’s lease time list for the different connected clients, but osmc doe snot appear anymore. It does not really cause big problem for me, but I think this is not the right. So my feeling is that connman does not do the right things, but I’m saying it without any evidence. I can play with my rooter and decrease the leasing time to see what happens, but I’m not sure that what I should do with the connman to create log. Is it enough that in the /usr/bin/start-network, line 31 I add the -d ? or is there any better/other way?

thanks and regards!

Are you saying OSMC does not renew the DHCP lease? If that’s the case, then connectivity should drop entirely.

Are you saying that OSMC does not continue to take the hostname from DHCP? I know DHCP can specify a hostname too? Is this the issue?

S

Hello Sam,

Yes, I say this. After the lease time OSMC does not renew it with my setup, which means. RPI2+NFS install, DHCP with fix ip and the rooter and the nfs share is on the same device. I tryy to decrease the lease time on the rooter, and try to install osmc to a separate SD card (only sd card installation) and see what happens.

In my rooter(with the firmware of OpenWRT) you can do the following: you assign for MAC addresses fix IP and DHCP will give it to the specific device. (normal DHCP) what I do not know is standard ( I guess yes) that you can add a hostname to this. Not a separate hostname for an IP, but together with the DHCP fix ip address assignment. And it is valid (in the nameserver) until DHCP is working well. However I see from the lease time list (on the rooter) that OSMC does not renew itself. No entry anymore for OSMC. That’s why I asked that on OSMC side what can I see/check/send log from? Until now I found in dmesg the initial DHCP entries, but nothing more.

And I can confirm that the connection does not broken, on my rooter not renewing the lease by the client does not drop the whole connection. I can reach the OSMC via the old ip address, becasue OSMC itself does not do anything. Luckily it won’t cause for me any problem as it is fix address and on a separate place on the rooter I can add again the hostname to the nameserver part.

But ok, maybe I’m completly wrong with my setup. So if you think I did something wrong (from home networ setup perspective) then tell it to me. For the NFS installation is the fix address the right way? the DHCP should not work as I imagine? Or is there any log file(then the method how to get is important for me) I can send to you?

Thanks and regards

I think what you’re saying is you want OSMC to get the hostname from the router. This should change the /etc/hostname file as well. Does it?

I think that option has to be explicitly enabled in ConnMan’s settings to work properly.

S

Hello Sam,

This hostname problem is only a side effect, not the root cause, so for a moment try not to focus on it. The problem in my opinion is independet from where the rpi will get its hostname (from DHCP server or send it by itself). The problem that after the lease time rpi(osmc) does not renew itself and it has side effect like reach the rpi only via ip address.

I tried to check connmanctl but I was not able to get any answer from it. Any suggestion what I can try out? or should I go to static IP address for NFS installation? I tried out with 2m lease time on the server and the same result, no renew from osmc.

Regards

Can you confirm on your router that the lease is expiring and the router is not seeing a renewal attempt from the client ? (eg if you look in the DHCP lease table on the router, the client is no longer listed)

If so what is probably happening is that the router removes the dynamic DNS entry when the lease is not renewed. The problem is, on an NFS install it is the linux kernel itself that directly handles the DHCP lease, whereas normally a network manager such as connman deals with this.

This suggests that either there is a bug in the way the DHCP client in the kernel works, or it is only designed to obtain the initial lease and then expects a network daemon to take over to do further renewals…

dmesg will show that

Sam

Hello Sam and DBMandrake,

I can confirm that the lease is expiring and the router is no seeing a renewal attempt from the client, so DHCP lease table does not contain osmc anymore. In dmesg I see only the initial connection.

dmesg log:
http://paste.osmc.io/xupenuratu

Thanks and regards!

Can you please paste dmesg after the lease has expired? I understand it may take some time.

Sam

Hi Sam,

the uploaded dmesg was after the lease time has been expired. I set it on the rooter for 2m, I was watching the count down, and osmc has been disappeared from the lease table. I was wating some minutes after and uploaded the dmesg.

What was comming into my mind that the original problem (/etc/resolv.conf overwritten) wasn’t a side effect too? because connman is running but maybe can’t really connect/use the eth interface? If the kernel setup the connection what does connman realy does? I tried to check connman but without real luck.

regards

In an NFS install we pass -I eth0 to connman which basically says “don’t touch eth0 at all”. If we didn’t connman would try to configure the interface and cause the NFS connection to drop which would hang the system. connman is still required if you also use a wireless adaptor or Bluetooth, which is why it still needs to be running.

But it will not handle dhcp for eth0 when it has been told not to touch it. We are doing some research into this problem - from what I’ve found so far it seems that kernel mode DHCP/NFS not renewing the lease is a problem that has been discussed before in various places, and it’s also unclear whether it’s the kernels job to renew the lease later or whether it has to be handed over to a userland dhcp client to take care of ongoing renewals. (And whether this differs with different kernel versions and distributions)

In the meantime I’d suggest that you configure your NFS install statically rather than using DHCP and we will update this thread when we have more to report. As well as the host name resolution issue you have the problem that your DHCP server might allocate that address to another device causing an IP conflict…