Igor

You will not get commit rights, so you will not be able to break anything  You can try to work on some features which were not be addressed and when you have a working solution, patch, you send it to Github as PR. I am just pointing you to the latest sources, that you will not deal with something that has already been solved.
 

It is true in both cases. On build script branch sunxi-4.18, NEXT was already moved to 4.17.y, while master branch have NEXT on 4.14.y and DEV on 4.17.y or 4.18RC ... it doesn't matter. Just read my post once again

Aha. I am working on an Allwinner patches cleanup. Perhaps you could join? 
https://github.com/armbian/build/tree/sunxi-4.18

I haven't try to build H6 images yet, but I think you need to enable NEXT in board configuration since we only have NEXT kernel, v. 4.17.y ... 4.18.y when it's ready. This whole part will be merged into master when current regressions are solved and when its tested well enough.

Hi:
    thanks a lot for your hint!!
    google "armbianEnv.txt" I learn a lot of things.
    BTW, I can use "extraargs" to add boot parameters now.
    thanks again for your kindly help.
 
 
  

We stopped to deal with this kernel (3.4.y) a long time ago and you will not find many people around that still do something about it. We fixed a ton of issues but it's impossible to fix them all with resources that are around. Fixes that were discovered are usually implemented. That's what our project essentially do.
 
Virtually all devs are working only on a modern kernel, (4.17.y ->), which will soon cover most of the functionality. Actually, when video/3D acceleration is working, these old kernel images are going to be trashed. We keep them solo for multimedia capabilities.
 
This is an old issue which is gone from my head so rather try to do some search for a possible solution.

What about starting with this: https://apt.armbian.com/pool/main/l/linux-source-4.4.120-default-rockchip/

Edit /etc/default/armbian-zram and disable it.

Please switch to nightly (armbian-config), update and repeat the tests. You should be running 4.17.4

Okay, my stress test runs stable for several hours now with 4.17.4 kernel.
Thumbs up!

Recommended:
https://forum.armbian.com/topic/5246-wifi-performance-benchmark-test/?do=findComment&comment=42408

Recommended:
https://forum.armbian.com/topic/5246-wifi-performance-benchmark-test/?do=findComment&comment=42408

Unknown or too complex to explain.
 

If there is USB support and since there is, all of those will and they do work out of the box. Just remember to use USB2 port. USB3 is also not working yet.
 

Ok, thanks, this time I have configured my host and yunohost with a 5.51.180705 nightly Debian GNU/Linux 9 (stretch) 4.17.4-sunxi, it works !
I will use nand-install after have reconfigured my backports...

According to Hardkernel folks, it's stable. Last time I want to make a switch (again) I made a few tests and sometimes I could not boot. 
 
If you know what you are doing is easy. Everything is packed (kernel, dtb, u-boot, root, headers, firmware) and it was explained how to do it manually in case armbian-config way of switching kernels and repositories fails. You can try, but if you fail you are on your own to do some forum searching and fix the problem.

It's getting ready. You can install it from a nightly repository, kernel name DEV.

And updated images with many bugfixes.
 
 

You can.
 
They have been recently reduced down to https://github.com/armbian/build/blob/master/packages/bsp/common/etc/apt/apt.conf.d/02-armbian-periodic#L4-L10 so you might just wait for update.

https://github.com/armbian/build/commit/c63b2129f64a741d71b30bc7bf3bb6ede98de6fb
I attach to last known for now. It's better than having a broken system. I did test and boot Rock64 ... check Renegade and I'll remake the images if it works as well.

Building Renegade....
 
***time goes by***
 
:-( 
[ 58.886742] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1454: inode #16268: comm blueman-applet: reading directory lblock 0 [ 59.661737] EXT4-fs error (device mmcblk1p1): ext4_journal_check_start:56: [ 59.661785] EXT4-fs (mmcblk1p1): Remounting filesystem read-only I don't know what's doing that, this was one I built, let me try the official download, maybe I need to purge my build system again.  ;-)
 
Problem on my end it would seem.  Works good, now to play with it.
 
***installed to/booted from eMMC.***
 
Job well done, lads.

The new image boots successfully! Great job guys, thanks for your work.
 
PS: It shows 4gb RAM for my board, as it should. Let me know if there's anything else you'd like me to check or test and I'll do my best to help.

Restored.

Restored.

Support is not on the x86 level yet in areas such as DKMS. It works on some kernels, but mostly it's broken. You still can compile drivers, since headers are available by default, but auto updating will not work. Each family has it own kernel, maintaining is scattered around,  mainlining is still months to years behind, some kernels are critically old.

8812AU (also 8811AU and 8814AU) NIC is supported by Armbian out of the box, drivers are built into the kernel (except those critically old ones) and we update them, so you don't need to compile anything. With best possible driver.

Says Igor clone #4, apparently.  I couldn't make it into my basement and start an SSH session before he fixed it...  ;-)

Is this still present? This looks like a temporally (upstream) network related bug.
 
Yes. Fixed. Now it is also clear why u-boot was from Rock64 ... I haven't notice error while compiling ... and since u-boot was already present (not cleaned properly) ... it didn't break the compilation. I'll remake it and put to the server.

Is this still present? This looks like a temporally (upstream) network related bug.
 
Yes. Fixed. Now it is also clear why u-boot was from Rock64 ... I haven't notice error while compiling ... and since u-boot was already present (not cleaned properly) ... it didn't break the compilation. I'll remake it and put to the server.