Failed to start Entropy Daemon based on the HAVEGE algorithm on boot

Archurcl4w commented 3 years ago

Raspberry Pi 4 8GB running Kali Linux armv7l(armhf) - Linux kali 5.4.83-Re4son-v7l+ . Failed to start Entropy Daemon based on the HAVEGE algorithm durinng boot . haveged --version haveged 1.9.14 $sudo 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 Fri 2021-10-01 06:11:47 UTC; 1 day 21h ago Docs: man:haveged(8) http://www.issihosts.com/haveged/ Process: 504 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS (code=killed, signal=SYS) Main PID: 504 (code=killed, signal=SYS) CPU: 60ms

Oct 01 06:11:47 kali systemd[1]: haveged.service: Failed with result 'signal'. Oct 01 06:11:47 kali systemd[1]: haveged.service: Scheduled restart job, restart counter is at 5. Oct 01 06:11:47 kali systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm. Oct 01 06:11:47 kali systemd[1]: haveged.service: Start request repeated too quickly. Oct 01 06:11:47 kali systemd[1]: haveged.service: Failed with result 'signal'. Oct 01 06:11:47 kali systemd[1]: Failed to start Entropy Daemon based on the HAVEGE algorithm.

jirka-h commented 3 years ago

Hi,

I'm sorry to hear that. Could you please try to run the haveged standalone, if it works?

haveged -w 1024 -v 1 --Foreground

We need to find out if there is an issue with systemd setup or with haveged itself.

Thanks Jirka

Terraminator commented 3 years ago

I have the same problem my output is the following

Output: haveged: command socket is listening at fd3 haveged: ver: 1.9.14; arch: generic; vend: ; build: (gcc 10.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 continous tests(B): last entropy estimate 7.99612 haveged: fills: 0, generated: 0

Thanks for trying to help

jirka-h commented 3 years ago

Hi,

unfortunately, I don't have Raspberry Pi. Could you please try to use gdb to localize the problem?

Here are the steps.

Get haveged from github
Compile it with debugger support and link it statically (for this, you would need glibc-static package - I'm not sure if Kali Linux is using the same package name)
./configure CFLAGS="-static -g" --prefix /tmp/haveged
make LDFLAGS="-all-static"
mkdir /tmp/haveged
make install
As root, go to /tmp/haveged/sbin and start debugger:
gdb haveged
run -w 1024 -v 1 --Foreground
Please send me the output

Hopefully, this will help us to find the root cause of the problem.

Thanks a lot! Jirka

Terraminator commented 3 years ago

I did the folllowing to fix a couple of errors I got by running configure after fixing I get another error by doing: make LDFLAGS="-all-static"

sudo apt-get update sudo apt-get upgrade git clone https://github.com/jirka-h/haveged.git cd haveged sudo apt-get install libc-dev sudo apt-get install autotools-dev sudo apt-get install automake sudo apt-get install libtool sudo apt-get install autogen sudo apt-get install autoconf autoreconf -f -i -Wall,no-obsolete -I/usr/share/aclocal/ autoreconf -f -i -Wall,no-obsolete -I/usr/share/aclocal-1.16/ ./configure CFLAGS="-static" --prefix /tmp/haveged make LDFLAGS="-all-static"

root Desktop/haveged# make LDFLAGS="-all-static" make all-recursive make[1]: Entering directory '/root/Desktop/haveged' Making all in src make[2]: Entering directory '/root/Desktop/haveged/src' make[2]: No rule to make target 'havege.c', needed by 'libhavege_la-havege.lo'. Stop. make[2]: Leaving directory '/root/Desktop/haveged/src' make[1]: [Makefile:478: all-recursive] Error 1 make[1]: Leaving directory '/root/Desktop/haveged' make: *** [Makefile:374: all] Error 2

root Desktop/haveged# sudo make LDFLAGS="-all-static" make all-recursive make[1]: Entering directory '/root/Desktop/haveged' Making all in src make[2]: Entering directory '/root/Desktop/haveged/src' make[2]: No rule to make target 'havege.c', needed by 'libhavege_la-havege.lo'. Stop. make[2]: Leaving directory '/root/Desktop/haveged/src' make[1]: [Makefile:478: all-recursive] Error 1 make[1]: Leaving directory '/root/Desktop/haveged' make: *** [Makefile:374: all] Error 2

I couldnt run the following steps because the error above^^

mkdir /tmp/haveged make install cd /tmp/haveged/sbin gdb haveged run -w 1024 -v 1 --Foreground

Thank you

jirka-h commented 3 years ago

Thanks for giving it a try!

The error message is weird:

make[2]: Entering directory '/root/Desktop/haveged/src' make[2]: *** No rule to make target 'havege.c', needed by 'libhavege_la-havege.lo'. Stop.

havege.c is the source file, coming from the git repository. My guess is that there might be an issue with file permissions. Can you try

cat src/havege.c

to make sure it's readable? I can see it's stored under /root directory, so perhaps that's causing the problem.

BTW, in CFLAGS in configure step, -g is missing. This is needed for gdb to annotate binary objects to the source code. The complete command is:

./configure CFLAGS="-static -g" --prefix /tmp/haveged

Thanks a lot! Jirka

Terraminator commented 3 years ago

For some reason havege.c wasnt in my src folder so i reinstalled it and now it works, here is the output of gdb: root@TERRAMINATOR:/tmp/haveged/sbin# gdb haveged GNU gdb (Debian 8.3.1-1) 8.3.1 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from haveged... (No debugging symbols found in haveged) (gdb) run -w 1024 -v 1 --Foreground Starting program: /tmp/haveged/sbin/haveged -w 1024 -v 1 --Foreground haveged: command socket is listening at fd 3 haveged starting up haveged: ver: 1.9.16; arch: generic; vend: ; build: (gcc 10.2.1 CTV); collect: 128K haveged: cpu: (VC); data: 16K (D); inst: 16K (D); idx: 9/40; sz: 14994/65034 haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 8.00118 haveged: fills: 0, generated: 0

jirka-h commented 3 years ago

Great!

I don't see any error message from gdb. Could it be that haveged itself runs just fine?

Could you please try this?

1) Get the pv utility (either from package or here: https://github.com/icetee/pv) 2) Try pv /dev/random /dev/null (without running the haveged) and recortd the /dev/random speed 3)/tmp/haveged/sbin/haveged -w 1024 -v 1 --Foreground (as root in another terminal) and check if pv reports higher rate for /dev/random

If haveged stops, what is the return status of haveged command?

/tmp/haveged/sbin/haveged -w 1024 -v 1 --Foreground
echo $?

It's still not clear if A) haveged itself is running just fine and there is an issue with systemd haveged service B) haveged itself ends with error

Thanks a lot for the testing! Jirka

Terraminator commented 3 years ago

I guess the service works: with haveged: root@TERRAMINATOR: /Desktop/pv# pv /dev/random>/dev/null ^C.1MiB 0:02:00 [ 835KiB/s] [ <=> ]

without haveged: root@TERRAMINATOR: /Desktop/pv# pv /dev/random>/dev/null ^C 206 B 0:02:01 [0.00 B/s] [ <=> ] root@TERRAMINATOR:~/Desktop/pv#

So it has to be a bug in systemd haveged? Thank you for your help

jirka-h commented 3 years ago

Awesome! Yes, it means that daemon works. I suspect some problem with /etc/systemd/system/multi-user.target.wants/haveged.service. But let's first double check that haveged binary coming with your distro works.

Could you please stop the manually compiled binary (/tmp/haveged/sbin/haveged) and try instead haveged coming with your distro?

/usr/sbin/haveged -w 1024 -v 1 --Foreground

If that works (double check that with pv command) , could you please post here your haveged.service file?

cat /etc/systemd/system/multi-user.target.wants/haveged.service

Thanks! Jirka

Terraminator commented 3 years ago

The system havege service works too:

root@TERRAMINATOR:/home/User# /usr/sbin/haveged -w 1024 -v 1 --Foreground haveged: command socket is listening at fd 3 haveged starting up haveged: ver: 1.9.14; arch: generic; vend: ; build: (gcc 10.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 7.99998 haveged: fills: 0, generated: 0

Double Check: WIth haveged: root@TERRAMINATOR: /Desktop/pv# pv /dev/random>/dev/null 51.8MiB 0:01:01 [ 864KiB/s] [ <=> c52.6MiB 0:01:02 [ 866KiB/s] [ <=> ^C

Without haveged: root@TERRAMINATOR: /Desktop/pv# pv /dev/random>/dev/null ^C8 B 0:01:00 [0.00 B/s] [<=>

My haveged.service file looks like this:

[Unit] Description=Entropy Daemon based on the HAVEGE algorithm Documentation=man:haveged(8) http://www.issihosts.com/haveged/ DefaultDependencies=no After=apparmor.service systemd-tmpfiles-setup.service systemd-tmpfiles-setup-dev.service Before=sysinit.target shutdown.target

[Service] EnvironmentFile=-/etc/default/haveged ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS Restart=always SuccessExitStatus=137 143 SecureBits=noroot-locked CapabilityBoundingSet=CAP_SYS_ADMIN PrivateTmp=true PrivateDevices=true PrivateNetwork=true ProtectSystem=full ProtectHome=true ProtectHostname=true ProtectKernelLogs=true ProtectKernelModules=true RestrictNamespaces=true RestrictRealtime=true

LockPersonality=true MemoryDenyWriteExecute=true SystemCallArchitectures=native SystemCallFilter=@basic-io @file-system @io-event @network-io @signal SystemCallFilter=arch_prctl brk ioctl mprotect sysinfo

[Install] WantedBy=sysinit.target

Hope this helps

jirka-h commented 3 years ago

I think we are almost there! We will have to update haveged.service

Please try to

set PrivateNetwork=false
set PrivateTmp=false
update CapabilityBoundingSet=CAP_SYS_ADMIN CAP_SYS_CHROOT

and try to restart the service.

If it still does not work, try to compare haveged.service with the one from git repo (contrib/Fedora/haveged.service).

Please let me know how it goes.

Thanks Jirka

Terraminator commented 3 years ago

It doesnt work: root@TERRAMINATOR:/home/User# sudo service haveged restart Warning: The unit file, source configuration file or drop-ins of haveged.service changed on disk. Run 'systemctl daemon-reload' to reload units. root@TERRAMINATOR:/home/User# systemctl daemon-reload root@TERRAMINATOR:/home/User# sudo service haveged restart root@TERRAMINATOR:/home/User# sudo systemctl status haveged �� haveged.service - Entropy Daemon based on the HAVEGE algorithm Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor prese> Active: failed (Result: signal) since Fri 2021-10-01 20:49:02 CEST; 15s ago Docs: man:haveged(8) http://www.issihosts.com/haveged/ Process: 2115 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_> Main PID: 2115 (code=killed, signal=SYS) CPU: 80ms

Okt 01 20:49:02 TERRAMINATOR systemd[1]: haveged.service: Scheduled restart job> Okt 01 20:49:02 TERRAMINATOR systemd[1]: Stopped Entropy Daemon based on the HA> Okt 01 20:49:02 TERRAMINATOR systemd[1]: haveged.service: Start request repeate> Okt 01 20:49:02 TERRAMINATOR systemd[1]: haveged.service: Failed with result 's> Okt 01 20:49:02 TERRAMINATOR systemd[1]: Failed to start Entropy Daemon based o> lines 1-14/14 (END)

My haveged.service file now looks like this:

root@TERRAMINATOR:/home/User# cat /etc/systemd/system/multi-user.target.wants/haveged.service [Unit] Description=Entropy Daemon based on the HAVEGE algorithm Documentation=man:haveged(8) http://www.issihosts.com/haveged/ DefaultDependencies=no After=apparmor.service systemd-tmpfiles-setup.service systemd-tmpfiles-setup-dev.service Before=sysinit.target shutdown.target

[Service] EnvironmentFile=-/etc/default/haveged ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS Restart=always SuccessExitStatus=137 143 SecureBits=noroot-locked CapabilityBoundingSet=CAP_SYS_ADMIN CAP_SYS_CHROOT PrivateTmp=false PrivateDevices=true PrivateNetwork=false ProtectSystem=full ProtectHome=true ProtectHostname=true ProtectKernelLogs=true ProtectKernelModules=true RestrictNamespaces=true RestrictRealtime=true

LockPersonality=true MemoryDenyWriteExecute=true SystemCallArchitectures=native SystemCallFilter=@basic-io @file-system @io-event @network-io @signal SystemCallFilter=arch_prctl brk ioctl mprotect sysinfo

[Install] WantedBy=sysinit.target

Terraminator commented 3 years ago

There are a some huge differences between the two files, should I try to replace the file with the one from Github?

jirka-h commented 3 years ago

should I try to replace the file with the one from Github?

Yes, I think this is the best course now. The file on github works fine on Fedora and I assume it should work fine on any distro.

Terraminator commented 3 years ago

This gives the same error

jirka-h commented 3 years ago

Please try firt to comment out both

SystemCallFilter

lines. If it does not help, please try to commenting out one by one "Protect" and "Restrict" lines.

Terraminator commented 3 years ago

Ok it only works when i comment both lines when i uncomment one of them the errror appears! Thank you for your help seems to Work now!

jirka-h commented 3 years ago

Great! I'm really glad that you were able to solve this!

Could you please share your haveged.service file? I would like to add it to the GIT repo. (you can also create a merge request and place it under contrib/Kali_Linux directory).

Could you please also close the loop with Kali Linux package maintainer so that they update haveged.service in the binary package?

Thanks a lot Jirka

Terraminator commented 3 years ago

This is the working file: [Unit] Description=Entropy Daemon based on the HAVEGE algorithm Documentation=man:haveged(8) http://www.issihosts.com/haveged/ DefaultDependencies=no After=apparmor.service systemd-tmpfiles-setup.service systemd-tmpfiles-setup-dev.service Before=sysinit.target shutdown.target

[Service] EnvironmentFile=-/etc/default/haveged ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS Restart=always SuccessExitStatus=137 143 SecureBits=noroot-locked CapabilityBoundingSet=CAP_SYS_ADMIN CAP_SYS_CHROOT PrivateTmp=false PrivateDevices=true PrivateNetwork=false ProtectSystem=full ProtectHome=true ProtectHostname=true ProtectKernelLogs=true ProtectKernelModules=true RestrictNamespaces=true RestrictRealtime=true

LockPersonality=true MemoryDenyWriteExecute=true SystemCallArchitectures=native # SystemCallFilter=@basic-io @file-system @io-event @network-io @signal # SystemCallFilter=arch_prctl brk ioctl mprotect sysinfo

[Install] WantedBy=sysinit.target

I will do a merge Request in contrib/Kali_Linux_raspberry soon Thank you for your help!

jirka-h commented 3 years ago

I will do a merge Request in contrib/Kali_Linux_raspberry soon

Awesome:-) Thank you!

Jirka

Terraminator commented 3 years ago

Ok i copied the other files from contrib/Fedora and added the working haveged.service file. I guess we need to create another Makefile to integrate this? I will do a merge request for https://github.com/Terraminator/haveged/tree/master/contrib/Kali_Linux_raspberry Thank you

Terraminator commented 3 years ago

Oh btw here is the bug report: https://bugs.kali.org/view.php?id=7429

steev commented 3 years ago

This should be specific to the armhf version of the raspberrypi, not just raspberry. Haveged starts fine on the arm64 edition.

This may also be something because we use the 5.4 kernel on the raspberrypi?

steev commented 3 years ago

Looking back, because someone else had run into a similar issue, on the irc channel... where they thought haveged was causing their system to enter into recovery mode....

Looking closer here, what we see when haveged fails to start on the 32bit armhf images:

Aug 15 19:10:59 kali kernel: [    5.117123] audit: type=1326 audit(1629054659.249:2): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=478 comm="haveged" exe="/usr/sbin/haveged" sig=31 arch=40000028 syscall=122 compat=0 ip=0xb6f9ae98 code=0x80000000

Which, syscall 122 on arm is 122 common uname sys_newuname

jirka-h commented 3 years ago

@Terraminator: Thank you for the MR! I have renamed the directory to Kali_Linux_Raspberry_armhf and merged it.

@Steev: thank you for the details of why the systemd failed to start the haveged service. Do you know how to modify systemd SystemCallFilter to make it work?

This works fine on 64-bit systems:

SystemCallFilter=@system-service
SystemCallFilter=~@mount

Ideally, we would modify it so it works on all systems, including armhf. I don't have Raspberrypi to look for a fix. Right now, we have commented out the both lines to make it wotk on armhf.

Thanks a lot Jirka

steev commented 3 years ago

I have a few here (I'm the Kali ARM dev fwiw) - I'm going to look into this closer. I've always kind of ignored it because it was never fatal but when @Terraminator reported it in the bug tracker he said it was making his system go into recovery mode, which I've never seen here and the only other time that happened, it turned out to be a power issue for the person who reported it, they just assumed it was haveged because of the failure message.

For what it's worth, just those two you list above being in there, instead of the full lines as they are (before the pull request) seems to start just fine here on my 32bit rpi4 8gb (same setup as @Terraminator)

jirka-h commented 3 years ago

Thanks for looking into this! I appreacite it!

Could you please test this systemd service file https://github.com/Terraminator/haveged/blob/master/contrib/Fedora/haveged.service

if it works for you? I wasn't working for @Terraminator - the solution was to remove SystemCallFilter lines.

Thank you Jirka

steev commented 3 years ago

The one that is working for me is

cat /lib/systemd/system/haveged.service
[Unit]
Description=Entropy Daemon based on the HAVEGE algorithm
Documentation=man:haveged(8) http://www.issihosts.com/haveged/
DefaultDependencies=no
After=apparmor.service systemd-tmpfiles-setup.service systemd-tmpfiles-setup-dev.service
Before=sysinit.target shutdown.target

[Service]
EnvironmentFile=-/etc/default/haveged
ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS
Restart=always
SuccessExitStatus=137 143
SecureBits=noroot-locked
CapabilityBoundingSet=CAP_SYS_ADMIN
PrivateTmp=true
PrivateDevices=true
PrivateNetwork=true
ProtectSystem=full
ProtectHome=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
RestrictNamespaces=true
RestrictRealtime=true

LockPersonality=true
MemoryDenyWriteExecute=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@mount

[Install]
WantedBy=sysinit.target

The contents of /etc/default/haveged are:

cat /etc/default/haveged
# Configuration file for haveged

# Options to pass to haveged:
#DAEMON_ARGS=""

That said, I modified mine to be exactly what is in the Fedora one, and that also works here:

● haveged.service - Entropy Daemon based on the HAVEGE algorithm
     Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2021-10-12 20:40:00 UTC; 2 weeks 2 days ago
       Docs: man:haveged(8)
             http://www.issihosts.com/haveged/
   Main PID: 180 (haveged)
      Tasks: 1 (limit: 4915)
        CPU: 4.192s
     CGroup: /system.slice/haveged.service
             └─180 /usr/sbin/haveged -w 1024 -v 1 --Foreground

Oct 12 20:40:00 kali-rpi haveged[180]: haveged: command socket is listening at fd 3
Oct 29 03:25:52 kali-rpi haveged[180]: haveged: ver: 1.9.14; arch: generic; vend: ; build: (gcc 10.2.1 CTV); collect: 128K
Oct 29 03:25:52 kali-rpi haveged[180]: haveged: cpu: (VC); data: 16K (D); inst: 16K (D); idx: 12/40; sz: 15006/57790
Oct 29 03:25:52 kali-rpi haveged[180]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B):  last entropy estimate 7.99957
Oct 29 03:25:52 kali-rpi haveged[180]: haveged: fills: 0, generated: 0

jirka-h commented 3 years ago

@Steev: Thanks a lot for testing this.

I'm quite puzzled because this setup was NOT working for @Terraminator

@Terraminator - is there anything special about your setup?

Thanks a lot Jirka

Terraminator commented 3 years ago

No there isnt any special. I mean not just I got the bug, so I guess this hapens for some other reason. But one thing could actually be, I used this SD before on a Raspberry Pi 3b and used it for a long time after the change, but when I rebooted after the new updatethis error occurred. So i am a little bit confused. Thank you

jirka-h commented 3 years ago

@Terraminator - it's weird. Could you please conduct one more experiment? Based on comment from @steev , haveged service is terminated because it requires newuname system call which is disabled by systemd settings in haveged.service. Could you please try to add these lines to your haveged.service ?

SystemCallFilter=@system-service newuname
SystemCallFilter=~@mount

If it still fails, could you please check logs for hints which system call is required but blocked? Try

journalctl -u haveged.service

or

grep haveged /var/log/messages | grep audit

My goal is to find a haveged.service setup that works for everyone.

Thanks a lot! Jirka

Terraminator commented 3 years ago

This command works! Thank you

jirka-h commented 3 years ago

Finally! I'm glad that we have found a universal solution. I have added it to the haveged.service file.

Thank you, @steev for the hint and @Terraminator for testing!

eworm-de commented 2 years ago

With this change systemd now reports:

systemd[1]: /usr/lib/systemd/system/haveged.service:32: Failed to parse system call, ignoring: newuname

This is with latest linux (5.15.12) and systemd (250). Is this syscall specific to some architectures?

jirka-h commented 2 years ago

Hmm, it works fine for me on Fedora 33 and Fedora 34 (kernel 5.15.6, systemd 248) on x86_64.

I have now tested it on Fedora 36 running kernel 5.16.0 and systemd 250 (again x86_64) and it works fine there as well. Relevant part of /usr/lib/systemd/system/haveged.service:

SystemCallArchitectures=native
SystemCallFilter=@system-service newuname
SystemCallFilter=~@mount
SystemCallErrorNumber=EPERM

If I'm correct, newuname correspond to sys_newuname system call: https://github.com/torvalds/linux/search?p=1&q=sys_newuname

On which arch are you getting the Failed to parse system call, ignoring: newuname error?

eworm-de commented 2 years ago

This is x86_64. I will try to dig into this if I have some time.

Tuinslak commented 2 years ago

Looks like adding

SystemCallFilter=@system-service
SystemCallFilter=~@mount

Fixed it on a Raspberry Pi 1 and Zero (running RaspberryOS, latest version). Did not encounter the same issue on other Raspberry Pi 3 or 4.

jirka-h commented 2 years ago

Thanks for investigating it and sharing it here!

chippey5 commented 2 years ago

Looks like adding
SystemCallFilter=@system-service
SystemCallFilter=~@mount
Fixed it on a Raspberry Pi 1 and Zero (running RaspberryOS, latest version). Did not encounter the same issue on other Raspberry Pi 3 or 4.

This also fixes the issue on my Odroid XU4 (Linux 5.4.212-odroidxu4, Armbian 22.08)

jirka-h commented 2 years ago

This is great news! Thanks for sharing.

Chemita23 commented 2 years ago

This work ok for me in Odroid XU4, without "~@mount"; because in few minutes this make errors:

[Unit]
Description=Entropy Daemon based on the HAVEGE algorithm
Documentation=man:haveged(8) http://www.issihosts.com/haveged/
DefaultDependencies=no
After=apparmor.service systemd-tmpfiles-setup.service systemd-tmpfiles-setup-dev.service
Before=sysinit.target shutdown.target
Conflicts=shutdown.target
# RNDADDENTROPY ioctl requires host-level CAP_SYS_ADMIN, fails in unprivileged container
ConditionVirtualization=!container

[Service]
EnvironmentFile=-/etc/default/haveged
ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS
Restart=always
SuccessExitStatus=137 143
SecureBits=noroot-locked
CapabilityBoundingSet=CAP_SYS_ADMIN CAP_SYS_CHROOT
PrivateTmp=false
PrivateDevices=true
PrivateNetwork=false
ProtectSystem=full
ProtectHome=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
RestrictNamespaces=true
RestrictRealtime=true

LockPersonality=true
MemoryDenyWriteExecute=true
SystemCallArchitectures=native
SystemCallFilter=@system-service @basic-io @file-system @io-event @network-io @signal
SystemCallFilter=arch_prctl brk ioctl mprotect sysinfo

[Install]
WantedBy=sysinit.target

G2G2G2G commented 1 year ago

Most of this thread doesn't need the system service edited haveged detects CPU wrong on most ARM devices

you just have to edit the /etc/defaults/haveged

and add this:

DAEMON_ARGS="-w 1024 -d 16"

which is funny because the author at least tells you to run it with -w 1024 in this very thread the fallbacks don't seem to work either which is what above should be

this will fix several armbian boards (all the ones I have) xu4, hc2, and some others.. and raspberry pi etc.

https://lists.opensuse.org/archives/list/bugs@lists.opensuse.org/message/MAMNAE7Q57SN356VFLEV4LQLOOOYWCNI/

https://github.com/MichaIng/DietPi/issues/3689#issuecomment-678322767

also here which was posted before this github issue lol https://forum.armbian.com/topic/17276-haveged-fails-to-start-systemd/

seemingly posted all over already, lots of places mention needing -d 16 for ARM

jirka-h / haveged

Failed to start Entropy Daemon based on the HAVEGE algorithm on boot #63