Bernie_O

Actually, there is a better way to eliminate this CPU load without disabling the ADC driver and losing the ability to access the SOC temperature. The Linux thermal management periodically polls the SOC temperature, and you can disable it by adding the following line to /etc/rc.local:
echo disabled > /sys/devices/virtual/thermal/thermal_zone0/mode  
Details/background:
The A20 ADC driver is very inefficient: it seems to be using a busy loop (as mentioned here: https://linux-sunxi.narkive.com/1UetD5rh/bug-report-kworker-issue-for-mailline-kernel-4-12) The Linux thermal management periodically polls the SOC temperature (runs the ADC) at around 0.9Hz. I presume this would be useful for controlling the CPU fan, but probably not applicable to most A20 systems. Disabling this polling (as above) removes the CPU load, while still allowing inefficient one-off reads of the CPU temperature, as well as other ADC usage.

sure thing.

This is about three Helios, one Pine64 and two EspressoBin boards. @Werner could we move this thread to a place visible to others than Rockchip please?

Ditto on a Pine64 running Buster or Bullseye (can't remember which). 
I thought it must have got corrupted somehow, but it's just a spare that I have so It didn't bother me.  I noticed that it looked like /var/log/ stuff and thought that it was peculiar.
I took the opportunity to try the new Jammy instead and forgot about it until I saw this post.

Unfortunately, auditd is not working at all. It just doesn't show any file access whatsoever, even though the demon is running and the rule is set. So this is of no help on my system.
edit: Maybe the Armbian kernel is compiled without audit kernel module!?

Hi,
You can try the following to get an idea of which process is modifying the file:
 
sudo apt-get install auditd sudo auditctl -w /boot/armbianEnv.txt -p wa sudo tail -F /var/log/audit/audit.log  
The output should show actions performed on the file and (IIRC) the process ID performing those actions, perhaps that might help?
 
e.g.:
type=CWD msg=audit(1624526184.097:207): cwd="/home/djurny" type=PATH msg=audit(1624526184.097:207): item=0 name="/boot/" inode=7601 dev=b3:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1624526184.097:207): item=1 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.097:207): proctitle=xx type=SYSCALL msg=audit(1624526184.109:208): arch=40000028 syscall=94 per=800000 success=yes exit=0 a0=3 a1=81a4 a2=c80eeb00 a3=81a4 items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=PATH msg=audit(1624526184.109:208): item=0 name=(null) inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:208): proctitle=xx type=SYSCALL msg=audit(1624526184.109:209): arch=40000028 syscall=226 per=800000 success=yes exit=0 a0=1787820 a1=b6e3e1a0 a2=1907fc0 a3=1c items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=CWD msg=audit(1624526184.109:209): cwd="/home/djurny" type=PATH msg=audit(1624526184.109:209): item=0 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:209): proctitle=xx  
Source: Find which process is modifying a file [duplicate]
 
It honestly sounds a bit more like a filesystem that has lost track or a inode mixup somewhere? As someone mentioned, perhaps something else is writing to this file, thinking it is something else? Perhaps try to locate a symbolic (or hard)link to armbanEnv.txt:
## find any symbolic links to armbianEnv.txt sudo find / -xdev -type l -ls | egrep -i -- armbianEnv.txt ## find hardlinks to armbianEnv.txt - need to be on the same filesystem! sudo find / -xdev -samefile /boot/armbianEnv.txt  
Groetjes,

I had also the same problem, take a look on /etc/logrotate.d folder, here there are other files corrupted.

Had the issue happen semi-regularly to my Helios as well. Same "gibberish" saved to ArmbianEnv.txt as in your example.
Haven't been able to figure out where the issue comes from unfortunately.

I've been having a recent issue over the last couple months where my ArmbianEvn.txt file is being overwritten thus causing Helios to hang in the boot process.  Using some samples i've found on these forums, I was able to re-create my file and get the Helios back up and running and have since stored a copy so that when it happens, I can just copy and paste and back up running in no time.  To date, i've had this happen to me 4 times.
 
I'm not worried about having go through this at this point in time, but I was curious if anyone else has seen this issue or not?  I've saved a couple samples of what was written into the ArmbianEnv.txt file:
/var/log/armbian-hardware-monitor.log {
  rotate 12
  weekly
  compress
  missi
 
/var/log/alternatives.log {
monthly
rotate 12
compress
delaycompress
missingok
notifempty
create 644 root root
}
 
I'm running Buster 5.10.21.  I have 5-14TB EXOS drives in Raid 6 and have OMV as the only thing installed.  

Same has happened on EspressoBin running Buster 5.10. I don‘t believe it to be a filesystem problem. It looks like something happening at boot time perhaps while running /usr/lib/armbian-hardware-optimization.sh ? I will try to go further into it.

Finally, Globalscale did the trick and pushed the modifications, that they had added to make 17.10 stable for all EspressoBin-Boards, to 18.12 as well. Thanks a lot, Globalscale!!
 
Unfortunately, they did this in their repos and not in the official Marvell repos. I extracted the changes and made a pull request at the Marvell repo. I hope the changes will be merged soon, because I can then use the official Armbian build tools to generate a U-Boot/firmware that flawlessly works with my EspressoBin v7 DDR4 1cs 1GB boards. For now, I compile using the Globalscale repo and got a really stable firmware (tested on three boards for now), I am using the mainline U-Boot (2020.10), too and have no problems – but have not tested this with PCIe periphery (like wifi or SATA adaptors).

Old kernel naming doesn't receive updates anymore. You have to do this manual procedure / switch to new naming ... then update goes the usual way. It could be done automatically, but even without it was already insane lots of work most people don't even notice or support. Manual updating is a small price you need to pay.

I will spend sometime during next 2 weeks to migrate DEV to @megi 's 5.5.y branch ...

Release details

https://docs.armbian.com/Release_Changelog/
 
Upgrading your Armbian to v19.11.y
 
This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
 
 
Choose latest version of 19.11.x and select upgrade according to this scheme:
Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:
 

Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
Main build system changes
Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
LIB_TAG="v19.08" to your build config file which by default is:
userpatches/config-default.conf Then run your script as you did before.
 
Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.

In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.

Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
 
Enjoy! 

No. I have not, since the stress test didn't show any problem with power supply.
 
The workaround has kept the box up for 11 days now:
 
$ uptime
 04:42:34 up 11 days,  5:02,  9 users,  load average: 0.21, 0.28, 0.28

I have read two old threads in this forum:
I have been running this (will post more details if needed) for a few days:
VERSION=5.90
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
 
Kernel is 4.19.62-sunxi
 
The BPi would hang/freeze, seemingly randomly within a day or two. When it does that, there is no HDMI video or response to ping.
 
After reading the first thread, I did stress test on the BPi for more than 2 days. The BPi actually hold up.
 
So, next I ran "ping -i 30 -D 192.168.8.1" -- pinging my home gateway every 30 seconds. The BPi has also been up while that is going on. Now its uptime is more than 5 days.
 
I have no problem keeping this going as a workaround -- just thought it may also be of interest to some one.

I posted the full solution here   :  https://github.com/armbian/build/issues/1582
The basic idea is :
 
Once the "--delete" issue is corrected, log.hdd is better, but there is still an issue : the rotated files overlap, because the effect of the rotation is not mirrored to /var/log. I have a log rotated daily, but each rotated file contains 3 or 4 days.
This can be solved easily by the following process :
ramlog write (to update log.hdd before rotation) logrotate ramlog postrotate (which will copy to /var/log the modified files of /ram/log.hdd).  
See the code on Github, link above.

You don't need it.

logrotate is one item to look at to close out logs and age them out.
 
FWIW -  There's armbian specific services in systemd that you might want to actually disable - armbian-ramlog for example, as when it runs out of space it gets ugly.
systemctl list-unit-files | grep armbian armbian-firstrun-config.service            enabled         armbian-firstrun.service                   disabled        armbian-hardware-monitor.service           enabled         armbian-hardware-optimize.service          enabled        armbian-ramlog.service                     disabled        armbian-resize-filesystem.service          disabled        armbian-zram-config.service                disabled  Anyways - the ram logging and ZRAM stuff tend to be problematic for some that come into Armbian from other platforms...
 
The two services I would disable from SystemD are below:
armbian-ramlog.service armbian-zram-config.service  
I know folks might be offended here - but disabling this results in expected behavior.
 
 

I made typo  We are at 5.2.5 ...

@Igor
My big thank to you for your work. I will check the images and will give feedback for errors etc.

v5.90 / 7.7.2019
All images were updated. It mainly goes for a bugfix update, cleanup, adding Debian Buster release. Beware that software maturity with Buster is not just there yet (even it was declared stable) and with some applications (like OMV) you will encounter problems. Kernel/BSP wise, Debian Buster is the same, uses Armbian kernel, as our other builds. Most of the builds were briefly tested, but bugs might be hiding somewhere. This is the best what is out there thanks to greater Debian community, those around boards and of course ours which pushes generic Debian/Linux to the sky . Enjoy the summer time.
 
What's new? -> https://docs.armbian.com/Release_Changelog/

Is there any news on this kworker issue? Actually, I'm running armbian 5.90 with 4.19.57 kernel an the problem persists. Before, I was running dev-kernel 5.1 which didn't fix the issue either.

To sum up my not too excessive tests of the new kernel on the Lime2 - I did not encounter any read/write errors up to now. Right from the start I switched to nightly builds and still had a reasonably stable system. What I found dissapointing were the speeds over network (SMB): I did never exceed 44MB/s in any condition (reading, writing, HDD, SSD, SD card, SATA, USB, always GBit-Ethernet).
If there's any procedure of testing read/write over SATA excessively - please let me know. Does a benchmark apply?
OT: So this board might be a good update to my first generation Raspberry Pi (which makes 6MB/s ;-) ) but compared to the EspressoBin V5, which I obtained a couple of days ago and which is stable (other than the V7 I had to send back), it is about half as fast. And I am running the EspressoBin at a conservative 800MHz.

Thanks @Tido for this link, I hadn't seen it and it gives quite a good explanation to why it took so long and why it's so difficult to have a decent SATA speed on Allwinner boards. :-)  So I think testing should include all different kinds of transfer block sizes, verifying the write result on the fly, just to be sure that one trial-and-error-finding is as good as the previous trial-and-error-finding, which has already been tested since 2014.