Build 18.06.4 => /etc/config/network missing (Banana PI r2)

Hi guys,

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?

Thanks!

Bye

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.

Recipe (that is run on the first boot) is here:
https://github.com/openwrt/openwrt/blob/master/target/linux/mediatek/base-files/etc/board.d/02_network
Same for 18.06:
https://github.com/openwrt/openwrt/blob/openwrt-18.06/target/linux/mediatek/base-files/etc/board.d/02_network

2 Likes

Thanks for the information!

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?

Thanks!

Bye

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.
https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#custom_files

1 Like

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?

Thanks!

Bye

The network service is started automatically, yes. As to what is needed to mount NFS on boot, your own config and experience with, for example, https://openwrt.org/docs/guide-user/services/nas/nfs.client and How shoud you auto-mount an NFS share in LEDE should be able to answer that.

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.

Hi Jeff,

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.

Thanks!

Bye

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.

1 Like

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.

Bye

1 Like

Hi Jeff,

tried all the suggestions but the boot process simply does not pass futher than:

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?

Thanks!

Bye

What is this file actually doing:

/etc/board.d/02_network

? Is it performing also other tasks than creating "/etc/config/network" file? From the contents I can see that there are calls to

ucidef_set_interfaces_lan
ucidef_set_interfaces_wan
board_config_update
mediatek_setup_interfaces
...

Does anybody know what needs to be done to setup interfaces initially? It seems to me that creating "/etc/config/network" is not sufficient...

Thanks!

Bye

so... a vbox booting from nfs....

[    2.713211] sched_clock: Marking stable (1119670407, 1589322904)->(2724482675, -15489364)
[    2.716244] rtc_cmos rtc_cmos: setting system clock to 2019-10-01 06:58:03 UTC (1569913083)
[    2.720951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    2.722597] 8021q: adding VLAN 0 to HW filter on device eth0

[    2.870430] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    2.872121] ata2.00: ATA-8: VBOX HARDDISK, 1.0, max UDMA/133
[    2.875140] ata2.00: 

                            [ snip ]

[    3.580361] ata4: SATA link down (SStatus 0 SControl 300)

                    [ hang-point if nfs cmdopts no good ]

[    4.797872] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

                    [ ^ vbox needs this built-in ]

[    4.817513] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    4.847616] Sending DHCP requests ., OK
[    4.888716] IP-Config: Got DHCP answer from 10.2.3.1, my address is 10.2.3.86
[    4.891041] IP-Config: Complete:
[    4.891953]      device=eth0, hwaddr=08:00:27:c2:62:85, ipaddr=10.2.3.86, mask=255.255.255.0, gw=10.2.3.1
[    4.894391]      host=10.2.3.86, domain=lan, nis-domain=(none)
[    4.895868]      bootserver=10.2.3.1, rootserver=10.2.3.230, rootpath=/nfs/x86/
[    4.895869]      nameserver0=10.2.3.1
[    4.900368] Root-NFS: DHCPv4 option 17: /nfs/x86/
[    4.901635] Root-NFS: nfsroot=/nfs/x86/,nfsvers=3,tcp
[    4.905912] NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,nfsvers=3,tcp,nolock,addr=10.2.3.230'
[    4.909560] NFS:   parsing nfs mount option 'vers=2'
[    4.911304] NFS:   parsing nfs mount option 'udp'
[    4.914269] NFS:   parsing nfs mount option 'rsize=4096'
[    4.917176] NFS:   parsing nfs mount option 'wsize=4096'
[    4.918978] NFS:   parsing nfs mount option 'nfsvers=3'
[    4.920621] NFS
:   parsing nfs mount option 'tcp'
[    4.925370] NFS:   parsing nfs mount option 'nolock'
[    4.927258] NFS:   parsing nfs mount option 'addr=10.2.3.230'
[    4.930195] NFS: MNTPATH: '/nfs/x86/'
[    4.932555] NFS: sending MNT request for 10.2.3.230:/nfs/x86/
[    4.935993] NFS: received 1 auth flavors
[    4.937328] NFS:   auth flavor[0]: 1
[    4.938437] NFS: MNT request succeeded
[    4.945504] NFS: attempting to use auth flavor 1
[    4.950790] VFS: Mounted root (nfs filesystem) on device 0:12.

                                        [ snip ]

[    5.033824] init: Console is alive
[    5.106039] kmodloader: loading kernel modules from /etc/modules-boot.d/

*** i dont get a done loading modules.d i think its a master thing ***
ip=dhcp root=/dev/nfs nfsroot=10.2.3.230:/nfs/x86/,nfsvers=3,tcp nfsrootdebug

see here for make kernel_menuconfig options: http://www.programmersought.com/article/4829647006/

i might get some time later this week to investigate further... basically need an updated tar.gz as seen here: https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg12677.html

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....

Hi wulfy,

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:

  1. uboot takes args from uDev.txt and applies them correctly to the kernel process
  2. kernel successfully assigns ip and gateway to lan0
  3. kernel successfully mounts nfs share for root fs
  4. kernel passes control to rootfs
  5. rootfs boots up by loading boot modules and other modules
  6. 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!

Bye

purely for your learning... in case you really want to see ... / play with the full init process... ( well the non-C side anyway )

what you can do is put;

echo "############LEARNING: 01SYSINFO-ETC-ETC" > /dev/kmsg

inside of any file in;

/lib/preinit/
or
/etc/init.d/

there are better ways to runtime full verbose the boot... but at least now you will have clearer insight into what's going on...

nice to have a cleaner (nfs)bypass hook... but have to remember the main use of the OS...

you should get progress by putting a;

return

at the start of all the preinit_ip functions... and temporarily removing /etc/config/network and /etc/init.d/network

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):

start_service() {
  init_switch

  procd_open_instance                                                                                                     
  procd_set_param command /sbin/netifd                                                                                    
  #procd_set_param respawn
  #procd_set_param watch network.interface
  #[ -e /proc/sys/kernel/core_pattern ] && {
  #   procd_set_param limits core="unlimited"
  #}
  procd_close_instance                                                                                                }
}

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?

Thanks!

Bye

1 Like

here is the debug output of netifd call:

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?

Next step...

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...

Hi wulfy,

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...

Bye

You won't belive what I found out...

The problem seems to be the initial network setup. My process upon now was:

  1. Build image
  2. Update kernel file on SD card
  3. extract rootfs to nfs share
  4. create /etc/config/network with initial configuration <--- problem
  5. boot BPI

with that process the BPI seems to consider the network already set up, and that is why no initial configuration is done.

Changing the process to:

  1. Build image
  2. Update kernel file on SD card
  3. extract rootfs to nfs share
  4. Initial boot (network gets setup up but as there is no network configuration ports get disabled)
  5. shutdown
  6. create /etc/config/network with initial configuration
  7. boot BPI

And suddenly everything is working fine. What a pitty... I lost 3 days in searching this small "issue" :slight_smile:

Thanks all for your help!

Bye

2 Likes