Oops, I didn't see Ken's reply where he already figure this out (spotty cell
service).
Where I work we were having this issue when bringing up new VMs. While
provisioning, it would seem to just hang for 10 or 15 minutes when installing
packages. No cpu usage, no disk io, no network io. And ev
VMs lack hardware devices to fill up the pool of random numbers. Installing the
haveged daemon will do expansion on the random numbers to keep the pool full.
-Dennis
On August 8, 2017 3:30:46 PM EDT, Ken D'Ambrosio wrote:
>On 2017-08-08 15:18, Joshua Judson Rosen wrote:
>
>>The /dev/ra
Well, I don't know what was wrong with catting random data to
/dev/random and /dev/urandom, but it didn't to diddly. "apt install
haveged", howver, and I'm now booting in ~20 seconds instead of 3 - 5
minutes. (It adds entropy -- or, if you prefer, "entropy" -- by seeing
how long certain thing
On Tue, Aug 8, 2017 at 3:18 PM, Joshua Judson Rosen
wrote:
> On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote:
> > On 2017-08-08 14:43, Bill Freeman wrote:
> >> As to why ruby is designed to require a random number before being
> >> asked to do something dependent on such a random number is a questio
On 2017-08-08 15:18, Joshua Judson Rosen wrote:
>The /dev/random interface is considered a legacy
> interface, and
>/dev/urandom is preferred and sufficient in all use cases,
> with the
>exception of applications which require randomness during
> early boo
On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote:
> On 2017-08-08 14:43, Bill Freeman wrote:
>> I don't know, but getrandom() may well be using /dev/urandom (or a
>> related facility). And that, in turn, might be waiting to "collect
>> sufficient entropy". So some network traffic, keystrokes, whateve
On 2017-08-08 14:43, Bill Freeman wrote:
> I don't know, but getrandom() may well be using /dev/urandom (or a
> related facility). And that, in turn, might be waiting to "collect
> sufficient entropy". So some network traffic, keystrokes, whatever,
> need to happen between boot time and the first
I don't know, but getrandom() may well be using /dev/urandom (or a related
facility). And that, in turn, might be waiting to "collect sufficient
entropy". So some network traffic, keystrokes, whatever, need to happen
between boot time and the first random emission, or that first "random"
number b