Igor

If you get this working, send a PR (to dev and next) and you don't need to worry about  In case board works well, we could also add an image ... we have it for some other CSC targets as well.

Small progress update -
 fresh photo.
 
 

I made an archive/backup when you said down.nu is going to be closed. And also more or less forget about  

16TB is partition/volume limit. Whatever goes below that is fine.
 
You can mount drives separate, but can't join them into one volume that is larger than 16TB. It's 32bit OS/hardware limit.

I think this partially explains
https://github.com/megous/linux/commit/0376281ed8ef09e81dbc6ce72a7b3f7b675962b5#diff-445fc9c5ea648f3611cc61ce04a601ef

Hi, I am using 4 x 2.5 inch disks in the standard Helios4 enclosure. Instead of Laser cutting the smaller enclosure I created a simple 3D printable bracket for it which I'd like to share.
 
For those interested its here:  https://www.katerkamp.de/maker/helios4/helios4-and-diskbracket.xhtml
 
Including FreeCAD source and STL files.
 
Have fun :-)

I help a lot, but can help everyone whenever they want. Your request is also far above contract you have.
 

Perhaps it looks like like a irrational decision, but its not -> crappy and wrong(!) manuals, low quality product and incompetent people have great potential for huge waste of time if you go that path. I have to remind you that dealing with (this shitty) hardware and with you is 99% sponsored from our private pocket. If you have problem me not helping you, read as "I refuse or don't have to pay for dealing with you".
 

  Here, people will gladly help you. Ups, they want money for wasting their time. That's really strange, right?

Its (always) a compromise 
 
The primary reason for this upgrade is to have a better working solution for easy experimenting with things as such: https://forum.armbian.com/topic/11424-playing-with-limamesa-mali-drivers/ 
 
Initial upload repository size will be addressed (recreating/truncating), while for upload limit, there is nothing I can do. On the other hand Github has advantages, like existing user management ... for one user this is not a problem.
 
The bulk of the job surrounding this change is elsewhere - package management RFC - rebuild is done much faster/in parallel, cleaning is more efficient ... 

Its (always) a compromise 
 
The primary reason for this upgrade is to have a better working solution for easy experimenting with things as such: https://forum.armbian.com/topic/11424-playing-with-limamesa-mali-drivers/ 
 
Initial upload repository size will be addressed (recreating/truncating), while for upload limit, there is nothing I can do. On the other hand Github has advantages, like existing user management ... for one user this is not a problem.
 
The bulk of the job surrounding this change is elsewhere - package management RFC - rebuild is done much faster/in parallel, cleaning is more efficient ... 

Updated to 4.4.6.
https://invisioncommunity.com/release-notes/446-r87/

Updated to 4.4.5
https://invisioncommunity.com/release-notes/445-r86/

Cosmetic issues may appear during the procedure and fixing them might take from hours to days.
 
Starting early in the morning, backup late in the evening CET.

Upgrade from v4.3.6 -> 4.4.3

What's new:
https://invisioncommunity.com/release-notes/440-r81/
https://invisioncommunity.com/release-notes/441-r82/
https://invisioncommunity.com/release-notes/442-r83/
https://invisioncommunity.com/release-notes/443-r84/

https://www.armbian.com/get-involved/
 

Those are user land limitations, but what you are looking for is below. HW encoded limitations which are set in the "bios" / u-boot. Ergo. I limit scope of your search, send you to I am sure correct destination, but from here you are on your own to find and change/things. 

I tried booting off sdcard and then immediately installing to eMMC, rebooting, and *then* running upgrades.  Now it reboots ok after doing the upgrade on eMMC instead of the sdcard.  I can't explain this.  I had installed a stretch 5.0.0 nightly a while ago, but it didn't see my NVMe (Samsung 970 EVO).  At some point I was booting off sdcard again because the 4.4 installer can see my SSD, then left it alone a few months.  when I came back I started over with a fresh 4.4 sdcard image and then the above reported sequence happened.

Furthermore, console=serial in armbianEnv.txt seems to work now.  I am perplexed how this could work on eMMC, but not on sdcard.  I dont understand how that can be so, but everything is working.  Thanks greatly for your help!

Upgrade on a Banana Pi bpi-m2+ and on a Solid-Run Clearfog base also works like a charm
 
I had a problem with my iptables rules. Buster changes the system to use nf_tables or so. I had no time yet to look deeper into this. So for whom that needs the iptables rules, you can switch back to iptables.
 
update-alternatives --set iptables /usr/sbin/iptables-legacy  

v5.90 / 7.7.2019
All images were updated. It mainly goes for a bugfix update, cleanup, adding Debian Buster release. Beware that software maturity with Buster is not just there yet (even it was declared stable) and with some applications (like OMV) you will encounter problems. Kernel/BSP wise, Debian Buster is the same, uses Armbian kernel, as our other builds. Most of the builds were briefly tested, but bugs might be hiding somewhere. This is the best what is out there thanks to greater Debian community, those around boards and of course ours which pushes generic Debian/Linux to the sky . Enjoy the summer time.
 
What's new? -> https://docs.armbian.com/Release_Changelog/

For such operation you need some experiences. There are no shortcuts, but perhaps starts this way:
https://forum.armbian.com/search/?q=GT911&fromCSE=1

https://docs.armbian.com/User-Guide_Getting-Started/
 
Try images with kernel 4.9.y https://www.armbian.com/cubox-i/ Those are directly tied to official u-boot/kernel sources.

I just upgraded to nightly and installed linux 5.3, so far it seems to be solved. I even tested with iperf3.

I will try to hack the armbian-config softy modules  

Spent some time to sort out things... not a kernel issue...
 
ended up being that systemctl rc.local.service was exiting based on a bad entry in rc.local that was calling dnsmasq as a systemd resource, and it failed.
 
Since the rc.local.service fails, oled-start doesn't run
 
Don't ask me how dnsmasq service ever got into my rc.local, along with an iptables-restore entry - as I don't recall...
 
Might have been when I was trying to help one of our forum members out with AP mode stuff...
 
I've never been the biggest fan of systemd - it is things like this where one can get nested items that make it hard to troubleshoot. 
 
 

https://docs.armbian.com/User-Guide_Getting-Started/

Added (untested) nightly images:
https://dl.armbian.com/kvim1/