Igor

First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU

Summary of diff between development and master + related from armbian-config. I left out some minor changes: - Network manager is now by default except Espressobin which needs systemd network. Ifupdown can still be overridden if one wanted. - upstream patches for many kernels ... - Ubuntu Bionic target (under expert mode, fully functional testing version) - RFC for firstrun config to set IP or connect to Wireless. Using Network manager method now. - switched NEXT to 4.14.y on Odroid XU4 - kernel packaging support for 4.17.y - RK3399 kernel upstream updates (can't produce bootable image yet) - docker support for RK3328 DEV kernel - sign "sha256sum.sha" instead of "armbian.txt" - add missing dependency libpam-google-authenticator to armbian-config - reworked SSHD management, kernels and nightly/stable switching with armbian-config - added upgrade to desktop from armbian-config (only generic desktop) - added CODA module on imx6 and upstream patches. Requirement for video acceleration but ... haven't got it working under mpv - Olinuxino. Enabled USB within atf, sane RAM speed - icon pack moved to our repository. (Note to myself: remove .deb from build script) - created desktop package per release, architecture independent, could be installed on top of any Debian / Ubuntu base - removed old way of making desktop - moving Odroid away from their mainline sources with a patch - added bionic to the beta repository, soon to main - added Z28PRO to the RK3328 kernel source (tested, working everything but wifi) - meson64 default becomes 4.14.y, next 4.16.y, DEV master - sunxi-dev pinned to 4.16.y and u.boot to v2018.03, most of the patches were adjusted - S56818 is breaking. pinned to last known working kernel 4.14.15 - fixed eMMC install on Rock64 - adding eMMC support for Neo and Neo2 to make images usable for Core / Core2 - added Odroid C1 mainline config (DEV, it should boot but it doesn't) - removing GKSU and rework dependencies Those are areas where we should be focusing. Some are important now, some later. I have done many tests but it's impossible to predict and catch everything. Latest changes will show up in tomorrow's beta repository update and those images which are enabled for the nightly remake. No larger moves until testing and the big merge from my side. I haven't checked: - how changes will affect firstrun and armhwinfo - networking in general. I did only a few tests and notice at least one power management set to "on" ... I think on OPI Prime. - haven't made OMV images

https://dl.armbian.com/nanopik2/archive/ Look whatever under 5.42 ... it should work but this board is "work in progress". Random freezing is usually a sign of a bad power supply. Check that first. How do you power the board?

1. See /etc/update-motd.d/ or use armbian-config to enable/disable those items 2. https://www.google.com/search?q=debian+start+on+boot

Always start with the last image but if you need another kernel ... we have older kernels and u-boot packages in packages repository: apt.armbian.com ... use apt-get tool to install the desired version.

Nothing special. I encourage people to create a PR but since this is less work to just add then explaining to people what to do. I would propose to add this to new web page's FAQ, somewhere among medium important questions. Cleaning as https://github.com/rfrht made should be done on all kernels and if there is some request we usually translate it to other kernels ... but sometimes enabling on one might break compilation, while it will work on some other kernel.

The only real difference is that nightly images are (usually) not tested. They are just built from upstream, normally every day ... in reality building can be on hold for a week or more until things, which break the compilation, gets fixed or are removed. And most of the images don't get daily images rebuild, but only packages. This means any existing image, stable or nightly, can be upgraded to the latest nightly. (armbian-config -> switch to nightly) 171217 = 17. December, 2017

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.