manuti

Another option - as clean as possible.
https://www.armbian.com/ddd/

Currently h3disp and h3consumption won't be updated automagically: https://github.com/igorpecovnik/lib/blob/master/common.sh#L366-L369
 
Currently you would have to update it manually:
sudo su - wget -O - https://raw.githubusercontent.com/igorpecovnik/lib/master/scripts/h3disp >/usr/local/bin/h3disp A long term solution would be to add both utilities to the board support packages.

Another take on the 'cheap ARM thingie running OMV' approach:
 

 
So what about taking 3 things for $7 each and combine them to a compact DIY NAS?
Orange Pi Zero (with 256MB DRAM) NAS Expansion board An external USB3 Gigabit Ethernet dongle The above setup uses the 'Orange Pi Zero Plus 2' that has not even Ethernet (only el cheapo AP6212 Wi-Fi) and I used it just since I'm working on this board currently anyway (still waiting for Xunlong to release an Gigabit Ethernet equipped Zero variant just like NanoPi NEO 2 -- then it get's interesting).
 
With the above setup you can add a mSATA SSD (maybe not that smart behind an USB2 connection and that's the reason I used a passive mSATA to SATA converter to connect an external 3.5" HDD, they're as cheap as $1.5). The other alternative is to attach a 2.5" HDD/SDD (maybe using Xunlong's SATA+power cable) but then it's mandatory to power the whole setup through the 4.1/1.7mm barrel plug that can be seen on the right.
 
Anyway back to the software side of things: In Armbian's special OMV installation variant we support the above setup so even boards without Ethernet at all can simply be used together with one of the two USB3 Gigabit Ethernet dongles available (there's only ASIX AX88179 or RealTek RTL8153). We activate both drivers in /etc/modules and deactivate those not attached on first boot.
 
So you could also run this OMV installation variant on H3 boards lacking Ethernet or with only Fast Ethernet and get some extra speed by attaching such an USB3 GbE dongle on first boot and from then on just if needed (for example you could use an Orange Pi PC this way for hourly incremental networked backups with Fast Ethernet where 'NAS performance' is only needed when it's about large restores or 'desaster recovery' and then you attach the GbE dongle and performance is 2-3 times higher).
 
Unfortunately I ran into 2 problems 1 problem when trying out the only reasonable variant: OMV running with mainline kernel. First for whatever reasons it seems Armbian's build system currently is somewhat broken regarding H3 boards (should also affect nightly builds). It seems cpufreq/DVFS doesn't work and currently H3 boards with recent mainline builds are slow as hell. And 2nd problem with the NAS Expansion board is that disks attached to any of the two JMS578 USB-to-SATA bridges don't make use of UAS (needs investigation).
 
Since I'm currently limited to USB's Mass Storage protocol anyway I used legacy kernel to create an OMV image. Performance not really stellar but ok-ish for a board lacking Ethernet at all:

I tried also one of my (older) JMS567 USB-to-SATA bridges (main difference: no TRIM support unlike JMS578 on the NAS Expansion board) and numbers look slightly better (needs also some investigation):

I won't publish OS images for H3/H5 boards now using legacy kernel since patience is the better variant. When we're able to use mainline kernel on the boards performance will get a slight boost and hopefully we can then also make use of UAS on the NAS Expansion board. Why H3/H5? Since up to 4 independant real USB host ports that do not have to share bandwidth (compare with RPi 3 above -- no way to exceed poor Fast Ethernet performance there with a similar looking setup since RPi's USB receptacles have to share bandwidth)
 
Interesting detail: The two USB type A receptacles have higher priority than the 2 JMS578 chips on the board. If an OPi Zero is connected to the NAS board as soon as you connect an USB peripheral to one of the two USB ports the respective JMS578 disappears from the bus (left receptacle interacts with mSATA, the right one with the normal SATA connector).

For all my Oranges, I'm using https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
Be aware that on PiZero, the STATUS_LED is not on PA15 but on PA17, therefore you will need to tweak mapping.h to change that.

In the meantime I added a lot of tweaks to Armbian's OMV installation routine and started to create OMV images from scratch for the more interesting boards: http://kaiser-edv.de/tmp/NumpU8/ (based on most recent OMV 3.0.70 and Armbian 5.27 releases)
 
I stay with legacy kernel where appropriate (that's currently Clearfogs, ODROID-C1/C2 and A64) and skip both H3 and H5 boards for now since too much WiP at the moment. Some of the tweaks lead to much better performance numbers even if we can't use 'USB Attached SCSI' now with Pine64 for example:

Sequential write performance looks way better compared to the above Pine64 numbers in post #2 (made with mainline kernel, UAS but also cpufreq limited to just 864 MHz back then and no IO scheduler tweaks).
 
The nice thing with these OMV images now is that they use already the following repos:
Official Debian Jessie repos (here you get updates and security fixes for normal packages) OMV (OMV and OMV Extras updates) Armbian (kernel/bootloader updates and also potential performance tweaks) In the screenshot it's obvious that read performance dropped down to just 32MB/s in one run (check the orange triangles). Am currently investigating this and if it's fixable with better settings that are applied through Armbian's prepare_board mechanism at startup then the fix will magically find all installations in the future since it will be applied through the usual 'apt upgrade'.

IMHO FA might go for the S912 now..
They already got M3 (with Samsung CPU) in the past as a 8xCore (and from my experience on it its really fast) but it lacked support, now with Amlogic the foundations are already there to deliver the first decent and trully mainline supported hacker-friendly 8xCore 64-bit A53 SBC.
 

A small update regarding "NAS performance" on A64 devices. Since I'm currently busy evaluating Armbian's build system as base for universal OpenMediaVault OS images I made a quick test after tweaking NAS relevant settings once more:
 
This is a "SAMSUNG MZ7TE128HMGR-00004" (EVO 840 OEM) connected to the lower USB port on Pine64+ running with legacy kernel:

And this is the same SSD connected to the upper USB port which is A64's USB OTG port connected to a different controller that is said to perform worse:

Well, performance numbers do not differ that much but unless an OMV image with mainline kernel is available (where we can set some magic bits to connect Pine64's upper USB port to a real USB host port using an own EHCI/OHCI controller pair) it's recommended to connect any disk to the lower USB port since this is the real host port.
 
Regarding other A64 boards and their USB ports: all behind an internal hub and having to share bandwidth. Do not even try the 'NAS use case' there

I got it, thanks to everyone who helped  

See your 32 and go down to 16MB
 

Really impressive work for a "one man army". Much appreciate your effort.

Getting back to the Tinker Board itself.. 
 
I swapped in the device tree from the miniarm branch at rockchip-linux, it compiles and boots properly, however I have had no luck getting the Bluetooth or wifi devices enumerated, I need to spend some more time with it.  More troubling, and the reason I have so little progress, is the adjustments made to the HDMI portions of the DT have rendered video output almost impossible to maintain (anytime the system puts the monitor output to sleep it refuses to wake up, sometimes a hotplug of the monitor will rectify it).  The mainline builds fail if I try to patch anything at the device driver level, I'll dig into that later.

Hi Igor and everyone else.
 
Id'like to suggest the following:
 
/etc/fstab
It´s not necesary to use both noatime and nodiratime, because noatime already implies nodiratime, so you can use only the option "noatime" instead of both.
 
When creating the ext4 filesystem with mkfs.ext4 you can type a label for it with the parameter " -L " so when the users mount their cards on a computer, the desktop will show some name instead "NO NAME".
For example:
 # mkfs.ext4 -O ^has_journal -L Armbian /dev/mmcblk0p1
or...
# mkfs.ext4 -O ^has_journal -L Cubox-i /dev/mmcblk0p1
 
Cheers
- Klez

Hi ... I acquired more OPIZ and some NAS (just before they offered the H3 and H5 ... well, next purchase maybe for these machines).
 
When receiving them, I realized the need for the special SATA cable, so I made a small Frankenstein with some old cables I had around (just for primary testing purposes while I have real supported cables).
 
I have an Orange Pi power supply, but attached to a 2E device that I can't turn off right now, so I decided to risk myself a little and to power only the OPIZ (no power to the NAS device).  And both work with a Canakit 2.5A microUSB power adaptor.  The OPIZ powering the NAS worked, at least turning it the tiny green leds.
 
Next test:  To put USB memories on all the USB ports (3 of them) ... and they work well, as 480 Mbps devices.  OK, this means, the power from OPIZ to NAS it is enough, at least for that.  And then, the big test ...
... a WD Blue 500GB 2.5 inch hard drive connected to the NAS.  And ... it works!!  Even together with another USB memory on the same machine.  Without using the NAS dedicated power connector.
 
NOTICE: Before updating the armbian, the hard disk was working as an 1.1 USB device ... painfully slow ... so, update the operating system before testing this.
 
OK ... how fast is this? (after the update)
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 686 MB in 2.00 seconds = 342.52 MB/sec Timing buffered disk reads: 74 MB in 3.03 seconds = 24.41 MB/sec root@orangepizero:~# hdparm -Tt /dev/sdb1 /dev/sdb1: Timing cached reads: 684 MB in 2.00 seconds = 342.08 MB/sec Timing buffered disk reads: 94 MB in 3.05 seconds = 30.80 MB/sec root@orangepizero:~# In this case, sda1 is a Lexar 32GB memory stick and sda2 is the WD Blue.
 
Then, the raw speed on the hard disk it is good enough for many purposes.
 
NOTICE: When attaching a USB memory stick on the USB port next to the SATA connector, the SATA disk it is expelled in some way (remains mounted but with i/o errors).  This must be the multiplexed ports that was previously indicated in this post.  Then, I imagine (still doesn't have one of them to test), that the msata will disable the "other" USB port on the NAS card (or the USB will disable the msata devices).  So, be careful when using these ports if there are sata devices connected to the NAS card.
 
A final "initial" test ... to copy with scp from a Mac Mini through ethernet a big file.
 
The average speed it is 10 MB/s this is 80 Mbps (when reducing the ssh and operating system overhead, it is not so bad) .  However, it is clear that the network it is a real bottleneck when observing the raw sata speed.
 
In this case, and with a regular OPIZ - H2+,512MB device, the speed it is good enough for not so demanding backups, some media files and other usages that have a good behavior on 100 Mbps.  OR ... when the OPIZ perform the tasks on the hard disks, as with databases when the 100 mbps it is not in the accessing equation.
 
When I have a msata at hand I will include more numbers.
 

Sure have at it. or hack up a current build.
 
 https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
I have mine running, not stable yet but working on it, no working Bluetooth yet but the HDMI and wi-fi are working.
 

Anyone ever dealt with OpenMediaVault (OMV) on SBC? Great piece of software but pretty slow, right? One of the many reasons why that happened are outdated crappy kernels and bad settings. I looked at an OMV image for A20 based boards like Banana Pi Pro recently, ended up here http://simplenas.com/download/bananas-simple-system and simply thought: Are you kidding me? Your stable release is based on horribly outdated Debian Wheezy, a kernel 3.4.something and a 2.x OMV release?! What a mess...
 
Igor had an OMV install routine since a long time in his Debian-micro-home-server post-processing script but since an Armbian user evaluated using Armbian's build system to generate OMV images we thought... why not integrating it in Armbian?
 
We started yesterday to prepare all kernels for the Ethernet equipped boards to meet the OMV requirements (just Quota/ACL/NFS stuff) and then played around with an installation routine that can be used from our image customization script to generate OMV images without the need to tamper with them manually later (one of Armbian's design goals). A first preview is now available. All that's needed to create a fresh OMV image from scratch is checking out Armbian build system as outlined in the docs and then use the new customize-image.sh.template as userpatches/customize-image.sh, uncomment the InstallOpenMediaVault line and then create an Debian Jessie Armbian image that will be a full OMV 3 release afterwards.
 
This will take some time but then you have an OS image that can be booted on your device of choice, needs 2-3 minutes for housekeeping (finishing the installation -- network connection required!), reboots and will then be accessible through http://openmediavault.local (if your router's DHCP server is not broken then http://openmediavault will also work). No need to use any smelly OMV images you find in dark corners of the Internet. Just create one yourself if needed or ping your hardware vendor of choice to look into the possibilities he gets when relying on a solid foundation for creating OS images.
 
Quick performance test with the beefiest device we currently support (Solid-Run's Clearfog Pro):

 
86/98 MB/s (write/read) over a wired connection isn't that bad but with other/slower devices we've seen that there's some room for improvement. I will join openmediavault forum soon to discuss stuff there. Especially that Armbian's cpufreq scaling settings get overwritten (/etc/defaults/cpufrequtils) is a bad thing since the settings OMV uses are ok for x86 boxes but not for those small SBC.
 
All quick tests looked good. I tried hard to destroy configurations on OrangePi Plus 2E, Banana Pi Pro, Clearfog Pro and Pine64+... but to no avail. Even nasty things like creating btrfs stripes on the command line (USB3+SATA with kernel 4.10) and then importing into OMV worked flawlessly, Armbian's nand-sata-install mechanism executed while OMV running to transfer the installation to a SATA disk worked and even downgrading the above btrfs stripe to 4.4.59 and moving the USB3 connected disk out of its enclosure and behind an ASM1062 PCIe SATA controller worked flawlessly (though performance sucks for whatever reasons). I'm pretty impressed by OMV
 
No need to fiddle around with the command line, everything can be configured through a browser... nice. This is how the interface looks like:

 

Sure can you put NEO 2 onto that board, it's just a different front panel that's needed since for whatever reasons the Ethernet jack on NEO 2 has been moved by a few mm:

The enclosure is even large enough to add a 2nd 2.5" disk so maybe they come up with a different front panel, 2 better USB-to-SATA bridges, 2nd PCB to mount 2nd disk and sell this as 'NAS Box Plus' or something like that. The power design already relying on external 12V could be an indication.
 
Anyway if you want to use a NEO 2 with that box it's time for some 3D printing. And I still hope FriendlyELEC replaces the JMicron bridge with an UASP capable variant since users can add Gigabit Ethernet easily to the normal NEO too by spending another $7 for a simple RTL8153 dongle (performance numbers and information here: https://forum.armbian.com/index.php?/topic/1440-h3-devices-as-nas/)
 

In the meantime FriendlyELEC provides something similar that is also much worse unfortunately:

 
It's an Expansion Board for their NEOs with DC-DC converter and an enclosure. Looks nice but a few details are awful:
According to their wiki page the USB-to-SATA bridge used is a JMicron JM20329 (designed for USB2, therefore lacking UAS capabilities. Insane when you think about that Allwinner SoCs with mainline kernel can make use of UAS even on USB2 ports. A JMicron JMS567 or JMS578 would've been a way better choice) This enclosure would've be the perfect choice to make use of NEO's design. Due to the SoC placement the enclosure could dissipate the heat to the outside by putting a simple thermal pad between SoC and enclosure. Putting a heatsink on NEO and both into an enclosure looks like a joke. On their product page (here or look at the picture above) you see that they talk about H3. Nasty since the H3 based NEO has only Fast Ethernet so it's a pretty bad choice for a NAS. The only NEO suitable for this use case fitting in that enclosure would be H5 based NEO 2. But on the other hand: if you're already bottlenecked by ultra slow network the crappy USB-to-SATA bridge doesn't matter any more. FriendlyELEC provides an OMV OS image ('OpenMediaVault' claims to 'make NAS easy', everytime I tried it performance was horribly low since the necessary parameter tuning hasn't been done -- I hope FriendlyELEC looked into this). This OS image is based on kernel 3.4.39! Are you kidding me? Why not mainline kernel for this? There's not a single reason to use a smelly Android kernel with this use case (no display and no audio) and especially not that outdated/unpatched 3.4.39 when there's a community patched 3.4.113 also available. I'm sure this thing will sell even if it will perform badly. And of course it's better than any Raspberry Pi based NAS but it's really sad that FriendlyELEC starts to target a clueless audience. If there would be a better USB-to-SATA bridge inside this thing combined with NEO 2 running mainline kernel and a custom OMV build that sets parameters correctly would make a great low-end NAS. Unfortunately we're talking about something different here
 
Screenshot showing kernel version used on their OMV build:
 

Yes, I've been messing with the device tree.  It hasn't been going well...  (Learning by doing has disadvantages)

As part of this I discovered that (64-bit kernel and userland for RPi 3 that should now also be useable on RPi 2 since newer models also use 64-bit BCM2387). And just for fun I will play around with this and maybe even publish a recipe how to build Armbian for RPi 3.
 
But I really really hope Armbian will never officially support Raspberries since this would be the project's dead (doing development for a platform where a mythical Foundation controls hardware's behaviour through something they euphemistically call 'firmware' we can't alter and dealing with an even larger userbase not caring about anything that's important -- if you buy a Raspberry you do it for a reason. The hardware is totally lame so there's other factors that attract people: and that's free support AKA large community besides the fairy tales a Foundation tells. Please leave this stuff where it belongs to: over at https://www.raspberrypi.org/community/)

I actually tested on Opi PC+ with 4.10.x but it was crashing all the time. I didn't investigate why, while on XU4 it was working. Linux i386 applications were working good while apps under Wine also, but they had some strange refresh. Usable, but still need some work. 

I started to talk with Eltech folks to see if something can be done to ensure better support on Allwinner boards.

You need to buy an Eltechs license I think this type: Eltechs ExaGear Desktop for ARMv7 devices and after installing ExaGear intall inside WINE and inside of Wine the Windows software.
I do some test https://raspberryparatorpes.net/instalacion/probando-exagear-emulador-x86-sobre-arm/
but for me is only usable under ODROID-U3 quad core 2GB RAM and eMMC memory.

BTRFS is enabled only on kernels 4.4 and higher. You can recompile this kernel with BTRFS support, but dealing with any issues, instability and possible incompatibilities with such an old version is up to you.

WTF? There are both H3 and H5 based Zero Plus 2 on sale by Xunlong:
https://www.aliexpress.com/item/Orange-Pi-Zero-Plus-2-H3-Quad-core-Bluetooth-mini-PC-Beyond-Raspberry-Pi-2-Wholesale/32799908030.html
https://www.aliexpress.com/item/Orange-Pi-Zero-Plus-2-H5-Quad-core-Bluetooth-mini-PC-Beyond-Raspberry-Pi-2-Wholesale/32801249806.html
 

Ahem, yes. I agree. I've to admit that I've not decided whether the same name for both boards is just worse or the H5 variant now being called 'Zero Plus Ultra 2' could even be worse. At least the whole naming scheme is already f*cked up to the max  

When adding any thing in /etc/rc.local, you need to make sure it done as a subprocess, not block /etc/rc.local from exiting.
So, you should call your script similar to :
 
nohup /usr/bin/python /root/hw_shutdown.py &