Igor

It doesn't have someone https://forum.armbian.com/staffapplications/application/8-single-board-computer-maintainer/ to take care of issues in order to get a better status: https://docs.armbian.com/User-Guide_Board-Support-Rules/

This problem was fixed but hasn't been released yet. Once it will be, there won't be any need for searching and switching to older kernels, where this function was still working.

Wait for release or build from sources.

https://github.com/armbian/build/tree/master/config/boards Add BOOTFS_TYPE="fat" to the end of the board config file. Perhaps it works if added as a parameter. But this is internal switch - if it won't work properly, its on you to debug.

Today's RC build (images has just been updated) is first, finally, after two weeks of constant struggle (bugs in CI, bugs in build process, bugs in hardware) that was done almost without errors. Just a few images has to be re-done. Thank you all for helping fighting bugs! Those need attention before release: https://armbian.atlassian.net/browse/AR-1197 https://armbian.atlassian.net/browse/AR-1196 https://armbian.atlassian.net/browse/AR-1198 If possible: https://armbian.atlassian.net/browse/AR-1186 https://armbian.atlassian.net/browse/AR-1186 https://armbian.atlassian.net/browse/AR-1176 https://armbian.atlassian.net/browse/AR-1158 I have manually (some via automation) tested: VIM1, VIM2, VIM3, Opi Zero plus2, Jetson Nano, Orangepi One, Orangepi Win, XU4, C4, C2, Cubox, Clearfog pro, Rockpi E, Nanoi pi M4, Opi Zero, Udoo quad, x86 UEFI

If its a bug, we have to fix it. Probably you need to set .ignore_changes ? Actions scripts are using this principle, so I didn't even notice there is something wrong.

This way: https://docs.armbian.com/Process_Contribute/

https://www.google.com/search?q=Can+you+pleas+tell+me+what+should+I+do+with+.zst+image&sourceid=chrome&ie=UTF-8

https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Check the rest of the FAQ too.

@Yakovis listed as a maintainer and could know what is the status. I don't have the board nor time to deal with this hw in particular. Currently we are trying to find out status for upcoming 22.05 release. If that would not be possible, we will be forced to remove the support status and cut down investments, "competition" included. Usually if one doesn't boot, others will also not boot since its something wrong with a boot process. If hope those boots as expected: https://imola.armbian.com/dl/radxa-zero/rc/ Since they are abusing our resources they must have more time to test. Going that route seems to be the right way and we all will have much worse software support, but otherwise doing well. By getting a subscription you can help mitigating costs. Regardless which OS you will use, original or copy.

Yes, it was tested, briefly, but since we don't have a dedicated maintainer or support sponsor, there is nothing we can do. Images will still get better and better since general support will be there and kernel support from Raspberry Pi foundation is also updated almost daily. But for those things in between additional man power is needed, which we can't find or hire (we already generate loss).

OP place this question on many forums and chat channels so I am sure he found it by now. AFAIK we also do but he can also look into the code like anyone else.

The case is that with all those actions we are actually forcing you to start thinking about supporting us - currently you support our work with less then 0.5%. We can raise this number in two ways - cutting the value we are giving or you start giving something in return. If we fail to persuade you to help and invest into our work, we have nothing to loose. You loose. Our copy cats can only provide the same. Alternatives are here to deceive - add as low as possible or just something and take as much as possible. Remember that by using our kernel means they don't need to invest nothing into R&D, sales only. This is totally different league. We have to. Their support, when it comes to expensive to solve problems, looks like this: Their "customers" which costs them close to nothing, but costs us a lot, perhaps even donating them money because (our) OS works so good ... They steal from our work and also steer their customers to us to steal more, even we asked them not to, even they know we will not support them since we have no budget to support expensive technical problems even for people that believes in us and supports us. In case you don't want to have half working software that is destined to fall apart sooner or later with fake support or as cheap support as possible (Manjaro, Arch, Debian) you actually have no alternative.

Locales problem again - are you seeing this: http://ix.io/3Yhy Seems to be Debian bullseye thing, since Jammy doesn't have that.

That is possible, but features in mainline kernel are breaking down in regular cycles if not maintained. Most people wrongly assumes works is done when hardware reaches mainline, but that is not the case. When hardware, especially of cheap HW such as Rock64, gets here (never with all functions supported) it starts the journey of breaking its usable features down. We are seeing this everywhere and without our intervention many board would not be usable at all anymore. Those interventions could (are) easily costs somewhere between 5 and 15k euros per board per year. Current cost covering scheme - you as our "clients" are only adding 0.5% of needed. CSC -> Supported didn't fix you the problem. It only helps sharing the non most critical burden: Someone will keep a list of what is not working, but he/she is not obligated to do anything. We also accept people that has no clue about R&D. If this would be a requirement, most likely nobody would show up. But this is again just a wish / theory - in reality - very little of those that joined actually does anything on that list. They report nothing, they don't (all) participate in release process. When there is no help, status is going back again ... If someone pays hours needed to fix the feature / bug, someone will try to fix it. If not, bugs stays. This is not a problem of Armbian since public is not even trying to cover expenses related to keeping the device usable.