Igor

Exactly. It's already problematic - information is scattered around a web page, documentation, Github and forum which is mainly community, self-organized. IMO adding yet another chunk of infrastructure (Wiki) can only make things worse. If we wanted to improve the current situation, we would need to assign a person(s), dedicated editor for keeping documentation well organized. We can dupe docs as they are now and move them to the web page or to another form or engine ... but its a huge task/challenge. We are releasing new webpage, which was quite a challenge, in a few weeks and with it, new features and possibilities are being unleashed. Its also a paradigm change - the current website was a single user renderer directly from build script config. With many dirty scripts and plugins. A future website should be a group, community managed with a simple but powerful backend. Most of the work was done to improve that management, previously controlled with configs. I will give rights to anyone who wants to participate as a board(s) maintainer. In a sense to set facts, collect relevant information, decide which download options should be exposed and adjust things, add warnings, etc. This task is not hard work but helps core crew to find some breath. It should be fun and it comes with some responsibility. More when it's out ... Getting access there or rights for editing the documentation is liberal. Like Wiki. Anyone wants to edit textual data, ping me, you get instant commit access. Back to the topic. I think we should keep those how-to's updated but implement features directly into Armbian. When things are matured and when core developers team finds the time. And then, they become irrelevant for the implementation part but still keep the educational role. For that purpose, it should remain in the right place. Subforum "Research and tutorials" is IMO right spot, it's indexed by the main search engine and it will be linked directly from our new web page. They are important.

You still need to patch u-boot. Well, not anymore: https://github.com/armbian/build/commit/a9bff610645aa671a2ce8ea9bb7fd3c9ecdd1ddd (development branch!)

Nope. Not that familiar with the forum software. If you didn't find the solution on their forums, open a topic there, perhaps you get some hints or help for implementing. I can only do that. It's definitely a cool and useful idea. I usually record an actual video and post it to the YT which is more work.

Those settings are for automated build. You should be able to build Jessie and Xenial. Good. Now read this thread again. Debian Stretch on this old kernel doesn't work properly. Jessie yes, but Jessie is old.

Noted. True, there is no need to hurry but its more convenient to repair things on the way. As a side task. My intention was to bring it to the level, where one can build and test. We are there now. We can build, we have a network, a desktop is up, ... There are small known problems and probably many hidden. Some will be fixed upstream and some can be fixed by people interested to run Bionic ASAP. I will still fix things if I bump into them, but will not hunt them.

RELEASE=jessie,xenial,stretch,bionic

It works. https://github.com/armbian/build/commit/ac9319a62c2a2bf179a80109c49c3e3ca849a53e Now what to do with gksu ... gone from Bionic. Shell we simply add it?

True. I forgot that we are still running 3.10.y there IIRC on a modern kernel 4.16.y we have a broken network on this board.

That is not a problem. Problem is that they are not labeled with warnings enough. Automated nightly images were never designed for end users and they might work or not. If they don't work ... The problem was "fixed" - all nightly images were removed. Once again - you can try to build one from recent sources, but ... boards with A64 are not supported very well at the moment. Debian Stretch with default kernel should work, but you need to build it on your own since it happens that we don't provide it by default.

armbianmonitor -u with the attached USB wifi would be for a start.

That is not true. They - which are exposed on the download page - work. If you need a Debian 9 or any other combination: https://docs.armbian.com/Developer-Guide_Build-Preparation/ Images in the "nightly" folder are made automatically from the development branch (this will be noted better on the upcoming web redesign). We are building them for developers and testers, for people which seek bugs and work hard many months, to provide a system with as fewer troubles as possible. They were never meant for end users and might be completely broken.

Yes. Changes to packaging method upstream. It is getting fixed. Check my last commits to developmebt branch for quick fix. Wrote on mobile

We have to remove this https://insights.ubuntu.com/2017/12/01/ubuntu-bionic-netplan and use network manager/ifconfig

What about staying on a clean, stable and supported base and dealing only with a minor userspace problem? Our Xenial base could probably be upgraded to 17.10 ... never tried but at least this should not break hardware features. 3rd party builds are not a subject of support.

This:

https://github.com/armbian/upload/commit/1a63938c6eeb6226f7ffea46f77ba3629bd45c17 Kernel for Tinker was updated to 4.14.34 apt update & upgrade

Main repository? Recompile rockchip-next from development branch and push up?

Yes. The simplest way is to add eMMC support to Neo image and both boards are covered.

You want to have ethernet in u-boot or in a kernel? Or both?

Our system for creating patches stops right before the compilation starts, but at that moment defconfig was already applied. You need to: 1. Edit this config and proceed that patch is created 2. Copy patch from output/patch/u-boot-sunxi*.patch to userpatches/u-boot/u-boot-sunxi 3. Recompile with this patch included Then it should be applied. Perhaps best to add eMMc support (CONFIG_MMC_SUNXI_SLOT_EXTRA=2) to Nanopi Neo u-boot config and use that image?

Hmm. We had some urgent updates from development branch which is already at 5.42 Splitting master and development branch, in general, brought some confusion and this is a direct consequence. Not that critical but it shell be fixed soon.

Rainer, thank you. Fixed: https://github.com/armbian/build/commit/28feb0269a8f084e23f0760ab5a19ab6b12b174f Will show up in next nightly update.

Worth to add here that we host kernel sources as well. Those are present in a stable repository, while beta we don't since it takes too much space.

You need to edit/add configs in cache/sources/u-boot-source/u-boot-branch/configs/ More precisely, add whatever you need to /configs/nanopi_neo_defconfig ... in theory, you could have there the whole .config, but its not needed. You will need to do this patch in two runs. First, run "compile.sh" with CREATE_PATCHES option, edit this nanopi_neo_defconfig ... save, proceed and a patch to the Neo config will be created. Then run again and eventually put this patch to your userpatches/u-boot/sunxi-u-boot-sunxi ...

Theoretically you could put things together on 4.14.y but not recommended. 4.17.y ... in a few months to get theoretical grounds, then few more to get things operational.