Igor

We (I think) hopefully fixed the problem. Is this still happening?

Use v24.02 or take commit id from there.

Such board does not exists. It exists with H2+. Which is H3 - 4k video. Which is anyway irrelevant for this use case. Armbian support it as any other Linux distribution. https://docs.armbian.com/User-Guide_Board-Support-Rules/ This means. We don't know if images https://www.armbian.com/orange-pi-r1/ works and if you will have problems, you are on your own to fix them. As this is old and simple board, it will probably just work.

Yeah, mirrors syncing / checking which are in sync is not working perfectly well. Yet. In a day, those random errors should be gone.

This is by design. Community maintained targets are hosted at one location only, GitHub. We can't host everything at our primary fast download network. And all torrents have HTTPS sources, this file just one (1). This file changes every week, so there are slim chances file will have more then one seeder (GitHub 1x). Torrents from standard supported hardware should maxed out your download line. I needed 2 minutes to download this file successfully.

Fixed.

Keeping this in overlay is probably best way ...

It is. Wait. We are working on it. https://github.com/armbian/mirror/issues/16

It is included there too, just there DE doesn't need / know how to use that for DE functions.

It should work out of the box with Gnome desktop image. This is nothing related to 3D, but some tweaks / optimizations, more DVFS points which we might be missing out, not sure ... we'll check if we miss something. @ALIGMSTEN @Gunjan Gupta

That is wrong image which is the reasons why it doesn't work. https://www.armbian.com/download/?device_support=Community maintained and search from correct hardware / image.

https://github.com/armbian/os/wiki/Import-3rd-party-packages This was made to support Raspberry Pi 5 desktop acceleration. https://github.com/armbian/os/pull/167/files Yes, its in testing repository, so no harm was made. I have disabled this and within next repo update this won't be a problem anymore.

- tested image for Khadas VIM4

- fixed and tested images for Khadas VIM1S with install to eMMC - updated my test instance to 2024.2.5

WiringPi is deprecated, must be some other high level lib that works with mainline kernel. Also you usually can't use applications designed for vendor proprietary kernel with mainline derived kernel. Check this instead:

Device is currently not supported by Armbian team due to lack of support for team resources (people that sponsors software support for you and HW makers). Don't worry, support can't be worse then Debian / Ubuntu / Manjaro / Arch / Orange * Linux quality level where such deal comes by default. https://docs.armbian.com/User-Guide_Board-Support-Rules/#community-maintained Few ideas how to resolve this problem: code and SDK can be download here: https://github.com/armbian/build Download, fix the problem, integrate it. Don't know how to proceed? Hire developer that is familiar with the topic, compensate his time and share the fix with community. .. or revert kernel (via armbian-config) to last working one and forget about this problem, and minimize chances of further collapse, and/or just wait that someone volunteer to fix this problem. And nobody know what you mean by "latest kernel" -> https://forum.armbian.com/topic/5699-how-to-provide-and-interpret-debug-output/

Install it via armbian-config -> software (or sudo apt install linux-headers-current-odroidxu4)

https://unix.stackexchange.com/questions/159094/how-to-install-a-deb-file-by-dpkg-i-or-by-apt For each file that you have build. Since you are currently using "current" kernel its wise that you also build "current" kernel (v6.6.y) and not edge (v6.7.y). Or wait few days, a week, as this kernel will become available in armbian-config.

Kernel 6.6.y needs some (actually a lot of) work ... so we reverted images back to 6.1.y alongside with generic fixes. https://www.armbian.com/bigtreetech-cb1/

I can confirm this bug on another (Rockchip) device running Bookworm user space, but with NFS. https://unix.stackexchange.com/questions/554961/nfs-mount-fails-on-boot-although-ip-address-is-configured This comment is telling: "After almost 2 years, this is the only one that worked! There must be a bug around network-online.target" Try to manually implement solutions to the OS you can find on stackexchange and others. When you get it working, look into build framework how to implement it. It seems some additional tweaking of systemd services is needed. We can maintain this OS only with your help - there are too many of issues in open source software.

I tested his image and it works the same as Armbian. As expected.

OK. I don't have any 32Gb rk3588 device here, 16Gb works fine ... Did you perhaps tried with most recent 24.2 images? Also I am running GitHub runners on two 16Gb Rock5 with 6.x kernel ... where memory is abused dramatically. And it works. Perhaps related to u-boot or ddr blobs?

Using this snippet. No issues whatsoever, latest Gnome image from the download section.

Rockpi S was reverted back to supported as @brentr agreed to maintain it further. Latest Images at the download page https://www.armbian.com/rockpi-s/ should have this fix in, while kernel updates were not pushed to repository yet. For any kernel family.