djurny

Try with:
 
sudo touch /root/.not_logged_in_yet  
+ reboot.

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,

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,

A few months back I came across something interesting on David Taylor's web site.
A shell script to control the temperature of a SBC using the heat generated by the CPU.
Of course if your clock oscillator is integrated into the CPU then this is a way to control it's temperature and theoretically get more accurate time.
I tried this and it worked really well with a few tweaks.  I liked it so scripted it as a service.
I'm getting a maximum offset of less than +-20 micro seconds

http://www.satsignal.eu/ntp/Raspberry-Pi-ntpheat.html
 
#!/usr/bin/env python # # Requires python3 # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and #!/usr/bin/env python # # generate some heat! # # Run ntpheat in the background. # It will try to stabilize the CPU temperature at 54C by default. # Sometimes one copy of ntpheat can use 100% of one CPU and # still not heat up your Pi as much as you want. The temptation # is to add more insulation to your Pi, but then it will overshoot # your target temperature if your load factor goes high. # # The solution is to run more than one copy of ntpheat. This is # easy to do with the -c option. # # To run 3 copies of ntpheat: ntpheat -c 3 import argparse import hashlib import os import sys import time # Work with argvars parser = argparse.ArgumentParser(description="make heat") parser.add_argument('-c', '--copies', default=[1], dest='copies', help="Number of copies to run. Default is 1", nargs=1, type=int) parser.add_argument('-t', '--temp', default=[57.0], dest='target_temp', help="Temperature to hold. Default is 57.0", nargs=1, type=float) parser.add_argument('-w', '--wait', default=[0.001], dest='wait', help="Set delay time in seconds, default is 0.1", nargs=1, type=float) args = parser.parse_args() args.copies[0] -= 1 while args.copies[0]: args.copies[0] -= 1 pid = os.fork() if pid: # I am the fork break zone0 = '/sys/class/thermal/thermal_zone0/temp' cnt = 0 m = hashlib.md5() temp = 0 max_cnt = args.wait[0] * 100000 # on a RasPi 3 the temp steps seem to be about 0.537 to 0.539C temp_gate = args.target_temp[0] while True: # on a RasPi 3, 200,000 of the m.update() can be one second delta = temp_gate - temp if 0 < delta: # heat it up my_str = "Time is an illusion. Lunchtime doubly so." my_enc = my_str.encode('utf-8') m.update(my_enc) else: cnt = max_cnt # cools off slower than it heats up. # undocumented Python 'feature', no sleep less than 1 milli Sec sleep = args.wait[0] * 10.0 * -delta if 0.001 > sleep: sleep = 0.001 time.sleep(sleep) cnt += 1 # read the temperature every max_cnt if max_cnt < cnt: cnt = 0 zone_data = open(zone0, 'r') for line in zone_data: temp = float(line) / 1000 zone_data.close() The service file: ntpheat.service - if you don't know how to set up a systemd service then go here https://wiki.debian.org/systemd/Services
[Unit] Description=ntpheat [Service] ExecStart=/usr/bin/ntpheat.sh Restart=on-failure [Install] WantedBy=multi-user.target  

 
I should add:  To make the CPU based temperature control work, there must be no CPU intensive processes at all.  This means disabling any cron jobs that load the CPU or forcing them to use less CPU over a longer period.
To do this you need cgroup-tools
 
#spread out heating caused by scheduled maintenance on NTP server #get package sudo apt-get install -y cgroup-tools #create a cpu group called cpulimit sudo cgcreate -g cpu:/cpulimit #set cpulimit group limit to 100000uS out of 1000000uS (= 10% of CPU cycles) sudo cgset -r cpu.cfs_period_us=1000000 cpulimit sudo cgset -r cpu.cfs_quota_us=100000 cpulimit #check settings sudo cgget -g cpu:cpulimit #to limit your process start it as follows - sudo cgexec -g cpu:cpulimit YOUR_COMMAND
You can use this to run CPU intensive jobs at 10%
To reconfigure some cron jobs:
 
/etc/cron.d/armbian-updates @daily root cgexec -g cpu:cpulimit /usr/lib/armbian/armbian-apt-updates
Some cron jobs run scripts:
#for some cron scripts: /etc/cron.daily/apt-show-versions cgexec -g cpu:cpulimit apt-show-versions -i /etc/cron.daily/sysstat cgexec -g cpu:cpulimit exec /usr/lib/sysstat/sa2 -A Apt xapian index is a hog...  limit it to 5%
#create a cpu group called cpulimit5 (for 5% CPU) sudo cgcreate -g cpu:/cpulimit5 #set cpulimit group limit to 25000uS out of 500000uS (= 5% of CPU cycles) for bad process. sudo cgset -r cpu.cfs_period_us=500000 cpulimit5 sudo cgset -r cpu.cfs_quota_us=25000 cpulimit5 /etc/cron.weekly/apt-xapian-index - comment out all except top line and replace with cgexec -g cpu:cpulimit5 /usr/sbin/update-apt-xapian-index
 

Hi @IgorS,
After following the how to's on this forum and the internets, would like to share some other things I did to make it work even better on my OrangePi Zero.
 
Connect DS3231 to TWI0 (PA11+PA12 and +5V/GND of course).
  Add i2c0 overlay to /boot/armbianEnv.txt (or use armbian-config to enable the i2c0 overlay). [...] overlays=usbhost2 usbhost3 uart1 pps-gpio i2c0 [...]  
Add custom overlay to add DS3231 RTC (using DS3232 module instead of DS1307). Save as rtc0-i2c0-ds3231.dts.
 
Add the custom DT overlay: sudo armbian-add-overlay rtc0-i2c0-ds3231.dts  
Add custom overlay to rename H2+ SoC RTC to rtc1. Save as rtc1-soc.dts.
 
Add the custom DT overlay: sudo armbian-add-overlay rtc1-soc.dts  
Disable fake-hwclock service: sudo systemctl stop fake-hwclock.service # stop sudo systemctl disable fake-hwclock.service # disable sudo systemctl mask fake-hwclock.service # really disable Reboot and verify that you now have 2x RTC on your OrangePi Zero: root@sinaspi:~# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Aug 5 22:57 /dev/rtc -> rtc0 crw------- 1 root root 253, 0 Aug 5 22:57 /dev/rtc0 crw------- 1 root root 253, 1 Aug 5 22:57 /dev/rtc1 As mentioned in another post, on the H2+ the SoC supplied RTC is indeed running fast, confirm this as follows: for RTC in /dev/rtc[0-9] do hwclock --rtc="${RTC:?}" --adjust hwclock --rtc="${RTC:?}" --systohc done sleep $(( 5 * 60 )) for RTC in /dev/rtc[0-9] do echo "${RTC:-N/A}:" hwclock --rtc="${RTC:?}" --get date --rfc-3339=ns done On my OrangePi Zero the SoC RTC is dashing ahead:
 
/dev/rtc0: 2021-08-08 09:17:52.760046+08:00 2021-08-08 09:17:52.526062078+08:00 /dev/rtc1: 2021-08-08 11:59:11.150733+08:00 2021-08-08 09:17:54.392611945+08:00 (rtc0 = DS3231 and rtc1 = SoC RTC.)
 
On the same OrangePi Zero, there is also a GPS receiver connected that has PPS output. Used @Elektrický's how to, to set up GPS and ntpsec. After successfully following the how to, ntp will synchronize and adjust system clock to high(er) accuracy. Once system clock is synchronized, the kernel will also update the RTC (/dev/rtc0) every 11 minutes, giving you a system as follows:
root@sinaspi:~# timedatectl Local time: Sun 2021-08-08 09:24:01 CST Universal time: Sun 2021-08-08 01:24:01 UTC RTC time: Sun 2021-08-08 01:24:02 Time zone: Asia/Taipei (CST, +0800) System clock synchronized: yes NTP service: inactive RTC in local TZ: no root@sinaspi:~# ntpq -p remote refid st t when poll reach delay offset jitter ======================================================================================================= 0.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 1.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 2.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 3.debian.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0019 oPPS(0) .PPS. 0 l 56 64 377 0.0000 -0.0072 0.0035 xSHM(0) .GPS. 0 l 21 64 377 0.0000 -15.3659 1.7862 +SHM(2) .PPS. 0 l 18 64 377 0.0000 -0.0163 0.0094 +europa.ellipse.net 209.180.247.49 2 u 40 64 377 167.9069 -0.9358 0.1437 +ntp1.time.nl .MRS. 1 u 43 64 377 210.9643 1.7869 0.1945 +promethee.boudot.one 94.198.159.10 2 u 21 64 377 220.2528 2.3322 0.0931 root@sinaspi:~# As the DS3231 is now set as rtc0, the udev rules in /lib/udev/rules.d/85-hwclock.rules will make sure to read the DS3231 clock time after a reboot, making sure your system clock has a nice starting offset after being powered off for a while.
 
Hope this helps anyone out there,
Groetjes,

Hi @Elektrický,
Nice tutorial, worked great for me. Bought a cheap GPS module:

 
And a pinheader to solder onto the OrangePi Zero board itself.

 
The only thing I had to change was to swap the RX/TX wires, as a straight connection did not work for my GPS board.


 
I did not have any success getting PPS to work through the USB connection (works as ttyACM). I had to use the GPIO dtb overlay and electrical connection as per your tut.
gpsd in action:

 
ntp[sec] in action:

 
Thanks a lot!
Groetjes,
 
p.s. I still have to figure out why I needed this

I think @lanefu was referring to doing a diff between the configs of the rockchip64 kernel which does not work, and the sunxi kernel which does.
 
Based on the error, I'd wager the keyslot open is failing because you're missing a hash function. Believe the default is SHA1, unless you specified something different. Running "cryptsetup luksDump /dev/sda1" or whatever, should tell you for sure.
 
If your system has AF_ALG compiled in, you can also run "cryptsetup benchmark", which runs typical hash and cipher algorithms used by LUKS. If it fails on something, that could be a clue.

Manually or by driving our test rig?
 
 
 

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,

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,

Hi @Elektrický,
Nice tutorial, worked great for me. Bought a cheap GPS module:

 
And a pinheader to solder onto the OrangePi Zero board itself.

 
The only thing I had to change was to swap the RX/TX wires, as a straight connection did not work for my GPS board.


 
I did not have any success getting PPS to work through the USB connection (works as ttyACM). I had to use the GPIO dtb overlay and electrical connection as per your tut.
gpsd in action:

 
ntp[sec] in action:

 
Thanks a lot!
Groetjes,
 
p.s. I still have to figure out why I needed this

Hi,
Have you checked "nut" (network UPS tools) to see if they have some prefab solutions?
Perhaps a custom nut driver, as I recall they have this type of behavior already available for "regular" UPSes.
Groetjes,

Hi, sorry, I forgot to mention that the configure-serial-tty script does require some target modification: it depends on the baudrate being fixed on the target, as sending <BRK> both triggers Magic SysRq and optional baudrate switch by *getty. To get this to work on my setup with highish successrate, I reconfigured the target's serial-getty configurations to only work on one baudrate.
 
See parts of my ansible task that sets that puppy up:
The ansible task shell script will try to parse the commandline to get the currently configured baudrates. It assumes the baudrates are sorted from high to low, i.e. 1500000,115200,38400,9600 for my NanoPi R2S and Helios64 boxen. It will replace the baudrates with the most-left it had parsed (which should be the highest baudrate). It also will disable the options to *getty that skip setting the baudrate explicitly (i.e. keep-baud and extract-baud).
 
Let me know if this worked out for you!
Groetjes,

Hi,
I made a small detection script using expect. That will spit out the hosts it found per try and baudraute guesstimate. Afterwards it will query the USB port location using udevadm info and build udev rules on a name basis for the hosts it found on those ports.
It's not a generic solution, let me know if you are interested, I'll share when back at my workstation.
Groetjes,

RK3399 has a single PCIe 2.1 x 4 lanes port, you can't split the lanes for multi interfaces unless you use a PCIe switch which is an additional component that would increase a lot the board cost.
 
That's clearly the intention, we don't want either to restart form scratch the software and documentation :P
 
Yes this will be fixed, it was a silly design mistake. We will also make the back panel bracket holder with rounder edges to avoid user to scratch their hands :/
 
We will post soon how to manage fan speed based on HDD temperature (using hddtemp tool), that would make more sense than current approach.
You can already find an old example : https://unix.stackexchange.com/questions/499409/adjust-fan-speed-via-fancontrol-according-to-hard-disk-temperature-hddtemp
 

Orange Pi Zero NTP Stratum 1 PPS GPS Server with Armbian OS.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

This tutorial uses a 3.3V capable GPS module with PPS output - TOPGNSS GN-701 (u-blox 7) but other similar modules should work.

 
This tutorial is for the Orange Pi Zero, but will probably work for other boards.

 

I couldn't easily do a comprehensive hardware and software tutorial on this forum, so I've published it on my web server and linked from here and attached a PDF.
Link to the Tutorial - http://schwartzel.eu3.org/ntp-stratum1.html

Tutorial PDF
ntp-stratum1.pdf

If you spot any typo's or errors please let me know.
 

It’s been 3 months since we posted on our blog. While we have been pretty active on Armbian/Kobol forum for support and still working at improving the software support and stability, we have been developing in parallel the new iteration of Helios64 around the latest Rockchip SoC RK3568.
 
However things haven’t been progressing as fast as we would have wished. Looking back, 2020 has been a very challenging year to deliver a new product and it took quite a toll on the small team we are. Our energy level is a bit low and we still haven’t really recovered. Now with electronic part prices surge and crazy lead time, it’s even harder to have business visibility in an already challenging market.
 
In light of the above, we decided to go on a full break for the next 2 months, to recharge our battery away from Kobol and come back with a refocused strategy and pumped up energy.
 
Until we are back, we hope you will understand that communication on the different channels (blog, wiki, forum, support email) will be kept to a minimum for the next 2 months.
 
Thanks again all for your support.

Hi @SR-G,
FYI I have been running Linux kobol0 5.9.13-rockchip64 #trunk.16 SMP PREEMPT Tue Dec 8 21:23:17 CET 2020 aarch64 GNU/Linux for some days now. Still up. Perhaps you can give this one a try?
Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster  
/etc/default/cpufrequtils:
ENABLE=true MIN_SPEED=408000 MAX_SPEED=1200000 GOVERNOR=powersave (The box runs idles with 'powersave' and will be set to 'performance' when performing tasks.)
 
I do not know which non-dev kernel version this is? I assume it's 21.02 or 21.03?

Groetjes,
 

Hi @tikey,
Did you make sure the SSD is making proper contact to the backplane connector? I also have some issues with the utmost left disk slot, when I remove/replace a disk in that slot, I have to open up the box and make sure that the connectors are tight and snug. If that does not help, you can try to insert the disk in another slot to rule out any connector or power rail issues. When box is open, make sure to also press down on the connectors in the main board, to make sure this is not related to loose cables or such.
Just FYI, I run a CT120BX500SSD1 in my box, although not the same model, but it works :-)
Groetjes,

Hi @snakekick,
USB HDD for snapraid parity, sounds like my setup! You can check with vm_block_dump what is waking up your device: 
 
echo 1 | sudo tee /proc/sys/vm/block_dump Above will enable logging of block device accesses into syslog.
 
If you want to see it happen without flooding your /var/log/syslog:
sudo service rsyslog stop while true ; do dmesg -cT ; done sudo service rsyslog start  
See: Documentation for /proc/sys/vm/* and How to conserve battery power using laptop-mode.
 
You should also check if you have enabled SMART offline auto testing on your HDD; that might also wake up your drive, but this is done by the drive itself:
sudo smartctl -a /dev/sdX | egrep 'offline' sudo smartctl --offlineauto=off /dev/sdX  
Other things that will wake up your drive: temperature monitoring services like hddtemp, you should check if it offers options to not access the drive if it's in standby/sleep mode.  Other things like blkid when used as root, will also check all blockdevices, even if you think it is using cache.
 
What is the brand of USB dock you are using? Perhaps your dock is doing something to the drive to wake it up regularly.
 
Hope that helps,
Groetjes,

Hi @snakekick,
USB HDD for snapraid parity, sounds like my setup! You can check with vm_block_dump what is waking up your device: 
 
echo 1 | sudo tee /proc/sys/vm/block_dump Above will enable logging of block device accesses into syslog.
 
If you want to see it happen without flooding your /var/log/syslog:
sudo service rsyslog stop while true ; do dmesg -cT ; done sudo service rsyslog start  
See: Documentation for /proc/sys/vm/* and How to conserve battery power using laptop-mode.
 
You should also check if you have enabled SMART offline auto testing on your HDD; that might also wake up your drive, but this is done by the drive itself:
sudo smartctl -a /dev/sdX | egrep 'offline' sudo smartctl --offlineauto=off /dev/sdX  
Other things that will wake up your drive: temperature monitoring services like hddtemp, you should check if it offers options to not access the drive if it's in standby/sleep mode.  Other things like blkid when used as root, will also check all blockdevices, even if you think it is using cache.
 
What is the brand of USB dock you are using? Perhaps your dock is doing something to the drive to wake it up regularly.
 
Hope that helps,
Groetjes,

djurny......thanks for your help but I decided to restart from scratch knowing the issue. Back up and running now. I set CPU Governor to "Performance".
 
I read and make some power management changes in Windows 10 (esp ACHI Power Management) to get max performance for SSD/HHDs file transfer and turned off any idling/power savings. I also wanted an option on this tweak to prevent data loss on power loss to hdparm.conf:  http://ubuntuhandbook.org/index.php/2014/01/disable-disk-caching-prevent-data-loss/

Hi,
Not sure if I can help here, but willing to help.
Can you put the SDcard into another Linux system and list the contents of the /boot folder? Also, please share the contents of the /boot/armbianEnv.txt. Looks like the same thing I had once, after a downgrade of kernel, the DTB files were renamed or not present for unknown reasons.
Groetjes

@djurny Thanks for the feedback. We will let you know.
 
We are working with Rockchip to get to the root cause of this instability. We are still suspecting wrong DDR timing settings.

Hi all,
Something to share for those who use the USB-C serial console from another Linux host. Install and use 'tio' to connect to the serial console instead of minicom. This supports both 1500k baud and also can be easily used inside GNU screen (minicom gets a meta key conflict per default; CTRL-A is default meta key for both GNU screen and minicom). Minicom resulted in regular errors posted in syslog by the ftdi_sio kernel module. Did not run any strace to find out what syscall is causing it, but in short, tio appears to not treat the tty as a modem: no errors are popping up in syslog. Hopefully the serial consoles will remain up now.
One caveat: I did not find a way to send a BREAK over serial using tio. This is something that is handy in case kernel freezes up, as sometimes you will still have opportunity to do a magic sysrq triggered reboot (BREAK + b = initiate a reboot of the kernel, also see magic sysrq & REISUB).
 
Groetjes,