Collected test image with 5.27. When you run "armbianmonitor -m" is not displayed the temperature. It had me at the Assembly get an error or is it a new mode of monitoring ?

No relevant changes to the script ... do you have temp readings from login script?

Now checked. In the input username is not display the temperature.

 

Than something is wrong with kernel, probably with configuration.

Checked Assembly 5.26. The kernel configuration and source code are the same. All the config files for the Board are the same. 5.26 in all works. I will study all that has changed in all files in the merge.

 

 

Think I found the cause. Here is the line that has changed script 30-sysinfo

 

if [[ -d "/sys/devices/virtual/thermal/thermal_zone0/" && $(cat /sys/devices/virtual/thermal/thermal_zone0/type) == "cpu_thermal" ]]; then

Yes, that's the problem, it need's to be solved somehow differently.

I've removed this check and now everything works as before.

4 minutes ago, balbes150 said:

I've removed this check and now everything works as before.

But this will break things for other boards/platforms (for us), so this should be configured per SoC / board family.

To add a new variable in config file to describe the Board ? Or such a parameter is already in the configuration and I can use it ?

1 minute ago, balbes150 said:

To add a new variable in config file to describe the Board

 

It's even more complicated since for most boards we support 2 kernel families (for some even 3). So with mainline kernel we would use /sys/devices/virtual/thermal/thermal_zone0/temp (reading 39000 when 39°C are reported) but with legacy kernel on H3 devices it's /sys/devices/virtual/thermal/thermal_zone1/temp (reading 39 when 39°C are reported).

 

The way it's currently done is an ugly hack anyway (trial&error in update-motd.d/30-sysinfo and creating there the necessary symlink to /etc/armbianmonitor/datasources/soctemp). We discussed this almost a year ago and back then the best idea was to integrate this into some sort of template and set it from armbianmonitor-daemon. But since this project is somewhat halted (my fault) I'm currently thinking about moving the symlink creation to /etc/init.d/armhwinfo (and then 30-sysinfo uses /etc/armbianmonitor/datasources/soctemp).

 

Any objections?

15 minutes ago, tkaiser said:

But since this project is somewhat halted (my fault) I'm currently thinking about moving the symlink creation to /etc/init.d/armhwinfo (and then 30-sysinfo uses /etc/armbianmonitor/datasources/soctemp).

I would prefer to have this platform and kernel specific code in $SRC/lib/config/sources/*.conf files (stored in a function) and called in firstrun, not in armhwinfo - no need to change the filesystem on every boot (and kernel branch switching is broken anyway IMO).

7 minutes ago, zador.blood.stained said:

no need to change the filesystem on every boot (and kernel branch switching is broken anyway IMO).

 

Well I had the latter in mind and there's no need to set the symlink on every boot. Only based on

/usr/bin/realpath -q /etc/armbianmonitor/datasources/soctemp || ln -sf ...

So please let's collect opinions on kernel switching first. I'm fine with disabling (not advertising) this (any longer).

Maybe I'm wrong and don't understand much. But I think it's time to optimize the entire structure of an Assembly of images. To make all the specific and associated with the characteristics of the particular iron personal\standard (model-specific) configuration files. That would, in themselves, the build scripts were (possibly) only specify those variables (which will go to lookup from config file). The upper level describe motherboard or family close models. This is a directory with the same name. Inside the directory can be a subdirectory with the description of specific models. Configuration files can be placed in the General catalogue of the family (the parameters of these files are used first). Next comes refinement (overriding) parameters , if they occur in the file (if the file is in lower subdirectories). In the beginning it will mean more work for the formation of configuration files for each model, but will greatly facilitate the support of most Assembly systems and subsequent maintenance and adding new models. In the catalog settings model you can place all that relates to the features of the model - drivers, firmware, scripts, binaries, etc.

 

 

--- Продублирую текст, а то при переводе часто меняется смысл информации.

 

Возможно я ошибаюсь и многого не понимаю. Но я думаю, что пришло время оптимизировать всю структуру сборки образов. Вынести всё специфичное и связанное с особенностями конкретного железа в персональные\типовые  (по конкретным моделям) настроечные файлы. Что-бы в самих сборочных скриптах были (по возможности) только указания на переменные (в которые будет идти подстановка из конфиг файлов). Верхний уровень описания платы или семейства близких моделей. Это каталог с таким же именем. Внутри каталога могут быть подкаталоги с описанием конкретных моделей. Настроечные файлы могут размещаться в общем каталоге семейства (параметры из этих файлов используются первыми). Далее идёт уточнение (переопределение) парметров , если они встречаются в файлах (если такие файлы есть в нижних подкаталогах). В начале это добавит работы по формированию файлов настроек для каждой модели, но существенно облегчит сопровождение самой сборочной системы и последующее поддержание и добавление новых моделей. В каталоге настроек по моделям можно размещать всё , что касается особенностей модели - драйвера, фирмваре, скрипты бинарные файлы и т.д.

What if we re-read board configurations here? This way overrides can be in board configuration files. The question is - do we want to clutter this config file with per board snippets?

Mostly we need SoC specific adjustments, not per board ones. And we moved most of the things to the sources templates already, so there isn't much left to do - armbianmonitor & rpi-monitor templates, firstrun adjustments and MOTD adjustments. I hope this will be resolved eventually, but my TODO list is long enough already.