Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It takes about 100 seconds for the openssh server to start on my Beagleboard X15
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
~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!
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.
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:
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.
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.
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).
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.