Igor

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?

If this worked for you, I propose to open a PR, so there is a GitHub record of your work. Add it here https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.12 Here you also need to pay attention to add to series* files.

Not supported by forum software. Keeping Facebook and Google operational requires constant attention and adjustement, while others worked so far without troubles.

Added instructions for joining your home lab: https://docs.armbian.com/WifiPerformance/#adding-a-new-device

FYI. HDMI out is broken on those board at the moment. Try to access the board remotely. We don't have people to maintain those old boards.

True. Also on most computers we have eth0 Not just eth Devices naming is a cosmetic thing from the outside / user perspection, while it has consistency issue from the inside and currently breaks initial (default netplan) configuration. Our job is not to tell user how to configure his network, but that network devices gets up at first boot. Now they do. Job done.

I just found one weird setting on R6S. Can you provide what is in this file: cat /etc/udev/rules.d/70-persistent-net.rules Reference for what to do: https://github.com/armbian/build/pull/8325

From the picture - I can only guess that kernel package was somehow not upgraded properly as kernel image files are missing. Perhaps they were removed by accident or there was some disk / file system troubles involved. @Chris007 Try hints from here: https://docs.armbian.com/User-Guide_Troubleshooting/

To be more precise - parameters that are provided to that driver. If driver would be the problem, both NICs would be down. You need to find / create correct settings (device tree), based on schematics. This forum (search) can provide plenty of resources and hints how to do this. Someone from community (with the device so testing can be done) has to sacrifice afternoon or more to get this in operation.

With logs, we could see if this is NIC not recognized or network stack problem. Community supported target are often not having anyone behind https://docs.armbian.com/User-Guide_Board-Support-Rules/

It's a progress! This or similar problem was seen / reported on H3 too.

It is possible that broken patch removal is already a solution.