Igor

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)

I doubt that our last images are broken as this is one of popular devices and this is the only report I can remember. Also we are running test automation, which shows not problems. However, non working images can exists, ... we keep previous versions for you to verify quickly: "Current images doesn't work ..." ... if its something on your side (powering, SD card) or image is broken. Official images are few years old version of Armbian with different boot loader and kernel. Can you attach UART to the serial console and see where it stops?

This could be one option: But beware that most of those cards, including this one, uses SATA port multiplication. For spinning rust over gigabit line this is enough ...

Follow instructions armbian-config -> software -> install headers This is the package name: # apt search linux-headers-current-bcm2712 Sorting... Done Full Text Search... Done linux-headers-current-bcm2712/jammy 23.11.3 arm64 Armbian Linux current headers 6.1.74-current-bcm2712

VMware ESXi on non Raspberry Pi is not usable (yet) in production, to install it and forget about. Several features does not work (stable) and overall performance is questionable. Here one can observe more, dunno how up2date is that documentation ... Orangepi is good enough for running Armbian and similar OSes and here one can run KVM virtualization. That will work fine, perhaps not the best with this board as mainline kernel still has rough edges.

Make an apt update + upgrade. Kernel + header combo exists for 6.1.74 and it should be there for future versions.

We have no plans or budget to support this hardware. Finished assembly will be provided only for small selection of boards, most likely we will provide this for platinum support section only. Purpose of the topic is promoting Armbian build framework. If something can be done on board X, we can't help to make it on board Y. Without investing tens or hundreds thousands of dollars. This is your problem. Board provider problem. Not ours. Build framework can do this, but if board is not maintained ... it might not just work.

Yes. https://github.com/armbian/build/commit/833e1c20c63ea3da7f1323429828e94eaa9b52c7 We forgot to pin it to the commit / version. Its still branch: https://github.com/armbian/build/blob/v23.11/config/sources/families/odroidxu4.conf#L24

We pin major releases this way (branch v23.11) https://github.com/armbian/build/commit/d69350a88447ee64bbb50b443f86858a7f6f4075 while main (or some tag) is not. For mainline based, check this: https://github.com/armbian/build/blob/main/config/sources/mainline-kernel.conf.sh Main branch is updated and fixed daily in case upstream messes up. Just keep rebasing.

6.1.74 current and 6.6.13 edge are going to be available on stable repository shortly after this is done: https://github.com/armbian/os/actions/runs/7708966983