tkaiser

Tried it out this way and then used the usual GPIO sysfs:
root@orangepione:/# echo 354 > /sys/class/gpio/export root@orangepione:/# echo "out" > /sys/class/gpio/gpio354/direction root@orangepione:/# echo 1 > /sys/class/gpio/gpio354/value root@orangepione:/# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash Card Reader Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@orangepione:/# echo 0 > /sys/class/gpio/gpio354/value root@orangepione:/# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Calculating the respective sysfs node is following the mainline rule here (even with legacy kernel): https://linux-sunxi.org/GPIO

And this works surprisingly VERY WELL. My Orange Pi powering a Banana Pi (since there we can measure voltage):
 

 
The Orange Pi is powered through Xunlong's 5V/3A PSU. And this is how it looks wrt voltage on the Banana Pi (the white cable in between is an 20AWG rated MicroUSB cable):
### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 11:38:12: 960MHz 0.18 10% 6% 2% 0% 2% 0% 48.9°C 30.1°C 5.14V 0/6 11:38:13: 960MHz 0.18 17% 15% 2% 0% 0% 0% 48.7°C 29.9°C 5.12V 0/6 11:38:14: 960MHz 0.18 25% 20% 1% 0% 3% 0% 48.4°C 29.7°C 5.15V 0/6 11:38:15: 960MHz 0.18 10% 8% 2% 0% 0% 0% 48.4°C 30.0°C 5.16V 0/6 11:38:16: 528MHz 0.18 22% 19% 2% 0% 0% 0% 48.2°C 29.9°C 5.15V 0/6 11:38:18: 960MHz 0.32 10% 6% 2% 0% 1% 0% 49.4°C 30.7°C 5.07V 0/6 11:38:20: 960MHz 0.32 100% 7% 92% 0% 0% 0% 50.3°C 31.0°C 5.10V 0/6 11:38:21: 960MHz 0.32 75% 7% 68% 0% 0% 0% 49.1°C 30.2°C 5.15V 0/6 11:38:23: 960MHz 0.38 16% 11% 0% 0% 4% 0% 49.0°C 30.0°C 5.16V 0/6 11:38:24: 528MHz 0.38 11% 10% 1% 0% 0% 0% 48.6°C 30.2°C 5.10V 0/6 Starting at 11:38:18 a short stress test had been started in the background. Voltage still at 5.07V which is just... great.
 
Adding a host powered SSD to Banana Pi of course led to an instant poweroff. But on the Orange Pi it was just a simple CLI command to get the Banana restarted (without SSD connected of course!):
echo 0 > /sys/class/gpio/gpio354/value ; sleep 2 ; echo 1 > /sys/class/gpio/gpio354/value  

And this works surprisingly VERY WELL. My Orange Pi powering a Banana Pi (since there we can measure voltage):
 

 
The Orange Pi is powered through Xunlong's 5V/3A PSU. And this is how it looks wrt voltage on the Banana Pi (the white cable in between is an 20AWG rated MicroUSB cable):
### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 11:38:12: 960MHz 0.18 10% 6% 2% 0% 2% 0% 48.9°C 30.1°C 5.14V 0/6 11:38:13: 960MHz 0.18 17% 15% 2% 0% 0% 0% 48.7°C 29.9°C 5.12V 0/6 11:38:14: 960MHz 0.18 25% 20% 1% 0% 3% 0% 48.4°C 29.7°C 5.15V 0/6 11:38:15: 960MHz 0.18 10% 8% 2% 0% 0% 0% 48.4°C 30.0°C 5.16V 0/6 11:38:16: 528MHz 0.18 22% 19% 2% 0% 0% 0% 48.2°C 29.9°C 5.15V 0/6 11:38:18: 960MHz 0.32 10% 6% 2% 0% 1% 0% 49.4°C 30.7°C 5.07V 0/6 11:38:20: 960MHz 0.32 100% 7% 92% 0% 0% 0% 50.3°C 31.0°C 5.10V 0/6 11:38:21: 960MHz 0.32 75% 7% 68% 0% 0% 0% 49.1°C 30.2°C 5.15V 0/6 11:38:23: 960MHz 0.38 16% 11% 0% 0% 4% 0% 49.0°C 30.0°C 5.16V 0/6 11:38:24: 528MHz 0.38 11% 10% 1% 0% 0% 0% 48.6°C 30.2°C 5.10V 0/6 Starting at 11:38:18 a short stress test had been started in the background. Voltage still at 5.07V which is just... great.
 
Adding a host powered SSD to Banana Pi of course led to an instant poweroff. But on the Orange Pi it was just a simple CLI command to get the Banana restarted (without SSD connected of course!):
echo 0 > /sys/class/gpio/gpio354/value ; sleep 2 ; echo 1 > /sys/class/gpio/gpio354/value  

Unfortunately the DRAM cannot even be initialized on this board.
 
Yes, quite prototype ;-)

Interesting, maybe a packaging fix is needed.
 
No idea and won't look into further. Current situation is that most needed bits are part of Armbian repo, everyone can build/improve legacy images and wrt 'full support' we need a wiki page and some copy&paste work (using Beelink X2 mainline stuff it's mostly just that + testing which I can't since not owning the device).
 
Desktop and CLI image as well as 'support package' with individual packages: http://kaiser-edv.de/tmp/NumpU8/
45a44de60feb7b388ad77c456ff58917 Armbian_5.34_Sunvell-r69_Support_Package.tar.gz f3eb7ae54762e37df11a069d4193fddb Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113_desktop.img.xz 44fdbd858437df4c1cfce81f0d92a8a6 Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz (No Debian yet of course since Stretch needs a newer kernel than the smelly Allwinner 3.4)

Well, that was what we observed one year ago on Orange Pi Zero prior to disabling wi-fi powermanagement (it reads off in your and @t.munzer's iwconfig output). Anyway new image finished uploading: http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz
 
In my opinion the fex file is fine now (looking at it not that much from an Armbian perspective but more having users of other projects in mind like H3Droid, RetrOrangePi, Lakka or @jernej's OpenELEC who hopefully can use the fex 1:1). For Armbian we would need mainline kernel/u-boot support contributed by volunteers.

Good, please tell me if an issue appears with this patchset ! I cleaned it up because it was insane !

8811 consumes up to 250mA while 8814 go up to 600mA. AP mode, single 2T2R AC client, close proximity running iperf test. When someone would attach this directly to some old BananaPi board she will shut down almost instantly at wifi power up  Other will have less obvious troubles, while 8811 should be fine on most boards that does not use microUSB powering 

The current image is a "testing" release for that reason.  Also, 4.13 is an "in progress" support situation for the meson-gxl, I'm running 4.14 with the current patchset through some testing to move NEXT to it.

After latest armbian-config updates the following will now also be tweaked if OMV is installed this way:
Disable Armbian's log2ram in favour of OMV's folder2ram Device workaround for Cloudshell 1 (checks presence on USB bus -- for this to work the Cloudshell 1 must be connected when installing OMV!) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working -- for this to work the Cloudshell 2 must be connected when installing OMV!)) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf  
So only remaining difference to the 'dedicated' OMV images is now the following: The dedicated OMV images
set the correct timezone at first boot replace swap entirely with zram limit rootfs resize to 7.3 GB and automatically create a 3rd partition  
BTW: There is currently no OMV uninstall routine and there will most probably never be one. While you could probably succeed with an 'apt purge openmediavault' this is also not recommended since too many leftovers will remain. If for whatever reasons after installing OMV you want to stop using it it's strongly recommended to start over from scratch with a freshly burned new image.

After latest commit on those crappy Bananas and other A20 boards a little bit more underpowering monitoring should be possible when our next major release is out soon. Example output (from a Lime2 with a dying PSU and only protected by a huge battery and AXP209 PMIC any more):
 
### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 21:57:46: 720MHz 0.33 4% 1% 1% 0% 0% 0% 39.6°C 40.3°C 4.44V 0/6 21:57:47: 528MHz 0.33 17% 13% 3% 0% 0% 0% 39.6°C 40.0°C 4.44V 0/6 21:57:47: 528MHz 0.33 18% 13% 5% 0% 0% 0% 39.6°C 40.1°C 4.44V 0/6 21:57:48: 528MHz 0.33 17% 14% 2% 0% 0% 0% 39.3°C 40.1°C 4.34V 0/6 21:57:49: 528MHz 0.33 29% 23% 2% 2% 0% 0% 39.3°C 40.1°C 4.44V 0/6 21:57:50: 960MHz 0.54 4% 1% 1% 0% 0% 0% 39.4°C 41.1°C 4.19V 0/6 21:57:51: 960MHz 0.54 100% 0% 100% 0% 0% 0% 39.4°C 41.9°C 4.19V 0/6 21:57:52: 960MHz 0.54 100% 1% 98% 0% 0% 0% 40.3°C 42.1°C 4.19V 0/6 21:57:53: 960MHz 0.54 94% 2% 92% 0% 0% 0% 40.3°C 41.6°C 4.42V 0/6 21:57:53: 528MHz 0.54 17% 14% 2% 0% 0% 0% 40.3°C 40.8°C 4.41V 0/6 The first 5 lines should show normal/idle behaviour while then a 'stress' task is fired up (as many threads in parallel as CPU cores available) which should show voltage drops on boards with insufficient power cables and PSUs (applies especially to those Micro USB equipped boards but of course can also show PSUs making problems as above -- without battery I would assume this Lime2 would be dead already since a long time)

After latest commit on those crappy Bananas and other A20 boards a little bit more underpowering monitoring should be possible when our next major release is out soon. Example output (from a Lime2 with a dying PSU and only protected by a huge battery and AXP209 PMIC any more):
 
### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 21:57:46: 720MHz 0.33 4% 1% 1% 0% 0% 0% 39.6°C 40.3°C 4.44V 0/6 21:57:47: 528MHz 0.33 17% 13% 3% 0% 0% 0% 39.6°C 40.0°C 4.44V 0/6 21:57:47: 528MHz 0.33 18% 13% 5% 0% 0% 0% 39.6°C 40.1°C 4.44V 0/6 21:57:48: 528MHz 0.33 17% 14% 2% 0% 0% 0% 39.3°C 40.1°C 4.34V 0/6 21:57:49: 528MHz 0.33 29% 23% 2% 2% 0% 0% 39.3°C 40.1°C 4.44V 0/6 21:57:50: 960MHz 0.54 4% 1% 1% 0% 0% 0% 39.4°C 41.1°C 4.19V 0/6 21:57:51: 960MHz 0.54 100% 0% 100% 0% 0% 0% 39.4°C 41.9°C 4.19V 0/6 21:57:52: 960MHz 0.54 100% 1% 98% 0% 0% 0% 40.3°C 42.1°C 4.19V 0/6 21:57:53: 960MHz 0.54 94% 2% 92% 0% 0% 0% 40.3°C 41.6°C 4.42V 0/6 21:57:53: 528MHz 0.54 17% 14% 2% 0% 0% 0% 40.3°C 40.8°C 4.41V 0/6 The first 5 lines should show normal/idle behaviour while then a 'stress' task is fired up (as many threads in parallel as CPU cores available) which should show voltage drops on boards with insufficient power cables and PSUs (applies especially to those Micro USB equipped boards but of course can also show PSUs making problems as above -- without battery I would assume this Lime2 would be dead already since a long time)

Most probably it's the '2 GB DRAM' that sells best. Anyway: fixed VDD_CPUX at 1.2V + powering with Micro USB + no Gigabit Ethernet... I'm already out but shouldn't matter that much since the boards are advertised as Android 7.x devices anyway...

Well, problem has been reported by Hardkernel to them but most probably with wrong description ('We need more than 3 minutes' instead of 'make the bridge behaving SAT compliant everywhere'), TL Lim forwarded JMicron a link I provided and established then a direct contact in parallel. When they got back it seemed they already considered this a bug and not a feature (which could be a valid alternative given drive enclosure manufacturers might prefer sending disks to sleep as soon as possible)
 
You can follow progress here BTW: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?page=4
 

Yep, if you have something like this (from "lspci" output) then inserted SD/MMC cards will be displayed as /dev/mmcblk* and you'll have access to SD/MMC additional partitions, card info in /sys, etc.
08:03.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 08:03.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 08:03.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) The main disadvantage of this is that these controllers need drivers, compared to devices that present themselves as a standard USB mass storage class.
 
Edit: "native" may be not be a correct word in my previous post since this is an internally attached PCI device, the main difference is whether it represents itself as s SD/MMC host controller or a mass storage abstraction, which I'm pretty sure is specific to USB devices.

Or via a native SD/MMC interface on a laptop (tested with SD->microSD->HK eMMC adapter->eMMC setup)

Well, I expect the HC2 (or HC1+ or whatever HC$something will be released by Hardkernel the next time) to be fully software compatible. It will be just another variant using the same SoC and a JMicron USB-to-SATA bridge (maybe just like with their Cloudshell 2 using JMS561 which will then lead to the same issues as today with this Cloudshell thing). The thread title there has a reason  
 
 
No, since all the results of our work are still there (we don't fiddle around manually with OS images but each and every improvement gets commited to the build system so everyone on this planet is enabled to build fresh OMV images from scratch as often as he wants to). It's just that there's currently nothing to improve and it also makes no sense to provide more OMV images since every Debian based Armbian image using kernel 4.x can be transformed into an OMV installation with 'armbian-config --> Software --> Softy --> Install OMV' (takes care about almost all the performance tweaks our OMV images contain).
 
To finalize this a summary what 'Armbian + OMV' exactly means and what the result of this 7 month journey was. It was about identifying problems (both technical and user experience) and developing optimal settings for performance and energy efficiency. And now we're there.
 
So if you want to run OMV on an SBC simply check whether the board is supported by Armbian with a recent kernel and you're almost done. If you want to do yourself a favour then click here on GbE (to avoid boards that are bottlenecked by slow networking) and have in mind that some stuff that looks nice on paper like Allwinner's 'native SATA' performs pretty poor in reality (check SBC storage performance overview)
 
While you basically can turn every SBC Debian Jessie or Stretch OS image into either an OMV 3 or 4 installation the real differences are as follows:
 
1) Armbian as base:
we care about kernel support, providing for all relevant platforms pretty recent kernel versions that enable all the features needed by OMV. Difference to other distros or OS images: they often use horribly outdated kernels that lack features needed for OMV working properly (please compare with the OMV related kernel config changes) our OS images contain several performance and/or consumption tweaks, eg. we optimize IO scheduler based on type of storage, we take care about IRQ affinity (on almost all other SBC distros all interrupts are processed on the first CPU core which will result in lower performance) and optimized cpufreq governor settings (allowing the board to idle at minimal consumption but switching to highest performance immediately if needed) We try to use modern protocols, eg. enabling 'USB Attached SCSI' (UAS) where possible while taking care also of broken USB enclosures that get blacklisted automatically. UAS allows for higher USB storage performance with less CPU utilization at the same time. Armbian contains powerful support tools that allow to remotely diagnose problems very easily (only problem: here in the forum we play mind-readers instead of asking for armbianmonitor output all the time) 2) Armbian's OMV/NAS performance/reliability tweaks:
we use improved Samba settings to increase SMB performance especially on the weaker boards Several file sharing daemons that usually store caches on the rootfs are forced to use RAM instead (heavily increases performance in some areas and also helps with SD cards wearing out too fast) Enabling driver support for the only two USB3 GbE dongles (ASIX AX88179 and the better RealTek RTL8153) so even boards with only Fast Ethernet or without Ethernet can be used as NAS with those dongles 3) Armbian's OMV integration tweaks:
we take care that we set in /etc/default/openmediavault three variables that heavily influence board performance once a user clicks around in OMV's 'Power Management' settings. Without this tweak otherwise OMV defines 'powersave' cpufreq governor which is totally fine on x86 systems but can result in a horrible performance decrease on ARM boards with kernels that then remain all the time on the lowest possible CPU frequency (on some systems like ODROID-XU4 or HC1 this can make a difference of 200 MHz vs. 2 GHz!) we install and enable OMV's flashmemory plugin by default to reduce wear on the SD card and to speed certain things up. WIthout this plugin OMV installations running off SD cards or eMMC might pretty fast fail due to flash media already worn out (way higher write amplification without the plugin will lead to your storage media dying much faster) All these 9 tweaks above make the difference and are responsible for such an 'Armbian OMV' consuming less energy while performing a lot better than distros that ignore all of this. I tested the last months a lot also with other OS images where OMV has been installed without any tweaks and Armbian's way was always way faster (biggest difference on ODROID-XU4 where I tested with OS images that showed not even 50% of our performance).
 
That being said it's really as easy as: Choose a sufficient board (GbE, fast storage) supported by Armbian's next branch (so kernel version recent enough for all features to work), choose either Jessie (for OMV 3) or Stretch (OMV 4) and call armbian-config to let OMV be installed (few minutes on a fast SD card, if you have to wait ages it's highly recommended to throw the SD card away and start over from here).
 
Just as a reference: the dedicated OMV images I generated the last half year do include another bunch of minor tweaks compared to installing OMV with armbian-config:
Disable Armbian's log2ram in favour of OMV's folder2ram Automatically setting the correct timezone at first boot based on geo location (IP address) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working) Device workaround for buggy Cloudshell 1 (checks presence on USB bus) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf Replacing swap entirely with zram
Limit rootfs resize to 7.3 GB and automatically creating a 3rd partition using the remaining capacity that only needs to be formatted manually and can then be used as a data share
All tweaks can be studied here and by using this script as customize-image.sh you can still build fully optimized OMV images for every board Armbian supports with a next kernel branch.
 
And now may I ask a moderator to lock this thread from now on so new issues will be discussed separately? Thank you!

Well, I expect the HC2 (or HC1+ or whatever HC$something will be released by Hardkernel the next time) to be fully software compatible. It will be just another variant using the same SoC and a JMicron USB-to-SATA bridge (maybe just like with their Cloudshell 2 using JMS561 which will then lead to the same issues as today with this Cloudshell thing). The thread title there has a reason  
 
 
No, since all the results of our work are still there (we don't fiddle around manually with OS images but each and every improvement gets commited to the build system so everyone on this planet is enabled to build fresh OMV images from scratch as often as he wants to). It's just that there's currently nothing to improve and it also makes no sense to provide more OMV images since every Debian based Armbian image using kernel 4.x can be transformed into an OMV installation with 'armbian-config --> Software --> Softy --> Install OMV' (takes care about almost all the performance tweaks our OMV images contain).
 
To finalize this a summary what 'Armbian + OMV' exactly means and what the result of this 7 month journey was. It was about identifying problems (both technical and user experience) and developing optimal settings for performance and energy efficiency. And now we're there.
 
So if you want to run OMV on an SBC simply check whether the board is supported by Armbian with a recent kernel and you're almost done. If you want to do yourself a favour then click here on GbE (to avoid boards that are bottlenecked by slow networking) and have in mind that some stuff that looks nice on paper like Allwinner's 'native SATA' performs pretty poor in reality (check SBC storage performance overview)
 
While you basically can turn every SBC Debian Jessie or Stretch OS image into either an OMV 3 or 4 installation the real differences are as follows:
 
1) Armbian as base:
we care about kernel support, providing for all relevant platforms pretty recent kernel versions that enable all the features needed by OMV. Difference to other distros or OS images: they often use horribly outdated kernels that lack features needed for OMV working properly (please compare with the OMV related kernel config changes) our OS images contain several performance and/or consumption tweaks, eg. we optimize IO scheduler based on type of storage, we take care about IRQ affinity (on almost all other SBC distros all interrupts are processed on the first CPU core which will result in lower performance) and optimized cpufreq governor settings (allowing the board to idle at minimal consumption but switching to highest performance immediately if needed) We try to use modern protocols, eg. enabling 'USB Attached SCSI' (UAS) where possible while taking care also of broken USB enclosures that get blacklisted automatically. UAS allows for higher USB storage performance with less CPU utilization at the same time. Armbian contains powerful support tools that allow to remotely diagnose problems very easily (only problem: here in the forum we play mind-readers instead of asking for armbianmonitor output all the time) 2) Armbian's OMV/NAS performance/reliability tweaks:
we use improved Samba settings to increase SMB performance especially on the weaker boards Several file sharing daemons that usually store caches on the rootfs are forced to use RAM instead (heavily increases performance in some areas and also helps with SD cards wearing out too fast) Enabling driver support for the only two USB3 GbE dongles (ASIX AX88179 and the better RealTek RTL8153) so even boards with only Fast Ethernet or without Ethernet can be used as NAS with those dongles 3) Armbian's OMV integration tweaks:
we take care that we set in /etc/default/openmediavault three variables that heavily influence board performance once a user clicks around in OMV's 'Power Management' settings. Without this tweak otherwise OMV defines 'powersave' cpufreq governor which is totally fine on x86 systems but can result in a horrible performance decrease on ARM boards with kernels that then remain all the time on the lowest possible CPU frequency (on some systems like ODROID-XU4 or HC1 this can make a difference of 200 MHz vs. 2 GHz!) we install and enable OMV's flashmemory plugin by default to reduce wear on the SD card and to speed certain things up. WIthout this plugin OMV installations running off SD cards or eMMC might pretty fast fail due to flash media already worn out (way higher write amplification without the plugin will lead to your storage media dying much faster) All these 9 tweaks above make the difference and are responsible for such an 'Armbian OMV' consuming less energy while performing a lot better than distros that ignore all of this. I tested the last months a lot also with other OS images where OMV has been installed without any tweaks and Armbian's way was always way faster (biggest difference on ODROID-XU4 where I tested with OS images that showed not even 50% of our performance).
 
That being said it's really as easy as: Choose a sufficient board (GbE, fast storage) supported by Armbian's next branch (so kernel version recent enough for all features to work), choose either Jessie (for OMV 3) or Stretch (OMV 4) and call armbian-config to let OMV be installed (few minutes on a fast SD card, if you have to wait ages it's highly recommended to throw the SD card away and start over from here).
 
Just as a reference: the dedicated OMV images I generated the last half year do include another bunch of minor tweaks compared to installing OMV with armbian-config:
Disable Armbian's log2ram in favour of OMV's folder2ram Automatically setting the correct timezone at first boot based on geo location (IP address) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working) Device workaround for buggy Cloudshell 1 (checks presence on USB bus) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf Replacing swap entirely with zram
Limit rootfs resize to 7.3 GB and automatically creating a 3rd partition using the remaining capacity that only needs to be formatted manually and can then be used as a data share
All tweaks can be studied here and by using this script as customize-image.sh you can still build fully optimized OMV images for every board Armbian supports with a next kernel branch.
 
And now may I ask a moderator to lock this thread from now on so new issues will be discussed separately? Thank you!

Armbian implements some basic 'system logging' at every startup and shutdown and contains a little utility to provide this collected information combined with some more useful debug info from user installations. All that's needed is executing 'sudo armbianmonitor -u' (or armbian-config --> Software --> Diagnostics) and then all this support related information is uploaded to an online pasteboard service automagically (see example output) 
 

 
How to interpret this wall of text? The output is best read from bottom to top since the most important information is collected during upload:
 
At the bottom /proc/interrupts contents to check for IRQ affinity problems (interrupt collissions on some CPU cores negatively affecting performance) Then last 250 lines dmesg output are included. Here you might find important information wrt the last (kernel) events that happened on the machine uptime output including average load statistics (1, 5 and 15 min) free output telling how much physical memory is available and how much swap and/or zram is used (you need to look directly above whether zram is active or not to interpret the 'Swap:' line) vmstat output contains virtual memory usage information since last reboot iostat output contains the same but allows for a 'per device' view since all devices are listed with individual statistics (so it's easy to spot IO bottlenecks by looking at these numbers and also looking at %iowait value) 'Current system health' displays what the system is actually doing while uploading the debug log (on systems where DC-IN monitoring is available also allowing for underpowering diagnosis -- if you read here numbers below 5.0V stop reading the log and tell the user to fix his underpowering issues first) In case the installation has been moved from SD card to other storage nand-sata-install.log will be included in the output 'Loaded modules' allow to look for module related problems If it's an Allwinner board running legacy kernel the whole script.bin contents are included 'Installed packages' shows version numbers of relevant Armbian packages 'Group membership of' should list all groups the user is member of. If this line is missing ignore the whole contents and ask the user to re-submit debug info, this time doing it correctly not as root but using 'sudo armbianmonitor -u' (group memberships are important to understand certain problems, eg. users not being member of audio group won't have success getting noise out of their devices) If the board is PCIe capable list of attached PCIe devices is included The lsusb output lists all connected USB devices and also information about speed (12M, 480M, 5000M) and protocol/connection details (mass-storage vs uas for example) If the user installed the lshw utility and verbosity is set to 4 or above in /boot/armbianEnv.txt some more disk related information will be included  
Important: The debug output also contains all collected support files that follow this naming scheme: /tmp/armbianmonitor_checks_* -- so if a user complains about 'transmission so slow' or 'latest files are always missing' ask him to run 'armbianmonitor -c /path/to/torrent-storage' and afterwards 'sudo armbianmonitor -u' without a reboot in between since then the checking results will also be contained.
 
Everything above of this information at the output's bottom is result of regular logging at startup and shutdown (the contents of /var/log/armhwinfo.log). 
 
At startup the following items are logged: dmesg output, /etc/armbian-release and /boot/armbianEnv.txt contents, lsusb and lscpu output, /proc/cpuinfo and /proc/meminfo contents, network interface information, available partitions and filesystems, on Allwinner boards where /boot/script.bin points to, some metadata information for all MMC media connected to the host (eg. SD card and/or eMMC) and some system health information.
 
At shutdown iostat, vmstat and free output are added to /var/log/armhwinfo.log as well as the last 100 lines from dmesg output. If these '### shutdown' entries are missing after reboots the system crashed while shutting down.

Well, I expect the HC2 (or HC1+ or whatever HC$something will be released by Hardkernel the next time) to be fully software compatible. It will be just another variant using the same SoC and a JMicron USB-to-SATA bridge (maybe just like with their Cloudshell 2 using JMS561 which will then lead to the same issues as today with this Cloudshell thing). The thread title there has a reason  
 
 
No, since all the results of our work are still there (we don't fiddle around manually with OS images but each and every improvement gets commited to the build system so everyone on this planet is enabled to build fresh OMV images from scratch as often as he wants to). It's just that there's currently nothing to improve and it also makes no sense to provide more OMV images since every Debian based Armbian image using kernel 4.x can be transformed into an OMV installation with 'armbian-config --> Software --> Softy --> Install OMV' (takes care about almost all the performance tweaks our OMV images contain).
 
To finalize this a summary what 'Armbian + OMV' exactly means and what the result of this 7 month journey was. It was about identifying problems (both technical and user experience) and developing optimal settings for performance and energy efficiency. And now we're there.
 
So if you want to run OMV on an SBC simply check whether the board is supported by Armbian with a recent kernel and you're almost done. If you want to do yourself a favour then click here on GbE (to avoid boards that are bottlenecked by slow networking) and have in mind that some stuff that looks nice on paper like Allwinner's 'native SATA' performs pretty poor in reality (check SBC storage performance overview)
 
While you basically can turn every SBC Debian Jessie or Stretch OS image into either an OMV 3 or 4 installation the real differences are as follows:
 
1) Armbian as base:
we care about kernel support, providing for all relevant platforms pretty recent kernel versions that enable all the features needed by OMV. Difference to other distros or OS images: they often use horribly outdated kernels that lack features needed for OMV working properly (please compare with the OMV related kernel config changes) our OS images contain several performance and/or consumption tweaks, eg. we optimize IO scheduler based on type of storage, we take care about IRQ affinity (on almost all other SBC distros all interrupts are processed on the first CPU core which will result in lower performance) and optimized cpufreq governor settings (allowing the board to idle at minimal consumption but switching to highest performance immediately if needed) We try to use modern protocols, eg. enabling 'USB Attached SCSI' (UAS) where possible while taking care also of broken USB enclosures that get blacklisted automatically. UAS allows for higher USB storage performance with less CPU utilization at the same time. Armbian contains powerful support tools that allow to remotely diagnose problems very easily (only problem: here in the forum we play mind-readers instead of asking for armbianmonitor output all the time) 2) Armbian's OMV/NAS performance/reliability tweaks:
we use improved Samba settings to increase SMB performance especially on the weaker boards Several file sharing daemons that usually store caches on the rootfs are forced to use RAM instead (heavily increases performance in some areas and also helps with SD cards wearing out too fast) Enabling driver support for the only two USB3 GbE dongles (ASIX AX88179 and the better RealTek RTL8153) so even boards with only Fast Ethernet or without Ethernet can be used as NAS with those dongles 3) Armbian's OMV integration tweaks:
we take care that we set in /etc/default/openmediavault three variables that heavily influence board performance once a user clicks around in OMV's 'Power Management' settings. Without this tweak otherwise OMV defines 'powersave' cpufreq governor which is totally fine on x86 systems but can result in a horrible performance decrease on ARM boards with kernels that then remain all the time on the lowest possible CPU frequency (on some systems like ODROID-XU4 or HC1 this can make a difference of 200 MHz vs. 2 GHz!) we install and enable OMV's flashmemory plugin by default to reduce wear on the SD card and to speed certain things up. WIthout this plugin OMV installations running off SD cards or eMMC might pretty fast fail due to flash media already worn out (way higher write amplification without the plugin will lead to your storage media dying much faster) All these 9 tweaks above make the difference and are responsible for such an 'Armbian OMV' consuming less energy while performing a lot better than distros that ignore all of this. I tested the last months a lot also with other OS images where OMV has been installed without any tweaks and Armbian's way was always way faster (biggest difference on ODROID-XU4 where I tested with OS images that showed not even 50% of our performance).
 
That being said it's really as easy as: Choose a sufficient board (GbE, fast storage) supported by Armbian's next branch (so kernel version recent enough for all features to work), choose either Jessie (for OMV 3) or Stretch (OMV 4) and call armbian-config to let OMV be installed (few minutes on a fast SD card, if you have to wait ages it's highly recommended to throw the SD card away and start over from here).
 
Just as a reference: the dedicated OMV images I generated the last half year do include another bunch of minor tweaks compared to installing OMV with armbian-config:
Disable Armbian's log2ram in favour of OMV's folder2ram Automatically setting the correct timezone at first boot based on geo location (IP address) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working) Device workaround for buggy Cloudshell 1 (checks presence on USB bus) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf Replacing swap entirely with zram
Limit rootfs resize to 7.3 GB and automatically creating a 3rd partition using the remaining capacity that only needs to be formatted manually and can then be used as a data share
All tweaks can be studied here and by using this script as customize-image.sh you can still build fully optimized OMV images for every board Armbian supports with a next kernel branch.
 
And now may I ask a moderator to lock this thread from now on so new issues will be discussed separately? Thank you!

The proper way to deal with those crappy external Seagate drives is to either create an usbstoragequirks entry in /boot/armbianEnv.txt or let Armbian do this for you (with next gen Armbian images -- new boot script required -- we try to auto-detect these drives and UAS blacklist them automagically but this requires the drive to be connected at boot and at least another reboot in between)

Nah, but let's try another 'joke'. Can you imagine how the lower PCB side of the new small Xunlong H6 boards might look like if checking the size of a mPCIe Marvell SATA controller and OPi One/Lite:

 
(disclaimer: I've really no idea what Xunlong is planning, just a thought since H6 has PCIe so why not trying to expose the interface? Maybe just routing/preparing the 52 pins and not soldering the connector by default?)

Not to me. USB hub by itself is a very light load but it results in a measurable voltage drop on DC IN. And I have a couple of USB hubs that can reboot a microUSB powered RPi if you connect them - most likely because of a filtering capacitor on the input causing a large enough current spike.

I tested this out, I can control those pins.  Is the issue that the SPI driver can show up and smash everything?  And if so, is this possible accidentally, or would it have to be triggered by an unsuspecting user?
 
Side note for @tkaiser I was getting about 160-190 mA consumption (varied widely) on the vendor image, with the nightly Armbian I get about 150.
 
 

Revised and re-tested tutorial with current Armbian OPi PC2 images, removed unneeded kernel compilation section.