Igor

True. More precisely in the driver or somewhere close. But kernel is a work of thousands of people and we are just a few that support this project. It is good to bring this up, but you are using board we don't support (Bpi M2U) and hardware we have nothing to do with (DVB tuner) and we never provide any support. If it stopped working ... its mainly on you to fix it up, perhaps try to find if someone knows something. Even you are willing to cover debugging and fixing (count few days, perhaps weeks), we https://github.com/armbian/build/graphs/contributors?from=2020-01-08&to=2020-07-09&type=c can't afford to help you. We are overloaded with, 1000 x too many, issues already "addressed to armbian", while we have nothing to do with them and we will not do anything about ... I hope you do understand that.

Everything is correct, just script loading is probing one after another since different configuration are possible ... without boot.ini loaded, you can't boot.

Somewhere here: https://github.com/armbian/build/blob/master/lib/configuration.sh https://docs.armbian.com/Process_Contribute/ Also about other bugs yet to be discovered? And who has to do that?

You can try with this tool: https://github.com/zador-blood-stained/fel-mass-storage ... but it was never tested with this hw so its on you to find out. Support terms: https://github.com/armbian/build#support

Everything is fine but your monitor which doesn't show the login prompt. What if you type ENTER few times - can you login ... how? https://docs.armbian.com/User-Guide_Getting-Started/#how-to-login

We are having a slightly different approach. Lima is enabled, but acceleration is disabled where broken - on Bionic for example. On Focal / Bullseye it works, yeah. For headless devices, its blacklisted with a build config: https://github.com/armbian/build/blob/master/config/boards/nanopiair.conf#L6 Tnx for the tip. Cheers!

Providing logs with armbianmonitor -u significantly raises chances that issue is getting addressed.

https://github.com/armbian/build#support

It helps and its already solved. https://docs.armbian.com/Release_Changelog/ https://armbian.atlassian.net/browse/AR-305

AFAIK all possible acceleration for imx6 has been mainlined and they are most likely enabled by default. Old 3.14 and 4.4 kernels were dropped long time ago. You will need to research the topic. Without researching ... I don't know. We never maintained this functionality. We care about basis functionality and if that works and if we have spare time (which never came), we proceed to such fancy and expensive to maintain functions. Armbian provides builds tools which gives you a solid base. General support terms: https://github.com/armbian/build#support

No problem. In context of mvebtu there is not muc, perhaps switching DEV to 5.7.y if not already? More complicated is E-bin upgrade. We stuck at 4.19.y ... https://github.com/armbian/mpads/pull/3 Do we need 3rd party reviewing here, perhaps @martinayotte find some time? Perhaps this needs a bit more clearing / explanation? I am not sure that I understand what options do we have here and why would we need to change this ... ?

Possible / planned ... when we settle up our CI rearrangement ... which is getting extremely complicated and expensive to maintain. If you want better support, you are welcome to add your resources. With trunk we are already at 5.7.y while for pushing updates from a previous build system stable branch we have no maintainer(s), build (probably) fails ... Kernel 5.4.y was first kernel where this hardware become usable to some degree. With 5.6.y some features were fixed, with 5.7.y a bit more ... there are ofc some problems ... one annoying problem which we are sorting out ATM is that board sometimes doesn't come back after reboot. It stays powered off ... This problem was so far only in 5.7.y Philosophy regarding "stability" is slightly different, until software for this particular hw matures. We are not there yet. So it usually doesn't really matter if upstream kernel is LTS or non LTS.

Selinux - also my primary suspect in this case - should in theory be disabled in userspace / on target by default. Perhaps this is not enough or not working properly ...

Worked after this?

Providing logs with armbianmonitor -u significantly raises chances that issue is getting addressed.