blood

@Igor
Fans working great with fancontrol. I have 92 MM Noctua Fan attached and it is working perfectly. I can adjust the configuration as described here https://wiki.kobol.io/helios4/pwm/
@all
I also edited the default 2.5 inch drives case provided from helios4  (replaced fan mounts from default 70 mm fan to 92 mm fan) and added holes to mount ssds horizontally as well using 3.5 to 2.5 metal adapter from aliexpress .. It looks like this.. Very quiet and the drives stay cool.

Slightly off topic, but a very similar problem (if not exactly this problem) is a current issue for clearfog base and pro as they're based on the same SoC and use the same kernels. I had been running on an older kernel with some packages (including the kernel) held by dpkg. I also had never installed u-boot to SPI before (running it off my boot media instead). This morning I installed a newer u-boot to SPI (maybe not necessary), included the same offsets to armbianEnv.txt, unheld all packages, upgraded everything and rebooted - and everything worked. Thanks to everyone that contributed information here. Hopefully we can keep these systems running for a bit more now!

As seen in some other threads for mvebu-based boards (helios4, etc), the current images for clearfog base (and I assume) pro are broken in that it appears the initrd can't be loaded. I also haven't been able to use the u-boot for SATA booting in a while. I have been hitting both of these issues for a while and as I showed above in the past you can still flash old images, use an even older u-boot binary for SATA and get up and running - but now (and I'm not sure when it started) any upgrade to current packages renders the system unbootable. It's unfortunate, but it seems these boards are old enough that their support is rotting (and to be clear, I'm not blaming Armbian for this). While this hardware is old it's plenty performant as my home firewall to the Internet and so I don't want to replace it - but it's maybe time to start looking for a replacement anyways.
 
Just a few nights ago, I installed updates for the first time in a few months and when I rebooted it, it failed to come back up. Considering this is my router, that really cramped my style! But I got another box in place in this role and since then I've poked at this a bit. It's easy to reproduce:
Flash a copy of Armbian_23.11.1_Clearfogbase_bookworm_current_6.1.63.img to an m.2 SATA drive (if this isn't available any more, ping me and I can post it somewhere). Write a copy of the old u-boot for SATA support to the beginning of the drive (dd if=u-boot.sata of=/dev/foobarbaz bs=512 seek=1) Put the m.2 SATA drive into your clearfog and configure the jumpers to boot off SATA - see here. Plug in ethernet and micro USB to another system and attach to it for console (picocom -b 115200 /dev/ttyUSBFOOBARBAZ) Power it on and hopefully observe it boot - then go through the initial setup Update and upgrade packages (apt update && apt upgrade) Reboot - and watch it stall before it gets anywhere The trick then is to put a "hold" on the kernel and firmware packages before doing #6. The latest kernel I've been able to get running stable is 6.6.63-current-mvebu (installed via armbian-config).
for pkg in armbian-bsp-cli-clearfogbase-current armbian-firmware linux-dtb-current-mvebu linux-image-current-mvebu linux-u-boot-clearfogbase-current; do   echo "$pkg hold" | dpkg --set-selections done  
Then you should be able to upgrade everything else and reboot and have it not break. That list of packages is likely larger than it really needs to be, but after rebuilding my drive a couple of times I decided to not take any chances. The rest is either pure Debian or at least things that shouldn't break due to bit rot.
 
If I have more time I'll try to actually dig in and figure out what's wrong with the ramdisk (or whatever it is that causes this) and submit a fix, but this is better than nothing for now.

Slightly off topic, but a very similar problem (if not exactly this problem) is a current issue for clearfog base and pro as they're based on the same SoC and use the same kernels. I had been running on an older kernel with some packages (including the kernel) held by dpkg. I also had never installed u-boot to SPI before (running it off my boot media instead). This morning I installed a newer u-boot to SPI (maybe not necessary), included the same offsets to armbianEnv.txt, unheld all packages, upgraded everything and rebooted - and everything worked. Thanks to everyone that contributed information here. Hopefully we can keep these systems running for a bit more now!