[oe] [meta-networking][Patch] Revert "networkmanager: Use ALTERNATIVES for resolv-conf handling."

[Drew Moseley]

On 9/3/19 11:42 AM, Drew Moseley wrote:

> On 9/1/19 8:59 PM, kai.kang at windriver.com wrote:
>> From: Kai Kang <kai.kang at windriver.com>
>>
>> This reverts commit 3982dc5b1994ffcc52336b02fbd2c44db164dd82.
>>
>> With this commit it creates link file /etc/resolv.conf via
>> update-alternatives but the target doesn't exist.
>>
>> On target:
>>
>> root at qemux86-64:~# ls -l /etc/resolv*
>> lrwxrwxrwx    1 root     root            33 Aug 27 09:17 /etc/resolv-conf.NetworkManager -> ../run/NetworkManager/resolv.conf
>> lrwxrwxrwx    1 root     root            34 Aug 23 03:08 /etc/resolv-conf.systemd -> ../run/systemd/resolve/resolv.conf
>> lrwxrwxrwx    1 root     root            31 Aug 27 09:22 /etc/resolv.conf -> /etc/resolv-conf.NetworkManager
>>
>> root at qemux86-64:~# ls -l /run/NetworkManager/resolv.conf
>> ls: /run/NetworkManager/resolv.conf: No such file or directory
>>
>> root at qemux86-64:~# cat /etc/resolv.conf
>> cat: can't open '/etc/resolv.conf': No such file or directory
>>
> (Apologies for the delay in getting back to this)
>
> Interestingly, in rocko, the /var/run/NetworkManager/resolv.conf file is
> automatically generated but in thud it does not seem to be.  Without
> this patch, we are relying on /var/run/systemd/resolv.conf existing even
> when not using systemd for name resolution. I wonder if the right
> solution is to figure out why the /var/run/NetworkManager/resolv.conf
> file is no longer created.
>
I dug into this a bit more and I was incorrect about it being different
on different branches. It actually seems to be different when using qemu
vs hardware (in my case an RpI3).  Basically runqemu sets up
kernel-level IP autoconfiguration so NetworkManager has nothing to
configure and thus the /var/run/NetworkManager/resolv.conf file is not
created.  But on RpI, it is.

In the systemd recipe, there are tmpfiles.d entries setup to ensure that
/var/run/systemd/resolve/resolv.conf exists. Should we make sure
NetworkManager and connman do something similar? I verified that systemd
will properly populate the file even when using kernel level
autoconfiguration but initial experiments indicate that NetworkManager
does not.

Drew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2456 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20190903/2f723417/attachment.bin>