Improve 'Support over Forum' situation

[pfeerick]

6 minutes ago, tkaiser said:

And zero responses to 'preventing boards to boot when rootfs is read-only and executing cpuburn-a7 or cpuburn-a53 as part of firstrun crashing/freezing underpowered boards' reminds me why I consider this babbling here a waste of time.

 

Sorry about that, I only just caught up with the thread, so I didn't many to reply to that before now. 

 

Hm... first boot checks? Do some basic 'has the user used a crappy or faulty SD card, or using unreliable power (i.e our old favorite microUSB with a phone charger) at first boot, and basically say... if you continue past here, don't come near the forum or expect support? And have a reminder as part of the MOTD of this flawed configuration? If that essentially what you are proposing, I second that. But I'm not part of the inner circle, so my vote probably doesn't count for anything!

 

And as far as information regarding SD card issues and power issues, I have started work on two posts which will probably be merged into one and used for an announcement at the top of the board pages as a 'basic troubleshooting' methodology. It'll be a few days before I finish it, and get it how I want it though. So you're not alone in thinking this needs fixing, and I am working on it.  

[tkaiser]

6 minutes ago, pfeerick said:

Do some basic 'has the user used a crappy or faulty SD card, or using unreliable power (i.e our old favorite microUSB with a phone charger) at first boot, and basically say... if you continue past here, don't come near the forum or expect support?

This might work in case of a read-only rootfs (as a clear indication of 'something's wrong with SD card since if this happens already at the first boot there can be only one reason for it). Catching this type of error also allows from then on dealing with forum posts that talk about 'Authentication error' since then it's users not getting how to change root passwd.

 

The other problem -- underpowering -- we can not detect and provide a nice notification and some polite guidance since on the vast majority of boards we can not measure voltage/current. IMO it's way better to create a worst case scenarion already at first boot (starting cpuburn from firstrun task and do a 'pkill cpuburn' at the end of it) so boards that suffer from severe underpowering simply will never boot unless this problem is fixed. With boards using shitty DC-IN connectors it will look simply like this: a nice boot/crash cycle https://www.youtube.com/watch?v=y4EIhh0VT5g&feature=youtu.be&t=2m18s or just a freeze.

 

At least Armbian will refuse to boot on such a device so the user will not waste his time with an instable Armbian freezing/crashing later, then already adding more instabilities to rootfs gone corrupted so the user will not even be able to learn that once he fixed powering something improves since Armbian running off a corrupted rootfs will still crash/freeze or at least behave erratic/instable.

 

This won't work great in the beginning. But after some time this will be simply a measure of quick check. User will ask eg in Tinkerboard forum why he runs in instabilities and mods and other users will immediately recommend 'Burn Armbian with Etcher, if it does not boot you have a powering issue that needs to be resolved first'. Care to remember how much time and efforts it took to promote Etcher here and there? In the meantime it's getting recommended by many more people around and in 2018 no one will even think about using Win32DiskImager any more. But it takes some time, people even get angry about stubborn guys like me repeating that over and over again and there's always one who has to make the first step. 

 

22 minutes ago, pfeerick said:

And as far as information regarding SD card issues and power issues, I have started work on two posts which will probably be merged into one and used for an announcement at the top of the board pages as a 'basic troubleshooting' methodology.

 

That's good but again I see I couldn't make my point. It's about a PSYCHOLOGICAL ISSUE. Preventing users (especially the smart ones) running in a 'them vs me' situation since many people seem to be offended by that which prevents them thinking calmly about the real issue.

 

Collecting various user threads here and there that are short and understandable is something completely different than a forum post made by a moderator. Let's call it success stories: people who report weird failures, get Etcher / SD card recommendation, come back immediately with 'That made it!'. If we have at least 10 of them instead of lenghty explanations no one reads or wants to accept it's simply a pinned two liner like this 'Please be aware that crappy SD cards (example, example, example, example, example, example, example, example, example, example) and insufficient power supply (example, example, example, example, example, example, example, example, example, example) are reason N° 1 why things are failing' (example all the time just the link to such a success story).

 

Then it's not a 'them vs me' issue but turns into a 'me being part of the same community and learning from other's mistakes'.

 

[tkaiser]

Wasted a bit time over there so that link might qualify for 'success story' collection too. Re-opening original thread would be the better idea though.

[pfeerick]

25 minutes ago, tkaiser said:

The other problem -- underpowering -- we can not detect and provide a nice notification and some polite guidance since on the vast majority of boards we can not measure voltage/current. IMO it's way better to create a worst case scenarion already at first boot (starting cpuburn from firstrun task and do a 'pkill cpuburn' at the end of it) so boards that suffer from severe underpowering simply will never boot unless this problem is fixed.

 

That was what I was proposing... sort of. I fully understand due to different board configurations and architectures that board specific methodologies are too varied and complex, assuming all the information needed is exposed. I was thinking the cpuburn type task, coupled with a token, so that say if the system does that sort of power on b0rkage that after a couple of cycles it could let up and basically tell you your power system is broken. Because end-less boot loops aren't user friendly either. Part of the the change in thinking that is needed here is acceptance of the fact that a lot of people won't read the documentation, no matter how well it is written, unless they are forced to (or just plain want to). So making the system itself as robust as possible to the most common of issues should be a major goal. Those more technically inclined of us don't need that, we can just look at it and diagnose the problem, or perform a few 'simple' tests. Not the average joe though. 

 

21 minutes ago, tkaiser said:

Collecting various user threads here and there that are short and understandable is something completely different than a forum post made by a moderator. Let's call it success stories: people who report weird failures, get Etcher / SD card recommendation, come back immediately with 'That made it!'. If we have at least 10 of them instead of lenghty explanations no one reads or wants to accept it's simply a pinned two liner like this 'Please be aware that crappy SD cards (example, example, example, example, example, example, example, example, example, example) and insufficient power supply (example, example, example, example, example, example, example, example, example, example) are reason N° 1 why things are failing' (example all the time just the link to such a success story).

 

Then it's not a 'them vs me' issue but turns into a 'me being part of the same community and learning from other's mistakes'.

 

That is what I intend it to look like. I'm just in the process (when I have the time and desire to go back to the post and do a bit more) of collecting what appear to be the more to the point threads, and then the short piece for the top. As you say... not them vs me. 

[tkaiser]

2 hours ago, tkaiser said:

User will ask eg in Tinkerboard forum why he runs in instabilities and mods and other users will immediately recommend 'Burn Armbian with Etcher, if it does not boot you have a powering issue that needs to be resolved first'.

To elaborate a final time on this (and why that's related to improved support situation).

 

Armbian is the only distro around able to provide such a service to users.

• No vendor OS image can do that (since it's in their interest to hide design flaws like Micro USB for DC-IN that are part of their 'calculation' encouraging users to underestimate device costs since they think they could use their old phone charger)
• No 'vendor community' derived OS images will do this (since those vendor communities usually behave somewhat strange)
• No other distro supporting more than a few devices simply don't give a sh*t about low level issues since they only fiddle around in userland and blame the underlying build system if stuff happens (DietPi).

Especially people struggling with Micro USB powered boards won't get it immediately that their powering is insufficient (since 'works with my Raspberry Pi' which is almost never true, it's just Raspberry Pi firmware masquerading the problem due to under-voltage detection circuitry there and downclocking everything) but instead of discussing this for no reason over and over again let Armbian simply not boot on such devices. If they're confident that Armbian is at fault... well then they should simply use another distro (and flood the respective vendor forum with instability babbling). Once they learned that there's something wrong with powering after fixing that they'll come back anyway. But in the meantime unnecessary discussions are avoided or happen where they should happen anyway (vendor forum).

[zador.blood.stained]

1 hour ago, tkaiser said:

And zero responses to 'preventing boards to boot when rootfs is read-only and executing cpuburn-a7 or cpuburn-a53 as part of firstrun crashing/freezing underpowered boards' reminds me why I consider this babbling here a waste of time.

Zero responses because it needs more thought:

• Regarding read-only rootfs - relatively easy to detect, but only if it's completely read-only. Should this be done only on the first boot? What should be the visible action in case of an error - shutdown, reboot, dropping to the emergency mode?
• Regarding cpuburn: should this be done only on first boot? Should this be done only on problematic boards with microUSB power input? For how long should we run the test?

[tkaiser]

24 minutes ago, zador.blood.stained said:

Regarding read-only rootfs - relatively easy to detect, but only if it's completely read-only. Should this be done only on the first boot? What should be the visible action in case of an error - shutdown, reboot, dropping to the emergency mode?

 

For subsequent boots / login attempts there's a warning already in place. But I've to admit that I don't know whether this check works or not since when working on our 'media quality control' mechanism last year ('armbiamonitor -c' no one recommends as diagnostic measure in the forum since no one seems to know of) I finally destroyed two of the broken SD cards I had in the drawer to test through such stuff.

 

IMO this is a first boot issue since if it happens at this stage then it's really only 'burning gone wrong' that could be the culprit. Filesystem corruption later leading to a read-only rootfs can also be caused by freezes/crashes as the result of $anything (eg. underpowering) so the user should then do some investigations. I don't know whether we're able to display anything prior to the root passwd change dialog but if we're not able to explain the problem here IMO shutdown is the best idea (emergency console is encouraging users to try to fix the problem at the wrong location)

 

39 minutes ago, zador.blood.stained said:

Regarding cpuburn: should this be done only on first boot? Should this be done only on problematic boards with microUSB power input? For how long should we run the test?

 

IMO only on first boot since otherwise all the attempts with Armbian's IoT mode ensuring that specific small H2+/H3 boards not exceed 2W overall consumption while booting are useless. This won't catch all occurences of 'powering gone wrong' but will help reduce the number significantly.

 

And IMO it's much more 'user friendly' to simply prevent booting than allowing to boot into an instable system. Users don't want to be told about 'Ohm's law' (which would be important for them to understand the real issue called under-voltage and that they will only run into troubles when consumption increases), users if affected by instabilities simply try it again and again, they end up wasting way less time with Armbian refusing to boot at all compared to the amount of time wasted unnecessarily when being allowed to set up an instable system that finally after the 10th freeze doesn't boot any more due to corrupted rootfs.

 

We don't sell anything, we don't have to fear 'losing customers', in fact this is a service for users to tell show them immediately that there's a problem needing a fix. We only achieve that first time users might think of Armbian being the wrong choice (since not booting at all), then switching to alternatives, running into all the instability hassles there (good for Armbian's reputation) and once they discover the importance of sufficient powering they might return later. It's really no loss if all the useless discussions and the reasoning 'my PSU can't be at fault since with Raspberries it works' happen also somewhere else.

 

The real problem are hardware vendors using crappy DC-IN connectors and NOT elaborating that users need to take care about appropriate powering (and that's part of their strategy trying to attract more customers who think: 'Cheap buy, I don't need to spend the additional $ for a PSU since there's a charger somewhere lying around'). Those hardware vendors benefit from this design decision since more clueless people will buy such boards. There's no disadvantage for them doing so until now since frustrated users discuss 'Armbian instability issues' in Armbian forum wasting their and our time. IMO there's nothing wrong if such users stay away in the beginning until they learned the hard way what's wrong with their powering method and then also leave some feedback about that where it belongs to (in the vendor's forum and not here)

 

IMO it doesn't hurt if this runs everywhere and most probably the following will do it:

(cpuburn  & ; sleep 60 ; pkill cpuburn) &

 

[zador.blood.stained]

1 minute ago, tkaiser said:

But I've to admit that I don't know whether this check works or not since when working on our 'media quality control' mechanism last year ('armbiamonitor -c' no one recommends as diagnostic measure in the forum since no one seems to know of) I finally destroyed two of the broken SD cards I had in the drawer to test through such stuff.

I though about this.

[    3.958922] mmc0: host does not support reading read-only switch, assuming write-enable

So I'm assuming a simple DT overlay with a write-protection GPIO added to the mmc0 can be used to make any SD fully read-only for tests.

 

4 minutes ago, tkaiser said:

IMO it doesn't hurt if this runs everywhere and most probably the following will do it:

(cpuburn  & ; sleep 60 ; pkill cpuburn) &

Or something like "timeout 30 spuburn" in a blocking (oneshot) service, so screen and serial console will display something like "[...] Starting Armbian quick reliability test (20s/1m)"

[tkaiser]

1 hour ago, pfeerick said:

Because end-less boot loops aren't user friendly either.

 

Well, there is an alternative (check the timestamps please): https://github.com/longsleep/build-pine64-image/issues/16

 

That means: we have hardware vendors attracting especially clueless customers (!) with designs that provoke underpowering issues by encouraging users to use the wrong cables and the wrong 'PSUs' (even phone chargers or 'smart chargers'). They make money with this design decision.

 

I'm not aware of anyone of us devs or moderators getting paid for trying to compensate from this design decision that leads to the same stupid support cases again and again. To implement this in a more 'user friendly' way a lot of development and testing efforts are needed. In other words: we should work for free to compensate from a hardware vendor's design leading to instability issues we can't fix at the software layer but only raise awareness for (while 'support drama' will still continue since people won't believe us telling them 'There's a problem!' since 'Nope, works with my Raspberry' which is in most cases simply not true but people don't realize since it's perfectly masqueraded by RPi firmware).

[tkaiser]

8 minutes ago, zador.blood.stained said:

Or something like "timeout 30 spuburn" in a blocking (oneshot) service, so screen and serial console will display something like "[...] Starting Armbian quick reliability test (20s/1m)"

 

Yes, that's way better than my idea! And both 'armbianmonitor -c $HOME' as well as starting a 3 min cpuburn run should be accessible via armbian-config so mods/users can try to help other users reporting stability issues by simply asking them to follow a few simple steps (underpowering testing should be accompanied by some USB consumers added after each successful 'Armbian underpowering test' run)

[Igor]

"Before you think to report a problem with your board running Armbian" announcement ... is enabled only for moderators and developer groups. Feel free to edit & comment ... I'll reverse showing when done: to guests and users and to "Technical support" section only.

 

It's a small step and we can remove certain pinned posts because of that. I don't expect miracles, but some improvements.

[pfeerick]

@Igor I've edited both announcements a bit, see what you think of the changes. And please, please, please change "Before you think to report a problem with your board running Armbian' to something a little less... sharp? I know I would do that tongue in cheek (and do... hence why you sometimes see strikethroughs in my text)  , but that could be a little less unfriendly... "Before reporting problems with your board running Armbian" or ""Before reporting problems with your board running Armbian, check the following" ... something like that?

[pfeerick]

Oh FFS... now the forum ate half of my post because I went back to turn off the code syntax highlighting!  

 

I had basically said that if we want to be stuck in a vicious cycle of saying 'have you checked this' and 'have you checked that' then, sure doing things the way they are now. Or if you want to be proactive and head them off, add some simple checks that you can point to and then say here are the docs that explain what the problem is. 

 

And no, no-one gets paid for this. But time is time, and I'd rather spend it doing other stuff, rather than answering the same question day in and day out. And scaring people off is not what I want to do either, because that doesn't achieve anything other than annoy and frustrate. I'd rather be promoting a community of people that share ideas, problems and solutions. I'm just thankful that some manufactures are listening, including the infamous supercomputer SBC manufacturer, which should now be using a barrel jack instead of a micro USB connector for power (which doesn't help people with the earlier revisions, naturally) and was incorporated into their designs for future products. Yes, mistakes are still being made, but so is progress. Sometimes. Doesn't mean we should let up the pressure on manufactures to do the right thing, but something is needed to protect the sanity of Armbian folks from their stupidity. 

 

Anyway, was this the sort of boot test you were thinking of?

 

Spoiler

[Unit]
Description=Armbian quick power reliabilty test
Before=basic.target
After=sysinit.target local-fs.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=-/bin/sh -c "/usr/bin/timeout 60 /usr/bin/cpuburn"
TimeoutStartSec=70 

[Install]
WantedBy=basic.target

 

 

Obviously /usr/bin/cpuburn would have to be added into the right place.  This if course doesn't go any further than the power-on test... there's no linkage to MOTD or anything. I was thinking of a script that checks how many attempted starts there have been, and then after a set number, say on the third fail, it bypasses, cleans up its attempts tracker, and touches a file that can can trigger a permanent MOTD warning. Then if in the future the user changes their power supply, they re-enable the service, and run it through again, where it will clear the MOTD warning if the test passes. And it's linked to the firstboot process, so it is disabled once first boot completes either way. Bad idea? Waste of  time?

 

And then as you said, add a more rigorous 3-5 minute test to armbianmonitor -c . Then that becomes the standard diagnostic if anything possibly power or microSD related is reported. 

[Igor]

49 minutes ago, pfeerick said:

I had basically said that if we want to be stuck in a vicious cycle of saying 'have you checked this' and 'have you checked that' then, sure doing things the way they are now.

Well, we have to force (with nice words of course) to check at least 1,2,3 basic things. If they would do that in first place, huge amount of time would be saved. On both sides and we would be less stressed out.

The main idea is that, they do something, before seeking for attention. Basic checks and preparation  .... that not first question on support is: please provide logs, chech this ... but filing an issue looks like this: "here are logs, I checked this but the problem is still here ..."
 

I changed the title to some generic one. I hope it sounds better now  ... I am adjusting, unpinning and moving stuff, starting in A20 section. Let's wait if anyone else has any complains about this message, than we can enable this ... 
 

[tkaiser]

2 hours ago, Igor said:

Let's wait if anyone else has any complains about this message, than we can enable this ... 

 

I'm fine with it but maybe it's good to mention how to create logs too?

 

Besides that it would still be great when 4 additional posts are added later that will be linked to from the pinned 'header': SD card issues explained, underpowering explained (both with links to success stories), bad board design explained (maybe just a few flaws listed and only moral of the story 'do some research first, search the net, don't trust in advertisements) and how to provide logs (upload functionality, manual functionality, importance/difference of serial console). But all 4 topics can be added later of course.

[TonyMac32]

2 hours ago, pfeerick said:

Oh FFS... now the forum ate half of my post because I went back to turn off the code syntax highlighting!  

 

I've had absolutely no issues with the forum, but now both you and tkaiser have mentioned it eating input.  Browser of choice, perhaps?

[chwe]

Since this thread is started, a lot of improvements are made to clean up the forum. Also a lot of cool ideas to avoid same questions again and again. I have one for the Getting Started guide. Here's the part of burnig the SD-Card:

Quote

7z and zip archives can be uncompressed with 7-Zip on Windows, Keka on OS X and 7z on Linux (apt-get install p7zip-full). Raw images can be written with Etcher (all OS). Image writing takes up to 2 minutes on a good SD card.

Why don't we add one sentence about why we use Etcher to burn Armbian on a SD-Card? Something like: Compared to other burnig software like win32 etc. etcher validates the image after burning so that you don't run into SD-Card corruption. 

On the SD-Card part there is clearly writte what TK found out with all his tests, but the reason why someone should use etcher isn't that clear. It's obvious that not every one will read it, but most of the blogs I saw in the past, copy-past their sentences from docs to save time, and hopefully they'll 'spreading of the gospel' 

 

Thinking about 'The Ten Commandments' of armbian:
1. Use a reliable powersource
2. Burn your image with etcher
3. Tbd

Nobody calls into question the ten commandments, whereas a lot of people does this on armbians recommendations...  Ok, sounds like a religious armbian sect (time to go to bed  ). 

 

Edit: Just had to search to find my own thread about my IoT stuff that I'm doing.  I miss somehow a subforum where users can describe their projects. For sure they can write a tutorial, but it can inhibit the less experienced users to call it a tutorial (I would never call my thread a tutorial cause it started more or less as a link sharing of some stuff I found with google, as soon as I have more time & being sure that everything works fine, I'll rewrite it to make something that I would call a tutorial).

[pfeerick]

8 hours ago, TonyMac32 said:

I've had absolutely no issues with the forum, but now both you and tkaiser have mentioned it eating input.  Browser of choice, perhaps?

 

It's just IPB being IPB... all the fluff and 'pretty' stuff it does sometimes comes back to bite you. Made the mistake of double-clicking the code block to edit, for some reason it then promptly decided I really wanted it to be sole contents of the post, and I had already hit save before I realised it was going to trash the post on me. I'll live.  It may not! 

 

Oh no, now you done it @chwe ! You should know better than to bring religion into the mix! :-O All I can say is.... here's the github page... see if you get a PR past the four disciples!  

'

 

[tkaiser]

5 hours ago, chwe said:

Why don't we add one sentence about why we use Etcher to burn Armbian on a SD-Card? Something like: Compared to other burnig software like win32 etc. etcher validates the image after burning so that you don't run into SD-Card corruption. 

 

https://github.com/armbian/documentation/commit/8271943480ebba13ded9e86ddea238cac02b7d35

 

Once there is a thread collecting 10 'It was the SD card' success stories the bold 'saving you from corrupted SD card contents' part can be set as link to this thread. 

[StuxNet]

On 6/25/2017 at 8:21 PM, Bubba said:

You must FORCE us provide the info. needed to help us, get us to READ the docs and How to’s.

 

The more effort you make us put into solving our own problems... the more we learn.

 

Because I used cheap SD cards for weeks without issue, once a issue came up, I dismissed the SD as the possible problem because it had never been an issue before,

and I JUST KNEW it could not be...well you know what happened….wasted hours of time...time I do not have much of…

 

By not listening to the folks here.. who know what’s what’s….I broke one of my basic rules….

 

“You must learn from other people’s mistakes. You can’t possibly live long enough to make them all yourself.”

Sam Levenson

 

Reading this made me realize that it would be pretty dope to have a mandatory 'quiz' for newcomers. At least a quiz before being allowed to post, PM or w/e. Cover the absolute basics that are....

• Which IMG burning software is recommended by armbian? A.) Etcher B.) Win32 DiskImager?
• How do you know you have a proper power supply? A.) Cable? B.) Multimeter? C.) How can I possibly know?

Redirecting newbs to a 3+ question quiz, that wouldn't even need correct answers, wouldn't be hard but I have no idea how you'd do that or if it would even be possible to integrate into the forum for granting posting permissions, etc.. I completely agree though, "You must FORCE us." Because personally, I rarely read every ReadMe/FAQs/Etc....  out of technical hubris and the fact that 9/10 I do just fine. As result I arguably save time just jumping right in as opposed to reading stuff I already know or will learn along the way or through osmosis.

Like Bubba mentions though, every once in a blue moon that 1/10 times comes back to bite me. The difference is that I always keep an open mind to the stupid things. SD Card, New Micro USB, hardware, software, etc... And when I'm being bitten, I never take it out on the free community who gave it away in the first place while completely rejecting any free help. ie: I'm always left smacking myself in the head, not someone else. Anyways, that's a little winded to say, It sure would be nice to force newbs to educate themselves, more so if their posts content is going to be about the basics.

[Igor]

Quote

Reading this made me realize that it would be pretty dope to have a mandatory 'quiz' for newcomers. 

Actually we could create this as an automated prove that they are human - currently moderator has to approve users first post - I'll check if forum software can handle this.

 

I know that it's hard to force users to read manuals prior to jumping here and bubbling about their problems: "please please, help me, nothing is working, you have to help me, my time is very important, why you don't provide a working product? etc." I am sure we won't get rid of time to time outbursts of this kind, but I am sure we made some progress. Awareness is the key and its hard to miss texts saying something about power and SD card problems. Over and over again, each time they open a forum topic ... brainwashing works This will of course work only on steady and regular users, while complete newbies can and will overlook even the most obvious messages. Even we would provide any other obstacles, they will rush to see how to get out of the trap without actually reading anything.

We made a progress by adding big notes, we have more man power to cope with standard issues and we have to start using certain tools, which are here by default and help to cope with this kind of situation.

[Bubba]

Where is the "Getting started guide"?

I think it should pinned at the top the page.

[Igor]

9 minutes ago, Bubba said:

Where is the "Getting started guide"?

 

Added yet another link - directly to "Getting started". @pfeerick I hope words are not too harsh ?

[Bubba]

The guide that got me started off right was much shorter, I can not find it now (could have been linked at the OrangePI forum)

something like

Getting started:

Purchase only High Quality class 10 or better SD cards, from this list (had a link to a list of cards).

Use only approved power sources. ....DO NOT USE phone chargers. 

Download and install ETCHER (linked) to burn the images with, by using any other software you will just about guarantee failure at some point.

it had few points more but it was short easy read....

[Igor]

Perhaps we can make a quiz after all  It does the job: "promote members to a group when they reach a specific rank in the quiz"
https://invisioncommunity.com/files/file/8381-quizzes/

 

@tkaiser Would you like to design this member evaluation quiz?  Even if we have only this quiz its worth the trouble.

 

2 minutes ago, Bubba said:

The guide that got me started off right was much shorter, I can not find it now (could have been linked at the OrangePI forum)

Well, some people would want to know more and some explanation must be present.

[zador.blood.stained]

3 hours ago, Igor said:

Actually we could create this as an automated prove that they are human - currently moderator has to approve users first post - I'll check if forum software can handle this.

I would rather prefer to leave premod enabled. I don't know if we could have a good enough quiz that can be applied to all supported devices.

 

And for the common issues - IMO we need a separate, better designed toubleshooting page in the documentation. Current one looks like an irrelevant wall of text with some SD card pictures (embedded into another wall of text called "Getting started"), so no wonder that people choose to ignore it even if they are pointed to it.

 

And maybe we could have a special subforum and move all SD and power supply issues related threads there.

[TonyMac32]

I've run a couple small forums for Assembly Language programming/etc, I can say that no amount of quiz keeps out the machines.  And let's face it, do we want to make the bots smarter by feeding them harder puzzles?  Soon they will gain sentience. 

[Tido]

I like the Quiz idea.

Before Software download and first posting

What is the Power ratining of Micro-USB in Amperé:  1   1,8  3 ?

and some others eg. for RPi users and such.

And show after each answer the right result and why.

[zador.blood.stained]

5 minutes ago, Tido said:

What is the Power ratining of Micro-USB in Amperé:  1   1,8  3 ?

And this applies only to boards powered through microUSB. We could solve this differently - mark all boards that use microUSB as a main power input, and for those boards adisplay an extra warning page when user presses the "Download" button. Or possibly drop support for some of them, maybe "Armbian drops support for X,Y,Z boards due to hardware design flaws" with a good detailed explanation will provide more attention to this problem than any warnings or troubleshooting guides.

 

Again - I don't really like the quiz idea. Even though powering and SD cards are the most common hardware issues, they are not that common compared to total number of installations on all boards, and percentage of users registering to report "armbian does not boot please help" is relatively low too, IMO thanks to Xunlong fitting most of their cheap and popular boards with a barrel power connector.

 

Regarding SD cards issues we have to check how much disk space do we have on our download server and what is the status of Etcher specific archive formats. Maybe we could build Etcher compatible archives and link them on download pages, while linking "normal" images as "Other download options" or hiding instructions for unpacking Ethcher compatible images somewhere deep in our docs.

[Tido]

I like this one:    an extra warning page when user presses the "Download" button.

 

6 minutes ago, zador.blood.stained said:

hey are not that common compared to total number of installations on all boards

you are right. We shouldn't get lost in it  BUT  a couple of bad forum posts (not here) and some blogs  voila you have the bad reputation.

Dropping support is not really necessary as my R1 with spindle drive and short Micro-USB cable proofs, not to forget the GPI/O power options.

Edited June 28, 2017 by Tido
added I like this one