Werner

Ah okay, so some manual hacking was still needed.

moved to userspace related issues

Slightly off-topic but interesting. Quite a while ago I tested a 16:10 monitor with 1920x1200 resolution on the Station P1 I could not get to work with other kernels than legacy 4.4.y. Which branch did you build against? current or edge?

3rd party sources. Case closed.

moved to offtopic since neither a board/device Armbian has ever seen nor related to Armbian at all.

IIRC there is some sort of Asus related package within Debian/Ubuntu repository. Maybe that will deal with your issue. Regarding forums I do not see any further content from you. New users are limited in posting for a short period of time. This measure is unfortunately necessary in order to fight spam.

Not sure but I think there were some very recent changes about this pushed to master (?). Maybe check against trunk images? (https://github.com/armbian/build/releases/download/23.02.0-trunk.0191/Armbian_23.02.0-trunk.0191_Orangepi5_jammy_legacy_5.10.110_minimal.img.xz) Regardless, all pre-built downloadable images from Armbian are built using the same build script as it is available on Github. Just with a bunch of - partially undocumented - switches that allow better automation and build distribution in that matter.

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.