Could you please update to haveged 1.9.15-1 ?
The kernel condition (<5.6) introduced in the 1.9.14-2 disable it…
Could you please update to haveged 1.9.15-1 ?
This is not our package. We get it from arch-arm and I built 1.9.15-1 using the arch-arm PKGBUILD and it still has the kernel version check in the .service file.
Arch ARM has not pushed 1.9.15 to the mirrors yet. When they do, it will get into our Unstable branch too.
I was wrong, they remove the patch command from PKGBUILD but put it directly to the haveged.service file in the repo.
So, it is supposed to be inaccurate for our new kernel which are greater than 5.6…
I guess, you will have to patch the package.
I don’t see anything related to the kernel 5.6 stuff in the 1.9.15 Arch Linux ARM PKGBUILD. So where do you see that?
Well, haveged is obsolete in newer kernels. He means this: haveged/haveged.service at master · jirka-h/haveged · GitHub More info here.
Remove the line
ConditionKernelVersion=<5.6 from /usr/lib/systemd/system/haveged.service
Ah okay. So it’s an upstream issue now then.
When the haveged.service fails on my x86 with the kernel check the available entropy is much higher than with the pi4 when the service fails with the kernel check. In the past they have recommended on the pi to have @3000 available entropy. For some reason the kernel thinks the pi4 should have 472. I have no clue if this low number is going to be ok or not for the pi but it seems to me it should be some near as my Desktop.
[ray@ray-pc ~]$ cat /proc/sys/kernel/random/entropy_avail 3578
472 available entropy when the .service fails on the pi seems to be too low to me but I do not know at the moment what is recommended.
With the kernel check removed on the pi4:
[ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail 2459
In this case we could create a pacman hook which replaces the service on package updates with one without the check. We can then avoid maintaining haveged on our end.
The update has been pushed to the upstream as you may have noticed.
The kernel condition is still there as @Darksky said.
I don’t know how to handle it but everyone should be affected since 1.9.14-2 which was already in all other branches.
In former time on other platforms, I used to have delay to connect to servers via ssh because of lack of entropy (key exchange mechanism).
Because haveged is no longer needed. This is very much intentional. If you think Haveged is not obsolete then you may want to comment that upstream, since the creator himself was the one that came to the conclusion that his project was no longer needed: is haveged still useful/relevant? · Issue #57 · jirka-h/haveged · GitHub
@philm - haveged is also a requirement of
manjaro-tools-pkg. Maybe it should be removed?
I just ran this command on my Pinebook Pro and the result was 3229.
Which would indicate the issue is a kernel config option.
The Pinebook Pros kernel (
CONFIG_CRYPTO_JITTERENTROPY=y while the
linux-rpi4-mainline kernels have
So maybe the module is just not loaded on the Raspberry Pi. Changing it to
y might be the solution here.
That’s a good lead and good news!
Hope it’s working ans we can end this…
Well, @Darksky you can modprobe the module
jitterentropy_rng and see if the result changes. Then decide to built it in by setting Y. Pinephone Kernel also uses Y here.
I will have to go back and test the linux-rpi4-rc 5.15-rc3 kernel which was used in the original post on this topic in another thread but this seems to not be an issue with the linux-rpi4-mainline 5.14.9 kernel.
Notice the module
jitterentropy_rng does not get loaded here also so it looks like it is not related to the issue. At this time with out some more testing it looks like it is an issue with the linux-rpi4-rc 5.15-rc3 kernel it’s self.
[ray@pi3 ~]$ uname -r 5.14.9-1-MANJARO-ARM [ray@pi3 ~]$ [ray@pi3 ~]$ sudo systemctl status haveged ○ haveged.service - Entropy Daemon based on the HAVEGE algorithm Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled) Active: inactive (dead) Condition: start condition failed at Tue 2021-08-31 08:11:21 CDT; 1 month 2 days ago └─ ConditionKernelVersion=<5.6 was not met Docs: man:haveged(8) http://www.issihosts.com/haveged/ [ray@pi3 ~]$ [ray@pi3 ~]$ cat /proc/sys/kernel/random/entropy_avail 3413 [ray@pi3 ~]$ [ray@pi3 ~]$ lsmod | grep jitterentropy_rng [ray@pi3 ~]$
OK with more testing with the linux-rpi4-rc 5.15-rc3 kernel It looks like it’s default entropy value is low but it does climb up and if I force a lot of disk activity in another terminal it climbs up fast. Of course this is not a solution for the low initial entropy value.
[ray@pi4 ~]$ uname -r 5.15.0-rc3-1-MANJARO-ARM [ray@pi4 ~]$ [ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail 624 [ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail 3115 [ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail 3296 [ray@pi4 ~]$ lsmod | grep jitterentropy_rng [ray@pi4 ~]$
What I did find that worked is install rng-tools since it looks like haveged is obsolete and will probably will not be in future images. Hopefully in the future either upstream or RPi will get this issue fixed with this kernel. But from reading about rng_tools this might be a better option to have for the entropy pool.
sudo pacman -S rng-tools sudo systemctl enable rngd.service
After reboot (the modulejitterentropy_rng is still not a factor ):
[ray@pi4 ~]$ uname -r 5.15.0-rc3-1-MANJARO-ARM [ray@pi4 ~]$ [ray@pi4 ~]$ cat /proc/sys/kernel/random/entropy_avail 4035 [ray@pi4 ~]$ [ray@pi4 ~]$ lsmod | grep jitterentropy_rng [ray@pi4 ~]$
But by switching the jitterentropy module to be built in, a third party tool (like rng-tools) won’t be needed.