SIGSEGV

Thanks @lanefu. Another idea would be a "test week" (or whatever period makes sense) - a time when the users can download pre-release/test images of the upcoming version/release and the maintainers give timely feedback about issues found in the test kernels and user space binaries. I know that Fedora follows a similar approach (I get the notifications from the Fedora Magazine) - the main objective is to catch breaking bugs. Now, if the community doesn't participate - then all complaints can be considered rants. We have to participate to make sure our systems are running as smoothly as possible. Software development, QA, Trouble shooting are task that take time/effort, as @Igor has always pointed out, we need to get involved somehow in order to contribute back. In the end Armbian is a community project - if you can't/want to donate funds, donate time and effort instead.

@Igor, is there a way to have access and test pre-release images from the official Armbian build system (nightly images should be fine)? That way we can participate on the QA process and help raise flags when pre-released changes break the stable builds. I understand that you do not have an Helios64 to test, and so as part of the community we should be able to help in that regard.

Thank you @aprayoga

@halfa I get this as output: Package: armbian-bsp-cli-helios64 Version: 21.05.8 Priority: optional Section: kernel Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 1,024 B Provides: linux-focal-root-legacy-helios64, linux-focal-root-current-helios64, linux-focal-root-edge-helios64 Depends: bash, linux-base, u-boot-tools, initramfs-tools, lsb-release, fping Recommends: bsdutils, parted, util-linux, toilet Suggests: armbian-config Breaks: linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~) Replaces: zram-config, base-files, armbian-tools-focal, linux-focal-root-legacy-helios64 (<< 21.05.8~), linux-focal-root-current-helios64 (<< 21.05.8~), linux-focal-root-edge-helios64 (<< 21.05.8~) Download-Size: 417 kB APT-Manual-Installed: yes APT-Sources: http://apt.armbian.com focal/focal-utils arm64 Packages Description: Tweaks for Armbian focal on helios64 I see a few packages listed under 'Breaks'

@ebin-dev @m11k - how often do you update the packages on your NAS? Or do you do installation once and then cherry pick which updates you want?

@Heisath @Igor I don't have environment to build the image at the moment, but if there is a repository where the beta images are available I can test them out.

@Heisath Right now the file present on the installation is: '90-helios64-hwmon-legacy.rules' I'll update the title of this post to mark a temporary fix, I agree with both of you that the fans should be tied to the CPU temperatures and not the board. But since the release broke monitoring having the fan control tied to something is better than nothing - otherwise the fan don't even spin up.

A few Armbian packages were updated (armbian-bsp-cli-helios64, armbian-config, armbian-firmware &armbian-zsh) to version 21.05.08. At some point I noticed that the fancontrol service had failed to start up after the reboot - it was complaining about a file missing(/dev/thermal-cpu). If you run into this after the update, just update your /etc/fancontrol to the content below and your fancontrol should go back to normal. # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu # After 21.05.08 [2021.08.10] # Temp source : /dev/thermal-board INTERVAL=10 # FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input # After 21.05.08 [2021.08.10] FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-board/temp1_input /dev/fan-p7/pwm1=/dev/thermal-board/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=20

@jsfrederick You can just write the image to the SD card and boot. For SSH, as long as you know what IP address the Helios64 gets than you can just use that to connect. The serial terminal is just to check if things booted correctly or in case of an error that needs to be diagnosed. You should be fine with your usual process.

Thank you @Werner

I checked for any available updates yesterday, and this (linux-u-boot-helios64-current 21.08.1) was applied. Can't find what was new or if it was only a version bump. By the way, nothing broke after the update.

I'm curious about this issue. Let us know if changing the CPU Voltage has an effect on system stability.

Hello @Igor, @Werner, I'm open to collaborating to the armbian project, my background is on software development and system administration and I have a small Helios64 to test things with.

Enjoy your time off - looking forward to new products from you guys.

My comment might be late to the party - if there was a possibility to add an optional display and a few user-configurable buttons to the Front Panel, that would be great. I know it would mess a bit with the airflow, but it could be used for system monitoring and few other specific use cases.

Thanks @aprayoga. What's new or has changed in the latest SATA firmware image?

@wurmfood The script looks goods. I like the check for main power before the battery level verification, it solves the use case @clostro mentioned. @aprayoga Looking forward to the new release

@wurmfood On my system the helios64-ups.timer is disabled by default. Is this a timer that has to be manually enabled ?? I thought that the Helios would check if it had the battery and activate this automagically. It might be better to have a daemon in the background that checked the battery value every 20 seconds and only printed out output when there was a change.

Thanks for the information @gprovost. From the looks of it - Armbian 21.02.03 seems to install the Rockchip Blob. Where does the U-boot TPL/SPL come from ?? the new beta builds? Regards.

My case is similar to @wurmfood's - latest OS, ZFS and no OMV. @gprovost, how can we check and determine "if you are using rockchip blob or u-boot TPL/SPL"?

Thanks for the tip @ShadowDance, in my case I haven't had any crashes while using ZFS. But I've updated my systemd scripts to take the ZFS scheduler into account. What I did notice was that my data-sets on raid-z1 pool seems to be a bit more snappy (it might be a perception issue on my part). [Unit] Description=HDD-Idle service After=basic.target multi-user.target [Service] Type=oneshot ## Set Power Management parameters to all HDD ExecStart=/bin/sh -c '/usr/sbin/hdparm -qB255S120 /dev/sd[a-e]' ## Allows ZFS to use it's own scheduler for rotating disks. ExecStart=/bin/sh -c 'echo none | tee /sys/block/sd[a-e]/queue/scheduler' [Install] WantedBy=multi-user.target

@oneo - what distro are you trying out?

@allen--smithee Thanks for the feedback.

I did have a few lockups when running my setup scripts that actually install a few of the packages I needed/wanted to run on the Helios64. It would lock sometimes while idle. 'tuned' was one of the packages that is installed on our cloud environments and some options are available through the cockpit management interface. I wouldn't describe 'tuned' as a CPU Scaling Governor. The one thing I noticed was that if configured tuned in the early steps of installation - my scripts would finish running their task and I didn't have lockups (if tuned was not configured early in the process it would freeze at random points). tuned project - their website description is as follows Tuned is a system tuning service for Linux. It: monitors connected devices using the udev device manager tunes system settings according to a selected profile supports various types of configuration like sysctl, sysfs, or kernel boot command line parameters, which are integrated in a plug-in architecture supports hot plugging of devices and can be controlled from the command line or through D-Bus, so it can be easily integrated into existing administering solutions: for example, with Cockpit can be run in no-daemon mode with limited functionality (for example, no support for D-Bus, udev, tuning of newly created processes, and so on) for systems with reduced resources stores all its configuration cleanly in one place – in the Tuned profile – instead of having configuration on multiple places and in custom scripts Take my word with a grain of salt - this is only my experience with the Helios64.

@aprayoga, @gprovost, One thing that has worked for me since I got the board around on Nov of last year is to install package 'tuned' and set the profile to 'server-powersave'. The two BIG cores can go up to 1.8GHz and the little cores go up to 1.4GHz under heavy usage without any lockups - most of the time in idle they stay at 408MHz. apt -y install tuned tuned-adm profile server-powersave systemctl restart tuned