Hi,

I generated SD images for A20-OLinuXino-Lime2-eMMC boards.

 

Kernel is 4.6.2, Debian wheezy, u-boot 2016.05

 

On my last two images (generated with slight differences in u-boot configuration), the first time I booted, everything worked fine.

 

After that, I installed a booting system on the eMMC of the card.

 

After few boots, (on the same board) the first SD card hanged  (several minutes) just after displaying:

random: nonblocking pool is initialized

The other card continued to work (booting did not hang).

 

A few hours later, I copied several files into a /data directory (.deb files).

 

Trying to boot that second card, it ran in the same blocked status: "random: nonblocking pool is initialized".

 

The first card: same thing.

 

I already waited for an hour once without success.

 

Booting from eMMC does does not hang

 

Any clue on what could avoid this problem ? And what causes it ?

a little guess here

the following step (after random init) blocks

 

it maybe hardware or in the example the swap setup http://askubuntu.com/questions/672121/is-it-usual-ubuntu-14-04-2-to-take-a-long-time-at-random-nonblocking-pool-is-i

 

Maybe your SD card has a problem.

Thank you,

 

I think I found why it did not work: without Ethernet cable connected, the boot process hangs. With the Ethernet cable connected, it works.

 

So I think that the random pool was not enough random without the cable connection.

 

So good news: my SD card is fine !

Thank you,

 

I think I found why it did not work: without Ethernet cable connected, the boot process hangs. With the Ethernet cable connected, it works.

 

So I think that the random pool was not enough random without the cable connection.

 

So good news: my SD card is fine !

 

Good job and thanks as you give a clue to another thread.

I still have the same problem on some SD cards (even with network connected).

 

Here is another lead I have not time yet to follow:

 

http://blog.jamesrhall.com/2014/04/ubuntu-server-1404-fun.html

 

Apparently, the kernel switches to a video mode that is not seen through serial link. So adding nomodeset could avoid this blocking.

 

Good job and thanks as you give a clue to another thread.

 

I am interested in the link of the other thread you talked about