zador.blood.stained

Thanks. Will be fixed soon.

Just a note: sound is muted + lowest level by default.

Try this:
 
http://mirror.igorpecovnik.com/test/variant-1.zip
 
Unzip and install all deb packages:
 
dpkg -i *.deb

OK
 
Then this can be resolved by creating empty file (with same file name) in "lib/patch/kernel/sun8i-default/orangepiplus/" if needed, so patch will be disabled when BOARD=orangepiplus

Well, I managed to extract OCV curve from PMU, right now it matches default settings in fex file for cubietruck. It should be possible to change it, I'll think about the best way to implement it.

Quick google search for port 51413 indicates that this port is commonly used by Transmission (bittorrent client).
Though I don't see Transmission in default packages list.

Yes, just checked, something like this should work
Make backup of you existing /boot/dtb/sun7i-a20-pcduino3-nano.dtb
Decompile:
dtc -I dtb -O dts /boot/dtb/sun7i-a20-pcduino3-nano.dtb -o /tmp/temp.dts Edit /tmp/temp.dts:
Add uart2_pins_a label
uart2_pins_a: uart2@0 { allwinner,pins = "PI16", "PI17", "PI18", "PI19"; allwinner,function = "uart2"; allwinner,drive = <0x0>; allwinner,pull = <0x0>; }; Change serial section:
serial@01c28800 { compatible = "snps,dw-apb-uart"; reg = <0x1c28800 0x400>; interrupts = <0x0 0x3 0x4>; reg-shift = <0x2>; reg-io-width = <0x4>; clocks = <0x2a 0x12>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&uart2_pins_a>; }; Compile it back (assuming you are using non-root user):
sudo dtc -I dts -O dtb /tmp/temp.dts -o /boot/dtb/sun7i-a20-pcduino3-nano.dtb

Tido, why should I start recommending crap? Have a look at this (incomplete) list to get the idea that there is a little bit more than the few SBC vendors you personally know: https://en.wikipedia.org/wiki/Comparison_of_single-board_computers  (you should really accept that there exist more than 5 vendors and there's no need to choose vendors that got somewhat known/famous for supporting product A -- Banana Pi/Pro -- and now are only dealing with totally incompatible products B, C and D)
 
When I read "some kind of debian for a webserver/hotspot and some other things which my current rasperry pi B+ is doing way too slow" I'm not able to recommend anything since I neither know a single SBC suitable as 'hotspot' nor do I have an idea what specific criteria are needed for 'some other things'.
 
For a webserver I would've a look at boards with high I/O and network bandwidth that are able to run with mainline kernel. But regarding AP mode and 'some other things' I still have not the slightest idea. Since if one of these other things would be HW accelerated video encoding/decoding recommendations might look totally different.

TK can really be patient if it come to explain why Banana is not Banana.
I would simply send you links like:
Difference between Raspi and SinoVoip (Banana) Not enough power (read this thread to understand) Overheating of the SoC (heat-sink attached?)  
Ah, what TK didn't do this time recommend you better alternatives like: ODROID, Olimex, LeMaker and many more.
 
I had just yesterday installed Ubuntu Mate on Raspberry Pi 2 - quick is different !
If you want to use a GUI I have to say LeMaker Guitar is quicker with Lemuntu (quad core 1,2GHz).

It's 3 GB: http://linux-sunxi.org/A64#A64_SoC_Features(and this means unless someone manufactures 12gb DDR3/LPDDR3 modules you will be limited to 2 GB).
 
But that seems to be a common problem with all those cheap Cortex-A53 ARMv8 implementations. While you can benefit from a huge virtual address space the useable physical address space doesn't exceed the 'magical' 64-bit border of 4 GB. And if you don't move both kernel and userspace from ARMv7 to ARMv8 code you won't get that much more performance either. According to Allwinner's PM A64/H64/R18 (all the same more or less) are made in a 40nm process (so the linux-sunxi wiki is still wrong) which might be responsible for the low clockspeeds possible (1152 MHz max.). The A64 seems to be just a bunch of 64-bit Cortex-A53 cores in a 32-bit SoC and the whole '64-bit thing' is more or less marketing and no technical improvement.
 
But hey, people buy numbers: They need 64 bit since... that's twice as much as 32 bit. Same with memory: the very same people cry for 4 GB RAM instead of reading through http://www.linuxatemyram.comand being happy with 1 GB.

Luckily your first image name contains "28j60", so we can say that it's an enc28j60 module.
Linux driver for this is in \drivers\net\ethernet\microchip\enc28j60.c, and required kernel option is CONFIG_ENC28J60,
Unfortunately it's not enabled by default in Armbian kernel.
 
For compiling your own kernel please read the documentation here or wait for a new kernel release (I'll enable this module if I don't forget).

Just a small update: I implemented the aforementioned approach (record the peak value of battery/charge and then use this and the actual value to calculate percentage) and at least it looks good:
 

 
Discharging started at 9:50, at 10:00 I started a sysbench run and at 10:10 an iozone run on the connected SSD and sysbench in parallel (~4W consumption). When the value derived from my primitive formula fell below 49% I stopped the benchmarks to let the Lime2 being idle more or less. I'm curious how high the value is when the Lime2 shuts down due to battery being drained. Update this evening or tomorrow morning.
 
EDIT: The Lime2 was shutdown when the calculated remaining percentage was at 13% -- will post an updated graph later...
 

 
When recharging the percentage value reaches 104% so this time the peak battery/charge value exceeds the one from yesterday (in case this formula is useful then the daemon approach to adjust the peak value while charging will prevent percentage to exceed 100%).
 
While this percentage value looks better I still doubt that it's useful without further corrections (implementing emergency shutdown if battery capacity falls below a certrain treshold and stuff like that).

If you installed systemd-sysv, you don't need to edit boot script (though it doesn't break anything).

Let's not forget about rsync just yet 
1. It's still great for a client-server incremental backups (Linux->Linux), while for more complex setups something like syncthing would be better (although syncthing is very heavy on CPU usage, which will limit transfer speed to 2-3MB/s for example on A20-based devices)
2. @etrash200 mentioned remote server and dyndns, so for backups over Internet using checksumming on application level won't be totally redundant, some ISP's infrastructure still may be from 2006. @tkaiser, you don't like downloading OS images without checksum files, do you? 

I didn't touch percentage calculations in a while, especially since it reports directly from a register (we are talking about battery/capacity, right?). Last thing I modified - fixed units for battery/power, it should report consumption directly without having to multiply voltage and amperage.
 
Percentage curve is expected to be linear if system power consumption is constant, but I guess it's calculated based on current/min/max voltage, so it looks OK compared to googled images for "li-ion discharge curve".
 
It may be not worth to display it as a graph, but it still should be displayed as a numerical value and it's still good for implementing any kind of "safe shutdown" logic.
 
Also, I finally managed to connect a battery to my cubietruck, so I'll try to do my own experiments with monitoring.
 
 

First, you are trying to install things from Raspbian repository. Packages there are compiled for different architecture, so it's a good thing you didn't manage to install anything from it.
 
Second, you were trying to install packages from Jessie (stable release), and all packages there has exact same versions as in Debian repository.
 
So, you need to install nginx from Debian testing branch, for example:
https://packages.debian.org/stretch/nginx- version 1.9.9
To do so, you need to duplicate repository entries in your sources.list, replacing "jessie" with "stretch". 
You still need to use apt pinning to prevent upgrading whole system to testing branch, or you can try downloading and installing packages manually, resolving dependencies as they appear.

Yes, Raspbian is based on Debian, but it has its own repo because Raspberry Pi SoC (except for Raspberry Pi 2) has armv6 architecture, while RPi 2 and all boards supported by Armbian have armv7.
 
There are enough search results in Google for installing packages from testing branch with apt pinning, so I won't copypaste anything here.
For example: https://serverfault.com/questions/22414/how-can-i-run-debian-stable-but-install-some-packages-from-testing
 
Just remember that you can use "-s" option for "apt-get upgrade" or "apt-get install" to see what packages and what versions are about to be installed without actually modifying your system.

@davigre
In another thread you mentioned that your system is jessie, however this output is from sysvinit's shutdown. It's possible that it's a configuration/packages issue, in which case the right command for shutdown would be
systemctl poweroff To check what's wrong you can provide output of these commands:
file /sbin/shutdown dpkg -S /sbin/shutdown

Since my battery arrived I had the time to try out your latest changes on a Lime2. I tested/monitored a few different situations:
    No battery, 5V through DC-IN:
Obviously wrong values that should be ignored. The only value that matters: "battery/connected: 0"     5V provided through DC-IN, battery starting to charge:
In this mode AXP209 gets quite hot (up to +25°C when charging with high current rating compared to normal idle mode without charging a battery) and internal recorded 'total consumption' in my setup exceeded 6W when starting to charge the battery.   Total consumption is the read-out of DC-IN (V*A). Charging consumption is 'charger/amperage' multiplied with voltage from DC-IN -> ac/voltage (not battery/voltage !). Therefore the board's consumption can be calculated by subtracting the 'charge consumption' from 'total consumption'.   Fully charged:
In this mode battery voltage doesn't matter that much. Consumption solely relies on the values that can be read out from DC-IN. But now 'battery/voltage' can be read out.   Disconnecting DC-IN and running on battery:
Now 'battery/amperage' isn't 0 any more and board's consumption can be measured using battery/amperage * battery/voltage   Conclusion (with mainline it _looks_ simple): if "battery/connected = 1" then a battery is present (and also the need to choose a different template and start a daemon approach to calculate total and charging consumption based on the variables below): if "battery/charging = 1" then state is "charging" (board consumption is total - charging -- see above) if "battery/charging = 0" and "battery/amperage = 0" then state is "charged" (board consumption calculated from battery/amperage * battery/voltage) if "battery/amperage > 0" then state is "discharging" (board consumption is battery/amperage * battery/voltage) TODO:  Adjust RPi-Monitor templates to reflect the aforementioned stuff and to check whether there's more to consider by trying out charging/discharing with active monitoring. Try this out with Lamobo R1 where 5V DC-IN is fed through battery connector. Use powermeter to verify internal measurements Check whether external components (SATA disk, USB peripherals) make a difference when reading out AXP209 internals Unanswered questions: Does logic/read-outs differ when power is provided through USB OTG instead of DC-IN? How does the older driver for kernel 3.4 behaves? In case with 3.4 drivers behaviour is different... better fix the driver or the code to detect 3.4 vs. mainline? How does 'charger/low_power' behaves (and should we take care of)?

Let's not forget about rsync just yet 
1. It's still great for a client-server incremental backups (Linux->Linux), while for more complex setups something like syncthing would be better (although syncthing is very heavy on CPU usage, which will limit transfer speed to 2-3MB/s for example on A20-based devices)
2. @etrash200 mentioned remote server and dyndns, so for backups over Internet using checksumming on application level won't be totally redundant, some ISP's infrastructure still may be from 2006. @tkaiser, you don't like downloading OS images without checksum files, do you? 

Cryptsetup works on dev branch, tested.

@wildcat_paris
ccache should be installed automatically and should work without any extra configuration. Since for some reason it didn't work, it's best to unserstand what is wrong and why before attempting to blindly fix the problem by poking at random places 
 
Also compiling kernel should be 99.99% safe even if you are using it without virtualization or isolation in a container; however building Trusty OS images on desktop Trusty host (at least with default settings/old debootstrap) is not safe and may cause issues.

/bin/sh: 1: ccache: not found  For some reason configure script (?) failed to find ccache executable file.
 
Is ccache package installed? ("dpkg-query -s ccache")
Is it present in PATH? ("which ccache")
Are you using the latest version of build script? (execute "git log -n 1" in "lib" directory)

Dear contributors,
 
the Armbian build framework sub-forum is dedicated to collaborate on the tool founded by Igor. The framework itself is opensource/GPL.
Please add in the title, if possible: [WiP] = Work in Progress [RFC] = Request for Comment [TEST], [TEST/CPU/Board] = Feed back on tests [Device specific] [Board specific] etc. The framework doc is here [WIP]
 
The tool aims at building {legacy, vanilla} linux kernels as well as (user-)patching/creating complete working images with {trusty,wheezy,jessie} to write on your flash {sdcard/NAND}
 
Long story short... feel free to:
Report bugs related to build script itself or patches supplied with it; Suggest new features and enhancements to building process; Participate in testing new and experimental features; Make contributions to support new boards. In other words, 
talk about development of {possible,on going} new features & boards; talk about QA/testing of the framework and report issues when using the Armbian build framework.  
Feel free to support Armbian to allow more ARM boards to be handled and enjoy up-to-date kernel & system images / kernel packages.
Thanks for contributions from the past and in the present from:
 
 
So, Welcome to Armbian the framework behind the scene
 
Guillaume, benevolent moderator & tester.

One small issue.
 
Charging / not charging seems not working ... When I unplug the power on fully charged battery, percentage drops to 98% which is somehow o.k. ... and when I do some stress tests it is going slowly down to 9x%. OK. When I put power back, there is no indication for charging ... but I can read out that AC is plugged.