I am trying to build from 18.06.4 branch, but after a successful build the network configuration file /etc/config/network is missing and also the network is not starting when booting it on my Banana PI r2. Other configuration files are created properly (firewall, luci, dropbear...). I have tried to use the standard configuration by copying the "config.seed" file from the release page for the BPI and only added a few more packets like LUCI and SQM. When I build from trunk a while back the network configuration was there... What am I missing here?
Thats is typical. For most routers it is generated on the fly at the first boot after flash if there is no existing one. So the file is not included in the image.
Problem here is that I am booting first time from a NFS share, so I need the network configuration to be available beforehand, as otherwise the system cannot establish the connection to the share. Can I "setup" the network manually?
You should include a readily tailored /etc/config/network as a custom file to your own build, (or to the image generated by the imagebuilder).
Look at wiki for more information.
I have tried to write the /etc/config/network file on nfs prior to the first start, but this didn't help either. Still after (or during) boot the BPI lost connection. I have traced this via "ping" statement on another machine, where I can see, that the BPI was reachable during kernel boot via ip configured in the "bootargs" of uboot, but then, when modules got loaded the connection was gone, because the network environment was not started correctly.
So you say that providing a config file in /etc/config for network should be sufficient to make networking work? There are no other commands necessary? Is the network service started automatically?
If you need it to mount from first boot, a pre-configured /etc/config/network and fstab (or equivalent in UCI) are likely needed, as outlined by hnyman. This requires a custom build, such as from source or using image builder.
the boot process itself works fine, the only issue I have is that when modules are getting loaded from NFS share the network service fails to assign the configured options from /etc/config/network and thus the connection to the share gets lost.
I will try the suggestions and will revert back if getting stuck again.
Kernel modules? Usually boot-critical, kernel modules are built into the kernel, or accessible on a file system that can be mounted and read by the "bare" kernel natively.
no, not kernel modules, as the kernel is getting loaded earlier and connects to nfs share to load the root file system. At the point where the network configuration is handed over from kernel to system the connection drops. That is why I am assuming that the network stack is not loaded/initialized properly. I will verify this today.
I also tried to increase debug level to 4 but there is no more information on what could go wrong here. Do you have any ideas what I might have missed here?
seems that knocking out all of the preinit_ip stuff is one way to make it happy... but hang on for a week or so, cause it's not for the faint hearted....
thanks for your effort. I tried the suggestions in the thread mentioned by you but without success. I have analyzed a little bit more and the chain of events is as follows:
uboot takes args from uDev.txt and applies them correctly to the kernel process
kernel successfully assigns ip and gateway to lan0
kernel successfully mounts nfs share for root fs
kernel passes control to rootfs
rootfs boots up by loading boot modules and other modules
rootfs finishes loading modules
At that point, when I press any key, the console becomes available and I can start typing for about 5 seconds. After that the console becomes unresponsive and this is also the moment where a ping to the lan0 interface stops working. My guess is that when the BPI starts its network the ip gets somehow flushed and the connection to the nfs share drops. I have a network file in /etc/config ready which assigns the same IP as the bootargs, but it seems the network process does not consider it. I am stuck here as I do not know how to analyze further, any suggestions?
Thanks wulfy, that helped. I have now followed the scripts and figured out that the following block is responsible for my network configuration to disappear (/etc/init.d/network):
Even with the commented lines the network breaks. The same happens if I simply disable the complete block and execute "/sbin/netifd" after boot. Without this code openwrt is up and running, but without the other interfaces (lan1, lan2, lan3, wan...). So it is related to network configuration, but I do not know where the issue is, as my "/etc/config/network" is fine and even LUCI is able to read its configuration and show on UI. Any ideas?
root@test:/# /sbin/netifd -l 10
netifd_ubus_init(1179): connected as 809ddd66
proto_shell_add_handler(917): Add handler for script ./dhcp.sh: dhcp
proto_shell_add_handler(917): Add handler for script ./dhcpv6.sh: dhcpv6
proto_shell_add_handler(917): Add handler for script ./ppp.sh: ppp
proto_shell_add_handler(917): Add handler for script ./ppp.sh: pppoe
killall: hostapd: no process killed
killall: wpa_supplicant: no process killed
killall: meshd-nl80211: no process killed
after that the network connection is gone. there is no setup of lan devices like on other instances, so something is broken with network configuration... Any hint?
I figured out that the network configuration relies on "ubus list" command. I executed this command on a working openwrt installation, with this result:
dhcp
file
iwinfo
log
luci
network
network.device
network.interface
network.interface.lan0
network.interface.lan1
network.interface.lan2
network.interface.loopback
network.interface.wan
network.rrdns
network.wireless
service
session
system
uci
Then executed the command on the not working system:
log
network.rrdns
service
session
system
uci
Why is so much missing here? Is this related to the build process? Because there all packages are activated...
after long try&fail, I got it running. The problem was that I was trying to compile v18.06.4... After compiling master (snapshot) it worked out of the box. So it seems that the current stable release of v18.06.4 is not working when trying to boot directly from NFS share, even though the same packages are installed. Might help somebody...