wildcat_paris

I guess I'll keep my r1 to this kernel version (5.20), and as soon as I can I'll buy a real router.

I have a Odroid XU4 board that I am trying to build an image for and it will not boot from any images I have built from the compile.sh pulled from github. The board u-boot led doesn't turn on (solid blue) and nothing is displayed from the hdmi port. I select SD card image and have tried writing it with Win32 imager, Etcher, and the dd command. I did get an Ubuntu image downloaded from Odroid to work so the board is not faulty. Nothing has worked and I'm at a loss as to why when I personally compile an image it does not work.
 
Thanks for the help

Please try rebuilding the kernel with updated config. Since kernel doesn't pick command line both from legacy and mainline u-boot, it must be a kernel issue.

"If no data went trough for certain boards, than either tester failed to test or it does not boot at all."
 
If no data is auto-submitted, it indicates that network is not fully configured - not that the board doesn't boot. Or that it does not pass threw the firewall as in my case anyway ... In any case, you should explicitly ask permission for reporting.

I agree and I vote also for collecting feedback prior to start any work. I could imagine a simple HTML form accessible through GET method so a test mechanism can either submit data in an automated way or provide an URL that's ready for copy&paste. 
Please note that some ideas exist already -- please see https://github.com/igorpecovnik/lib/issues/512 and https://github.com/igorpecovnik/lib/issues/511#issuecomment-256420416. We must ease helping users testing through new releases and upgrade procedure so exactly this sort of feedback has to be collected NOW.

We are not there yet since I don't know yet how we will do it. And It depends -  if we collect data mostly automatically, than we better provide some html, generated based on auto submitting. If no data went trough for certain boards, than either tester(s) failed to test or it does not boot at all.
 
Let's see how far we can come with automated approach. 
 
I need some days off so I won't jump to coding in any case.

Ideally I would like to see no more than something like this:
Boot Network HDMI Install Date Performed by ------------------------------------------------------------------------------------------------------ Lamobo R1 yes yes yes yes x.y.2016 JohnDoe Odroid XU4 no www.link-to-boot-log.com Odroic C1 yes ... ... : 

Igor said "Today, this task can be done only together"
 
 
Right you are!
 
I wish to help as best as possible.
 
I posted about the need, and am happy to say it was reposted to various communities at least 6 times in this very short time.
 
I cannot think of a more deserving project - thank you!

Thanks Joe!
 
The idea is to establish a small team, which would help us test the boards upon request. Within 2-3 weeks before planned update. If we would made more changes, more testing will be required. We want to make sure that upgrade does not break the board's core functionality at first place, than we need to try to find hidden bugs and document them under "known problems" what was found in last moment.
 
Specific details about this process are still adjusting, but roughly this is it. 
 
When I cooked my first image, it was easy and I had a lot of fun trying to find and fix a problem. I like doing that   but I simply can not. Today, this task can be done only together.

Hello,
 
I know this will be a controversial subject, but I often like to see what's happening in a devel repository by browsing commits.
 
I start by looking at the commit titles (first commit message line) to approximate the interest that particular entry is to me, then if deemed interesting, I'll read the full commit message to understand what it is about, then if still interested I'll go read the code.
 
I think this is a fairly straightforward approach to digging in a codebase or development stream, avoiding to loose time on things outside of interest scope, and allowing to focus on specific subjects.
 
So, in order for this workflow to be doable, the commit messages content need a minimum level of details, which is what I'm asking the community to act upon.
 
Would it be possible to mandate a bit more work on that front ?
 
I'm not against messages like "Whitespace fix", "Typo fix", "Better comment", anything that explains a bit what the code diff is about.
 
WDYT ?
 
PS: I think armbian is not so bad wrt $SUBJECT, it just needs a little bit more. I've seen far worse projects where I wouldn't even ask for better commitmsgs, so take that as an endorsement of the (already good) quality level of the work done.
 
Thanks

@zador.b.s
your latest updates for XU4/next (uboot 2016.09) are working fine on SD, I will check when possible for legacy
 
 
edit: for eMMC, the sd_fusing.sh script is needed to wipe out uboot 2012.07 from "boot0" with 2016.09. if not wiped, booting is weird/KO.

The ODROID C2 image as listed below seems to work great! I am very pleased.
 
Sound, video, network are all very good. USB devices (flash drives etc) performed exceptionally well and and as expected.
 
I even tested the PayPal button. It worked fine (tested with 22 Euros). I encourage others to continue testing this very important feature using the same and or other amounts, as my ability to test this important feature testing is not nearly sufficient.
 
This image boots fast. Very very fast. I used a sandisk ultra SD card. I plan to try both the samsung and that other brand (ODROID red using with the XU4) of EEMC cards later tonight. Honestly, it run so fast now, I don't know what to think. I often have corruption troubles with EEMC on the C2 using the manufactures images. It would not surprise me to find that armbian would run perfectly stable on EEMC.
  At Igor's request, I did perform "nasty things" to the board, however, I'm a little embarrassed to publicly admit any testing I did in this area. Let's just put it into the "extreme" category, and call it good (OK, it was great... really really great).
 
I looked over the list of what you need, and saw nothing in particular that needs testing for this image, so IMHO, I would call this image good (great) and ship it! It beats the hell out of the manufacturers image (that rendered itself unbootable on two different devices).
 
If you need me to perform any particular test, please let me know... If it is in the nasty category, it will have to wait, as I am a bit spent at the moment from this exceptional boot.
 
Much thanks go out to Igor and the team! My boards would not boot without you and your fine work!
  Tested Image: http://image.armbian.com/betaimages/Armbian_5.23.161025_Odroidc2_Ubuntu_xenial_3.14.79_desktop.7z
 
Joe

I looked at the spoilers and see folks and boards listed, but don't quite understand. Are they covered? Need more coverage?
 
I have two ODROID C2's that I need to put an OS on (the last odroid updates rendered them useless). I am very time limited, but want to help.
 
I also have XU4's and Pine64's, but would rather take on the C2's (kill two birds - one stone - the C2's are in need).
 
Do you prefer me to use the prebuilt images, or the otherway? I could do either.
 
Is there someone that can coordinate these efforts? I'm thinking that this looks like a "free for all" and is in need of a little direction for a new guy coming in the door wanting to help.
 
Call me stupid, but I am thinking something like really clear "A-B-C" instructions:
 
a) Pick Board
 
-- Use this image
 
----c)  Do this   --------d)  Report results here   Just saying, if we could coordinate needs, we could coordinate the incoming offers to help, and you will get coordinated results.   It's gotta be fast and easy to figure out what you need, fast and easy to report, fast and easy to update needs, and fast and easy to find.   So what can be done to help an idiot like me provide useful help to really smart folks like you  guys?   Joe

Well, why not switching to distros that do not receive any upgrades? The problem Armbian project currently faces is a lack of community involvement and unless this changes it's a really good idea to slow down a lot (eg. fixing Dirty COW not within 2 days with all kernels but in the same amount of time as most other OS images do: never).
 
Apart from that me personally would drop support for Crapboard R1 rather sooner than later since so many people still don't get how insanely insecure this thingie is when used in the way as advertised by its careless manufacturer.
 
 
 
I tend to agree on that.

I have no idea what it is, I would need to hook up a board but have currently no motivation, a headache because of stress and lack of sleep. 
 
During two major updates, there was few cheer ups & thanks, a bunch of useless questions, support question on a private comm, what I "like" most, and we raise 15 euros. One, one person answered to our plead for help and saves us / you some time.
 
I will repeat this plead once again. We need regulars on testing. On daily basis, otherwise such things will continue to happen. We can't test all boards for everything on every update, nobody of the core crew even have them. If you want top service, we need volunteers and cash. I already work full time / way too much and I need to cut down my involvement within the project. Things can go only worse if tasks wont be patched on the way.
 
This service can sustain top quality level only with proper support from users, makers and us. Otherwise it will drift away from end user back to geeks, which always find a way ...

Sorry about complaining yesterday
I too was frustrated since I spent the afternoon trying to make the new armbian 5.23 to work...
I know that for armbian to be compatible with all boards takes a lot of work and testing. Since I enjoy tinkering with my board, not beeing able to fix what was happening, took a toll on me... Wasn't fair to you guys
So to make this clear, thank you for your hard work. As for donations... fire away with a paypal account or something... I'm sure I'm not the only one that can spare some cash for the cause

Since it is failing at building additional tools, you can try adding EXTERNAL=no to compile.sh to disable building these tools.
 
Maybe we should not interrupt build process if non-critical packages failed to build, or even remove temper and USB redirector since they are not specific to our supported hardware and most people don't need these tools.

Regarding XU4 there are these things to test:
Initrd support that was added recently Not a real test, but more a request for test or documentation - check if mainline u-boot can be used both for legacy and next kernels, also what problems forced using 2016.05 version (compilation issues?) In case legacy u-boot is still required, check loading environment from a text file like it's done, for example, here: https://github.com/igorpecovnik/lib/blob/master/config/bootscripts/boot-pine64-default.cmd#L15-L17 In case u-boot environment is properly loaded, booting by filesystem UUID can be activated for XU4.

Well the board survived ... I am know trying to survive to debian and systemd : a mistake in /etc/network/interfaces and the system hang at boot ...

I still think it would require some 'passion' on the tester's side since while testing with daily upgrades we might be able to catch problems like brcm40183-patch easily (and more early) a responsible tester would need to maintain more than one installation to be able to test through the 'normal' upgrade process also prior to major updates like this now. So given two kernels and two distros are affected as with most of our devices 5 SD cards are already needed (one for the 'daily' stuff and 4 to test through 'major upgrades'). Let's see how many people are willing to do this.
 
And with devices like Lamobo R1 it gets even more difficult since it really seems people are crazy enough to rely on this crapboard for routing purposes and NAS combined. A responsible tester would need a second R1 to test through possible upgrade scenarios (u-boot might cut SATA power, new kernel driver might affect networking in an unreliable way) and also some sort of a lab setup to test whether the advertisement claim (routerboard) works... which is not the case anyway. So good luck.
 
In other words: with more volunteers involved we might catch a few more bugs prior to release but still won't be able to guarantee 'hassle-free upgrades' as some seem to dream of.

Yes, not in general. This flasher covers only Allwinner boards with eMMC chip.

There is mainline (4.x) with limited functionality for server usage scenarios. Closely read here.
 
Edit: Upgrade from 3.10.x is untested. 

No worries. I have an XU4 currently running android on eMMC. i can throw xenial on an SD card and boot it up. i'll have a reply in about 2 hours

In order to make armbian better, we need your help with testing. 
 
Why?
there are simply too many boards to handle, there are task which can't be automatized, there are bugs which are not seen from our perspective. What kind of tests?
 

booting, user creation, updates, upgrades checking if basic supported functions work: video, audio, network, wireless, AP mode do nasty thing to your board and report. How to test?
Download nightly images from here. 

You want to test image which is not there?
Add those two parameters with desired targets to board's config and create a pull request. and / or
change to our daily build developer repository: deb http://beta.armbian.com $(lsb_release -cs) main utils $(lsb_release -cs)-desktop Note: you are entering developer area and things will sometimes be completely broken. Don't use this repository in production!
 
When bug is found?
 
* Provide logs with armbianmonitor -u or type as much data as you can.
 

Check if it's not already on the list and if not, add it there, [optional] Open a topic in issues support forum if you think we need to discuss it, [optional] Fix it.  
 

That's at least the symptom of a card reporting a capacity too high (fake/counterfeit card). The card's FTL has not the slightest idea about filesystems or partitions or anything else happening at the layers above (only possible exception: If the card would support DISCARD/TRIM and the block device driver also sends DISCARD calls to the FTL).
 
That means for the card's controller it's simply new data that arrives (it's always new since overwriting doesn't happen, in case a sector (logical) should change its contents the affected pages will be marked as 'to be erased' and the changed data will be written to a new page (or more pages in case sector size is larger than page size). As part of the garbage collection then a background task on the card's controller will collect pages to erasable blocks and delete them to be available as new pages where stuff can be written to). So in case your card is just 4 GB in reality but the controller fakes 16 GB then the problems occur after 4 GB of data has been (over)written to the card since the controller happily accepts new writes but they'll never arrive in flash cells.
 
Only way to fight this: ALWAYS immediately check an SD card directly after purchase. It's easy. Just do it.