I have installed the latest allo firmware on my Sparky / USBridge SBC
I have the following error message"haveged.service loaded failed " …
I do not really know what is haveged and how can it be important
How can I correct this error .?
Hello,
Could you provide some more information with:
systemctl status haveged
Hi,
many thanks for your message. haveged is an unpredictable random number generator based upon an adaptation of the HAVEGE algorithm.
Best to my knowledge, on newer DietPi images, it is not used anymore.
Please fin the result
root@DietPi:~# systemctl status haveged
● haveged.service - Entropy Daemon based on the HAVEGE algorithm
Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor preset: enabled)
Active: failed (Result: signal) since Sat 2021-01-09 09:22:18 CET; 12h ago
Docs: man:haveged(8)
http://www.issihosts.com/haveged/
Process: 940 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS (code=killed, signal=SYS)
Main PID: 940 (code=killed, signal=SYS)
janv. 09 09:22:18 DietPi systemd[1]: haveged.service: Service RestartSec=100ms expired, scheduling restart.
janv. 09 09:22:18 DietPi systemd[1]: haveged.service: Scheduled restart job, restart counter is at 5.
janv. 09 09:22:18 DietPi systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm.
janv. 09 09:22:18 DietPi systemd[1]: haveged.service: Start request repeated too quickly.
janv. 09 09:22:18 DietPi systemd[1]: haveged.service: Failed with result ‘signal’.
janv. 09 09:22:18 DietPi systemd[1]: Failed to start Entropy Daemon based on the HAVEGE algorithm.
@jolinar => so according to you I do not have to care about this error
best to my knowlage it’s not needed but MichaIng knows it better than I
On modern systems, an entropy daemon (random number generator to fill /dev/random faster than the kernel itself does) is practically required, else boot may hang, or services or security decreased when /dev/urandom or other theoretically predictable pseudo-ramdom number sources are used for any cryptographic task (which are much more in the background than what one might expect 
). A very typical symptom is indeed hanging boot for a longer time, which can be speedup by having a keyboard attached and typing some random keys which fills the entropy pool 
. I have that on my testing notebook, which sadly hangs before even starting the entropy daemon (haveged as well), so it fails it’s task in this particular case, at least for the boot hang.
haveged is one fallback daemon, which “should” always work, but is a bit more CPU and memory intense than using a native hardware random generator via rng-tools/rng-tools5. But that requires hardware/CPU support for it + a kernel that utilises it/creates a device from it, e.g. on RPi (and usually) it’s: /dev/hwrng (but there are a few other possible names)
AFAIK on Sparky SBC no hardware random generator is available, so we need to get haveged running reliably.
I strangely saw haveged failing in some other cases (unreliably, sometimes it starts, sometimes not). Can you check the following:
dpkg -l haveged # as we forced the manual install of a newer version to fix this bug: https://github.com/jirka-h/haveged/pull/7
haveged -F -v 1 # See if it starts up manually, cancel via CTRL+C in case and print output here
Thanks MichaIng for your help and explanation
Here is the result
root@DietPi:~# dpkg -l haveged
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Architecture Description
++±==============-============-============-===============================================
ii haveged 1.9.8-4 armhf Linux entropy source using the HAVEGE algorithm
root@DietPi:~# haveged -F -v 1
haveged: listening socket at 3
haveged starting up
haveged: ver: 1.9.8; arch: generic; vend: ; build: (gcc 9.2.1 CTV); collect: 128K
haveged: cpu: (VC); data: 16K (D); inst: 16K (D); idx: 12/40; sz: 15006/57790
haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 8.00323
haveged: fills: 0, generated: 0
^Chaveged: Stopping due to signal 2
root@DietPi:~#
Strange, works fine now and the version is the newer one, as expected (but we should still update it as there is 1.9.13 available meanwhile). Does the service work as well?
systemctl restart haveged
sleep 2
systemctl status haveged
root@DietPi:~# systemctl restart haveged
root@DietPi:~# sleep 2
root@DietPi:~# systemctl status haveged
● haveged.service - Entropy Daemon based on the HAVEGE algorithm
Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor preset: enabled)
Active: failed (Result: signal) since Sun 2021-01-10 18:42:17 CET; 9s ago
Docs: man:haveged(8)
http://www.issihosts.com/haveged/
Process: 3319 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS (code=killed, signal=SYS)
Main PID: 3319 (code=killed, signal=SYS)
janv. 10 18:42:17 DietPi systemd[1]: haveged.service: Service RestartSec=100ms expired, scheduling restart.
janv. 10 18:42:17 DietPi systemd[1]: haveged.service: Scheduled restart job, restart counter is at 5.
janv. 10 18:42:17 DietPi systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm.
janv. 10 18:42:17 DietPi systemd[1]: haveged.service: Start request repeated too quickly.
janv. 10 18:42:17 DietPi systemd[1]: haveged.service: Failed with result ‘signal’.
janv. 10 18:42:17 DietPi systemd[1]: Failed to start Entropy Daemon based on the HAVEGE algorithm.
Sorry, a typo my end, should have been: systemctl status haveged