Hello,
I'm using vocore2, and to decrease boot time I'm trying to remove ethernet completely what is the way to remove ethernet in OpenWrt?
That seems to be a great way to render the system inaccessible if there are any wifi issues.
Bringing up Ethernet takes a fraction of a second.
but for now, can you tell me how to disable it.I just wanna give a try
You'd probably have to hack the makefiles to remove it completely from the kernel, there'd likely be a bit of cruft left over still.
If your goal is reducing boot time, focus on finding out what is actually slowing down the boot process. If Ethernet is configured as a DHCP client there's a possibility that could cause an issue, just set it static to eliminate that possibility.
2 Likes
@Entropy512 suggestion is way better.
Device will still be accessible, if the wifi goes down, as long as you set a static IP on a client.
And there will be no boot delay.
There is no quick boot network routers or network hardware anywhere in the world no matter if the logo say Linksys or Cisco.
And what is the definition of fast boot?
If you look in the terminal connected with serial when booting then the first 40-50 seconds is the actual loading of the OS. Then comes the ports within a couple of seconds then it is ready for work.
So what is the actual problem because boot time because of ports isn’t it.
I can imagine the dhcp timeout, and retry, is making the boot "slow".
But the thing is that you boot a network device and then it runs for months or years non stop. So boot time of 50 or 55 seconds shouldn’t be a problem?
The DHCP address assigning isn’t included in the boot process. That is operational process.
But if he want to remove the ports I guess the most meaningful way is to remove them in the dts file and build the firmware without any ports.
[ 14.114561] random: jshn: uninitialized urandom read (4 bytes read)
[ 21.818703] br-lan: port 1(eth0.1) entered blocking state
[ 21.824347] br-lan: port 1(eth0.1) entered disabled state
[ 21.830258] device eth0.1 entered promiscuous mode
[ 21.835411] device eth0 entered promiscuous mode
[ 21.889539] br-lan: port 1(eth0.1) entered blocking state
[ 21.895169] br-lan: port 1(eth0.1) entered forwarding state
@Entropy512 from above as you can see, it took 7.704sec to enter into the blocking state.
and it is the maximum consuming time I found in dmesg log.
so @Entropy512 I have no other choice, I need to disable Ethernet
The port initialization is 0,08seconds.
Urandom is a crypto seeding function and they always take tragic long times on network equipment since they most often doesn’t have hardware acceleration support and HID input?
1 Like
Now, this is the log of OpenWRT v18.06.5 here you see there is no Urandom is used but, it takes 7 seconds
[ 15.007885] usbcore: registered new interface driver uvcvideo
[ 15.013721] USB Video Class driver (1.1.1)
[ 15.022570] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 22.710060] br-lan: port 1(eth0.1) entered blocking state
[ 22.715623] br-lan: port 1(eth0.1) entered disabled state
[ 22.721459] device eth0.1 entered promiscuous mode
[ 22.726517] device eth0 entered promiscuous mode
[ 22.751465] br-lan: port 1(eth0.1) entered blocking state
[ 22.757014] br-lan: port 1(eth0.1) entered forwarding state
[ 22.762876] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
Looking at only kernel logs is likely causing you to make improper assumptions about cause vs effect.
Have you confirmed that during those 7 seconds there is no CPU utilization or other tasks initializing? (e.g. have you proven that Ethernet is actually blocking the boot process?)
For comparison:
[ 11.900988] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
[ 11.909767] bcmgenet fd580000.ethernet eth0: Link is Down
[ 11.915218] br-lan: port 1(eth0) entered blocking state
[ 11.920450] br-lan: port 1(eth0) entered disabled state
[ 11.925875] device eth0 entered promiscuous mode
[ 13.147006] br-lan: port 2(tap0) entered blocking state
[ 13.152271] br-lan: port 2(tap0) entered disabled state
[ 13.157764] device tap0 entered promiscuous mode
[ 13.162544] br-lan: port 2(tap0) entered blocking state
[ 13.167817] br-lan: port 2(tap0) entered forwarding state
[ 13.174836] br-lan: port 2(tap0) entered disabled state
[ 13.180734] device tap0 left promiscuous mode
[ 13.185193] br-lan: port 2(tap0) entered disabled state
[ 16.169087] docker0: port 1(vethbcda212) entered blocking state
[ 16.175060] docker0: port 1(vethbcda212) entered disabled state
[ 16.181229] device vethbcda212 entered promiscuous mode
[ 16.212111] docker0: port 2(vethcd5951d) entered blocking state
[ 16.218118] docker0: port 2(vethcd5951d) entered disabled state
[ 16.224225] device vethcd5951d entered promiscuous mode
[ 16.229840] docker0: port 2(vethcd5951d) entered blocking state
[ 16.235840] docker0: port 2(vethcd5951d) entered forwarding state
[ 16.242159] docker0: port 2(vethcd5951d) entered disabled state
[ 16.800487] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation
[ 17.135630] eth0: renamed from vethcece158
[ 17.285109] IPv6: ADDRCONF(NETDEV_CHANGE): vethcd5951d: link becomes ready
[ 17.292207] docker0: port 2(vethcd5951d) entered blocking state
[ 17.298175] docker0: port 2(vethcd5951d) entered forwarding state
[ 17.305010] eth0: renamed from veth1421988
[ 17.364818] IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready
[ 17.372056] IPv6: ADDRCONF(NETDEV_CHANGE): vethbcda212: link becomes ready
[ 17.379105] docker0: port 1(vethbcda212) entered blocking state
[ 17.385123] docker0: port 1(vethbcda212) entered forwarding state
[ 20.246735] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 81.742203] br-lan: port 2(tap0) entered blocking state
[ 81.747511] br-lan: port 2(tap0) entered disabled state
[ 81.752975] device tap0 entered promiscuous mode
[ 81.757897] br-lan: port 2(tap0) entered blocking state
[ 81.763151] br-lan: port 2(tap0) entered forwarding state
[ 81.768660] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
In this system, what actually takes the longest is for WiFi to associate with the network. Not Ethernet.
The system was also up long before the events at 81 seconds - the events at 81 seconds are, in this example, OpenVPN getting restarted after an NTP stratum change. It took the NTP client nearly a minute to do this even after wifi connected.
(Sorry I can't show the corresponding system logs, too much private information in those.)
You need to look at the system log and not the kernel log.
BTW, in most cases, the kernel log is repeated in the system log which makes aligning things easier. Which is REALLY good because the kernel log timestamps are uptime, while the system log timestamps are wallclock time, which can jump with a time sync.
2 Likes