DietPi-Software | ARMv7: haveged crashes

[jg777]

Creating a bug report/issue

Required Information

• DietPi version | cat /boot/dietpi/.version
• G_DIETPI_VERSION_CORE=7
  G_DIETPI_VERSION_SUB=5
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'
  G_LIVE_PATCH_STATUS[0]='not applicable'
• Distro version | 11.0
• Kernel version | Linux solarship 4.14.241+ # 1 SMP PREEMPT Wed Jul 28 16:55:16 UTC 2021 armv7l GNU/Linux
• SBC model | Odroid XU3/XU4/MC1/HC1/HC2 (armv7l)
• Power supply used | 12V/2A
• SDcard used | PNY Elite
• SSD used | DietPi's rootfs is running off the SSD attached to the SATA port

Additional Information (if applicable)

• Software title | Nextcloud
• Was the software title installed freshly or updated/migrated? Fresh install with both Buster and Bullseye
• Can this issue be replicated on a fresh installation of DietPi? On this hardware it might be replicatible. I've had it happen today with three different Fresh installs; 2 Buster and 1 Bullseye from a Buster-upgrade

• Bug report ID | did not send one

Steps to reproduce

1. Type dietpi-software install 114 to start Nextcloud install. I have tried this with Apache or Nginx and it did not seem to make a difference as it hung at the same spot.
2. It runs thru most of the installs and I can see the services running as it installs with htop.
3. Everything appears great but then it hangs on the Nextcloud "section" with this message on all 3 fresh installs.
   [ OK ] DietPi-Software | chown -R www-data:www-data /var/www/nextcloud /mnt/dietpi_userdata/nextcloud_data
4. It never leaves that message on the terminal running dietpi-software.
5. Then I open a new terminal and restart the web server.
6. Then the web server functions on port 80 and with /nextcloud it presents the "Create a Nextcloud admin page". I don't know this information as I believed it was generated with the dietpi-software scripts.
7. Then I assume something might not be working and try to uninstall and reinstall it.
8. Type sudo dietpi-software uninstall 114 and it prompts "114: Nextcloud is not currently installed" when it seems to be there, but it did not finish setting up correctly with the script.
9. Also the only way to break from the stuck DietPi-Software line above is control + C.

Expected behaviour

• Nextcloud dietpi-script should finish and then bring you back to command prompt without having to control + C

Actual behaviour

• Nextcloud dietpi-script hangs at "[ OK ] DietPi-Software | chown -R www-data:www-data /var/www/nextcloud /mnt/dietpi_userdata/nextcloud_data" and the system does not register that Nextcloud is installed so it not able to be uninstalled

Extra details

• ...

[Joulinar]

Hi,

I guess is same behaviour as this one #4318
But it should have been fixed already, strange. 🤔

A workaround could be following

apt purge --autoremove rng-tools-debian rng-tools rng-tools5
apt install haveged
systemctl start haveged

[MichaIng]

Yes this should have been done as part of the update to v7.2: https://github.com/MichaIng/DietPi/blob/99739bd/.update/patches#L105-L111

[jg777]

@Joulinar I tried those commands and found the following:

1. system did not have rng-tools-debian rng-tools rng-tools5 installed.
2. haveged was already installed

after starting haveged, it's status was failed as follows

$ 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 Mon 2021-09-06 20:58:15 BST; 1min 26s ago
       Docs: man:haveged(8)
             http://www.issihosts.com/haveged/
    Process: 573 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS (code=killed, signal=SYS)
   Main PID: 573 (code=killed, signal=SYS)

Sep 06 20:58:15 SYS-NAME systemd[1]: haveged.service: Scheduled restart job, restart counter is at 5.
Sep 06 20:58:15 SYS-NAME systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm.
Sep 06 20:58:15 SYS-NAME systemd[1]: haveged.service: Start request repeated too quickly.
Sep 06 20:58:15 SYS-NAME systemd[1]: haveged.service: Failed with result 'signal'.
Sep 06 20:58:15 SYS-NAME systemd[1]: Failed to start Entropy Daemon based on the HAVEGE algorithm.

but them after a haveged service restart, it appears as follows:

$ 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: active (running) since Mon 2021-09-06 20:59:56 BST; 5ms ago
       Docs: man:haveged(8)
             http://www.issihosts.com/haveged/
   Main PID: 1314 ((haveged))
     Memory: 128.0K
     CGroup: /system.slice/haveged.service
             └─1314 (haveged)

Sep 06 20:59:56 SYS-NAME systemd[1]: Started Entropy Daemon based on the HAVEGE algorithm.

Now I try to install Nextcloud again and it hangs on the same message:
[ OK ] DietPi-Software | chown -R www-data:www-data /var/www/nextcloud /mnt/dietpi_userdata/nextcloud_data

[MichaIng]

EDIT: Ah wait, so you're on Bullseye now? Skip the below if so, that was only relevant on Buster!

Please try the following:

cd /tmp
curl -sSfLO "https://dietpi.com/downloads/binaries/buster/libhavege2_$G_HW_ARCH_NAME.deb"
curl -sSfLO "https://dietpi.com/downloads/binaries/buster/haveged_$G_HW_ARCH_NAME.deb"
G_AGI "./libhavege2_$G_HW_ARCH_NAME.deb" "./haveged_$G_HW_ARCH_NAME.deb"
rm "./libhavege2_$G_HW_ARCH_NAME.deb" "./haveged_$G_HW_ARCH_NAME.deb"

I forgot that there was an issue with the version on Debian Buster on ARM, so we did a patch to use the ones from Bullseye. But that was a long time ago before haveged was even installed on XU4: https://github.com/MichaIng/DietPi/blob/dev/dietpi/patch_file#L2711-L2721

Interestingly the other user, who reported failing rngd on XU4 first, didn't have any issues with the haveged from Debian. Probably it was a Stretch system 🤔.

---

When you are on Bullseye, check the following:

cat /proc/sys/kernel/random/entropy_avail
cat /proc/sys/kernel/random/write_wakeup_threshold

The first should show a higher number than the second. haveged should actually assure that this stays true. When you run the following, you can trigger haveged to become active and see whether it keeps the entropy pool filled as expected:

tr -dc '[:alnum:]' < /dev/random | head -c30

If this hangs, likely cat /proc/sys/kernel/random/entropy_avail returns a very lower number and I bet that haveged then crashed for whatever reason.

[jg777]

Edit: just saw you added Bullseye commands to try. Will try and update

Yep, this install is on Bullseye. I tried the following commands and then tried to install Nextcloud again and it's hanging in the same place. Any suggestions on a good pkg to test installing to see if it's a "deeper" issue?

[jg777]

What I've found

• cat /proc/sys/kernel/random/entropy_avail always returns a number less than 100, haveged was started and then fails as above couple of comments mention
• after restart, now command is returning a number of 200 something
• after restart, now command is returning a number of 300 something
• then checking haveged status again shows the failed state I mention in a couple of comments above
• I started haveged again and the command is showing a 500 something number and now a 600 something number, so it appears to be incrementing slowly
• cat /proc/sys/kernel/random/write_wakeup_threshold keeps producing a higher number than all the above results of "896"

[MichaIng]

No joy with haveged on ARM continues 😄. I think this is the related bug:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985196
• https://archlinuxarm.org/forum/viewtopic.php?t=14549

So 32-bit ARMs seem to not support a certain syscall that haveged does. It then automatically falls back to a different one (uname), but the default systemd unit has hardenings which deny this. Workaround is hence to explicitly allow this syscall. Please try:

mkdir -p /etc/systemd/system/haveged.service.d
echo -e '[Service]\nSystemCallFilter=uname' > /etc/systemd/system/haveged.service.d/dietpi.conf
systemctl daemon-reload
systemctl restart haveged

[jg777]

@MichaIng I have tried those commands and the Nextcloud install appears to have completed, but fails to restart Apache2 at the end of the script.

[FAILED] DietPi-Services | restart : apache2

Apache2 fails when I try to start it complaining that /var/log/apache2 does not exist. I changed my system logging to SSD disk in one of the dietpi menus. I then created that directory and Apache2 started up just fine.

Navigated to http://ip-address/nextcloud, logged in using admin and my dietpi global password and we're good to go! The create-a-haveged-systemd "fix" definitely worked. Thank you for helping me get this working.

[MichaIng]

Okay, great that we found it. So two things to do:

• Re-apply the haveged fix on Buster ARM systems, using the Bullseye package, so it is applied on XU4 as well.
• On ARMv7, additionally apply the syscall fix.
• On Bullseye ARMv7, apply the syscal fix as well.

I changed my system logging to SSD disk in one of the dietpi menus.

What? There is no option to change the logging to an SSD disk. You can enable or disable RAM logging (install/uninstall DietPi-RAMlog), but that should preserve all /var/log content, when an ordinary shutdown was done at least.

[Joulinar]

Maybe RootFS has been moved to SSD.

@jg777 did you tested a reboot? Does Apache is still working?

[jg777]

@MichaIng Sorry for confusion, I moved the rootFS to SSD. I changed logging to disk. For some reason I had to create /var/log/apache2 for it to start again as it wasn't already created.

@Joulinar I have tested it on reboots and Apache2 starts and Nextcloud works. Yay!

[MichaIng]

I moved the rootFS to SSD. I changed logging to disk.

Ah you did both in the same session? Then it makes sense: Only non-volatile files are moved to the new disk, which means that newly created files in /var/log are not included, and on shutdown, the /var/log file/dir structure is copied to the old disk. One side affect of removing the mandatory reboot after software installs. I'll add a step when moving the root filesystem, to additionally copy the the current /var/log content to the RAM log disk store on the new drive, if RAM logging is enabled. Since moving the root filesystems forces a reboot, there is no chance that additional log files are created.

[MichaIng]

Fixed with: 899a42a