Two services fail on every boot of an ARM single board computer. Your monitoring goes red and stays red. Neither one can ever succeed on this hardware. Here is how to prove that, and what to do about it.
This assumes you already run an ARM board on Debian or Armbian. It assumes you boot off eMMC, not a SATA or NVMe drive. It assumes something is watching your services and telling you they failed.
List your failed units with command systemctl --failed
haveged.service loaded failed failed Entropy daemon using the HAVEGE algorithm
smartd.service loaded failed failed Self Monitoring and Reporting Technology (SMART) DaemonRestart them. They fail again. Reboot the board. They fail again.
Both of these are real failures. Neither of them is a problem you can fix.
A dead entropy daemon does not mean you have no entropy. Check that first.
Read the pool with command cat /proc/sys/kernel/random/entropy_avail
3042Read the pool size with command cat /proc/sys/kernel/random/poolsize
4096That is a healthy pool. On my board haveged had been dead four days when I checked.
Now confirm the kernel seeded itself with command dmesg | grep crng
[ 1.791215] random: fast init done
[ 3.290239] random: crng init doneThat second line is the whole answer. Once crng init is done your kernel random source is secure and it never blocks. It does not need help.
Run it in the foreground with command haveged -w 1024 -v 1 -F
haveged: Couldn't initialize HAVEGE rng 5haveged times CPU cache behavior to harvest randomness. It has to calibrate against that timing to start. Plenty of ARM boards never give it a signal it can calibrate against.
haveged existed to feed a blocking /dev/random on old kernels. Kernel 5.6 changed how
that works. Check yours with command uname -r
5.16.20-rockchip64On this kernel haveged is not protecting you from anything.
Ask smartd what it found with command smartd -q onecheck
glob(3) found no matches for pattern /dev/sd[a-c][a-z]
In the system's table of devices NO devices found to scan
Unable to monitor any SMART enabled devices. Try debug (-d) option. Exiting...That is exit code 17. It reads like a permissions problem. It is not.
List your block devices with command ls /dev/mmcblk*
/dev/mmcblk1
/dev/mmcblk1boot0
/dev/mmcblk1p1The board boots off eMMC. eMMC is not SATA and it is not NVMe. It does not implement SMART at all. smartd is scanning for hardware that is not in the machine.
Think of SMART as a report card the drive keeps about itself. SATA and NVMe drives are built to keep one and hand it over when asked. An eMMC chip is closer to a plain memory card soldered to the board. It was never designed to keep that report card, so asking for it is not a failure. It is the wrong question.
Stop and disable them with command sudo systemctl disable --now haveged smartd
Mask them with command sudo systemctl mask haveged smartd
Clear the failed state with command sudo systemctl reset-failed
Confirm with command systemctl --failed
Mask is stronger than disable. A masked unit is linked to /dev/null and cannot be started
by anything. That includes a package upgrade that would quietly re-enable it.
crng init done in dmesg first. If that line is not there, the daemon is doing real work and
removing it can make your board hang on first boot waiting for entropy. Check before you mask, not
after.
You still want to know when the flash wears out. Masking smartd does not remove that need. eMMC reports its own health, just not through SMART.
Install the tool with command sudo apt-get install mmc-utils
Read the health with command sudo mmc extcsd read /dev/mmcblk1
Three fields matter.
eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x00
eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01Life Time A and B count in ten percent steps. 0x01 means 0 to 10 percent of rated life used. 0x0B means the chip is past its rated life. A covers one cell type and B covers the other. A board will often report 0x00 for B because it only has the one type.
Pre EOL information is the one to alert on. 0x01 is normal. 0x02 means the chip is into its reserve blocks. 0x03 means replace it.
Point your monitoring at those three values. That is the check that tells you something true.
An alert that can never go green is worse than no alert.
You learn to skip it. Then you start skipping the ones next to it. A permanently red service on a 3D printer is how you miss a real one on a mail server.
Fix it or mask it. Do not leave it red.
https://www.kernel.org/doc/html/latest/admin-guide/laptops/index.html
https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git
https://www.smartmontools.org/wiki/TocDoc