pfeerick

While I agree that it is not our job to provide support to people buying the boards (that would be the manufacturer's responsibility) if someone wants to add support for the board in Armbian I don't see why we should refuse their help.
 
Of course I have zero sympathy for people who come here and complain about the hardware decisions the vendor made (e.g. microUSB power, crappy EMMC, bad 1T1R WiFi) because that is entirely outside our control.
 
So I would say, if someone does submit patches to support the Banana Pi M2U or Berry, we accept it. But it is also wise to put up a disclaimer that any images for Banana Pi come with zero support and we will ignore requests for free support on the forums.

Well, we don't exactly ask for "useful feedback".
Most of the problems reported currently are for unsupported/development configurations and those problems are known already.
For problems reported for supported configurations - sometimes it helps, especially when logs are provided, and especially for new boards or after bumping u-boot and/or kernel versions.
Also we have assigned beta testers, so IMO we still need nightly images (unless we want to encrypt .7z files with passwords available only to beta testers )

IMO this needs to be discussed separately, not in this (Banana Pi M2 Ultra) thread.

Mainline = experimental, no support. Network driver will be changed.

Armbian support feels like a bunch of parrots each time one of those questions from experimental area pops out 

I highly appreciate you doing this and I'll also invite you to become moderator of 'Random Ubuntu flavours as build system chaos' subforum. You should keep in mind that you'll soon deal with important questions like 'Why is Linux Mint not supported?! It's based on Ubuntu!!' and 'What about Bash environement for windows 10 with xenial distribution' and other ways to deal with everything that smells like Ubuntu. Of course you should first test through all 22 linux families currently supported with all kernel and u-boot variants (that's the funny thing with that: we have some combinations where u-boot needs GCC below 5.4 in 32-bit while the kernel only compiles with 64-bit GCC 6.1 or above). Of course you also need all boards to test through (maybe a Kickstarter? The few hundred bucks for the hardware aren't the problem but your new full-time job will be)
 
Maybe that's already enough to understand that this 'very little time' is better spent on real improvements? Besides that we recommend a virtualized environment for OS images for a single reason (not mentionend anywhere yet except forum): If there's ever just a little error when dealing with image creation (happens as root using dd and trying to overwrite sectors of the image) the build system can overwrite your whole OS or at least renders it unbootable!
 
The main reason people like to use something else than Ubuntu 16.04 is that they already run something else that's Ubuntu-ish. And that's bad and should be avoided. So forcing users to setup an own virtual machine wit 16.04 is already fighting lazyness and preventing a mess if something ever goes wrong.

[x] done.
 
@ssuloev: BTW: I didn't want to be offensive above. Just give the other devs the idea that 'trying to be friendly/polite' is sometimes wrong. Overreading/ignoring warnings is just human (even providing partially wrong information when requesting support) and if recommendations turn into requirements (as it's the case with 'Ubuntu 16.04 only' now) then we should switch warnings into errors too. Saves everyone time and hassles.
 
And also we should rethink answering questions in the forums. Now we have an infrastructure where commits below https://github.com/armbian/documentation almost immediately show up on https://docs.armbian.com. So when questions arise we should think twice about why (eg. 'why 16.04?' Nowhere answered below docs.armbian.com but multiple times in the forum) and then prefer to commit an unstructured entry to a yet not existing developer and user FAQ, wait until it shows up over at docs.armbian.com and then post a link to it?

Yes, Zador is right ! We shouldn't "trash" the WIPs, but simply hide them and make them visible with EXPERT=yes.
Otherwise, it will be a pain even for experts ...
 

We may still want those to be accessible for internal testing purposes, so hiding "Show WIP" button (unless, for example, EXPERT=yes hidden option is supplied) may be a better solution

IMO the only way to deal with situations like this (Armbian developers not developing anything useful any more since only being trapped in unnecessary first level support situations).
Documentation mentions that only 16.04 is supported build environment (14.04 was ok for kernel only compilation but that has been removed now too). You use 16.10, get a warning that 16.10 isn't supported, ignore this warning (you had to press [enter] to confirm what you do), fail as expected and ask for support (you confirmed before to not do this) now telling us you would use 16.04. Since 16.04 is the supported environment Armbian developers try to solve the problem (hunt for a bug) and look into your logs just to realize that your claim to use 16.04 doesn't match reality And then they also waste their time to explain why our recommendations are not written just for fun but to guide developers and trying to save both external devs as well as Armbian core team members from wasting their time on well known issues @Igor and @zador.blood.stained: what about immediately trashing the .wip files for crapboards now to focus back on important stuff?

There has never been a 'LeMaker M2' and SinoVoip's M2 has no Mali but PowerVR instead (with this M2 neither 3D nor video acceleration works). If you were talking about M1 instead I fear you either don't care that much about details or missed that two different SoCs are WAY MORE IMPORTANT than a stupid hardware vendor trying to sell all his ABSOLUTELY INCOMPATIBLE boards with a similar name. Those Banana morons today sell M2, M2+, M2 Ultra, M2 Magic and soon also M2 Berry. Only Berry and Ultra are somewhat compatible since the Berry inherits shitty software and support situation from Ultra but will cause even more problems due to crappy Micro USB for DC-IN.
 
M2 = A31s, M2+ = H3, M2 Ultra/Berry = R40, M2 Magic = R16 (which is an A33 in reality, we're dealing with here even with 'marketing by obfuscation'). There you go as @zador.blood.stainedalready outlined: http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix
 
If the Armbian project wants to focus on something relevant we should stop supporting crappy hardware. But that's obviously just me and others seem to love threads like this.
 
Edit: My definition of 'Armbian project' was being the bridge between kernel developers and end users. Caring about settings and details, spending an insane amount of time on research/testing and optimizing details, collecting patches, assembly everything to an easy to use OS image that ships with sane defaults (performance and security) and receives upgrades. This was never about providing shitty OS images people can complain about (since this and that doesn't work yet but users don't want to understand -- that's the 'nightlies' situation currently. Now it seems if we don't provide nightlies for reasons for a board users expect to be somehow related with Armbian users start to mis-use the build system to try to create shitty OS image with it on their own. And ask even for support if they fail. And we even try to deal with this over and over again instead of re-thinking the whole approach)
 
 

For some reason you ignored @tkaiser's words
and still are complaining that the image doesn't work.
 
First steps in developing for R40 and Armbian - go to https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix and wait first until R40 column appears in the table and then wait until at least third of the cells for it are marked light green and another third is marked bright yellow. Experience with other images on M2U or images on other boards certainly doesn't matter here.
 
That I still don't see a serial console log which is a prerequsite for saying that something "doesn't work" or "nothing happens", especially for targets marked as WIP.
 
And instead of doing release preparations we now have to think about putting extra dialogs and warnings for WIP targets and hope that this will help with avoiding wasted time with support requests for them.

The biggest problem is no switch from WYSIWYG to BBcode that was possible in the previous version.
For the code&spoiler combination - you can still write spoiler tags manually around the code block.

The thumb on #3 belonged to my son  It also burned, my son could just say "15 Mississippi" before shouting... 
On #1 I used my little finger, there the skin is thinner
 
I'll try all 3 later after by burns heal
 

You really couldn't make this shit up could you.
 
As far as I know connecting to open aps and being an open ap with hostapd works.
 
The main issues with the driver is that performance is awful because of all the frames it drops and that it's not structured very well and can lock up the kernel if it gets into a bad state. These things are also true if you compile the code dump from allwinner on their hotchpotch prehistorical kernel.
 
FYI - A weekend of work on stuff like this will cost you more than $5000. The source for the kernel may be "free" but getting people to do work on stuff you want costs money and lots of it. You might want to think of all the free work people here have put into putting together something useful before writing any more of your bizarre posts.

I was just looking at that again because of another post, and noticed that on line 66 $capacity is lowercase, and on line 73 it's uppercase ($CAPACITY)? Aren't shell script variables case sensitive?   Thus making it so the 8GB condition never fires???

They are. Thank you for reporting.

This NOT an etcher bug. A small image is written to a big (micro)SD card, and it is then resized on the first reboot. Sometimes there is a automatic reboot, other times it is left up to you. I believe it is something to do with whether resize2fs can do an online resize or not on different kernels?? (you can see the test here in the resize2fs script). 
 
When you logged into the CT for the first time, it probably have had the red text shown on this screenshot (which obviously for a OrangePi Zero, but never mind...). As the text indicates, and as Igor said... reboot!   If you manually reboot and the file system hasn't been expanded... then there is a problem!  
 

After receiving the board, I was sure I was going to try possible ALL OS images, but at the very first moment, my thinking was, *What is the Helloworld* OS image here... I want to start from the smallest and easiest possible start, and that was my very first question...
That is the reason I went to Debian CLI Base Image...
 
For example, if someone ask me the question today, I will answer: go with Armbian.
I even tested Armbiam with an old 2GB Class4 SDCard, and EVEN install XFCE4 there, and STILL leave about 300MB free!
apt-get inst xorg
apt-get clean
apt-get inst xfce
apt-get clean
apt-get lightdm
apt-get clean
and, still about 300MB free!!!
 
I was UNABLE to do the same 2GB SDCard test with Debian Base,  for some reson it fails (did about 2 or 3 times)...
 
Of course, I am not asking to develop and create an OS image specific for "helloworld", but it is the idea around which I was asking for... something like: This is the most basic stuff that we can recommend now...
 
Anyway, the question is more about "What is More Succesfull (to boot)" and less about the OS image itself...
 
So, this is, more or less, what I was then, trying to ask,
hope you can understand the general idea exposed,
 
Valter

Hi, thanks for the input, I fully understand and support some measures to certification that the message is a true message, for that, I believe there is a need to do something to provide a more safe environment where people can come, specially the less-technical people...
 
To be honest, I think I was very fortunate that tkaiser gave me valuable information, not only the suggestion to use Armbian, which ended up booting up the board successfully...
 
Thanks for clarifying the matter,
Valter

Yeah, sorry about the three day wait... we have had issues with human spammers (either that or bot spammers that are good at reading the latest google recaptchas) joining up and posting garbage on the forums. I asked for a first three moderated post queue, but instead we got a 8hr + 3d cooldown window. Not new user friendly, but it is working. I'm just concerned that it will also cut down on the number of new users who will join the forum, but my concerns fell on deaf ears.
 
You'll usually find somebody on the IRC chat though who can help, and the Armbian crew are very helpful also as you've found!  
 
What do you consider a 'simple' image? A console one or a GUI (graphical interface) one? The Armbian builds are probably the best supported due to the automated build process keeping everything consistent, and you get console and GUI options OOTB (out of the box). ayufan has some builds for the pine64 now also (although I haven't tried them yet) which could be quite interesting also going forward, although it's console only to start with. 

Hi tkaiser, btw, thanks, you is the one that help me then (on the chat) on my first boot experience, to which I describe as *dark moments* because I had no idea about what was going on then...
 
Here is the thinking (not doing it yet):
I want this "sys led on" signal for more than one reason, the first to signal booting and other kind of activity, unfortunatelly you right, since the LED is not physically present and new users may have difficulty to put one there (besides being easy)...
The second reason, and this is what I am thinking now, is to put a small MCU (a PIC 10F or 12F) to monitor this "sys led" state and, if the signal "ON" does not come out after 30 seconds, the MCU will issue a hardware-reset directly to the reset line, and keep repeating the procedure until it receive the "sys led ON" signal...
 
Looks crazy, but since I want to use (also) this board as headless, having a mechanism to overcome the "power instability", even if it is a "dirty" solution, I will like to have one...
 
Besides... the fact that the power instability issue does NOT obey any kind of pattern... the MCU boot assistent idea still persist in my mind... I will try it later...
 
Valter

My first boot experience with Pin64 board was not very happy because I was thinking something as easy as 1-2-3... but it was not so cool...
First, I want to ask on their forum what it the easiest and simple OS image I can try, but to my surprise, after registering on their forum, I was surprise to discover that only 3 DAYS after registration I can ask questions!!!
Then I decide for Debian Base and nothing... change AC adapter, and nothing, change monitor, and nothing, change SDCard and nothing... just black screen... also change image to Ubuntu... and nothing...
 
It was at this point that tkaiser (chat room) suggested the Armbiam, which I did, and THEN: IT WORKS!
Not easy to explain the logical connections of these actions, but it is the true description of my first boot experience... !?!?
 
Sometimes, very very little things can, together, compose to an issue that may become "significant" in some way...
 
BUT, I found this $15 GNU/Linux / Android box a very interesting proposition, and being a 64bit CPU I am trying to find a peaceful relationship with it, and if such is possible, this is a COOL raw material to have (my board is the $19 1GB Model)...
 
Hopefully, we can find a "way"...
 
Valter

Just for the record: Armbian's method does a few things differently: https://github.com/armbian/build/blob/af560222c7f08034a8dbe218249a989aab478e46/scripts/resize2fs#L61-L65 (so an '/etc/init.d/resize2fs start' is the way I would prefer)

Same Problem
Armbian uses log2ram for /var/log. And log2ram writes logs to storage every 1 hour.  Basically if you install services and reboot computer before write all changes including new folders be missing
most easy option is for example:
 
sudo apt-get install apache2
sudo log2ram write
sudo reboot
 
and all works fine
 
for confirmation after restart run:
ls /var/log
 
and look for "apache2" folder
 
for chaking if system use log2ram type:
df -h

I added this led to the DT as a standard GPIO LED with "heartbeat" trigger by default. Still better than nothing.