Werner

because new user write into the dev forum instead of  review their own actions and look for a solution.
Because of that there is an own section in the forum:
Board doesn't start
 SD card and PSU issues
Or if you want to read a current posting that goes in that direction.
 
So until you have gathered some basic experience,  supporting others,  you are blocked from writing to the dev forum, but everywhere else is open.
If you are here for a couple months on a regular basis, you will understand.
 

I made several test builds and tests installs on Debian Buster and IMHO it is ready for user level/extended testing. Most interesting for us is that our modifications and things defined in armbian-config remain working. Most of them will, but some will fail ... I did install a desktop over Buster, it works, but haven't done many tests, hostapd works (but it throws out some errors that need to be examined, ...)

Ubuntu Disco is in a similar state. CLI works, desktop upgrade works, ...

How to extend this testing? Shell all nightly images only be Buster/Disco, most popular boards gets a CLI test version? Exotic ones? "Chosen" ones? Shell we unlock building but leave a mark "WIP" or something?

added &mmc2 section into ****nanopi-neo.dts
from folder /usr/src/build/cache/sources/u-boot/v2019.04 run
"git diff arch/arm/dts/sun8i-h3-nanopi-neo.dts > /usr/src/build/patch/kernel/sunxi-dev/my-neo-emmc.patch"
from /usr/src/buid run ./compile.sh
...
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8"
reboot without SD - fault
 
BTW. ***nanopi-neo.dts hasn't &mmc2 section again. Looks like patch wasn't applied. 
 
I've copied .diff file to the same folder as Igor's destination: ./patch/u-boot/u-boot-sunxi
from /usr/src/buid run ./compile.sh
...
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8"
and 
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1p1 bs=1024 seek=8" (I'm not sure but I did it)
 
reboot without SD - SUCCESS!!!
 
Thank you martinayotte&Igor for your support
 
P.S.
last (I hope) doubt....
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8"
this command will copy a .bin file into the root folder on eMMC... how it will be read by system during the load?
no .bin files in SD-card's nor "/boot" folder nor "/ "folder
current configuration: ls /dev | grep mmcblk
mmcblk0
mmcblk0p1
mmcblk1
mmcblk1boot0
mmcblk1boot1
mmcblk1p1
 

Changed posting permission - one need 10 5 posts to post in RK3399 or Allwinner H6 forums.  

Orangepi PC2 is a good board and would be much safer option since support is fairly mature, while (any) H6 still has many glitches and is still under development.

It is not actually provided in any DT nodes ...
I will add it in the following days, directly in main DT, without any needs for overlay.
Then, you will need to take a new nightly image ...

This is not Armbian since there is no Armbian for this board. Only test build which were not done for you, but for experienced developers, which will not request support, but perhaps fix things. Big difference. We can't help you anything with having a good "Armbian" experience at this point. Not possible. Get a board, that is supported.
 
 
This is normal for a hardware where "half" of the missing component is not even developed. Development = thousands of working hours and not something you can download freely from the internet and install. Simple questions, like "how to use wireless" might be easily related with huge time and money costs. Not to mention time lost to clarify this "every day", since there are always people, who never read welcome text on those test images.
 

Send some. A very needed component for development and dealing with "customers"  

Bottom line. If you are not a developer, read and wait, wait until it gets to users level. We are still months away. 

Are you really considering building an madm RAID with USB drives?
Technically it is possible but I doubt you'll get anything but problems with reliability.
It's easier than you may think to compile yourself - check out https://docs.armbian.com/Developer-Guide_Build-Preparation/
If you're looking to 'play' with mdadm as a learning exercise then fine, but if you really value your data I'd suggest you should build a 'proper' raid using an x86 board and good quality SATA drives.
On budget SoC boards I'd just rsync my precious data across several physical drives.
 

Now this is last one - others broken ones were removed + nightly building has been disabled.

Latest one from the download should boot, but upgrade will break it most likely.

Support in modern kernel was made virtually from scratch. There is little in common between 3.4.y and 4.19.y

Strangely, I've put back the original DTB and it still working ...
I will try again with a "virgin" image.
 
EDIT : I took another SDCard, reburned 5.0.10, and this time, although still showing those "cpufreq" error, it booted successfully, although "filesystem resize" took more time than usual ...

Upgrade is complete ... now bug fixing.

As I don't want to undo the work I've done for 5.1.y, I've decided to download https://dl.armbian.com/orangepioneplus/nightly/Armbian_5.83.190502_Orangepioneplus_Debian_stretch_dev_5.0.10.7z instead.
Effectively, it seems broken, stopping/freezing during boot with the following errors :
[ 6.550967] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 912000 KHz [ 6.558474] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 1080000 KHz This must have been introduced between 5.0.7 and 5.0.10 ... I will investigate a bit more ...
 
EDIT : I found something, replacing the 5.0.10 DTB by the one of 5.0.7 allows booting successfully ! ... I will compare them ...

Right ! Every SoC users should have a USB-TTL Serial dongle nearby !
(I've more than 10 of them, leaving them connected on all boards where I do frequent updates)
My OrangePi3 is currently working with 5.1.0-rc4 from eMMC ...

Sure I understand, Igor. I'm not in a hurry for my OPI3, it's a real pleasure to make this board work. If I can help in your work, don't hesitate to tell me. For example, I've found a way to adress GPIO pins withour installing WiringOP/WiringPi library. I use /sys/class/gpio , export, unexport, and so on. I have written a short daemon in C to send "1" to a GPIO Pin to control a fan. I use a fan, a transistor (to trigger the fan), a resistor, a flyback diode to protect the transistor when the fan is stopping, and to make this circuit more fun, I control another GPIO to light a LED when the fan is running!

I love working with my boards, everyday I learn something new!!!
 
 

Why do you ask then?  Its broken beyond repair.

It seems that base packages are different ... I didn't check anything at this stage. Perhaps a diff between stretch and buster packages should be nice to have. From CLI and desktop ... and adjust accordingly. Probably there are some other packages missing.

Ja, sag einfach Bescheid ob es geklappt hat in der Bretagne

- to build engine (EXPERT="yes")
- repository update with the purpose for adding it (armbian-config and armbian-firmware update everywhere)

This time was at least controlled offline  and according to my info, there were no troubles. There will be some further actions - adding redundant this and that - to prevent (unplanned) downtime in the future. 

Thanks!  Time = around 6pm CET.
 
We had two hardware failures before the actual planned upgrade  We are using a proverb for describing such mess "when the devil have children ... " 

The memory controller for the h6 is 32 bits, 4gb may be there but only 3 will ever be usable. Which is why they are being sold as 2gb/3gb options.

certainly just execute:
root@orangepioneplus:~# systemctl disable NetworkManager root@orangepioneplus:~#ip a |grep ether link/ether 00:2d:fd:1e:f1:e1 brd ff:ff:ff:ff:ff:ff # take note of MAC address root@orangepioneplus:~#vi /etc/network/interfaces ## add or update in to /etc/network/interfaces.d/ auto eth0 iface eth0 inet static address 192.168.10.200 netmask 255.255.255.0 gateway 192.168.10.1 dns-nameservers 192.168.10.2 192.168.10.1 hwaddress ether 00:2d:fd:1e:f1:e1 root@orangepioneplus:~# reboot # wait 5 secs and reconnect to IP address set root@orangepioneplus:~# cat /etc/network/interfaces # tada!  
you guys don't even realise how perfect this weekend started,
once again cheers for all your efforts, it is appreciated a lot!

Awesome news. And everyone can still be an old school guy using interfaces file 

I've compiled a new kernel with DWMAC-SUN8I as module, and it seems to be the trick, even no needs to do manual "rmmod", simply "reboot", using NetworkManager on my OPiOnePlus.
I will verify that it still true with "old school /etc/network/interface" , and then I will also confirm that it is working the same way on OPi3.
 
This would means something is wrong in the cleanup when built-in in the kernel ...