Werner

I always freeze firmware updates when using custom build kernel images on my boards to avoid issues like this.

Merged !

That should be pretty easy to fix by commenting or erasing the duplicate in our patch.
I will look at it ...
 
EDIT: removal of guilty patches is now done !
https://github.com/armbian/build/commit/b53556a5f1ada29169d08b6a106a01f87d763774

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 ... 

Maybe simply a rare bad luck, because I personally own more than 10x OPis, and all of them are working great ...

Looks great@igor!

If you're in the states and interested in selling your Helios4, DM me.

Tested on forgotten boards in first AllWinner's garden Tour : nanopiduo2, nanopineo2, nanopim1plus2 and bananapim2plus ...

Many cheap NAS solutions uses virtually the same hardware and face the same limitation.
https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/What_kind_of_CPU_does_my_NAS_have
 
You need to invest more to get rid of this.
 

My NAS has no RAID. System is on SD card, data is rsynced to another hardware. If HDD died, its replaced and rsynced from backup. Speeding up with RAID0? Nonsense.

Great Job @martinayotte !
I did a new compile with 5.3 - and no exception anymore AND restart does work
(also while using the NAS-Hat for the OPi Zero on the OPi R1  )
login as: root root@192.168.6.101's password: ___ ____ _ ____ _ / _ \| _ \(_) | _ \/ | | | | | |_) | | | |_) | | | |_| | __/| | | _ <| | \___/|_| |_| |_| \_\_| Welcome to Debian Buster with Armbian Linux 5.3.0-rc3-sunxi package bsp-kernel[5.94] u-boot[5.94] dtb[5.94] firmware[5.94] config[5.94] System load: 0.72 0.26 0.09 Up time: 1 min Memory usage: 32 % of 238MB IP: 192.168.6.101 CPU temp: 46°C Usage of /: 7% of 15G Last login: Fri Aug 16 23:42:39 2019 from 192.168.6.17 root@opi-r1(192.168.6.101):~#  

Thanks ! ... And the WiFi 8189es is now working ...

In my case, I've done the tour of my AllWinner's garden : OPiPC+, OPiOne, OPiZero, OPi+2E, OPiPC2, OPi3, OPiOne+, OPiZero+2, OPiWin, OPiPrime, Pine64 and OlinuxinoA64.

Commit for the 5.3.y switch is now done !
 
https://github.com/armbian/build/commit/a00375179bbc27bac4b39927133578a3f2dae383
 

If you look at the end of "Start looking" thread, the issue found earlier is now fixed !
Switching DEV to 5.3.y will occur soon ...

And in my case it was the network switch:
 
Edimax ES-5500G V3 NOK TP-Link tl-sg105 OK  
Thanks again for your help.

how long did you wait?
what kind of monitor dis you use?
or serial console?
how fast is your sdcard?
what kind of powersupply did you use?

I didn't got any compile error, only one patch rejected, but because already present in 5.3.y.
 
One more thing I found with my OPiPC+ experiment : reboot doesn't restart, it stall at "reaching restart", but U-Boot "restarting" never appears ...
(a bit like the early days of H6, but OPiPC+ is H3 and never got this issue)
 
Now trying again with 5.2.6 to figure out when bugs has been introduced ...
 
EDIT: 5.2.6 still look good ...
 
EDIT2: Same behaviours with OPiPlus2E 5.3.0-rc3 image ...
 
EDIT3: Doing an OPiZeroPlus2-H5 images : No Wifi problem, and since no crash, "reboot" work properly, so, maybe related ...

I added OPi 3 Buster image as well as kernel debs to my builds and will be available tomorrow following the link mentioned in my signature below.

For me, it is only "naming convention" ... So, I will continue to work on "unstable" images ...

I made typo  We are at 5.2.5 ...

Fixed on Buster and Disco with apt update / upgrade.

I do have an OPiZeroPlus2-H5, but they're so much more expensive, and I have to pay import duties and handling

See conversation in this commit for background
 
The current default, Next, Dev naming convention for the kernel source trees is confusing, and a bit inconsistent.   I think it's time to rename them and provide clear definitions of what they are supposed to provide.
 
I'll start with some ideas here:

Vendor 
 
This Kernel is currently called Default .  The Vendor kernel would be the BSP-derived kernel or vendor maintained kernel.  Typically there for basic functionality early in a boards life.  Armbian can supply patches for these kernels
 
LTS

This kernel is currently called Next.   The LTS kernel would follow a LTS version of mainline or fork.  Ex: 4.19 of Megous's branch for orangepi, mainline:4.19 for espressobin.   This should be our flagship kernel and the only one we "support" for end users.  Armbian can supply patches for these kernels
 
Unstable
 
This kernel is currently called Dev.  The Unstable kernel would follow a recent branch or fork of a kernel.  Armbian can supply patches for these kernels.
 
Mainline
 
This is new.  It would follow mainline:master.  Its purpose is to provide a 100% mainline experience when practical.  No patches will be supplied by Armbian.

Odd. Seems like the debs are behind.
 
You may upgrade to dev branch, however there will not be any official support anymore.Though as for my experience I never had issues using dev on Allwinner H3 SoC
 
If you do not want to do that there are a few options:
- Wait until someone fixes the debs
- Go to https://github.com/armbian/build, clone the script and create your own packages
- Go to https://laet.pw/index.php/s/M2eXJKll5sdnlBN and grab the needed packages as I had boredom and built/uploaded a few packages today and maybe I'll even update this share from time to time.
 
I'd recommend option 1 as it is the safest. Never trust unofficial sources.

It's normal that you get error regarding network "wait-online" here if you are not online. Attached network where your DHCP server is operational and do some tests ...