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

 

5 hours ago, SIGSEGV said:

At some point I noticed that the fancontrol service had failed to start up after the reboot

 

Next update will break this again. It would be best that this gets fixed in https://github.com/armbian/build @Heisath Wasn't this fixed already?

@Igor no. This is a) a new problem and the proposed fix is IMHO not correct. AND b) the old fix (on branch https://github.com/armbian/build/tree/helios64-udev-hwmon-fix) was never merged, tested or anything else. 

 

Regarding the old problem:

As mentioned in the previous thread, I do NOT have a helios64 so cannot test any changes. Nobody else stepped up to test and report back. Also sometime later someone said:
 

  

On 6/24/2021 at 5:00 PM, halfa said:

The 21.05.6 release fixed the regression in the package build process (couldn't find a related commit, maybe during the build targets reworks?), removing the "legacy" udev rule and adding the correct one.

root@helios64:~ # apt info armbian-bsp-cli-helios64
Package: armbian-bsp-cli-helios64
Version: 21.05.6

Given that this is fixed, I don't know if there is a need to patch the upstream Heisath. I'm willing to test you're version of the merged udev rule but I don't have a legacy env. to properly test the other one.

 

SO  I assumed this had magically fixed itself and did not need further attention. Read here for full thread: 

 

 

Regarding the new problem:

Simply changing the fancontrol rules from thermal-cpu to thermal-board is incorrect AFAIK. Looking at the udev rules: https://github.com/armbian/build/blob/master/packages/bsp/helios64/90-helios64-hwmon.rules

It should be thermal-cpu for the cpu temperature and thermal-board for the board temperature. And then it only makes sense to attach the fancontrol to the CPU temp.

 

Why the thermal-cpu is not available anymore I don't know. But it is not a solution to the root cause to just fix the fancontrol to the board temp. We should instead investigate why the thermal-cpu node is not available anymore and fix it.

Maybe @aprayoga or @gprovost are back from their break? 

 

EDIT: Looking back at it, maybe it is the same problem.

@SIGSEGV can you check if you have the 90-helios64-hwmon.rules or the 90-helios64-hwmon-legacy.rules in your udev?

 

EDIT2:

PR here: https://github.com/armbian/build/pull/3092

2 hours ago, Heisath said:

I do NOT have a helios64 so cannot test any changes

OK, me neither. Lets's wait for some input here then.

@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.

Ok @SIGSEGV thanks for confirming that the old bug is back.

 

So the buildscript still does not correctly seperate between legacy and current.

 

If you are able to build images yourself it would be great if you could build a helios64 image (current) from this pr/branch https://github.com/armbian/build/pull/3092  and test if it works + the correct files are present.

 

 

@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.

13 minutes ago, SIGSEGV said:

@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.

This is not merged yet, so it won't be in beta builds.

On 8/11/2021 at 3:17 PM, Igor said:

Lets's wait for some input here then.

 

I am using Armbian 21.05.8 Buster with Linux 5.10.43-rockchip64 on a Helios64 (fully updated - in particular with armbian-bsp-cli-helios64 21.05.8) and there would not appear to be any issue with a missing thermal cpu node.

 

# cat /dev/thermal-cpu/temp1_input
45000
# cat /dev/thermal-board/temp1_input
35437
# fancontrol status
Loading configuration from /etc/fancontrol ...

Common settings:
  INTERVAL=10

Settings for /dev/fan-p6/pwm1:
  Depends on /dev/thermal-cpu/temp1_input
  Controls 
  MINTEMP=40
  MAXTEMP=110
  MINSTART=60
  MINSTOP=40
  MINPWM=0
  MAXPWM=255

Settings for /dev/fan-p7/pwm1:
  Depends on /dev/thermal-cpu/temp1_input
  Controls 
  MINTEMP=40
  MAXTEMP=110
  MINSTART=60
  MINSTOP=40
  MINPWM=0
  MAXPWM=255

File /var/run/fancontrol.pid exists, is fancontrol already running?

 

For anybody here looking for a solution, see the other thread (where you will find a manual fix)

 

@ebin-dev you need to look at what file you have in /etc/udev/rules.d/, as long as you didn't reboot you'll not have the issue.

 

Hello back @Heisath! I updated to armbian 21.05.8 and indeed I'm back on the old udev rule. If we still don't now why sometime the build mess up with the legacy settings, but if it's the ONLY thing that is related to the legacy switch, we might as well either merge both files into one, accommodating both CPU device tree thermal tree path. @Igor what do you think? I think I can make a PR for that.

1 hour ago, halfa said:

you need to look at what file you have in /etc/udev/rules.d/, as long as you didn't reboot you'll not have the issue.

 

My Helios64 shuts down overnight - it boots every day - so the changes made by "armbian-bsp-cli-helios64 21.05.8" are active on my system. I do not observe any issue though.

I checked the rules in /etc/udev/rules.d/ : the legacy hwmon rule is not present and the remaining hwmon rule contains the following:

 

# cat 90-helios64-hwmon.rules
# Helios64 persistent hwmon

ACTION=="remove", GOTO="helios64_hwmon_end"

#
KERNELS=="p6-fan", SUBSYSTEMS=="platform", ENV{_HELIOS64_FAN_}="p6", ENV{_IS_HELIOS64_FAN_}="1", ENV{IS_HELIOS64_HWMON}="1"
KERNELS=="p7-fan", SUBSYSTEMS=="platform", ENV{_HELIOS64_FAN_}="p7", ENV{_IS_HELIOS64_FAN_}="1", ENV{IS_HELIOS64_HWMON}="1"
KERNELS=="2-004c", SUBSYSTEMS=="i2c", DRIVERS=="lm75", ENV{IS_HELIOS64_HWMON}="1"

SUBSYSTEM!="hwmon", GOTO="helios64_hwmon_end"

ENV{HWMON_PATH}="/sys%p"
#
ATTR{name}=="cpu", ENV{IS_HELIOS64_HWMON}="1", ENV{HELIOS64_SYMLINK}="/dev/thermal-cpu"
#
ENV{IS_HELIOS64_HWMON}=="1", ATTR{name}=="lm75", ENV{HELIOS64_SYMLINK}="/dev/thermal-board"
ENV{_IS_HELIOS64_FAN_}=="1", ENV{HELIOS64_SYMLINK}="/dev/fan-$env{_HELIOS64_FAN_}"

#
ENV{IS_HELIOS64_HWMON}=="1", RUN+="/bin/ln -sf $env{HWMON_PATH} $env{HELIOS64_SYMLINK}"

LABEL="helios64_hwmon_end"

 

@halfa merging both files into one is the proposed solution. No need for PR, I already created one here: https://github.com/armbian/build/pull/3092

 

One thing I am not sure about is removing the old file(s) in case of update...

I don't think keeping the old file around would be an issue anyway, if somebody can hand me the resulting deb package I can test it on my helios64.

Else I would need to find a way to build the whole image (which may not be a bad thing? )

@ebin-dev I have 0 ideas how you ended up in that situation but on my side the version 21.05.8 is installed and it indeed contain the legacy udev rule (and you can confirm for yourself by looking at the package in the mirror at http://mirrors.dotsrc.org/armbian-apt/pool/focal-utils/a/armbian-bsp-cli-helios64/)

root@helios64 $ dpkg -s armbian-bsp-cli-helios64
Package: armbian-bsp-cli-helios64
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 1
Maintainer: Igor Pecovnik <igor.pecovnik@****l.com>
Architecture: arm64
Version: 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~)
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~)
Description: Tweaks for Armbian focal on helios64

root@helios64 $ dpkg -L armbian-bsp-cli-helios64 | grep legacy
/etc/udev/rules.d/90-helios64-hwmon-legacy.rules

 

3 hours ago, halfa said:

the version 21.05.8 is installed and it indeed contain the legacy udev rule

 

Thanks for following up on this. The same package is installed on my system, but the legacy udev rule is not present. However, I can not exclude that I might have deleted it manually weeks ago due to suggestions in the forum. Anyway - this configuration seems to work at least for me (Armbian 21.05.8 Buster with Linux 5.10.43-rockchip64).

 

# dpkg -s armbian-bsp-cli-helios64
Package: armbian-bsp-cli-helios64
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 1
Maintainer: Igor Pecovnik <igor.pecovnik@****l.com>
Architecture: arm64
Version: 21.05.8
Replaces: zram-config, base-files, armbian-tools-buster, linux-buster-root-legacy-helios64 (<< 21.05.8~), linux-buster-root-current-helios64 (<< 21.05.8~), linux-buster-root-edge-helios64 (<< 21.05.8~)
Provides: linux-buster-root-legacy-helios64, linux-buster-root-current-helios64, linux-buster-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-buster-root-legacy-helios64 (<< 21.05.8~), linux-buster-root-current-helios64 (<< 21.05.8~), linux-buster-root-edge-helios64 (<< 21.05.8~)
Description: Tweaks for Armbian buster on helios64

 

Hope I'm not adding noise to this thread.  Thought I would add another report matching @ebin-dev.  I just upgraded my Helios64 to this new package as well, and my fancontrol remains working after a reboot (both /dev/thermal-cpu and /dev/thermal-board are present).  I can confirm that I don't have a legacy file in /etc/udev/rules.d, and the contents of the 90-helios64-hwmon.rules file matches that posted by @ebin-dev.  I'm pretty sure I've never modified any of the files in /etc/udev/rules.d.

@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?

2 hours ago, SIGSEGV said:

how often do you update the packages on your NAS?

The installation is updated semy-automatically on a daily basis. No cherry picking :-)) .

On 8/13/2021 at 11:59 AM, SIGSEGV said:

@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?

I update manually, usually every one or two weeks.

@m11k can you run
 

sudo apt info armbian-bsp-cli-helios64

and post the output?

For those affected by the issue, the file has been patched to handle both the legacy and 5.10 kernel logic https://github.com/armbian/build/pull/3092

@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'

On 8/16/2021 at 10:33 AM, halfa said:

@m11k can you run
 

sudo apt info armbian-bsp-cli-helios64

and post the output?

For those affected by the issue, the file has been patched to handle both the legacy and 5.10 kernel logic https://github.com/armbian/build/pull/3092

Sorry for the late reply.  I get the following:

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-buster-root-legacy-helios64, linux-buster-root-current-helios64, linux-buster-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-buster-root-legacy-helios64 (<< 21.05.8~), linux-buster-root-current-helios64 (<< 21.05.8~), linux-buster-root-edge-helios64 (<< 21.05.8~)
Replaces: zram-config, base-files, armbian-tools-buster, linux-buster-root-legacy-helios64 (<< 21.05.8~), linux-buster-root-current-helios64 (<< 21.05.8~), linux-buster-root-edge-helios64 (<< 21.05.8~)
Download-Size: 417 kB
APT-Manual-Installed: yes
APT-Sources: http://apt.armbian.com buster/buster-utils arm64 Packages
Description: Tweaks for Armbian buster on helios64

N: There are 5 additional records. Please use the '-a' switch to see them.

 

Hello,

My workaround or patch, maybe it bad, sad or unclear but it's KISS and seem to work !

Bye

 

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
FCTEMPS=/dev/fan-p6/pwm1=/sys/class/thermal/thermal_zone0/temp /dev/fan-p7/pwm1=/sys/class/thermal/thermal_zone0/temp
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

Still not work with fresh-build edge images.

No simlink /dev/thermal-cpu, fancontrol start to work if manualy do

ln -s /sys/devices/virtual/thermal/thermal_zone0/hwmon0 /dev/thermal-cpu

 

TL;DR:

in /etc/udev/rules.d/90-helios64-hwmon.rules an line 16 set ATTR{name}=="cpu|cpu_thermal".instead of ATTR{name}=="cpu"

...

and I see two extra simlinks in root:

hwmon0 -> /sys/devices/virtual/thermal/thermal_zone0/hwmon0
thermal_zone0 -> /sys/devices/virtual/thermal/thermal_zone0

I look for /sys/devices/virtual/thermal/thermal_zone0/hwmon0 in udev:

udevadm info -q all -a /sys/devices/virtual/thermal/thermal_zone0/hwmon0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/thermal/thermal_zone0/hwmon0':
    KERNEL=="hwmon0"
    SUBSYSTEM=="hwmon"
    DRIVER==""
    ATTR{name}=="cpu_thermal"
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"
    ATTR{temp1_crit}=="100000"
    ATTR{temp1_input}=="34444"

  looking at parent device '/devices/virtual/thermal/thermal_zone0':
    KERNELS=="thermal_zone0"
    SUBSYSTEMS=="thermal"
    DRIVERS==""
    ATTRS{available_policies}=="user_space step_wise bang_bang fair_share "
    ATTRS{cdev0_trip_point}=="1"
    ATTRS{cdev0_weight}=="0"
    ATTRS{cdev1_trip_point}=="0"
    ATTRS{cdev1_weight}=="0"
    ATTRS{cdev2_trip_point}=="1"
    ATTRS{cdev2_weight}=="0"
    ATTRS{integral_cutoff}=="0"
    ATTRS{k_d}=="0"
    ATTRS{k_i}=="0"
    ATTRS{k_po}=="0"
    ATTRS{k_pu}=="0"
    ATTRS{mode}=="enabled"
    ATTRS{offset}=="0"
    ATTRS{policy}=="step_wise"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{slope}=="1"
    ATTRS{sustainable_power}=="0"
    ATTRS{temp}=="33888"
    ATTRS{trip_point_0_hyst}=="2000"
    ATTRS{trip_point_0_temp}=="85000"
    ATTRS{trip_point_0_type}=="passive"
    ATTRS{trip_point_1_hyst}=="2000"
    ATTRS{trip_point_1_temp}=="95000"
    ATTRS{trip_point_1_type}=="passive"
    ATTRS{trip_point_2_hyst}=="2000"
    ATTRS{trip_point_2_temp}=="100000"
    ATTRS{trip_point_2_type}=="critical"
    ATTRS{type}=="cpu-thermal"

I see there ATTR{name}=="cpu_thermal" have to be choosed.

an line 16 set ATTR{name}=="cpu|cpu_thermal".

Victory, now /dev contains link

thermal-cpu -> /sys/devices/virtual/thermal/thermal_zone0/hwmon0

fancontrol works

@Heisath?

upd: checked in https://github.com/armbian/build/commit/37662d8ed3cbcdb8c975e21bc2e709c365441d1e

 

Hi,

Thks for your patch, i think it's more "clean" than my "Kiss workaround"

Have a good day