Werner

moved

moved to tvboxes

So tl;dr: trunk is broken, stable works.

No reason. In this particular case however it might been the influence of the BSP. Well there is no warranty that it gets accepted, however if it is well documented and enabled across all configurations so people/maintainer have a chance to test I don't see a reason against.

We could delete but it would be worth more if you would share your solution.

If the board runs just fine with the currently installed firmware leave it, freeze it again and you are good to go.

It is always handy to have multple sdcards from various vendors with different sizes laying around since there are a few boards out there that are picky about sdcards. For example I have a Nanopi R4S that refuses to boot from 64G microSD Sandisk Extreme U3 but works fine with the same model in 32G. Anyway since it has been confirmed that the image works I assume either broken PCB, bad SD or powering issue where I guess former is the case since undervoltage should not be an issue with RPi charger that outputs slight overvoltage by default.

Best chances for debugging boot issues is a USB UART adapter to get output of the serial console. @schwar3kat can you confirm broken boot?

RPi3 compatibility seemed to got lost with the latest release. Reason unknown. Try older release. Be aware when doing do and upgrading firmware it might ran into unbootable state again. Feel free to do so anyway and report if that is the case.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

You are doing great for your first time (on a forum 😄). A good point of start is always to provide basic debugging information. Open a terminal window and put code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } sudo armbianmonitor -u into and paste the output URL here.

You know it is Armbian, not Arabian, right? 😄

Finally I found some time to watch the video. In the past we indeed followed the concept trying to centralize stuff and build it around forums which I have to agree is not ideal environment for developers. While increasing fragmentation I think giving Github discussion a try is worth it. To limit the freshly created fragmentation the cheapest solution would be to mark all other communication platforms Discord/IRC as exclusively community only. No developer talk or discussion. Same for forums but including the business stuff. Regarding moderation I don't think Github will need much moderation. Not in first place at least. Also here I'd say give it a try and see how it goes. Nothing we could not handle by yourselves. Regarding discussions in PR after merge I suggest to lock conversation in those once the Github discussions are in place. I like the idea to automate that.

Serial console is still best chance to get at least something. Make sure to change verbosity to 7 in /boot/armbianEnv.txt and reboot before attempting this again.

Well you cannot tell Armbian's redirector to choose a different mirror. However you can adjust the sources.list by hand and add a (packages) mirror that you like from this list manually: https://github.com/armbian/mirror

Desktop environment is not necessary for building. Check output/debug/ folder for more clues why it fails.

Again this is most likely handled in userspace, therefore causal tutorials for Debian/Ubuntu apply so check here: https://www.google.com/search?q=usb+tethering+debian+linux

https://gitlab.com/bztsrc/usbimager#installation

Unsupported build environment. https://docs.armbian.com/Developer-Guide_Build-Preparation/#what-do-i-need

moved

Posting the same question on multiple occasions is considered abusive behavior.

Is that arm'ish enough?

"other" is an option for choosing tag. moved.

This might be an option for you as well: https://gitlab.com/bztsrc/usbimager Lightweight, runs on many OS, no spyware controversy