I had a similar problem with the mini dock, using a 500ma left over wall wart. I've tried two Omega2+s. I next switched to a 2A unit (left over Kindle charger) and it's been running 4 days (so far, fingers crossed).
From the specs, 500mA should have been enough, but ...
@luz This is the community board, I haven't seen a lot of official presence here. Pretty much users helping each other.
Good info on the uboot. Thanks!
György -
Most Linux boots have a bunch of semi-scary messages. It's a function of trying to support as much hardware as possible, so that many things can "fail" w/o being catastrophic. A lot of the time they go away with a custom kernel that has the right drivers. But the hardware works fine because the required module is loaded ahead of time anyway.
It looks like you need to press enter per the prompt. The procd init piece is where the boot up sequence switches to running init. In normal Linux that's what sets up the ttys and takes over the console so you can have multiple sessions.
So I think it's waiting on you, LONG before the pool is finally initialized
I'm seeing the same problem. Interesting spin is that I have the OLED expansion, so I can see that sometimes my cron job keeps running (just the ssh server hangs) and sometimes the cron job stops too.
The logs are in the kernel buffer, access through logread, but if the ssh server is hung I can't get in to see them.
Just to close the loop in case anyone else finds this.
I found it worked using the standard location, ~/.ssh/authorized_keys.
I used puttygen (Windows) to create the key and pasted it in there.
There is a dropbearkey program that will let you create keys on the Omega2+ in case you want to ssh FROM the Omega2+ to, say GitHub/Gitlab...
There are a lot of reports of this across Google for various distributions including OpenWRT. No real solutions.
The "random: nonblocking pool initialized" message occurs when enough random (entropy) is finally collected to properly initialize /dev/urandom.
/dev/random is true randomness and so requests to it have to wait until enough random data is collected.
/dev/urandom is pseudo-randomness, requests are answered even if there isn't enough data to properly init (called the nonblocking pool since it won't block).
If you scan dmesg you will see warnings during boot of random data provided even though the pool isn't properly seeded:
[ 5.603477] random: procd: uninitialized urandom read (4 bytes read, 10 bits of entropy available)
[ 8.103183] urandom-seed: Seeding with /etc/urandom.seed
[ 9.136232] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
[ 9.145971] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
[ 9.155201] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
[ 9.164803] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
[ 9.174017] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
[ 9.183671] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
[ 9.193031] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
[ 12.104091] random: jshn: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[ 12.209382] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[ 54.978691] random: nonblocking pool is initialized
So basically this means that the hang-up is not occurring during boot, it has to be during the startup of the Linux system.
If you are lucky, you will still have data in the kernel buffer (logread) that matches up with the static dmesg data and you might be able to figure out what happens next... you might even see that message in the logread data!
On my Omega2+, what happened next was restarting dnsmasq to support the interfaces (I guess this makes sense, the required entropy probably came from packet arrival times after the interfaces came up)...
Tue Aug 1 14:26:10 2017 daemon.info odhcpd[836]: Initial RA router lifetime 0, 1 address(es) available on br-wlan
Tue Aug 1 14:26:12 2017 kern.notice kernel: [ 54.978691] random: nonblocking pool is initialized
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1447]: exiting on receipt of SIGTERM
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: started, version 2.76 cachesize 150
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no
-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: DNS service limited to local subnets
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq-dhcp[1737]: DHCP, IP range 192.168.3.100 -- 192.168.3.249, lease time 12h
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: using local addresses only for domain lan
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: reading /tmp/resolv.conf.auto
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: using local addresses only for domain lan
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: using nameserver xxx.xxx.xxx.xxx#53
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: read /etc/hosts - 4 addresses
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: read /tmp/hosts/odhcpd - 0 addresses
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq[1737]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Tue Aug 1 14:26:12 2017 daemon.info dnsmasq-dhcp[1737]: read /etc/ethers - 0 addresses
Not sure it's relevant, but it's a place to look...