Tido

Yes, this also happens to users (and quite often). When they run the update and as a result, some of the features they used are broken (you have to remove conflicting packages). They have to either write a bug report and wait for a fix, or roll back to previous, compatible versions of packages. When you manually update the system writes, if there are conflicts and the user decides what functions are important to him and how to do (what to remove and what to leave). In an automatic build, you cannot provide all the behaviors and always use the default.
It is possible you that the online repositories used in the build are usually in a stable state (already updated or not yet updated) when you run the build. That is, the time of the build system is well synchronized with the work of updates in network repositories.
 
IMHO I suggest for all versions of images where DE is used to use the standard approach from "adult" systems. The source image must use some kind of login Manager (for example, lightdm). This corresponds to the logic of safe operation and is a common (familiar) option for users moving from PC to ARM. The current state of Armbian and the hardware it runs on has already become quite Mature and capable of working on an equal footing with the PC. If the user wants to make a autologin or use "nodm" - he will do it yourself (good manuals for this is more than enough). In the server options of images, the default should not be any managers of the entrance.
 
In addition. I would put the u-boot Assembly in a separate process, with mandatory testing for the correctness of the assembled version on the intended devices. And only after that place the packages in the repository for Assembly by others or for use by users. U-boot is an important element for the safe use of the device (this is especially true for devices with built-in memory, where it is very difficult to fix not correctly recorded in memory u-boot).

Yeah you can integrate wireguard into the kernel, but you can also use DKMS framework to let it being recompiled each time a new kernel is installed.
Wireguard already comes with a small configuration file for DKMS, just follow a tutorial on how to install and setup DKMS on your machine (which is quite easy, just few steps) and register wireguard module and you're done.

Bumped/Pinned like the others.  If I'm going to be in the trenches on these boards, may as well make it count.  I want to see this, circuitpython, Larry Bank's and sgjava's libraries all in a subforum (and any I'm missing, authors step forward and be counted.  ;-)
 
Also @chwe tossed you a PR for Tritium H2+/H3 and your own Blinky example. 
 

https://github.com/sgjava/userspaceio supports C, C++, Python and JVM (Java, Scala, Koltin, etc.). Do we really need another Python lib besides WiringPi and RPi.GPIO? Also, I have non-root access working for pretty much everything.
 
Another thing, from looking at the CircuitPython site it appears to only support micro controllers at this point, not a full blown SBC. For this type of stuff I'm using NodeMCU with Lua which is mature and is hard to beat from a price/performance/usability perspective.

Honestly that's the only Pi I use for anything.  It is more stable than the 3 for video in my opinion.

Nice to see adafruit recommending armbian in his projects:
 
https://learn.adafruit.com/circuitpython-on-orangepi-linux/initial-setup

RAM and compressed

Both the API and our driver were merged in time for...  more over at: 
https://bootlin.com/blog/allwinner-vpu-support-in-mainline-linux-november-status-update/
 

https://www.merriam-webster.com/dictionary/masochism
 
(I would recommend sticking with definition 2.  Although it's tough these days to know for sure...) 

I try to eat organic when available and cost effective.  I also grow my own vegetables in the summer.  I also cut all the high-fructose corn syrup and a lot of sugar out of my diet, unless I need something to mix my rum or whisky with. 
 
Playing with genetics seems a risky game, but then again scientists love diving into the unknown and the loud ones live lives of pure hubris, thinking their tiny addition to the sum of humanity's knowledge somehow makes them a god.  

OK, for the unafraid, I have removed some HDMI hackery that was part of some patches on older U-boots than what we use.  Install the file below if you have kernel 4.14 (so "next") and are seeing this issue, let me know if that alone fixes it, or if you see any other issues.
 
http://electricgraveyard.com/armbian/tinker/uboot/linux-u-boot-next-tinkerboard_5.67_armhf.deb
 
[EDIT]    Updated, I found the issue now appeared on one of my "previously good" monitors.  I disabled video in u-boot entirely, seems ok now.  That does leave some questions for the 4.4 kernel as I think it now needs u-boot to set this up...

hehe had to accept that I can be fired from my mod duties today..
 
btw.
how should we deal with:
 
IMO I'm not a big fan of selling over forum.. In case somebody gets fooled they blame our forum for it. Same counts somehow for ebay links (at least, there's ebay 'in charge').

Here is a great talk about this
 

First.  Thanks for so great work in the ARMBIAN community.  Any word of gratitude will not be enough.

I have been installing Linux on different SBC.  Some of them are supported by ARMBIAN, others not.  There are some that never will be supported (as the Parallella 16).  And the ARMBIAN process it is very clean for the already refined machines.  However, when trying to bring up some other machine, it is complicated to understand what to do, how and where, as the process have been evolving for a long period of time.

Recently I began to work with @chwe on the BPI-R2, and my first job is to make the nand-sata-install to work.  So, I prepared an image to check this, to study the internal parts of the script and what is the purpose of it.  For my surprise, the script do several things, but it seems to accumulate also old stuff, maybe about previous ways to do certain things.  How to work this without breaking something else?  There, I realized how important is the /etc/armbian-release file, but also the /usr/lib/nand-sata-install directory (for all possible cards, as the ones are not a10 or a20 receive the a20 treatment).  And there is also the /usr/lib/u-boot directory with some operations that could be used in ... I suppose u-boot ..., although I am not sure in what way, as u-boot it is the first thing to run in the machine.
 
As a "reader", my perspective is that the vital system information it is not well organized.  At least it doesn't follow a unified standard, and carry the possibility of side effects as some elements could be located in not well known places.  I still need to make a catalog for all possible system parameter sources, and I figure that I will find some redundant elements in some place.  And redundancy it is not only about saving resources, but about breaking something when not following a referential methodology where any change must be system wide (i.e. universal).
 
Maybe ... and this is the reason for the discussion ... it is important to create a unified system information backbone where all processes in the system can obtain trustworthy information to work with (/proc only works with the kernel stuff).  This could also reduce the complexity of the different processes, as it could provide reusability of some information gathering functions (instead of repeating them in different scripts and or programs).  To install a system in a disk looks similar to reconfigure it in an already installed place or even to query how it have been installed.
 
What is the opinion of people here?  There are related discussions but they seems to be a little lost in time.  I am not really interested in the historical solutions (this can be written in some book), but in the actual problems and how to resolve them correctly.  There is a related thread about naming, although this one is about operating.
 
Thanks
 

It's quite cool. Not really multitasking. But instead of using delay what stops everything you check if the time has passed long enough to start a task. So you can do other tasks during that waiting time.
But when a task is busy you can't start another task. That 2nd task will start when the 1st task is done.

Very simple but effective. Why didn't anybody come up with this earlier?

Nope, mali binaries take care of everything.
 
BTW, Bionic version of the script is done, I'm just brushing up the documentation.

Yes, but is it still manufactured? Is it still sold worldwide? And what will you do if you are an "interested developer" and your board dies? Buy another one (if it would be even possible) or move it to "community supported"?
I'm not saying that we should drop support for this particular board right now (I'm sure that @tkaiser would have a different opinion) but any device will fade out in time, regardless of the history.
 

Things to add IMO, some general forum rules to let moderators make decisions based on written rules instead of personal opinions (yes, I think we already discussed this more than a year ago):
 - primary forum language is English, messages in other languages without translation outside of "General chit chat" section may be hidden or deleted
- don't bump topics too often and don't create duplicate messages and topics to bring attention to your issue
- be respectful to each other, follow the nettiquette
- don't abuse private messaging for tech support
- don't abuse forum for self-promotion and don't spam
- breaking the rules will result in a warning, getting multiple warnings will result in a ban
 
 

then it should be a real 'proposal' with an intention to contribute to the board bring up process.. If it's just an 'I want armbian on it' but don't even summarize specs and a pro/cons, better keep it here..  @constantius thread was merged from development subforum (but not board bring up) by myself to this one cause it didn't make sense to have a second thread with the same infos yo get here.  We have a search engine to spot such threads before you've to open a new one:

 
Before the board isn't on the table it IMO doesn't make sense to discuss a 'board bring up'.. 

Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
 
HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
DEB package and source code in case you want to extend or fix things.
Be aware the process list and task can be very intrusive if you want to monitor many things at once.
It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.
 
https://github.com/avafinger/htop-2.1.1_enhanced-version
 

Then the project should be scaled back to the point where it is sustainable?
 
If a problem requires too much time to solve then it should be ignored until someone more knowledgeable or more resourceful solves it?
 
Then maybe "we" should not try to satisfy everyone? This includes answering to topics if you don't know the answer or can't solve the problem right now, includes providing nightly images and images for community supported devices (let people build images by themselves and share them without using the project infrastructure (i.e. via MEGA or Google Drive) since disk space and traffic costs money that doesn't come from nothing). Also includes working on and especially providing any images already for H6 which is (IMO) > 6 months away from getting enough green squares in the sunxi status matrix for making images suitable for everyday use. Includes providing "better" wireless drivers if integrating and testing them takes too much time.
 
I think this would help too, I don't want to wash my eyes with a soap after reading some threads.

I received the box tonight. I will test it under Android this week-end, and afterwards, lets the butchery begin.

@Da XueI'm afraid you will have many complains about lack of SD card. I mean It would be good to have a big flashing banner >>[[ There is no SD card folks ]]<<

2 mounting holes on the same side will make any heatsink design "mechanically interesting"