Igor

Once PR is merged, automated nightly beta repository has this kernel within hours.

Sadly no. https://github.com/armbian/build/tree/main/config/boards There are (too) many boards in the system, added by random people (this is build system and we accept anything that builds, but we don't maintain those boards as we can't afford associated costs / there are not enough resources), but only supported / .conf are recognized until there is someone willing to maintaining them and fits condition of "supported" board. When we find out that conditions are not met anymore, they are "un-recognized". Support is defined under those rules: https://docs.armbian.com/User-Guide_Board-Support-Rules

Welcome to custom hardware / division exotics / subdivision retro It is hard already when its new custom hardware and main division. If nobody ported HW to mainline Linux and keep it operational, its usually quite a long path. Armbian provides build framework, that helps in the process, but hard work is still on the one that will deal with the SoC - here you can hope to find someone on forum(s) to share some specific ideas. Adding is fairly straightforward https://docs.armbian.com/Process_Contribute/#adding-a-new-board but if there are sources for boot loader, sources for kernel, or better - support in the mainline kernel. Even when you have all this, it can still be quite challenging. Each such board usually require more people, a team. When I recall how many months we lost on one of Marvell's 🤔 Espressobin is an example how board support can be made super complicated - check history from day one. If board support package is on that level ... its worse out of all we have seen here. And now its an old hardware, not interesting so much. And remain broken as we don't have anyone to deal with it / its not worth.

Feature regressions are expected - Linux kernel is complicated machinery and without spending hours, a day or a week investigating, it's usually not possible to tell. We don't touch Rpi kernels much. We have our own kernel config, but we use official Rpi sources, so I guess 1st step would be looking if someone reported something similar https://github.com/raspberrypi/linux/issues By newer you mean 6.12.y, 6.16.y ... or 6.6.63 ->

I hope you flashed u-boot from armbian-install ? U-boot package does not update u-boot automatically.

It works with Armbian too. Just two years ago it was not in good condition

Solved.

Check this thread

Gnome uses Wayland and there some features don't work ... switch to X, where you will loose some functions, but remote desktop will work. FYI: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

https://github.com/armbian/build/pull/8334

Perhaps try one of these https://docs.armbian.com/User-Guide_Armbian-Software/Management/ They cover most of the use cases. Otherwise, XFCE is lighter and more appropriate for the job.

We don't provide anything lighter then Gnome and there are some weird desktops in the build system, which most likely don't assemble as they are abandoned for a long time. I am not a Desktop guru ... perhaps someone else could give you other suggestions. I think Gnome is still the safest way, even it might eat more. But our Gnome is at least more or less vanilla, so no (Ubuntu) stuff coming with it.

This needs to be enabled: https://github.com/armbian/os/pull/332 As we started with a model without HDMI port, this was simply overlooked. Build with: ./compile.sh ENABLE_EXTENSIONS="v4l2loopback-dkms,mesa-vpu" That I don't know how it works if at all. Wayland is troublesome even on 1st class x86 hardware. Update: will rebuild images later today with mesa extension enabled.

I'm more concerned about what version 5 might break. Still, I don't think anyone makes Facebook account in order to login to Armbian forums 😄 and GitHub is not far from those I am afraid By the end of the day, this would be a symbolic gesture that works against practical ways. I think most of people uses Google login connector. Do we have any stats for that?