It takes about 100 seconds for the openssh server to start on my Beagleboard X15

How do I fix that?

I have no such issue with gentoo, funtoo or yocto based Linux


Here some log :

Last text on serial debug


Updating shared library links: /sbin/ldconfig &
setterm: cannot (un)set powersave mode: Inappropriate ioctl for device
Starting sysklogd daemons: /usr/sbin/syslogd ; /usr/sbin/klogd -c 3 -x
mount: /dev/shm: can't find in /etc/fstab.
Updating hardware database index: /sbin/udevadm hwdb --update
Triggering udev events: /sbin/udevadm trigger --action=change
Polling for DHCP server on interface eth0:
eth0: waiting for carrier
eth0: carrier acquired
DUID 00:01:00:01:01:e2:87:39:d4:36:39:28:be:01
eth0: IAID 39:28:be:00
eth0: adding address fe80::60d5:be64:2107:bbd2
eth0: soliciting a DHCP lease
eth0: offered 10.0.0.241 from 10.0.0.1
eth0: probing address 10.0.0.241/24
eth0: soliciting an IPv6 router
eth0: Router Advertisement from fe80::f60e:83ff:fef8:db8
eth0: adding address 2601:406:80:81d:8691:3944:5cd8:e3/64
eth0: adding route to 2601:406:80:81d::/64
eth0: adding default route via fe80::f60e:83ff:fef8:db8
eth0: soliciting a DHCPv6 lease
eth0: REPLY6 received from fe80::f60e:83ff:fef8:db8
eth0: adding address 2601:406:80:81d::db9f/128
eth0: renew in 302400, rebind in 483840, expire in 604800 seconds
forked to background, child pid 373
Starting system message bus: /usr/bin/dbus-uuidgen --ensure ; /usr/bin/dbus-daemon --system
Starting RPC portmapper: /sbin/rpcbind -l -w
Starting RPC NSM (Network Status Monitor): /sbin/rpc.statd
Starting OpenSSH SSH daemon: /usr/sbin/sshd
Enabled CPU frequency scaling governor: ondemand
Starting crond: /usr/sbin/crond -l notice
Loading /usr/share/kbd/keymaps/i386/qwerty/cf.map.gz


Welcome to Linux 4.14.79-gbde58ab01e armv7l (ttyS2)

In dmesg
[ 14.439779] 8021q: 802.1Q VLAN Support v1.8
[ 14.439802] 8021q: adding VLAN 0 to HW filter on device eth0
[ 16.485428] cpsw 48484000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 16.485473] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 16.511137] urandom_read: 1 callbacks suppressed
[ 16.511141] random: dhcpcd: uninitialized urandom read (120 bytes read)
[ 17.073052] omap_hwmod: timer14: _wait_target_disable failed
[ 18.404233] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
[ 18.411355] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[ 116.058207] random: crng init done


Michel

~1 minute for the Slackware boot process is pretty normal. Delays are often added by the DHCP client though - follow the boot process with the serial console and see how long that part takes. If it's DHCP, I don't have an answer for that!

The dmesg output suggests an unusually long time to initialize the entropy source. The commit that causes this monstrous delay is https://git.kernel.org/pub/scm/linux...fd77001536dd33

Do you have the "haveged" package installed? You might also try pinging your X15 during bootup from another machine, in order to generate some external entropy. The other machine might report "no route to host" but the point is to generate network activity to shake up the X15's entropy pool.

And if you're really brave (or foolhardy), revert the commit linked above and build a new kernel.

Aha! This makes sense.

If you're calling dhcpcd from rc.inet1 (rather than Network manager - I don't think that NM supports supplying any command line operators to dhcpcd), find the line:
And add an 'H' so that it becomes:
This should speed it up -- it seems to here, but the longest wait is for IPv6 addresses (which my DHCP server does not provide) so the next step would be to disable that if you don't do IPv6.
I'll have a look at this more and might roll this change in to the installer and the network-scripts package.

Yes, adding -H works.

This has bugged me for years - I thought it was due to having changed out a Managed switch, where the new one had some weird config on it.
Heh.

I'll push these updates out.
Thanks again!

Without giving it too much study, initially I think the issue is even if 'haveged' runs, it's too late because udevd initialised random from the initrd (at least if you're running standard Slackware ARM).
I thought about putting haveged in to the initrd to see if I could solve it that way, but as far as I know, I don't think that there are any other delay issues during boot that are due to a lack of entropy (if there are, let me know!); so it's easier to fix just dhcpcd that have to rebuild the Kernel whenever haveged is upgraded in order to keep the initrd and OS version of the binaries in sync. Also, people may upgrade the haveged package but not the Kernel package, and wonder why the old haveged is still running at next boot.

The "haveged" thing was just an idea off the top of my head. I wasn't at home when I posted that, so I had no machine(s) to research the issue (plus I had to leave for work shortly after).

Still, glad I could help.

Since your board has a hardware random number generator and assuming it works you could use that. You need to pass random.trust_cpu=on to the kernel boot time or compile your kernel with CONFIG_RANDOM_TRUST_CPU=y. That will tell the kernel that you trust the manufacturer of your machine.

Dunc.