slinde

The most simple solution would be to start your script from the file /etc/rc.local.
Just add a line starting your script before the "exit 0" line last in the /etc/rc.local file.
 
In this way there is no need to login. The file /etc/rc.local is run automatically by the system at boot.

I have read the latest posts and decided to upgrade Armbian logo. I wanted to do something simple, but it may be easier circle, a square and a triangle ? Here are the result 

Someone might have seen here a penguin. 

Meh. I hate the puzzle one. Not horrible, just doesn't define Armbian. I could always kind of tell it was a place holder.
 
To be honest, I don't care what the vote results are. Armbian needs a mascot. A symbol that is recognizable. The all black simple, minimalist ones are alright. As it always is... same for the sd card one. However, there will be boards that will be running armbian, without SD Cards ever being involved. Going with an SD card symbol is just an unreasonable attachment to the default, simplistic, layout Igor chose when he was running the site off an OrangePi. So, IMO the SD card ones don't do Armbian justice.
 
Polygon Penguin all the way! Aka, PolyPenguin, Penguin Polly, Polly the Penguin, Armbian's Penguin Polly (APP), the list goes on and on. Seriously. The penguin at least has character.
 
What If you combined the gradient background of #4 [Very Dark] with Dre0x's penguin? You'd have a dope, long lasting, original background, logo and mascot, while also staying true to the whole point of having a vote.
 
Por que no los dos?

(I realize the submission is late and doesn't meet requirements mention in the first place, but this isn't a submission. Just a proof of concept.)

I don't agree that bringing here Raspberry Pi users would benefit the Armbian project.
First, another Debian/Ubuntu derivative means fragmentation of user base - not an improvement for Raspberry Pi project.
Second, IMO Armbian project needs more developers, experienced users/experts and maybe sponsors, and not a lot of inexperienced users who bought an SBC for no reason and now don't know what to do with it.

Always do a verify since otherwise you never know when your hardware and/or dd failed. The following might require an
apt-get install gddrescue p7zip first. And then given we're talking about an SD card available as /dev/sda it's just:
root@ubuntu:~# cat /proc/partitions major minor #blocks name 179 0 3887104 mmcblk0 179 1 3686400 mmcblk0p1 8 0 500224 sda 8 1 1024 sda1 root@ubuntu:~# md5sum /dev/sda 19d9508a47b1469dc5570c2e8507112c /dev/sda root@ubuntu:~# ddrescue /dev/sda SD-card.img SD-card.log GNU ddrescue 1.19 Press Ctrl-C to interrupt rescued: 512229 kB, errsize: 0 B, current rate: 7798 kB/s ipos: 512163 kB, errors: 0, average rate: 7214 kB/s opos: 512163 kB, run time: 1.18 m, successful read: 0 s ago Finished root@ubuntu:~# md5sum SD-card.img 19d9508a47b1469dc5570c2e8507112c SD-card.img root@ubuntu:~# 7zr a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on SD-card-19d9508a47b1469dc5570c2e8507112c.7z SD-card.img 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) Scanning Creating archive SD-card-19d9508a47b1469dc5570c2e8507112c.7z Compressing SD-card.img Everything is Ok root@ubuntu:~# ls -al SD-card-19d9508a47b1469dc5570c2e8507112c.7z -rw-r--r-- 1 root root 192350156 Dec 8 11:35 SD-card-19d9508a47b1469dc5570c2e8507112c.7z So you end up with a verified and compressed card image. And since MD5 hash is incuded in filename you could also check integrity after unpacking again.
 
TL;DR: Do not use dd to either write OS images (use Etcher!) or read from devices (use GNU ddrescue!). Using dd is ALWAYS wrong. Verify reading and writing stuff. And in case you plan to do anything that should serve as backup then TEST it afterwards.

Designed a case for it. Available on thingiverse if anyone interested - http://www.thingiverse.com/thing:1918590
 

I used GIMP and Affinity Designer. I created the vector of the pcbs, which will be provided if needed.
If you do not like the sdcard, I can change to with whatever you want. Just ask.
I hosted the .zip file on dropbox, with all the resolutions needed. Download HERE

Good luck to everyone!

There have been several disjointed tutorials on making a raspberrypi or orangepi into a surveillance camera. So I threw this together to maybe help someone out there with any issues.
I used the orangepipc+ but any orangepi board should work as long as it has the basics, internet connectivity, storage, and a camera. (I highly suggest heatsinks as well)
 
any feedback or enhancements to this tutorial are greatly appreciated.
 
------------------------------------------------------------------
ORANGEPI IPCAMERA
------------------------------------------------------------------
  su root   apt-get update apt-get upgrade apt-get install wget https://github.com/ccrisan/motioneye/wiki/precompiled/ffmpeg_3.1.1-1_armhf.deb dpkg -i ffmpeg_3.1.1-1_armhf.deb   apt-get remove libavcodec-extra-56 libavformat56 libavresample2 libavutil54   apt-get install python-pip python-dev curl libssl-dev libcurl4-openssl-dev libjpeg-dev libx264-142 libavcodec56 libavformat56 libmysqlclient18 libswscale3 libpq5   wget https://github.com/Motion-Project/motion/releases/download/release-4.0.1/pi_jessie_motion_4.0.1-1_armhf.deb dpkg -i pi_jessie_motion_4.0.1-1_armhf.deb   pip install motioneye mkdir -p /etc/motioneye cp /usr/local/share/motioneye/extra/motioneye.conf.sample /etc/motioneye/motioneye.conf   mkdir -p /var/lib/motioneye   cp /usr/local/share/motioneye/extra/motioneye.systemd-unit-local /etc/systemd/system/motioneye.service systemctl daemon-reload systemctl enable motioneye systemctl start motioneye   sudo modprobe gc2035 sudo modprobe vfe_v4l2   systemctl restart motioneye Accessing The Frontend
After having successfully followed the installation instructions, the motionEye server should be running on your system and listening on port 8765. Fire up your favorite web browser and visit the following URL (replacing [your_ip] with... well, your system's IP address):
http://[your_ip]:8765/
Use admin with empty password when prompted for credentials. For further details on how to configure motionEye, see Configuration.
 
------------------------------------------------------------------
FOR UPDATES;
------------------------------------------------------------------
 
pip install motioneye --upgrade
systemctl restart motioneye
 
 
 sudo nano /etc/motioneye/motioneye.conf
ctrl+x then y (nano)
 
Modifiy the motion.config file to turnoff localhost;
stream_localhost off
 
change the port to 80 from 8765 if desired by; 
 
systemctl enable motion
systemctl start motion
 
 
Tutorial sources;
https://github.com/ccrisan/motioneye/wiki/Install-On-Raspbian
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=941 
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1988  (some resources for motion)
http://www.cnx-software.com/2015/09/26/how-to-use-orange-pi-camera-in-linux-with-motion/(VERY OLD)
 
WIP tutorial, I want to add a version with facial recognition using openface and a version using ALPR (automatic license plate recognition, as the orangepi systems can have 2GB of ram)
 
Update 1 09/30/16;
seems there is a issue with motioneye and being unable to find the csi camera. I'm trying to find a work around, any help is appreciated.
Update 2 11/05/2016
Updated motioneye installation
added information on motion and basic setup (incomplete)
the editor seems to be breaking my wget addresses
I forgot to add the login information and frontend... *DOH*

Thanks Igor.
 
Hope the attached are of use.
 
Armbian Designs.zip

WiFi is planned, BT also.
 
Opi zero (and PC2) just arrived on my desk today and I got Armbian running on it in no time   We need to add wireless drivers and apply fine tuning ... PC2 will be tested later.
 

hi!
real original and unique photo took by a friend with his telescope
 

At least I prefer to work on supporting interesting hardware which RPi 3 is clearly not. For me personally the various Raspberries have one single feature: That's the ability to use HW accelerated video encoding (identical on all RPi models since the job is done on the VideoCore IV and not the ARM cores) but fortunately we can now also use Allwinner boards (see github repos of community member @lex and various threads in H3 and free forum).
 
From a user's point of view the only great thing about Rasperries is the huge community, this advantage would be lost by switching to Armbian. So supporting these overpriced pieces of hardware really makes not that much sense IMO
 
The proprietary boot process and the ARM cores not being first class citizens (the CPU cores do not even know at which frequency they're clocked and information like /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is cheating on you) also make working with this platform less fun. Also Armbian is a lot about pushing the envelope (optimize settings, tweak kernel and u-boot) which is simply not possible on Raspberries since a lot of this stuff happens inside the properietary so called 'Firmware'. Armbian would just be another lame rootfs on these devices.
 
BTW: For my use cases I/O and network bandwidth is somewhat important and here even the cheapest devices Armbian currently supports (NanoPi NEO and soon Orange Pi Zero) easily outperform RPi 3.

Armbian microprocessor die


 
 
 
 

 
 




Remix from Wikimedia Commons Image, ARM chip under microscope, CC BY-SA 3.0 :
https://commons.wikimedia.org/wiki/File:PHILIPS_ARM_VY22549A6_N48752.00_04_kSG0631-1825-0172.jpg


 

Simplest and safest way is to use ssh-server on OPI and forward a router-port to OPI ssh-port. With ssh port-forwarding you can tunnel any services over secure ssh connection.

I use this on debian server image:
http://wiki.freepbx.org/display/FOP/Installing+FreePBX+13+on+Debian+8.1

I'd like to add another method which I found "cleaner" and "easier".
Debian provides an easy way to set sysfs values after reboot via the /etc/sysfs.conf file and the /etc/sysfs.d/ directory.
(This is basically the same as the relation between the /proc/sys and sysctl.conf and sysctl.d.)
 
My use-case:
I wanted to set the red light on my OpiPC to the heartbeat effect.
This can be set manually with:
# echo heartbeat > /sys/class/leds/orangepi\:red\:status/trigger The sysfs files format is really simple:
# the path omits the /sys/ path/to/the/settings = value So all I had to do was:
# echo "class/leds/orangepi\:red\:status/trigger = heartbeat" > /etc/sysfs.d/red_led.conf One can modify the sysfs.conf itself, but it's more pluggable/manageable via .conf files under the sysfs.d directory.

For me, the best H3 web browsing experience is with Firefox on a Beelink X2 using Armbian on the internal NAND. The difference between Beelink X2 (1GB RAM + armbian on NAND) vs Orange Pi One (512MB RAM + Samsung EVO) is very significant, is not like my core i5 with 4GB of RAM but is more or less decent.

You can simply use GPIO internal pullups by enabling them.
By using orangepi_PC_gpio_pyH3 ( https://github.com/duxingkei33/orangepi_PC_gpio_pyH3), python code will look like :
from pyA20.gpio import gpio from pyA20.gpio import port gpio.setcfg(port.PA1, gpio.INPUT) gpio.pullup(port.PA1, gpio.PULLUP) if gpio.input(PA1) > 0: print "not pressed" else: print "pressed"

Had a bit of time today to do testing.
Downloaded a fresh copy of the Beelink X2 Jessie server image file Armbian_5.14_Beelinkx2_Debian_jessie_3.4.112.7z. Unpacked it and burnt to a micro-SD card. Put the card in my Beelink X2 and switched the power on. The only thing connected to the Beelink X2 is power and network cable.
 
Of course it booted just as expected and performed the dual boot it should do on first boot. So there is no fault in the ARMbian image file.
 
Here are my observations of the LED behaviour. By LAN led I mean the led on the switch port my Beelink X2 is connected to. I find observing the led on the switch to be the best way to know what is happening.
 
  1st boot: solid purple solid blue LAN led on flashing blue/purple LAN led off flashing red/blue   2nd boot: solid purple solid blue LAN led on flashing blue solid blue ready to log in via ssh

Had a bit of time today to do testing.
Downloaded a fresh copy of the Beelink X2 Jessie server image file Armbian_5.14_Beelinkx2_Debian_jessie_3.4.112.7z. Unpacked it and burnt to a micro-SD card. Put the card in my Beelink X2 and switched the power on. The only thing connected to the Beelink X2 is power and network cable.
 
Of course it booted just as expected and performed the dual boot it should do on first boot. So there is no fault in the ARMbian image file.
 
Here are my observations of the LED behaviour. By LAN led I mean the led on the switch port my Beelink X2 is connected to. I find observing the led on the switch to be the best way to know what is happening.
 
  1st boot: solid purple solid blue LAN led on flashing blue/purple LAN led off flashing red/blue   2nd boot: solid purple solid blue LAN led on flashing blue solid blue ready to log in via ssh

Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
 
Hi All,
 
I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
 
Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
 
However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
 
Step 1) Adjust /etc/lirc/hardware.conf
 
Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
 
For Ubuntu Xenial (September 2017):
 
The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
# /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" 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="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=""  
For Debian Jessie (~year 2016):
 
By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
 
Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
# Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
  As lirc is actually already running and installed in Armbian, do the following:
 
root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
 
Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
  user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
    Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
Pressing the remote reveals events like:
Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
 
 
Step 5) Configure lirc to map IR input to key presses or events.
 
Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
 
There's plenty of information on how to use irrecord, command I used was:
/etc/init.d/lirc stop ...to first stop the service, then:
irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
 
 
Step 6) Test with irw
 
Now that I recorded my configuration file with irrecord:
/etc/init.d/lirc start .. to start lird service again
 
then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
  Step 7) Create a /etc/lirc/lircrc file to run commands
 
sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
# http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
 
 
Additional References:
[Guide] Android + InfraRed (IR) + Kodi 
How to setup Remote Control for Linux

Won't help you if u-boot or SPL are corrupted
 
The only way to see what is happening is UART console. LEDs are controlled from software, so they can't tell you much.
 
You can't put whole rootfs on FAT partition (at least without some very strong magic to emulate file permissions and owner information). These "small PCs" are using u-boot which does have ext4 filesystem drivers, well, unless you build your image on Debian Stretch (testing) or sid, which uses ext4 flags not supported by u-boot.
 
Yes. Compared to Raspberry Pi, these boards are not perfect for novice users, and also most things are already documented (i.e. here)
 
I wouldn't call this a trivial situation. If you search through this forum, you can see that most of early boot problems are related to either SD card problems (including using wrong/incomplete procedure for writing an image) or power supply problems (or interference from connected USB peripherials), but it may take ages and insane efforts to force users to admit that problem is on theirs side.
 
These images are designed to work out of the box, you don't need to touch anything related to partition table

Hotcloning Armbian SDcard ( tested on OPI ONE/LITE  )
 
You need a USB card reader and Linux. With a running Armbian you've got all the Linux you'll ever need. The aim is to copy the entire system on SDcard including bootstuff and our personal belongings, roots, cats, dogs etc... to a new SDcard. The new card must only hold the data content of the old card and can be of different size (smaller, larger). The new SDcard contains one big partition of maximum size and is bootable.
 
Setup
 
1. Download the script and rename it to armbian_hotclone.sh
 
2. Start your OPI ONE with the SDcard you want to copy and connect to it via ssh ( or putty ).
 
3. The script needs to be run on the board ( in my case OPI ONE ). Copy the script to your board and make it executable ( chmod +x )
 
4. Attach a USB card reader to the OPI ONE. Make sure there is NO OTHER USB storage attached.
 
Running the script
 
5. Insert the target SDcard into the card reader and check it has been detected ( lsblk )
 
6. Run the script as root ( sudo ) and depending on the card reader and SDcards wait 10-60 minutes
 
Test the new SDcard
 
7. Shutdown the OPI ONE.
 
8. Replace the SDcard in the slot with the new copy
 
9. Make sure the OPI ONE boots correctly before you put the SDcard into the cookie jar for desaster recovery and worse.
 
Notes on usage
 
The script is just a skeleton to showcase the basics. A break needs to be added to prevent it from running accidentally and eating up disks.
 
Warning : Do NOT run the script on your host
 
armbian_hotclone.sh.txt
 
Enjoy !

Test done with NanoPi M1 (with the image made for NEO, only real difference: in both cases DRAM has been clocked with 408 MHz instead of 624 MHz as we usually do in Armbian):
 
I used the following script called from /etc/rc.local to iterate through 816, 624, 480 and 240 MHz cpufreq running cpuminer and then killed the task to get idle consumption. Remaining in each state for 40 minutes so my 'monitoring PSU' is able to provide '30 min average consumption' numbers.
#!/bin/bash for i in 816000 624000 480000 240000 ; do sleep 2400 echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq done sleep 2400 pkill minerd Cpuminer scores at the 4 different CPU clockspeeds were identical: 1420, 1110, 875, 450 khash/s
 
But both temperatures and consumption differed (on the left is kernel 4.7.2, on the right 3.4.112 -- same board, same cables, same PSU, same SD card, only OS image exchanged):
816 MHZ: 67°C / 1820 mW 73°C / 2060 mW 624 MHz: 62°C / 1600 mW 66°C / 1820 mW 480 MHz: 57°C / 1430 mW 62°C / 1660 mW 240 MHz: 49°C / 1100 mW 54°C / 1340 mW idle: 41°C / 750 mW 47°C / 980 mW (I had to slightly adjust temperature readouts since the tests take a long time to get sane average consumption values and ambient temperature differs by 2°C in the lab -- day vs night).
 
On average we get a difference of +5°C / +230 mW for legacy kernel compared to mainline. This means running mainline kernel is another good measure to reduce consumption since with legacy kernel I already used NEO settings with GPU/HDMI disabled. You should also keep in mind that I powered the NanoPi M1 with FriendlyARM's PSU-ONECOM module which adds a few mW to consumption so NanoPi M1 with mainline kernel and NEO setting (DRAM clockspeed set to 408 MHz) might consume already less than 700mW.
 
Detailed graphs below:
 
 

Allwinner redesigned their website. H64 is gone, H5 has 3 real USB host ports (and a 6 core Mali450 GPU and other display/video improvements compared to A64) and they finally announced R40 (quad-core A7, 2 x USB host + SATA, GbE). R40 is said to be the 'A20 Upgrade Edition: Dual-core upgrade to Quad-core(CPU), 55nm upgrade to 40nm(Craft), lower power consumption, smaller package.' -- ok, time to stop wasting efforts with H3 and H5, let's wait for R40 hardware to appear 
 
BTW: For R40 is also mentioned: 'Open Sources: Supports our own lightweight Linux OS called Tina, which specialized designed for smart hardware' -- well, let's see how Allwinner's definition of Open Source will look like
 
Edit: First device already appeared: Banana Pi BPi-M2 Ultra. Well, 'Team BPi' continues with their 'copy&paste gone wrong' crap (according to their 'documentation' the board has either 3 USB host ports -- which would mean they use an internal USB hub -- or just 2 which would be the count of host ports R40 features) and chose a pretty misleading name: BPi M2 was based on A31s, BPi M2+ on H3 and 'M2 Ultra' has nothing in common with both since it's in a direct line with the original A20 based Bananas. Also M2 should indicate that M3 is a better choice (which it's clearly not, worst software/support ever, hardware design flaws, not possible to get performance by specs in reality)