oh, I then saw entropy drop down to 900 and now it is back up to 1023. Obviously some process wants randomness everysooften and drains the random pool. You might have something hitting you hard. On 04/21/2017 09:32 AM, Robert Moskowitz wrote: > I find this very interesting point. I have done a bit of research > into entropy_avail and for example, > > Cat /dev/random can empty it. I went for > 2080 on my Cubieboard2 to > Zero, it is now back up to 870. > > On 04/17/2017 11:39 AM, SW at EU wrote: >> Hi, >> >> today I will report a problem that is released to ipa-server. This >> server contains a certificate authority and such service need many >> entropy. The default on CentOS 7 on a Banana PI is not enough, i.e. >> $(cat /proc/sys/kernel/random/entropy_avail) is less than 1000. >> >> I have solved this in meantime by installing and enabling of haveged >> from the EPEL repository. Normally it would be done by installing the >> rng-tools. But there are two problems: >> 1. The rng-tools was not in the repositories, so I have >> downloaded rng-tools-5-8.fc24.armv7hl.rpm because this are the same >> version which is included in CentOS 7.3 for x86_64. > > You can find the Centos rng-tools at: > > https://armv7.dev.centos.org/repodir/c7-pass-1/rng-tools/5-2.el7/armv7hl/rng-tools-5-2.el7.armv7hl.rpm > > Unfortunately, there are a lot of EPEL rpms that did not make it into > the repo. > >> 2. This rng-tools are usable but the daemon starts and stops >> immediately with the following error message: >> # rngd -v >> /dev/hwrng: No such device >> /dev/tpm0: No such file or directory >> No entropy sources found, exiting > > I now get: > > # rngd -v > read error > > read error > > Available entropy sources: > Intel/AMD hardware rng > > Wow, entropy_avail is now up to 1052! Looks like since I added > rng-tools things are looking up. I am going to add this to my howto... > >> >> This is not the problem of this binary it is a problem of the Kernel. >> /dev/hwrng exists and if I remove it then it reappears after reboot, but >> >> # ls -l /dev/hwrng >> crw-------. 1 root root 10, 183 1. Jan 1970 /dev/hwrng >> >> # udevadm info -a -n /dev/hwrng >> >> >> Udevadm info starts with the device specified by the devpath and then >> >> walks up the chain of parent devices. It prints for every device >> >> found, all possible attributes in the udev rules key format. >> >> A rule to match, can be composed by the attributes of the device >> >> and the attributes from one single parent device. >> >> >> looking at device '/devices/virtual/misc/hw_random': >> >> KERNEL=="hw_random" >> >> SUBSYSTEM=="misc" >> >> DRIVER=="" >> >> ATTR{rng_current}=="none" >> >> ATTR{rng_available}=="" >> > > I get the same results. Try the Centos rng-tools and see if it makes > a difference on your BPi. > >> >> there is no driver for this device. I have searched and found this >> link http://forum.lemaker.org/thread-23618-1-1.html which includes a >> link to the full story. If I read all right then on bananian >> /dev/hwrng appears only if the adapted or a more actual sun4i-ss.ko >> module is loaded (there is written: "module author has indicated this >> will be going into the mainline kernel shortly“). This module is also >> loaded on a Banana PI with current CentOS 7. So does the kernel of >> CentOS 7.3 for ARM32 include this patch and if yes why it does not >> work or otherwise why this device appears but has no driver? >> >> TIA, >> Silvio >> >> >> Sent with ProtonMail <https://protonmail.com> Secure Email. >> >> >> >> _______________________________________________ >> Arm-dev mailing list >> Arm-dev at centos.org >> https://lists.centos.org/mailman/listinfo/arm-dev > > > > _______________________________________________ > Arm-dev mailing list > Arm-dev at centos.org > https://lists.centos.org/mailman/listinfo/arm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20170421/77a4a0e6/attachment-0006.html>