On 1/1/21 9:06 PM, Chris Murphy wrote:
On Fri, Jan 1, 2021 at 6:40 PM Frank McCormick wrote:
Running Fedora 33 under systemd.
Lately my journal log has been spammed with hundreds of these lines:
Jan 01 20:26:56 localhost.localdomain rngd[645]: Entropy Generation is
slow, consider tuning
On Fri, Jan 1, 2021, 7:14 PM Tom Horsley wrote:
> On Fri, 1 Jan 2021 19:06:44 -0700
> Chris Murphy wrote:
>
> > You can remove the rng-tools package if you want. It's being removed
> > in Fedora 34.
>
> So where does random data come from in f34?
Kernel handles it.
--
Chris Murphy
__
On Fri, 1 Jan 2021 19:06:44 -0700
Chris Murphy wrote:
> You can remove the rng-tools package if you want. It's being removed
> in Fedora 34.
So where does random data come from in f34?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscri
On Fri, Jan 1, 2021 at 6:40 PM Frank McCormick wrote:
>
> Running Fedora 33 under systemd.
>
> Lately my journal log has been spammed with hundreds of these lines:
>
> Jan 01 20:26:56 localhost.localdomain rngd[645]: Entropy Generation is
> slow, consider tuning/adding sour
Running Fedora 33 under systemd.
Lately my journal log has been spammed with hundreds of these lines:
Jan 01 20:26:56 localhost.localdomain rngd[645]: Entropy Generation is
slow, consider tuning/adding sources
Jan 01 20:26:56 localhost.localdomain rngd[645]: Entropy Generation is
slow
On 10/6/20 4:13 PM, Frank McCormick wrote:
On 10/6/20 6:29 PM, Samuel Sieb wrote:
Entropy sources that are available but disabled
1: TPM RNG Device (tpm)
4: NIST Network Entropy Beacon (nist)
Available and enabled entropy sources:
0: Hardware RNG Device (hwrng)
5: JITTER Entropy generator
On 10/6/20 6:29 PM, Samuel Sieb wrote:
On 10/6/20 2:28 PM, Frank McCormick wrote:
My system log is filled with dozens of this line:
localhost.localdomain rngd[638]: Entropy Generation is slow, consider
tuning/adding sources
I see that mine is too.
Is this something to be concerned about
On 10/6/20 2:28 PM, Frank McCormick wrote:
My system log is filled with dozens of this line:
localhost.localdomain rngd[638]: Entropy Generation is slow, consider
tuning/adding sources
I see that mine is too.
Is this something to be concerned about?
It depends on if you're doing any
On Tue, 6 Oct 2020 17:28:24 -0400
Frank McCormick wrote:
> Is this something to be concerned about?
Doesn't matter if you are concerned, there isn't anything you can do
about it unless you can get an add-on hardware random number generator
that linux supports (a lot of laptops are coming with the
My system log is filled with dozens of this line:
localhost.localdomain rngd[638]: Entropy Generation is slow, consider
tuning/adding sources
Is this something to be concerned about?
Thanks
___
users mailing list -- users@lists.fedoraproject.org
On 5/5/19 6:07 AM, Tom Horsley wrote:
But the service knows that. Why isn't there a way to tell
systemd that in the .service file?
There's no use case for it. rngd is expected to terminate (more or
less) immediately after it gets sigterm. If there were another
directive to ignore shutdown
Tom Horsley writes:
On Sat, 4 May 2019 22:12:11 -0600
Joe Zeff wrote:
> Because systemd has no way of knowing what the service is doing or that
> it's safe to kill it without waiting for it to finish.
But the service knows that. Why isn't there a way to tell
systemd that in the .service file?
On Sat, 4 May 2019 22:12:11 -0600
Joe Zeff wrote:
> Because systemd has no way of knowing what the service is doing or that
> it's safe to kill it without waiting for it to finish.
But the service knows that. Why isn't there a way to tell
systemd that in the .service file?
__
Allegedly, on or about 4 May 2019, Tom Horsley sent:
> Though a sane person might ask, "Why is it the right thing to wait
> for a service gathering information which will be utterly discarded
> on the reboot anyway?"
Well, much as I hate to defend systemd, *it* doesn't know that *that*
service is
On 05/04/2019 08:20 PM, Tom Horsley wrote:
On Sat, 4 May 2019 18:58:32 -0700
Gordon Messmer wrote:
We don't need tortured logic to blame systemd. It's doing the right
thing.
Though a sane person might ask, "Why is it the right thing to wait
for a service gathering information which will be ut
On Sat, 4 May 2019 18:58:32 -0700
Gordon Messmer wrote:
> We don't need tortured logic to blame systemd. It's doing the right
> thing.
Though a sane person might ask, "Why is it the right thing to wait
for a service gathering information which will be utterly discarded
on the reboot anyway?"
__
On 5/4/19 4:13 PM, Sam Varshavchik wrote:
In the good-old days, when integrating some new gizmo like rngd, by
the nature of the beast you'll always check into how it works and make
a minimal effort to learn its basics. Basic due diligence. From the
linked bugzilla bug, it seems that rngd was co
Samuel Sieb writes:
On 5/4/19 9:32 AM, Sam Varshavchik wrote:
How can you possibly get stopping a piddly daemon, like rngd, wrong? Who
knows. It's brain damage.
As usual, it is not a systemd problem, unless you consider that trying to do
a clean shutdown is brain damage. The rngd proces
On 5/4/19 9:32 AM, Sam Varshavchik wrote:
I just wait 90 seconds, in those instances, and write it off as yet
another systemd brain damage.
According to systemd.service man page, TimeoutStopSec sets this timeout.
So you can add that to rngd.service, I suppose. Or, if you want to bring
out the
On Sat, 04 May 2019 12:32:59 -0400
Sam Varshavchik wrote:
> Maybe 1 in every 20 if my reboots gets held up for "stopping user processes".
That happens to me so often that I built an entire
big hammer from scratch just to hit the system with when I
reboot:
https://tomhorsley.com/game/punch.html
Tom Horsley writes:
I'm frequently rebooting my new fedora 30 install as
I test things, and on one reboot I got the entire
boot process held up by a stop job for rngd.service.
I'm rebooting for God's sake. Why do you need to stop
the reboot process to wait till you've gat
I guess this is probably this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1690364
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.
I'm frequently rebooting my new fedora 30 install as
I test things, and on one reboot I got the entire
boot process held up by a stop job for rngd.service.
I'm rebooting for God's sake. Why do you need to stop
the reboot process to wait till you've gathered
enough entropy
| From: D. Hugh Redelmeier
| To: Community support for Fedora users
| Date: Tue, 17 May 2016 15:27:53 -0400 (EDT)
| Subject: Re: Entropy from TPM of Fedora 23?
|
| | From: D. Hugh Redelmeier
|
| | I don't know how to get the TPM to feed entropy to the Linux kernel RNG.
|
| Maybe a clue
| From: D. Hugh Redelmeier
| I don't know how to get the TPM to feed entropy to the Linux kernel RNG.
Maybe a clue here:
sudo modprobe tpm-rng
sudo ./rngd -f -v
and now I've got lots of entropy in the pool.
--
users mailing list
users@lists.fedoraproject.org
To unsu
I have a server that I want to use to test Libreswan VPN software. This
requires a lot of entropy (for random number generation).
Unfortunately, the box, a Dell, has a processor with no RdRand
instruction. But it does have a TPM 1.2 module, and that is supposed to
be able to generate entropy
On Monday 11 January 2010 15:51:20 Roberto Ragusa wrote:
> Tim wrote:
> > Using psuedo code, what it did was:
> >
> > x = random number between 1 and 200
> > y = random number between 1 and 200
> > draw dot at x,y
> > repeat
>
> Your "plot some graph" trick is actually a powerful way to det
Tim wrote:
> Using psuedo code, what it did was:
>
> x = random number between 1 and 200
> y = random number between 1 and 200
> draw dot at x,y
> repeat
>
> Now, considering that the random number is generated from white noise,
> there is no way for me to affect *how* the number is gener
Tim:
>> One of my very old computers had a white noise generator for use by
>> the random number function. One day I decided to test it by
>> repeatedly polling it and using alternate polls as X and Y
>> co-ordinates to place a mark on a graph. The images was,
>> predominately, two fat parallel d
On Mon, 2010-01-11 at 18:27 +1030, Tim wrote:
> On Sun, 2010-01-10 at 03:47 -0800, Don Quixote de la Mancha wrote:
> > it's just like a bunch of Physicists to go to all the trouble to
> > build a randomness source out of a Geiger counter. A noisy resistor
> > or diode would have done the job just
On Sun, 2010-01-10 at 18:05 +0100, Roberto Ragusa wrote:
> IMHO, 16 bit sampling of a mic with high gain will produce at least
> 100 bit/s of entropy, especially in a noisy environment (server room
> with a lot of fans).
Sampling a microphone is likely to capture a regular pattern. S
On Sun, Jan 10, 2010 at 03:47:56 -0800,
Don Quixote de la Mancha wrote:
>
> If our Monte Carlo had any kind of non-randomness in it, it would have
> been very difficult for us to tell. It would have caused a systematic
> error in the calculated acceptance, which would have caused a
> systemati
On Sun, 2010-01-10 at 03:47 -0800, Don Quixote de la Mancha wrote:
> it's just like a bunch of Physicists to go to all the trouble to
> build a randomness source out of a Geiger counter. A noisy resistor
> or diode would have done the job just as well.
One of my very old computers had a white noi
e at least 100 bit/s
of entropy, especially in a noisy environment (server room with a lot
of fans).
A webcam could easily provide 1000 bit/frame, so 25000 bit/s. A 640x480
frame has about 30 pixels, so we are just asking one bit of randomness
out of 300 sampled pixels. I would guess the
The Physics collaboration I was with at CERN a while back used a
radioactive source and a Geiger counter to seed the random number
generator used for their Monte Carlo simulations of the experiment's
particle detector.
High-quality randomness is important for such an application because
the detect
35 matches
Mail list logo
