Igor

Huh, you mean none, not even non-nightly build? IIRC it was working for me when I tried ... armbianmonitor -u

This problem is upstream. With Debian and could be related to the fact that Debian Jessie is officially EOL. It can be also just a random network problem. Pine64, until we don't have a stable modern kernel, you can only choose between (kernel 3.10.y) Jessie and Xenial. The best is to go for Xenial since it has more recent package base then Debian Jessie. https://dl.armbian.com/pine64/ If you were using some development builds ... and all modern kernels for A64/H5 are in such state, regressions are possible. There is nothing we can do with the resources we have.

Now repeat the whole thing with most recent kernel 4.17.y/u-boot 2018.05 combo from beta.armbian.com ... armbian-config -> system -> switch to nightly automated build -> reboot

Great! One more thing. Since you switched to beta.armbian.com repository and since this kernel is getting daily updates ... freeze kernel updates. Possible in armbian-config menu ... or manually (apr-mark).

armbian-config -> system -> alternative kernels -> next

If the board is not broken ... one possible explanation is that filesystem gets corrupted due to not perfect SD card/driver combo. But even this is a very long shot. There has been a lot of upstream kernel changes so it is hard to be sure where is the source of your problem. Rock64 is nice, powerful but also a complex board. Software support is not on the same level as simple (and stupid) hardware design from 2009 (Videocore + ARM core(s), single USB2 line: RPi 1,2,3). Despite this, Rock64 works pretty well and I never experienced problems you have.

Try: cd /usr/src/linux-headers-4.17.5-sunxi make scripts and repeat building.

There are many RK3288 boards out there while Amlogic S805 C1 is only one. Support for mainline is in an infant state. It's possible to build Debian Stretch (or whatever) with K4.17.y but serial console only, eMMC doesn't work, the network also doesn't work yet, ... not usable yet, but it can be fixed up in a few months. If there will be enough interest and spare time. You don't need to worry about RK3288. Mainline support is in a very good state, almost perfect. This means support will remain "for decades". He still can make a mainline kernel (NEXT, 4.14.y) which is any way in a better state if you don't need advanced/multimedia features. We provide cross-compilation for many reasons, but the most important is: to make it simple for an end user. Auto-builder uses the same build script with additional parameters to mark build as a daily build. It's also a testing ground to see if things are working. TB should be just fine for the job. IMO is even an overkill for a small server.

Kernel 3.10 is too old for Debian Stretch or Ubuntu Bionic. It might work, but not without many troubles ... that's why we don't support it.

Those old kernels are mostly EOL which means there is little to no help in case of troubles. There are certainly some dongles that work out of the box but there are little people who know that. I don't recall the state of the system/armbian-config on old images. You could at least keep those packages updated since they are kernel irrelevant. I hard about and it looks like 4.17.y -> should be stable again ... it is worth trying and better than idling on that old kernel. Get the latest image with NEXT kernel (4.14.y) and switch to nightly build with armbian-config or manually.

Switch to automated nightly builds and try default and next kernel, skip DEV. They all have matching headers and repeat the process.

That is a very old kernel and I don't recall if we had this at the time and most recent armbian-config, where those features are manipulated with a menu-driven utility. Upgrade to the latest version.

Yes.

I am also sad, but for other reasons. Remember. This is not a professional support service and I need to save our resources to be able to work on things that make us happy. The same you need to do on a legacy kernel: https://github.com/armbian/build/commit/5823d40016d2fd522dba5f75af2ec14bfc6986a3 But implementation might be different and perhaps you will need to adjust patches. Then you need to build and test. One could lose an hour or a day. If you are unable to do this, hire someone. 1 & 2 yes 3 & 4 follow the procedure written at the download page. Flash u-boot with correct numbers. 1200Mhz tells me nothing at this point. Just don't go with higher numbers than what you have now and expect that the board will boot and be stable.

Adding a SERIALCON=ttyMV0 to this config https://github.com/armbian/build/blob/master/config/sources/mvebu64.conf should probably fix this problem. Test (build an image with those changes) and send a pull request.

No. I am not sure we want to waste time with that kernel. Feel free to test and submit a patch. I can't. (correct) U-boot (for your board) should be updated in any case.

That is normal. Aptly 1.3.0 is broken on Bionic and I couldn't find any more elegant solution yet.

I would expect the other way around. Old kernel (3.10.y) images are tested and they should work, while automated build images from latest trunk (4.18. ATM) can work or not ... but they also lack features and can be unstable. They are made for development purposes. To hunt bugs.

Support for A64 boards is not the best but not this bad. Most of the images from the download sections have been tested. I can't double check ATM but I am almost sure the problem is not on our side. Boot bootlogs indicates troubles related to boot media. I would choose some other SD card brand, double check powering, ... https://forum.armbian.com/forum/31-sd-card-and-power-supply/

Not exactly the best way There could be some automated apt process with some purpose in the background. For example, we run index updates (apt update) every 21 days which means usually also at the first boot. This is getting some changes lately ... but on most images, it goes that way. The best tactic is to wait for a minute that index is updated, then proceed with apt get ...

Config is missing on the master branch. Add LIB_TAG="sunxi-4.18" to config-default and repeat the build process.

Start with a last known working and switch kernel to NEXT if you want to follow ... but this information might be changed soon.

We had that, but it was lost during this RFC. Fixed that current solution works again: https://github.com/armbian/build/commit/e78c66b3a91a7627cb502f2dd2ddfcbba470a8b1

apt update & upgrade will also do https://github.com/armbian/upload/commit/553477df85dfdd33810d1536409d62bd3a4cb789 Thanks.

branch sunxi-4.18 (sunxi-4.17 is already deprecated) I know it's confusing since kernel version is still 4.17 at this moment and will remain this way for weeks.