On Thu, 2014-11-13 at 09:56 +0100, Jan Stodola wrote:
On 11/13/2014 08:37 AM, Vratislav Podzimek wrote:
> On Thu, 2014-11-13 at 08:03 +0100, Vratislav Podzimek wrote:
>> On Wed, 2014-11-12 at 14:30 -0500, Samantha N. Bueno wrote:
>>> On Wed, Nov 12, 2014 at 02:42:43PM +0100, Vratislav Podzimek wrote:
>>>> We require minimum amount of random data entropy when doing encrypted
autopart
>>>> so this makes the 'part --encrypted' command work the same.
>>> I think this looks ok. I tested this with Jan's provided ks file in the
>>> bug; for whatever reason, with the %pre block, the amount of entropy
>>> keeps getting reset after reaching ~24%. Without the %pre block, this
>>> works perfectly fine though. I'm not really sure why that might be, or
>>> if you want to consider that a bug.
>> That seems like some process being run periodically which eats entropy
>> because of kernel's randomization used when placing new stuff somewhere
>> in memory. I'll have a closer look at the %pre section and our code
>> handling it, maybe there's something stupid.
> So, this explains a lot:
>> %pre
>> cat /dev/random > /dev/null 2>&1 &
>> %end
> which is precisely what you do if you want to eat entropy from the
> kernel's random pool all the time. No wonder entropy never gets to the
> required level with this %pre script.
>
> I just hope Jan didn't use this for all the bug reports on s390x he
> created because it's like testing new speed limit of a car with its
> tyres removed.
>
Sorry for confusing you with the %pre script. It really has only one
purpose - to ensure that kernel entropy is low, so that anaconda always
shows the prompt to increase the entropy by typing on keyboard.
And no, I didn't use this %pre script in my earlier entropy bugs :-)
Glad to
know that. :) Thanks for the explanation!
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic