Igor

Graphics driver is here for some time, first a simple one, now DRM, but it is still under development. If you mean video acceleration, then its what @gnasch pointed out. BTW. HDMI out is usually disabled on board that doesn't have it.

armbianmonitor -u for a start would really help in this case. USB ID will tell what driver to use.

eMMC support was recently added to this kernel and that could trigger this problem. Not sure ATM. When reporting a problem it saves time if people add their full logs, preferably with armbianmonitor -u .Sometimes a quick scan can already provide an answer.

Is this problem related to specific kernel, 4.4.y / 4.14.y?

This is far from kernel hacking or any serious involvement in electronics - it is only a serial console, 3 wires connected to board and USB to your desktop computer. This basic (debug) tool is sometimes the only way to proceed on boards without HDMI and a network. "Normal" users do accept advice and we just try to help them the best way we know.

Broken network or nothing at all?

Well, then setting $KERNELBRANCH="tag:v4.14.16" in userspace/lib.config might temporally solve this issue?

Unfortunately, Orangepi Zero wireless (check our frustration with forum search) is half broken and there is nothing to do about. We lost hope that this crappy chip will ever be fully usable. Stay away from wireless chip labeled XR819. Use some external USB or any other board but beware none is capable of handling many clients.

It's possible that some patches are obsolete/broken. Can you provide a patching log? You can find it in output/debug folder

Not necessarily. Did you check if there is an error before that? Build script end-user support exists if you don't touch the build script - except in user configurable areas. I don't know whether we have a problem or you made one.

Probably headers install script patch is not the correct one. It needs to be investigated closely. We don't provide headers package by default since some time and if they are default enabled, this is by mistake. If you don't need them, remove them and update should go with a normal speed.

Remove or commend hwaddress line in /etc/network/interfaces

Those "nightly" are automated builds, currently, on hold since we know its pointless to make them. Absolutely no idea if those old ones boot at all. They are made for developers and those who wanna try how far things are ...

Nope, unknown to this moment. Can you try to get some logs? I assume you are running kernel 4.4.y?

Thanks. We are using those sources: https://github.com/aircrack-ng/rtl8812au ... check if its already fixed, then we can bring them into the kernel and push an update.

This board at this stage is probably not the best for absolute beginners. You will only find yourself frustrated. Start your explorations with previous versions (preferable H3 Orangepi PC+), which are decently supported with Linux, Openelec, Android, Retrogaming, ... And here we are mainly - if not strictly - focused on (Debian like) Linux experience. Android or proprietary Phoenix tools are mainly out of this interest zone. But anyway, welcome for trying things and not being an absolute beginner anymore

I haven't noticed anything like that but this doesn't mean it is not present. There is only one way - to test closely but I can do that fastest once next week. Odroid kernel doesn't have support for 8814au either IIRC, only 8812au.

Thanks. Added, let's see.

Ubuntu is Debian based, but the main difference is packages selection and their versions. Since we also define the package base, most of the packages are the same but they are certainly not the same version. This means certain application might not work out of the box and you need to solve dependencies on your own. This can be simple or a true nightmare. In this case, it's better to start with a proper base, whether Ubuntu or Debian. One good example is OMV - it does not work at all on Ubuntu - at least not out of the box. Stable version requires Debian Jessie, while current development is based on Stretch. For a board, which might be used as OMV (Helios4), we provide both, Jessie and Stretch and it's up to the user to decide which OMV version he will go for. In the x86 world, a change between releases/distribution is usually also on a kernel branch, while here we don't have this luxury. We have to use what is available and since there is no better working kernel than 3.10.y for this board we simply can't provide Stretch. We could Jessie ... but since we provide a simple and easy to use build tools, this is not that urgent either.

One of the major goals of the project is to achieve universality among big diversity. Which is good. Now, moving more toward IOT use case would be the way to go. IMO a desktop is good enough and doesn't need more attention. At least not from a primary team. If there are folks, who have the intention to tune this up, perhaps even fix some web acceleration within Chromium ... welcome to play around and fix that overbranding mentioned by @zador.blood.stained Perhaps I really went too far with it. People are simply spoiled. The same case is with our "testing group" - only the first time there went through good enough, next time(s) I rather test all images on my own. This is now a serious multi-day task and it's not possible to test all. What happened if testing is not well organized? A lot of time is wasted, critical might completely slip through, frustration and anger build up. Also on the user's side, on those who ware too lazy to help to test. Frustration is usually a good motivator and we should make use of it. How? Be ready to aggressively recruit when releasing an update. Again, this we are a problem - who will take this HR like responsibility? If this is taken over by me or other individual who have not much clue what to do, just more frustration is building up on our side. This way only some problems are discovered. We already have a beta branch which shows us what is going on with a trunk. There are people who are using this and some do report when things broke. Perhaps more systematical approach on the infrastructure which is already there? In any case, we will not find all problems on all boards this way. The idea is marvelous, just how to get it up and rolling? I think we need a moderator/project manager for this section, something like @chwe is doing in this thread. Someone who transforms our ideas and babble into tasks? We are already under heavy load, I tend to be lazy when things jump outside of a primary goal and pessimistic that someone will just take and resolve some task. Let's simply reuse this term and - at the new web - expose this as a non-technical necessity "maintainer wanted" to move from WIP to supported section. On a related issue - yesterday, I received a question from @ebin-deb why we don't move Espressobin among stable and I point him here. Well, there are also some minor technical issues to be solved, but in a technical sense, it is ready.

Opi Prime is crashing for a currently unknown reason. That's why it is still in development/WIP section.

http://ix.io/F4j Mine (8G eMMC) works fine after upgrade from 5.37 (also with the mainline kernel) but I can revert this u-boot back to 5.35 ... We use more or less unchanged u-boot. Please report this incident to Hardkernel as well.

I suggest you to regularly backup your important data, not the whole system.

I also don't have eMMC for K2 but I know that this function is also broken on Odroid C2, which is almost identical to K2. Most eMMC cards don't work ... well, except mine Unfortunately, there is no known quick fix for this problem.

Nightly buildings are disabled since they are broken for A64 at this moment so it's pointless to make them. Use recommended builds at the download page. They are "recommended " for a reason. We don't provide Debian Stretch with older kernel because it lacks needed functionality, while Debian Jessie ... is a bit old and it's better to use an Ubuntu-based image. In any case, there is not any of Ubuntu junk on them. Stable kernel 4.y is months away.