Wireless interface is unmanaged when booting to NFS

Question

I have the ConnectCore i.MX6UL Starter Kit and I built the core-image-base image using Yocto and the DEY layer version 2.4. I have found a few differences between the behavior of this image when booted via NFS vs booting from NAND. To boot via NFS, I use the u-boot command "dboot linux tftp".

The first problem I see when booting via NFS is that the firmware for the wlan does not get loaded. The qualcomm.sh script in /etc/udev/scripts is supposed to create the appropriate links. This script runs, but the links are not created. I can workaround this issue by manually creating the links and re-booting.

Once the first problem is resolved, the next problem is that the wlan0 interface is not being managed by NetworkManager as I would expect. I compared all of the configuration files for NetworkManager, ifupdown, hostapd, etc... and found no differences between these files on the NFS filesystem and the UBI filesystem on NAND. I have not been able to find out why this happens or find a workaround. Here is the output of nmcli dev:

When boot via NFS

DEVICE TYPE STATE CONNECTION
eth0 ethernet connected eth0
can0 can unmanaged --
sit0 iptunnel unmanaged --
lo loopback unmanaged --
p2p0 wifi unmanaged --
wlan0 wifi unmanaged --
wlan1 wifi unmanaged --

When boot via NAND

DEVICE TYPE STATE CONNECTION
eth0 ethernet connected eth0
wlan0 wifi disconnected --
can0 can unmanaged --
sit0 iptunnel unmanaged --
lo loopback unmanaged --
wlan1 wifi unmanaged --

The main difference between these two runtime configurations is that eth0 is being used to mount the root file system. I suppose that somehow confuses NetworkManager. Does anyone have experience booting to NFS with this starter kit?

Thanks.
-John G.

Comments

Are you sure you are loading the proper device tree?
When you boot from NAND you are suing boot.scr script in boot partition that autodetects module variant and loads appropriate device tree. When you boot from NFS with "dboot linux tftp" you are skipping this process. It is ok if you point to a correct device tree via fdt_file variable.

---

I am pretty sure I am using the right device tree file. Yes, when booting from NAND, I can see that uboot loads and executes the boot.scr file. Here is an excerpt of the boot screen:

Loading file 'boot.scr' to addr 0x80800000...
Done
## Executing script at 80800000
Skipping mounting already mounted ubifs fs
Loading file 'zImage-ccimx6ulstarter.bin' to addr 0x80800000...
Done
Skipping mounting already mounted ubifs fs
Loading file 'zImage-imx6ul-ccimx6ulstarter-id129.dtb' to addr 0x83000000...
Done

I use the same file 'zImage-imx6ul-ccimx6ulstarter-id129.dtb' from the output of the Yocto build and I copy that file into my /tftpboot folder under the name 'zImage-imx6ul-ccimx6ulstarter.dtb'. I renamed it to match the file that u-boot looks for when transferring the device tree. My ftdxxx u-boot vars look like this:

fdt_addr=0x83000000
fdt_file=zImage-imx6ul-ccimx6ulstarter.dtb
fdt_high=0xffffffff
fdtcontroladdr=8eedd6f8



When I boot to NFS, my boot screen looks like this:

TFTP from server X.X.X.X; our IP address is X.X.X.X
Filename 'zImage-imx6ul-ccimx6ulstarter.dtb'.
Load address: 0x83000000
Loading: #######
3.9 MiB/s
done
Bytes transferred = 32531 (7f13 hex)
Kernel image @ 0x80800000 [ 0x000000 - 0x599268 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 83000000, end 8300af12
Modify /soc/aips-bus@02000000/bee@02044000:status disabled
ft_system_setup for mx6
switch to ldo_bypass mode!

Starting kernel ...

Answer 1

Looks like during the call of the "/etc/udev/scripts/qualcomm.sh" script, at booting time, the filesystem is mounted as ro, so when the script fails when it needs to execute this command:

ln -sf "${BDATA_SOURCE}" "${BDATA_LINK}"
I have modified the script (at local) and I remount the sysfilesystem as rw before doing that command

mount -o remount,rw /
ln -sf "${BDATA_SOURCE}" "${BDATA_LINK}"
ln -sf "${BDATA_SOURCE}" "${UTFBDATA_LINK}"
mount -o remount,ro /
This workaround appears to be working in the cc6ul/cc6qp.

Comments

Thanks, Leonid.

The ro mount during boot via NFS was unexpected. Thank you for your insight.

As for the unmanaged devices when booting via NFS, I found the following in the system log:

Mar 15 20:00:09 ccimx6ulstarter daemon.warn NetworkManager[652]: <warn> [1552680009.7155] plugin: skip invalid file /usr/lib/NetworkManager/libnm-device-plugin-wifi.so: file has invalid owner (should
be root)
Mar 15 20:00:09 ccimx6ulstarter daemon.warn NetworkManager[652]: <warn> [1552680009.7170] plugin: skip invalid file /usr/lib/NetworkManager/libnm-device-plugin-bluetooth.so: file has invalid owner (sh
ould be root)
Mar 15 20:00:09 ccimx6ulstarter daemon.warn NetworkManager[652]: <warn> [1552680009.7174] plugin: skip invalid file /usr/lib/NetworkManager/libnm-device-plugin-wwan.so: file has invalid owner (should
be root)

I changed ownership of those files using chown from the target device and rebooted. That took care of this problem. Now, wlan0 is being managed properly by NetworkManager.

When I extracted the rootfs.tar.bz2 file on my workstation, I did so as my current user. I did not think I would need to use sudo when extracting the filesystem. I do see in the Digi documentation (https://www.digi.com/resources/documentation/digidocs/embedded/dey/2.4/cc6ul/yocto_t_boot-images) that it is recommended to untar the rootfs using sudo. So, this was my mistake. Normally, I like to avoid using sudo unless it is needed, but I guess it should be used in this case.

Thank you.
-John G.