TDCroPower

@BipBip1981 very good to hear that a higher version also runs stable, did the python test work for you without errors... for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done

@BipBip1981 you have set min and max to 1200MHZ? However, this means that you have a considerable power consumption, as the processors are permanently set to 1200MHZ permanently?

@ebin-dev We have already created an extra thread for OMV and have described the topic there... you haven't had any problems with the Max frequency settings so far? That would be really good, of course, as there were problems with Bullseye when using higher frequencies.

now that OMV is finally installable on the Bookworm image from @ebin-dev (hopefully a proper fix will come from the OMV devs soon) I would like to share the changes you have made to the system for the Helios64. Here are my optimizations... CPU Frequency: Since only 2 of the 6 cores of the Helios64 can reach the max of "1800000", the general max setting must unfortunately be set to a value below which all 6 cores can reach. CPU 1: Microarchitecture: Cortex-A53 Max Frequency: 1.416 GHz Cores: 4 cores Features: NEON,SHA1,SHA2,AES,CRC32 CPU 2: Microarchitecture: Cortex-A72 Max Frequency: 1.800 GHz Cores: 2 cores Features: NEON,SHA1,SHA2,AES,CRC32 Theoretically, all 6 cores can handle a max of "1416000", but unfortunately there have also been frequent problems with this, so a value of max "1200000" is recommended for a stable system. root@helios64:~# cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR="ondemand" MAX_SPEED="1200000" MIN_SPEED="408000" root bashrc In order to be able to use the bashrc with the root user, the following .profile file must be created in the /root directory with the following content... root@helios64:~# cat .profile if [ "$BASH" ]; then if [ -f ~/.bashrc ]; then . ~/.bashrc fi fi mesg n || true Docker Fix to fix the problem the line with ledtrig-netdev must be commented out so that containers can be started... root@helios64:~# cat /etc/modules-load.d/modules.conf lm75 #ledtrig-netdev Fancontrol: Here I have the following optimizations of the Fancontrol settings from a user from here... root@helios64:~# cat /etc/fancontrol # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-p6/pwm1=45 /dev/fan-p7/pwm1=45 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=25 /dev/fan-p7/pwm1=25 MINSTOP=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 #MINPWM=20 MINPWM=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 MAXPWM=/dev/fan-p6/pwm1=120 /dev/fan-p7/pwm1=120 after the change restart the fancontrol.service with... root@helios64:~# systemctl restart fancontrol.service LED State: If the flashing of the blue status LEDs of the Helios64 bothers you, you can simply stop the service, then it's quiet... root@helios64:~# systemctl stop armbian-led-state.service Alternatively, you can also just stop the status LED from flashing heartbeat by changing the value from heartbeat to none... root@helios64:~# cat /etc/armbian-leds.conf [/sys/class/leds/helios64::status] trigger=none brightness=0 invert=0 Do you have other optimizations for the system or other values like me? Please share them here 😉

@Trillien comment out the ledtrig-netdev line fixed the docker run problem... root@helios64:~# cat /etc/modules-load.d/modules.conf lm75 #ledtrig-netdev

...deleted...

@Trillien could be due to the commands after the installation... line 345-347 omv-confdbadm populate 2>&1 | tee -a ${logfile} omv-salt deploy run hosts 2>&1 | tee -a ${logfile} fi also explains why your "workaround" probably works, since the part is skipped if OMV has already been installed... line 295-297, end with fi on line 347 # install openmediavault if not installed already omvInstall=$(dpkg -l | awk '$2 == "openmediavault" { print $1 }') if [[ ! "${omvInstall}" == "ii" ]]; then ... the DEV ryecoaaron from the script is currently looking at the script fortunately and will hopefully fix the problem in the next version. Do you use Docker? For me, Helios crashes when I try to start a container, even with the hello-world test image from Docker... docker run hello-world

@Trillien your command to clean up the install doesn't work... root@helios64:~# dpkg-reconfigure -a Unknown option: a Usage: dpkg-reconfigure [options] packages -u, --unseen-only Show only not yet seen questions. --default-priority Use default priority instead of low. --force Force reconfiguration of broken packages. --no-reload Do not reload templates. (Use with caution.) -f, --frontend Specify debconf frontend to use. -p, --priority Specify minimum priority question to show. --terse Enable terse mode. edit: The following command worked and then the script ran through without any problems... finally I have OMV 7 on the eMMC (boot) + SSD installation! dpkg-reconfigure openmediavault or do you perhaps mean the following command, which has at least the -a option... dpkg --configure -a

@Trillien I have monitored the installation with the following command to see when the frequency is changed and then when it crashes. Command to monitor the cpufrequtil file... while [ 1 ]; do sleep 1; clear; tail /etc/default/cpufrequtils; done at this point the cpufrequtils file is changed to the 0 values... /usr/lib/python3/dist-packages/salt/grains/core.py:2711: DeprecationWarning: Use setlocale(), getencoding() and getlocale() instead ) = locale.getdefaultlocale() /usr/lib/python3/dist-packages/salt/grains/core.py:2711: DeprecationWarning: Use setlocale(), getencoding() and getlocale() instead ) = locale.getdefaultlocale() /usr/lib/python3/dist-packages/salt/utils/pycrypto.py:26: DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13 import crypt /usr/lib/python3/dist-packages/salt/modules/linux_shadow.py:21: DeprecationWarning: 'spwd' is deprecated and slated for removal in Python 3.13 import spwd Deploying service configurations ... <<<<< here !!! Processing system modifications ... <<<<< or here !!! and at this point the cpufrequtils file is changed back to its own values... - modules.omv_conf - modules.omv_utils Summary for helios64 ------------ Succeeded: 4 (changed=4) Failed: 0 ------------ Total states run: 4 Total run time: 3.700 s Summary for helios64 ------------ Succeeded: 6 (changed=5) Failed: 0 ------------ Total states run: 6 Total run time: 22.648 s and exactly then the helios64 crashes/reboots directly. I'll take a look at the script that is executed at this point and see if it can be deactivated. edit: ok the installation of omv changes the cpufrequtils file at this point of the script... line 337 - 343... _log "Installing openmediavault..." aptFlags="--yes --auto-remove --show-upgraded --allow-downgrades --allow-change-held-packages --no-install-recommends" apt-get ${aptFlags} install openmediavault 2>&1 | tee -a ${logfile} if [ ${PIPESTATUS[0]} -gt 0 ]; then _log "failed to install openmediavault package." exit 2 fi ... I'll go to the OMV forum and ask why this is done and whether it is really necessary, because changing the cpufrequtils without reboot kills the Helios! Here my OMV forum post: https://forum.openmediavault.org/index.php?thread/52156-omv-7-install-on-helios64-fails/

@Trillien you can also see the CPU frequencies in the sbc check... CPU 1: Microarchitecture: Cortex-A53 Max Frequency: 1.416 GHz Cores: 4 cores Features: NEON,SHA1,SHA2,AES,CRC32 CPU 2: Microarchitecture: Cortex-A72 Max Frequency: 1.800 GHz Cores: 2 cores Features: NEON,SHA1,SHA2,AES,CRC32

@Trillien I recommend that you do not set the max frequency to 1800000, set it only to max 1200000. Only 2 of the 6 cores can reach this high frequency and this often leads to problems. It is unpleasant but so far there is no solution. But it is not so tragic with a NAS. But thank you for the instructions/tips, I'll give it a try.

@Trillien unfortunately, I can no longer edit my instructions in the post, otherwise I would optimize them further with the new tips.

I had a little time to test again today and had an idea. I simply install OMV on the eMMC + eMMC combination and then transfer it to the SSD. The installation worked without any problems but unfortunately armbian-config does not offer the transfer from eMMC + eMMC to eMMC + SSD. So I also discarded this idea and tried to install everything on my microSD and then switch to eMMC + SSD. Well... the installation fails here too! The only combination to install OMV cleanly is on eMMC + eMMC, everything else fails and then has the known strange cpufrequtils entries. @ebin-dev do you have any ideas as to what is causing the problem and how I can fix it? I'm slowly running out of good ideas 🥲

I think I found something in the install script of omv that may be causing the problems. The script changes the CPU min/max frequency and the governor, which is known to be fatal with a Helios64! the omv install script can be found under... https://raw.githubusercontent.com/OpenMediaVault-Plugin-Developers/installScript/master/install edit: ok it's totally crazy, now the omv installation went through without any problems. However, I am surprised that I saw the following cpufrequtils during the failed installation... GOVERNOR="schedutil" MAX_SPEED="0" MIN_SPEED="0" so now I'll test it again with eMMC + SSD, hope it runs smoothly this time! edit2: the same again, in the middle of the installation of omv the helios64 restarts and has the following cpufrequtils content... root@helios64:~# cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR="schedutil" MAX_SPEED="0" MIN_SPEED="0" Why does it only work with eMMC + eMMC but not with eMMC + SSD? I just don't see what the cause is. The sbc-bench script ran before without any problems and the check with... for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done ... was without any problems.

@ebin-dev ok great, this gives me a clean installation and no unnecessary leftovers lying around.