DoubleHP

Took me over a year to isolate this bug. Randomly, I have found that /boot/armbianEnv.txt had unconsistent content. Examples: .tty1tty1LOGIN.8 ¹[fU7ttyS0tyS0LOGINusbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u network={ ssid="Demaine_40_Grd_Rue_Chambre-BP" #psk="1234567890" psk=693d195a3bf2ab6defbcc0b54604ced4286a067996138db6dc793d8648f67d79 } usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u network={ ssid="fabste" #psk="1234567890" psk=95342031a4b28398045e1761f9c64f8454902e80d37102e5476fa79abd59e144 } 2 } usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u At last, I have found that "fabste" is the SSID of the network of my neighbour. How did this get here ? The bug occurs only on Orange Pi Zero boards ... which need to perform wifi scan. Does not happen on boards that operate as WIFI AP, or use ethernet. The wifi scan is required to connect to the AP. The scan seem to produce a temp file somewhere (maybe in /tmp, not sure). Then, later, /etc/init.d/armhwinfo runs this, which is very suspicious to me: read USBQUIRKS <${TMPFILE} sed -i '/^usbstoragequirks/d' /boot/armbianEnv.txt echo "usbstoragequirks=${USBQUIRKS}" >>/boot/armbianEnv.txt and if this is followed by a power failure, you end up with a corrupted file: https://lists.denx.de/pipermail/u-boot/2018-June/332375.html https://github.com/ConnectBox/connectbox-pi/issues/220 It's a rare issue from Google point of view; but it's known, and it makes most of my opi0 unusable. Sooner or later, it affects 100% of my opi0 that work as wifi clients. It rendends my pis unusable because I need very specific features which are set in /boot/armbianEnv.txt , usually w1-gpio. When the file is corrupted, and after reboot, I loose control over my 1W devices, and the whole project got broken. Here is my fstab, in case it matters: UUID=ebe9dacf-124f-486c-b6c1-08749e209374 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 I am not sure how to fix this at the distribution level: - use something different than sed in armhwinfo to alter /boot/armbianEnv.txt - perform a sync - change ext4 features - change mount options For now, I am trying to write a personnal fix: record a backup copy of /boot/armbianEnv.txt and restaure it if critical words like "overlay_prefix=sun8i-h3" disappear. Note that, when the file is heavily broken, for all 3 examples above, the pi can boot, establish network connexion, and remains reachable, mostly. I only loose the 1W or GPIO feature. There seem to be very good default settings set as fallback somewhere else. Here are unaffected opis: verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=cir usbhost2 usbhost3 w1-gpio param_w1_pin=PA15 rootdev=UUID=ebe9dacf-124f-486c-b6c1-08749e209374 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 w1-gpio param_w1_pin=PA15 rootdev=UUID=ebe9dacf-124f-486c-b6c1-08749e209374 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I am not sure why one has an empty line. But in both case, the usbstoragequirks line is doubled, and identical to my eyes. This means, /etc/init.d/armhwinfo tries to add already existing data. This script lacks checks !!! .

Either I tried to mkdir build, or, maybe I made the LCD work without this git tree; I forgot. But according to my last post, I probably got it working without this git tree. Try my post from Jan 17th 2018 ...

According to https://www.armbian.com/orange-pi-zero/ My way to do it is crontab: * * * * * root /usr/bin/cpufreq-set -f 1200MHz ; /usr/bin/cpufreq-set -g performance Of course, editing /etc/default/cpufrequtils sounds much better.

When default settings lead to "aptitude install munin-node" refuse to install the package, on 3 machines in two weeks, there is a bug at the distro level. My fix for now: # cat /etc/crontab | grep var * * * * * root [ $(df -h /var/log | grep -e "/var/log" | awk '{print $5}' | tr -d "\%") -gt 90 ] && rm "/var/log/$(ls -S /var/log/ | head -n1)" && systemctl restart log2ram # this crontab line checks every minute if /var/log is more than 90% full, and if it is, removes the largest file. tkaiser I disagree; your idea is very good; it's what I was planning to do on long term; but in emergency, I wrote the above simple line. I usually keep all my logs for 10 years. So, the best way to do this would be to sync rotated logs to .hdd, and then remove them immediately from the ramdisk. And sync at boot should exclude them. It's not hard to do; just a few rsync arguments. But I got more urgent things to do now. Logrotate also would probably need some customisation to handle side effect of this sync. Not finding /var/log/syslog at all, or having an empty file is much more an issue than not finding /var/log/syslog.1 The partial sync also allows to have a /var/log.hdd larger than 50M, allowing to keep a lot of logs, while log2ram limits it to 50M. PEople who would be confused by this can disable log2ram; but this comes with a risk for the flash.

I am working on a workaround; but there is a bug at the distribution level, because once var has reached 100%, the only way to get /var/log working again is to manually remove a file; if you reboot 10 times or wait a full week, the system will NOT fix itself. And since the bug occurs often, there should be a fix at the distro level.

On most your Orange Pi Zero 256M, I got this: # df -h Filesystem Size Used Avail Use% Mounted on udev 85M 0 85M 0% /dev tmpfs 25M 3.5M 21M 15% /run /dev/mmcblk0p1 15G 1.3G 14G 9% / tmpfs 120M 4.0K 120M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 120M 0 120M 0% /sys/fs/cgroup tmpfs 120M 80K 120M 1% /tmp log2ram 50M 50M 0 100% /var/log tmpfs 25M 0 25M 0% /run/user/0 This happens very fast, after a few days, for Pis that are now plugged 24/7. Then I have to manually remove some large file, and, when the Pi have run a cron.daily and cron.weekly, and it always stays on, then, this never happens again. What is the best workaround, or fix ? Obvisouly, I can not really increase the size of the ramdisk. I don't want either to stop using log2ram; I have killed many SD cards in the past. And the problem is always the same: # ls -lha /var/log/ | grep M total 50M -rw-r----- 1 syslog adm 25M Feb 27 04:49 kern.log.1 -rw-r----- 1 syslog adm 25M Feb 27 06:25 syslog.1 drwxr-xr-x 2 root root 40 May 12 2016 sysstat This is the third time. # head /var/log/syslog.1 Nov 25 06:20:40 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="579" x-info="http://www.rsyslog.com"] start Nov 25 06:20:40 localhost rsyslogd-2222: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ] Nov 25 06:20:40 localhost rsyslogd: rsyslogd's groupid changed to 108 Nov 25 06:20:40 localhost rsyslogd: rsyslogd's userid changed to 104 Nov 25 06:20:40 localhost kernel: [ 0.000000] Booting Linux on physical CPU 0x0 Nov 25 06:20:40 localhost kernel: [ 0.000000] random: get_random_bytes called from start_kernel+0x31/0x352 with crng_init=0 Nov 25 06:20:40 localhost kernel: [ 0.000000] Linux version 4.13.16-sunxi (root@armbian) (gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08)) #20 SMP Fri Nov 24 19:50:07 CET 2017 Nov 25 06:20:40 localhost kernel: [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=50c5387d Nov 25 06:20:40 localhost kernel: [ 0.000000] CPU: div instructions available: patching division code Nov 25 06:20:40 localhost kernel: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache # tail /var/log/syslog.1 Feb 12 17:44:52 localhost kernel: [23357.366931] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366935] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366940] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366944] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366949] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366953] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366957] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366962] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366966] rc rc0: IR event FIFO is full! 1: I don't like removing logs 2: this is a recurring bug on several pis; either I am doing something wrong each time, or there is a bug deep in Armbian.

Here is my solution: echo '@reboot root while true ; do echo 1 > /dev/watchdog ; sleep 3 ; done' >>/etc/crontab Everything else fails. Doing 'cat /dev/watchdog' or 'echo 1 >/dev/watchdog' makes the system reboot 16s later ... prooving the hardware part works fine, but that the service is not doing it's job properly. Some people say there should be one process per core. Other people have more than 1 line out of 'dmesg | grep wat' This second form procudess less mess in dmesg and syslog: echo '@reboot root { while true ; do echo 1 ; sleep 1 ; done ; } > /dev/watchdog' >>/etc/crontab But both may be unreliable; depending on which shell interprets the line, things like bash may produce a routine that is always run by the same process; so if the kernel is lacking of memory, or can not create any new process, that snipset may keep feeding watchdog even on a dead machine. So, this (untested) method may be reliable to track process creation issues: echo '* * * * * root { for i in $(seq 11) ; do echo 1 ; sleep 10 ; done ; } > /dev/watchdog' >>/etc/crontab but it will produce one line of garbage per minute. In either case, have fun killing the parent process, and you get a reboot. Proofing my stupid line works better than the service installed by 'apt-get install watchdog', even after loosing 2h in /etc/default/watchdog and /etc/watchdog.conf

I am stuck as well, did you find a solution ?

# echo plop | logger should show things in tail -F /var/log/syslog After digging a bit: # df -h Filesystem Size Used Avail Use% Mounted on udev 85M 0 85M 0% /dev tmpfs 24M 3.0M 22M 13% /run /dev/mmcblk0p1 15G 1.3G 13G 9% / tmpfs 120M 4.0K 120M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 120M 0 120M 0% /sys/fs/cgroup tmpfs 120M 0 120M 0% /tmp log2ram 50M 50M 0 100% /var/log tmpfs 24M 0 24M 0% /run/user/0 # du -lsh /var/log/* | grep M 24M /var/log/kern.log.1 25M /var/log/syslog.1 so ... WTF ? # tail -n1 /var/log/kern.log.1 Feb 12 10:35:14 localhost kernel: [ 6837.372115] sunxi-mmcroot@opi-12-gite-salon:/var/log# tail -n1 /var/log/syslog.1 # date Wed Feb 21 13:48:48 UTC 2018 # uptime 13:48:50 up 33 min, 2 users, load average: 0.00, 0.01, 0.00 Why is this crap filling my RAM with deprecated logs that are older than 1 week ? Either the system was up, and logrotate should compress and push this to disk, or, the system had been restarted recetly, and log2ram has no reason to fill my memory with deprecated logs !!! So, the point of log2ram is just to occupy RAM, and prevent admin from seing fresh messages ? Not even able to force log rotation when the ramdisk is full ?

FLiP-79 before any one can even try to help you, you need to tell exactly which Armbian image you have used, which updates you have done, and the current Armbian and kernel version; they are given when you log in. For example, I have burnt Armbian_5.35_Orangepizero_Ubuntu_xenial_next_4.13.16.img but after updates I got Welcome to ARMBIAN 5.38 stable Ubuntu 16.04.3 LTS 4.14.18-sunxi There have been major changes between kernel 3 and 4. Many things that used to work via drivers now work via overlays.

I have given up on the classic use of LIRC. It's definitely broken. mode2 have a bug, and drops the last bit of the last frame. My script reads the output of mode2, and works out the timing to compute the frame. Transmission is done on GPIO using home made code. All details are given in here: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=3388&page=1&extra=#pid22196

I have found one bug in LIRC: mode2 is telling me about the last bit (pulse timing) of the first received frame only when receiving the second frame. For subsequent frames, the last bit (pulse timing) is obtained immediately. I have written my own frame decoder, and IR transmitter tools. I will publish them later, when everything works. Spent 3 days in re-inventing the wheel. Why didn't I receive email notification for your message ?

I have spent two days on LIRC. I am going to give up if no one can help me on this. My software conf are ARMBIAN 5.38 stable Ubuntu 16.04.3 LTS 4.14.18-sunxi and ARMBIAN 5.35 user-built Ubuntu 16.04.3 LTS 4.13.16-sunxi # cat /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="audio_alsa" TRANSMITTER_DEVICE="hw@48000,r" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd #START_LIRCD="false" START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD="" # cat /etc/lirc/lircd.conf | grep -v "^#" begin remote name ATI_Remote_Wonder_II bits 24 eps 30 aeps 100 one 0 0 zero 0 0 gap 203970 toggle_bit 0 begin codes KEY_STOP 0x000231 KEY_PAUSE 0x000230 KEY_FASTFORWARD 0x000228 [...] KEY_B 0x000279 KEY_POWER 0x00020C end codes end remote -1- reading internal IR probe I have plugged a classic tri-leg IR receiver on IR-RX pin. The correct way to get it work is to add "cir" on the overlays line of /boot/armbianEnv.txt (or use armbian-config), then reboot. Immediately after reboot you should see /dev/lirc0 available. After installing lirc (aptitude install lirc), start configuring it: # irrecord -d /dev/lirc0 file [...] Press RETURN now to start recording. ............................ irrecord: could not find gap. irrecord: gap not found, can't continue I don't know if this is related to my remote, or if there is an issue with the rpi. But I have not been able to go further using LIRC. My workaround is to read lirc0 manually, and parse the timecodes with this. It's not clean, but it's good enough for me: #!/bin/bash n=1 t=1 v=400 mode2 -d /dev/lirc0 | { while true ; do read -t 1 line [ "$line" = "" ] && { # timeout [ $n -eq 0 ] && echo "" && n=1 t=1 continue } n=0 typ="$(echo "$line" | awk '{print $1}')" val="$(echo "$line" | awk '{print $2}')" z=0 [ $val -gt $(($v/2)) ] && [ $val -lt $(($v*2)) ] && r=s && z=1 [ $val -gt $(($v*2)) ] && [ $val -lt $(($v*4)) ] && r=m && z=1 [ $val -gt $(($v*8)) ] && [ $val -lt $(($v*12)) ] && r=l && z=1 [ $val -gt $(($v*12)) ] && r=x && z=1 [ $z -ne 1 ] && { echo "${val} ???" >&2 continue } # echo "$typ $r" [ "$typ" = "space" ] && { case "$r" in "s") echo -n "0" t=0 ;; "m") echo -n "1" t=0 ;; "l") echo "LARGE" ;; "x") true #echo "X" ;; *) echo "???" esac continue } # here, we have a pulse. case "$r" in "s") true ;; "l") # begin of frame true #echo -n ":" [ $t -eq 0 ] && echo "" t=1 ;; *) echo "???" esac done } This outputs 0s and 1s; and can later be piped to an other similar program to compare lines/strings with a home made database, or whatever. -2- CPU freq issues "armbianmonitor -m" shown me that CPU freq oscillates between 240MHz and 1.2GHz. I suspect this to affect my issues, and, I have tried unsuccessfully to fix it with the following line: /usr/bin/cpufreq-set -f 1200MHz ; /usr/bin/cpufreq-set -g performance -3- reading audio device Because I need to irsend things, and, after 6h of google, it seems impossible to do it on OrangePi/Armbian (pigpio is unusable on OrangePi/Armbian; Armbian does not include any equivalent of lirc-rpi; it should be possible to write a DTO to handle this, but I don't know how to do it; did not find any real time interface able to produce apropriate signals; still, it should be possible to do it at the very least on the MOSI pin, the same way as for SPI LCD and 1Wire), I have switched to LIRC-ALSA. In short ... irrecord --driver=audio_alsa -d hw@48000,r file [...] Press RETURN now to start recording.. .............irrecord: no data for 10 secs, aborting irrecord: gap not found, can't continue I have tried to run this inside "time"; irrecord can have two extreme reactions: - freese and never give prompt back ... for a full minute (until ^C) (if I don't press my remote at all, or, once every 5s) - give hand back after printing 1 to 10 dots, pretending "timeout after 10s", after a duration as short as "1.3s" (I am not showing here my tons of attempts), if I press my remote very fast. As said, fixing the CPU freq did not help. I have cheked 5 times I was working on the good input. IR data line can be plugged on pins MIC1P or MIC1N; then, use alsamixer to enable capture (F4 menu) on MIC1. MIC1_boost and ADC_gain affect the behaviour of irrecord. Best results are obtained with 54% and 57%. Other columns do not affect LIRC. -4- Sending IR frames Not having able to record any conf the proper way, I was unable to fire-send-transmit any stream. So I downloaded a random lircd.conf file, just to have a random "remove" in my conf, to dig irsend. # tail /var/log/syslog Feb 11 18:54:16 localhost systemd[1]: Starting LSB: Starts LIRC daemon.... Feb 11 18:54:16 localhost lirc[26693]: * Loading LIRC modules Feb 11 18:54:16 localhost lirc[26693]: ...done. Feb 11 18:54:16 localhost lirc[26693]: * Starting remote control daemon(s) : Feb 11 18:54:16 localhost lircd-0.9.0[26704]: lircd(audio_alsa) ready, using /run/lirc/lircd1 Feb 11 18:54:16 localhost lircd-0.9.0[26706]: lircd(default) ready, using /run/lirc/lircd Feb 11 18:54:16 localhost lircd-0.9.0[26706]: connected to localhost Feb 11 18:54:16 localhost lirc[26693]: ...done. Feb 11 18:54:16 localhost lircd-0.9.0[26704]: accepted new client from 127.0.0.1 Feb 11 18:54:16 localhost systemd[1]: Started LSB: Starts LIRC daemon.. [...] Feb 11 18:55:03 localhost lircd-0.9.0[26704]: accepted new client on /run/lirc/lircd1 Feb 11 18:55:03 localhost lircd-0.9.0[26704]: error processing command: SEND_ONCE ATI_Remote_Wonder_II KEY_STOP Feb 11 18:55:03 localhost lircd-0.9.0[26704]: hardware does not support sending Feb 11 18:55:03 localhost lircd-0.9.0[26704]: removed client ... # irsend -d /var/run/lirc/lircd1 SEND_ONCE ATI_Remote_Wonder_II KEY_STOP irsend: command failed: SEND_ONCE ATI_Remote_Wonder_II KEY_STOP irsend: hardware does not support sending So, I am trying to send data over /var/run/lirc/lircd1, which is confirmed by syslog to be the audio_alsa device. And it complains "hardware does not support sending". Also spent 2h in googling this; no help. Some people mention, /usr/share/lirc/lirc-old2new , but it's not available in my Armbian. -5- External USB-sound dongle Trying to use a USB-sound dongle gave similar (identical ?) results. -6- my need ATM, I am able to input the bits; my real urgent need is to find any way to send frames. Either via GPIO, or ALSA, I don't care. As long as it remains cheap. NB: do not talk about what happen over the air; I am stuck on a software issue; the frames I need to send are never to be converted in actual infra red light; I am working directly on IR data lines inside a device, after optical-electrical conversion. OrangePi hardly can receive IR; and not send any at all. Very sad. I have put too big hope in this cheap machine. I have also given-up on using Opi0 as USB-gadget gateway; opi0 can do only storage gadget; I need HID, and no tutorial explain how to do it with a recent Armban (all tutorial were written in 2015-2016, and fail on Armbian 5.35 or + ).

Hello. Two DS18b20 on OrangePi Zero (H2+) ARMBIAN 5.35 user-built Ubuntu 16.04.3 LTS 4.13.16-sunxi What did the trick for me: - armbian-config, enable 1wire, which added w1-gpio to the list of overlays in /boot/armbianEnv.txt ; it's probably possible to add it manually without running armbian-config - add param_w1_pin=PA10 - add 10k resistor between +3.3 and PA15(MOSI) - reboot. Did not need to change anything in /etc/modules* or anything else not mentionned above. Raw logs: # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=240000 MAX_SPEED=1200000 GOVERNOR=ondemand # cat /boot/armbianEnv.txt verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 w1-gpio param_w1_pin=PA15 rootdev=UUID=ebe9dacf-124f-486c-b6c1-08749e209374 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u # ls /sys/bus/w1/devices 28-0517023468ff 28-0517025727ff w1_bus_master1 # dmesg | grep -i -e w1 -e wire [ 15.291623] Driver for 1-wire Dallas network protocol. # cat /etc/modules /etc/modules-load.d/* g_serial g_serial It may be possible to use 1W on other pins that MOSI, but RaspberryPi forums recommend to use MOSI because for rPi it's the fastest pin, and the only one able to stand high bitrate. Some devices may refuse to communicate at low bitrate, making usually impossible to use any other pins. I agree that 1W may be sensible to CPU frequency scaling, but I never had any issue around this.

Crontab is definitely not executed, but rc.local is. So, I have inserted some sections in rc.local. What I insert in rc.local is not the code below directly, but a call to a script. The call looks like this: /usr/local/sbin/rc.local.sh & or /usr/local/sbin/rc.local.sh || /bin/true or { some code || true anothercommand || true } & both methods will work, as long as your code loses the sh -x property. I have tried various combinations like this: /usr/bin/expect -c " set timeout 30 set password 1234 set new orangepi spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=keyboard-interactive,password -l root localhost passwd expect \"*assword:\" send \"$password\r\" expect \"*UNIX password:\" send \"$password\r\" expect \"*nter new UNIX password:\" send \"$new\r\" expect \"*etype new UNIX password:\" send \"$new\r\" expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " >>/root/log1 2>&1 but they all ended up with Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. root@localhost's password: Permission denied, please try again. root@localhost's password: Permission denied, please try again. root@localhost's password: Permission denied (publickey,password). send: spawn id exp3 not open while executing "send "\r"" They work fine in all my simulation tests, but not in the live real run. For some reason I can't understand, the password 1234 can work later, from remote network, after the system has completed boot, but does not work from localhost during rc.local. I have tried to add this before the above section, but it did not help: /bin/echo "root:1234" | /usr/sbin/chpasswd So, I ended up with something else; after days of attempts, it's the only thing that works for me: cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys /usr/bin/expect -c " set timeout 30 set password 1234 set new orangepi spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=gssapi-with-mic,hostbased,publickey -l root localhost passwd expect \"*UNIX password:\" send \"$password\r\" expect \"*nter new UNIX password:\" send \"$new\r\" expect \"*etype new UNIX password:\" send \"$new\r\" expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " >>/root/log0 2>&1 Of course, a certificate is generated for root in an earlier step; but I do this just after writing the image on sdcard; so the certificates are already available in /root before the pi boots the SD, and before rc.local is started. Here is a hint for curious people; but this raw code will NOT work as is in rc.local: /bin/echo "" | /usr/bin/ssh-keygen -t rsa -N "" -C "root@$DAHOSTNAME" -f "$MNTPNT"/root/.ssh/id_rsa I am tired of trying 100 different things; so I am not going to work and identify the smallest optimal solution; the above code should work. So, there are two different ways to change the root password; I don't know which one best worksaround my Armbian specific issue: /bin/echo "root:armbian" | /usr/sbin/chpasswd or /usr/bin/expect -c " set timeout 30 set password 1234 set new orangepi spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=gssapi-with-mic,hostbased,publickey -l root localhost passwd expect \"*UNIX password:\" send \"$password\r\" expect \"*nter new UNIX password:\" send \"$new\r\" expect \"*etype new UNIX password:\" send \"$new\r\" expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " >>/root/log0 2>&1 After changing the root password, Armbian offers to set a user profile; if you don't, it will prompt you on first login. I also want to get rid of this message. What should work, but does not for me: /usr/bin/expect -c " set timeout 30 set password orangepi spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=keyboard-interactive,password -l root localhost expect \"*assword:\" send \"$password\r\" expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " >>/root/log3 2>&1 What works for me: /usr/bin/expect -c " set timeout 30 spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=gssapi-with-mic,hostbased,publickey -l root localhost expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " >>/root/log5 2>&1 I do not understand why expect is unable to sort this issue the first time, and why I need to run send \"\x03\r\" twice. But I am tired. So I just run expect twice. First time. And here is what the section should look like (I am not using this code as it is below; this code is not tested-certified): /bin/echo "" | /usr/bin/ssh-keygen -t rsa -N "" -C "root@$(hostname)" -f /root/.ssh/id_rsa cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys chage -l root >/root/chage1 /bin/echo "root:1234" | /usr/sbin/chpasswd chage -l root >/root/chage2 /usr/bin/expect -c " set timeout 30 set password 1234 set new orangepi spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=gssapi-with-mic,hostbased,publickey -l root localhost passwd expect \"*UNIX password:\" send \"$password\r\" expect \"*nter new UNIX password:\" send \"$new\r\" expect \"*etype new UNIX password:\" send \"$new\r\" expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " >>/root/log0 2>&1 chage -l root >/root/chage3 /usr/bin/expect -c " set timeout 30 spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=gssapi-with-mic,hostbased,publickey -l root localhost expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " >>/root/log5 2>&1 Of course, my scripts also include other features to avoid running this twice (at second and later boots) (but this is off-topic today). The minimalistic version should look like this (untested) /bin/echo "" | /usr/bin/ssh-keygen -t rsa -N "" -C "root@$(hostname)" -f /root/.ssh/id_rsa cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys /bin/echo "root:1234" | /usr/sbin/chpasswd /usr/bin/expect -c " set timeout 30 spawn -noecho ssh -t -o StrictHostKeychecking=no -o ConnectTimeout=20 -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=gssapi-with-mic,hostbased,publickey -l root localhost expect \"Please provide a username (eg. your forename):\" send \"\x03\r\" " Tutos I used: https://stackoverflow.com/questions/26654640/expect-script-to-change-password-using-ssh https://stackoverflow.com/questions/23836136/expect-interrupt-program-ctrlc

Just after writing the image on the SDcard, I start tuning rc.local and crontab. I have found that crontab is not run before first authentification; this is an issue, because I use crontab to handle my networking; and without networking, I can not know the IP of the pi, and I can't login. I have found that after first authentification, I am asked to change the root password, then I see /etc/update-motd.d/99-point-to-faq, then /etc/profile.d/check_first_login.sh (which includesuser account creatino), but not /etc/update-motd.d/41-armbian-config After second authentification, I can see /etc/update-motd.d/41-armbian-config and /etc/update-motd.d/99-point-to-faq have been removed from disk (the end of the script removes itself). What I don't understand: - during first boot, why (how) is 41-armbian-config not run ? how does it get enabled ? - where and how is root password change handlede ? - why (how) is root password change required to start crontab - is /etc/rc.local run before first root auth ? I am 100% certain crontab is not run, but I am not sure about rc.local. - if system is power cycled before first root auth, are sshd certificates regenerated ? Does /boot/armbian_first_run.txt handle IPv6 ? I have spent hours on studying the systemd dep tree, and reading all scripts, there are 4 details that I can't catch. Instead of removing 99-point-to-faq, it would be much more clean to add it to the MOTD_DISABLE list in /etc/default/armbian-motd

In the end, what worked for me: 0: my system: "ARMBIAN 5.35 user-built Debian GNU/Linux 8 (jessie) 4.13.16-sunxi" (called next) 1: I am not going to try using the touch layer. 2: wire things as described (with LED directly on 3.3V) 3: aptitude install linux-headers-next-sunxi 4: copy the content of "Configuration for the first spi bus" from initial post, except last line about EOF, into /root/myili9431.dts 5: armbian-add-overlay myili9431.dts 6: edit /boot/armbianEnv.txt and edit this line (some parts may be useless or overkill) overlays=usbhost2 usbhost3 spi-spidev spidev myili9431 (this appeared to be useless) 7: reboot 8: modprobe fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 ... and immediately the LCD turned from all white, into classic console (black background with prompt at the top) Here is my dmesg: [ 166.951033] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 166.962129] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 166.967576] fbtft_device: GPIOS used by 'fb_ili9341': [ 166.967602] fbtft_device: 'dc' = GPIO3 [ 166.967627] fbtft_device: 'reset' = GPIO0 [ 166.967649] fbtft_device: 'led' = GPIO6 [ 166.967703] spi spi1.0: fb_ili9341 spi1.0 16000kHz 8 bits mode=0x00 [ 166.983929] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 167.341354] Console: switching to colour frame buffer device 30x40 [ 167.344793] graphics fb0: fb_ili9341 frame buffer, 240x320, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi1.0 at 16 MHz https://kaspars.net/blog/linux/spi-display-orange-pi-zero mentions rotate=90 ... could be usefull for someone 9: xinit worked immediately

After reading https://docs.armbian.com/Hardware_Allwinner_overlays/ I have tried: # aptitude install linux-headers-sun8i # aptitude install linux-headers-dev-sun8i # armbian-add-overlay myili9431.dts Kernel headers are not installed properly. Please install the kernel headers package # uname -r 4.13.16-sunxi so in short, Armbian does not provide any package header for the default kernel ... EDIT: after a good sleep, I have found the right kernel-headers: # dpkg -S /boot/vmlinuz-4.13.16-sunxi linux-image-next-sunxi: /boot/vmlinuz-4.13.16-sunxi # aptitude install linux-headers-next-sunxi I have stored your first bit of code in /root/myili9431.dts: # armbian-add-overlay myili9431.dts Compiling the overlay Error: myili9431.dts:29.1-6 syntax error FATAL ERROR: Unable to parse input tree Error compiling the overlay After removing the very last line "EOF": # armbian-add-overlay myili9431.dts Compiling the overlay Copying the compiled overlay file to /boot/overlay-user/ Reboot is required to apply the changes So please edit your initial post and remove that EOF thing. I don't plan on using the touch layer, so, I am not going to break my mind on that part. Now comes the second big issue: # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Error: missing build directory structure Please clone the full repository https://github.com/armbian/build/ # ls build compile.sh lib I have cloned this twice, and it's still asking me to clone it.

Where do we store those files ? Which directory ? which file name ? Which compiler should be use ? What's the compile command ? What you are quoting is not any of the 12 languages I know (x86 ASM, ARM ASM, Saturn ASM, C, C++, Bash, Shell, Perl, Python, Prolog, VHDL ... )

I tried /boot/armbianEnv.txt ... did not work. I have inserted isolcpus=2,3 in /boot/boot.cmd in the middle of the line like setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} hdmi.audio=EDID:0 disp.screen0_output_mode=${disp_mode} panic=10 consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} ubootsource=${devtype} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}" and ran the command given at the very end of /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr reboot, and it's working for me. To check it's working, run top, press 1 to expand the CPU view, and launch four times this command in parallel: cat /dev/urandom >/dev/null It's a CPU eating task, but not yet a fork bomb. Isolated core should keep iddle between 99 and 100% OxFF you should avoid to isolate core 0 because it's the prefered core for kernel; running kernel on an other core may lead to bugs; this heavily depends on the platform, kernel version, kernel taste (features like process migration) ... and which drivers you are using. Isolate core #0 only if you are sure it will let the kernel run on core #0, and only prevent normal process from running on it.

How to improve handling of PWM: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=200793 My tutorial to drive WS2812 with an Orange Pi zero: http://www.orangepi.org/orangepibbsen//forum.php?mod=viewthread&tid=3318&page=1&extra=#pid21903 Both links contain clues which may be usefull for those who are playing with the PWM, even if you are not driving LEDs.