Igor

unsupported builds have weekly auto-builds and at one point it started working. i already removed that part of the text.

Logs says you are compiling quartz64 ?!

I suggested you something entirely different based on knowledge and experience. Not sure that it will work, but success ratio is much bigger. What Does Community Support Mean? Community maintained boards are not officially supported by the Armbian project. These boards are maintained (or not maintained) by community members (like you). These builds are provided by the Armbian project as a service to the community. They are automatically generated and untested! Maintaining custom devices is extremely costly and this level of support from your side (for whole project) is not sufficient (1/100 of needed for current level of work) for proper maintenance or R&D. For every USD of donation, we need to find 500-1000, often a lot more, from our own pockets, do it for free, to keep those devices operational. At one point we need to cut devices off to random community maintenance. Community help exists, yes, but it is small and fragile. You can't or don't want to support us financially? No problem. There are volunteering positions. If they are not filled, project struggles - if project struggle, we can't address common nor egoistic technical issues. If you help to refactor documentation, for example, and have some luck, you can get a high end workstation from us. See? Your contribution to common work is essential, not telling us what is wrong. We know for many many problems, but we can't resolve them. We lack people / resources / your support to fight them. Still, we provide images and they might work good to some degree. If they break, yes, you are welcome to report it here, but don't expect solutions. Team is overloaded with, very limited, officially supported hardware. And this board is not among. I would naturally like to help you with this problem, but I (or people that helps) could realistically look into this once mid next year as there are many other unresolved problems waiting in the list. You probably expect this to be fixed "yesterday" ... impossible, even if you start to respect our time and buy at least one hour at this level. No you will not. Why would you? There is another workaround / hint - use older images from archive. Some will work, but yes, update will kill them - don't update. Remember, not even officially supported hardware has professional level of support. Only better.

If this is minimal image - we have changed networking config to NetPlan: https://docs.armbian.com/User-Guide_Networking/

No, pathches will not apply for this kernel. That is just an idea. Path suggested by Nico might work. But that kernel is old ... With other limitations. Wrote on mobile

Oh. I didn't looked into the code ... We have a few of patches for previous generation in order to work (better), but on mainline: https://github.com/armbian/build/pull/6057 https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.6/rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch

Known problem. https://armbian.atlassian.net/issues/AR-2434 It is probably solvable with enabling correct overlay. I can see we don't have a dedicated for ITX board, but try others. @amazingfate Should we put this into main DT instead so its just enabled by default?

Try to build Noble with EDGE 6.10.y kernel - I think all this already works. Legacy kernel, especially 5.10.y, is too broken in many aspects and will never be updated = waste of time.

OK, then its something else apparently. We'll keep an eye on it, but if Ubuntu based variant just works, use it. There are no Canonical services in it so its more similar to Debian then regular Ubuntu for desktops, just better as packages are a bit more recent, more polished.

Vendors kernels are frozen in time and maintained only at HW stack level, while the rest is "as is". Which is why we all want mainline ... which is even a lot more expensive to make and maintain. It could be days, which can extend to weeks, of work with no warranty of success to sort this out - porting this kernel feature from upstream patches: https://www.kernel.org/ Here is best to wait for next kernel update by Amlogic, which is usually based on updated kernel stack.

[Task]: Verify all build commands and remove deprecated https://github.com/armbian/documentation/issues/467

Armbian kernel can be used on any userspace, but we only sent kernel updates to supported ones. Buster is EOL by Debian. Can you provide: armbianmonitor -u so we know more about your image. You are probably running Buster BSP package. That is not replace with upgrade.

Check /etc/netplan/10-dhcp-all-interfaces.yaml correct: name: "e*" wrong: name: "*"

We fixed one known bug two weeks ago. If you tested older images, then this is it. It only affects minimal images. https://github.com/armbian/build/pull/6990 That is not needed on kernel 6.1 ->

No. You need more recent ZFS, which comes with supported Armbian OS, which is Bookworm. Bullseye generally works, but we don't support it anymore as upstream is also deserting it. We ship ZFS v2.2.4, soon upgrading to 2.2.5, but only on: All those headers are useless, remove them, also generic kernel 5.10 as it probably won't even boot. You need: apt install linux-headers-current-rockchip64 Fresh Bookworm image, same (sub)arch:

I think this part is safe to ignore. Wireless works, BT scans finds nothing (this perhaps needs fixing). But this hardware is too old to bother with. Its more like a reference to see if Allwinner A20 generally works. That is important part, yes. Do it always the same even not most optimal ? We don't have this info in db at the moment. Its binary - board failed completely, not responding but it should = error at CI level. There were few people saying that they will help to develop this test framework, but its only what I wrote some time ago.

.20 is good indication, but we will try to stabilise around .43 https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi64_common.inc#L33 (or higher) but we need help in debugging. Currently it is more or less only @going trying to fix this but its a lot of work. https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results Smoke tests shows instability on Allwinner herd, but this is all what this primitive testing tells us. There is also another attempt bumping to 6.9 https://github.com/armbian/build/pull/6941 while we should be at 6.11.y already. That would help narrowing down this problem too.

Should be fixed now. base-files are now in correct place and repo should be in sync. https://fi.mirror.armbian.de/apt/pool/bookworm-utils/b/base-files/ sudo apt-update sudo apt-upgrade should do.

I think I fixed it, but review and testing is needed. I won't have time for this anytime soon https://github.com/armbian/build/pull/7019

Noting unusual as this hardware is community maintained. If nobody maintains it, it will stop working at one point. We provide images but these builds are provided by the Armbian project as a service to the community. Some HW works, some don't. They are competing with us, but we don't compete with them. In past 10 years, since they start to use Armbian as their starting point of re-branding, there were few fixes (<5) from their side, but all were very carefully egoistic weighted even they had balls to come here and humiliate developers with demands to fix this and that for them (their users). So you can understand how they think ... For this hardware you need to be a developer as support is immature. Whatever OS you will us. Its not just cable.

Try this way:

https://docs.armbian.com/Developer-Guide_Adding-Board-Family/

I don't know if hat is a cleaner way. This is just a suggestion / idea based on a quick search. Didn't test it while @dziekon did. As I understand it, but didn't really study it deep, that DHCPing on all devices is a trouble. But there could be more (border) problems.

This should also be ok now (run sudo apt update to make sure you have latest lists). File is present: https://imola.armbian.com/apt/pool/jammy/b/base-files/

Yes. Or update, install headers and try to build this driver via DKMS. But it might be challenging ...