Igor

- 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.

Thank you for testing. It seems we need to invest more time ... we'll try to come up with fixes during next week.

Today I went and update OS packages on my Odroid N2 running Armbian HA instance. Logs: I did reboot after this, then update Home Assistant Core via HA web interface to latest version 2024.2.3 All went fine!

Thank you! We have updated images. They should boot now.

I don't know why / when this bug was introduced but kernel upgrade workarounds it.

What Werner meant is that if you are running system upgrade scripts that are not made by us ... it could cause troubles. Those upgrades are fragile in 1st class world, while here ... its just more possible problems. However ... you can still try. Just don't hate us if something goes wrong You need to upgrade to keyword "noble" ...

There must be something with permissions. I just tested x86 cinnamon. Normal user fails, root can login via XRDP.

Perhaps this ? https://github.com/armbian/build/issues/6132

Oh, we are missing this utility? Will be added when possible. https://armbian.atlassian.net/browse/AR-2059

It was confirmed working with Debian Bookworm based images. For Ubuntu Jammy you need to find a way to backport Mesa driver for Noble (try nobble instead of unstable) and it will also (probably) work.

Did you read text here https://www.armbian.com/rpi5b/ ?

I don't know. It was tested on Odroid N2 and Nanopi M4. If you seek for plug and play solution and you don't want to support open source development, buy a Raspberry Pi, Odroid N2, ... I am afraid, that is not the case. https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-authenticity.

I have also disabled both mirrors from rotation until we develop & implement a proper solution to our router.

Can provide only dumb answer. Its not directed to you in person ... There is an add out there for almost a year. Nobody wants to use opportunity to learn and help you. Without maintaining automation ... things breaks down. Same will happen with board X, after we stop doing what we do. There is very little help elsewhere too. People don't want to know how much Armbian lost by providing you (and competitors, vendors, you ... that have no interest to cover our costs), those images. No, nobody asks, nobody cares, so we can live with what we already have. You assume this is what we do for fun? To some degree it is, but fun stops when abuse and blackmailing starts. Which is constantly present. Way too many people use all kind of tricks trying to manipulate with us to solve their computer problems in our private time. Welcome to Armbian forums Stay tuned, images will be back when they will be back.

Yes, but we are slowly applying automation. We currently don't have a dedicated person for website works and this is done by Effe with my assistance https://armbian.atlassian.net/browse/AR-909 (Automatic synchronization of board status between GitHub and website hasn't started yet)