Bug 75201 - Not boot with less than 1127MB of memory in VirtualBox "random: nonblocking pool is initialized"
Summary: Not boot with less than 1127MB of memory in VirtualBox "random: nonblocking p...
Status: NEW
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: other_other
Depends on:
Reported: 2014-04-30 23:50 UTC by Stefan de Konink
Modified: 2014-05-19 12:19 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.14.2
Tree: Mainline
Regression: No

Kernel configuration 3.14.2 (40.74 KB, application/octet-stream)
2014-04-30 23:50 UTC, Stefan de Konink

Description Stefan de Konink 2014-04-30 23:50:21 UTC
Created attachment 134511 [details]
Kernel configuration 3.14.2

I am building an embedded image to be used in a virtual environment. For this effort I have customly configured a kernel, and test my work in VirtualBox (4.3.10). Today I noticed that my configured kernel was unable to boot when the configured memory inside the Virtual Machine was smaller than ~1127MB of memory. To make it more exact: 1024MB or small doesn't boot and results in:

Random: nonblocking pool is initialized

or sometimes one step further:

futex hash table entries: 256 (order: 0, 6144 bytes)

At this moment I don't have a clue if this is a kernel issue, a kernel configuration issue, or a VirtualBox issue. I have added a bug in their tracker as well, prior to my validation with a vanilla kernel.


I have screen recorded my initial effort in the booting problem.


Is there any way to validate what it is doing when not having "sufficient" memory available?
Comment 1 Stefan de Konink 2014-05-01 09:50:37 UTC
Using VMware I can confirm that booting with 64MB works.
Comment 2 Alan 2014-05-19 12:19:52 UTC
A lot of the early setup code simply doesn't allow for out of memory - if we hit it we die, but I would usually expect a panic. The initcall tracer may help pin down where it gets too.

You can get a kernel into a fair bit under 1.1MB but you do need some patches that Dave Miller refuses to accept for upstream networking, some patches done for other trees and a recent x86 tool chain that can do the necessary link time optimisations/dropping.

Note You need to log in before you can comment on or make changes to this bug.