Igor

Did you perhaps tried CURRENT, 6.6.y ? ... here is more to check if 3d rendering works, which is needed at Cina / Gnome. Performances are as they are, its an old horse.

Chromium on Debian is reported broken upstream and there is nothing we can do about except forwarding you this information https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088162 If you are not an expert, use recommended download options, Ubuntu Noble, where we control Chromium and where it works. Be happy that we are able to provide you that (only working) option. Here you can make a donation.

This was moved under a switch to prevent users for switching into kernels that are not meant for end-users. https://github.com/armbian/build/blob/main/config/boards/rock-5b.conf#L7 And this https://github.com/armbian/configng/blob/main/tools/modules/system/switch_kernels.sh is the logic for anyone that might to change / improve this.

Single board computers and especially TV boxes are meant for advanced Linux users due to random low level support. Here you can surely learn a lot about Linux internals, but Linux users experience, if you want to use computer for daily tasks, will be better if you start with a mainstream Linux: https://www.armbian.com/uefi-x86/ https://www.armbian.com/rpi4b/ Also worth reading: https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first/

This was not designed by Armbian. I replied here: https://github.com/armbian/configng/issues/265#issuecomment-2487678726 Workaround: remove armbian-config package, upgrade to Bookworm, and install it again.

https://rsync.armbian.com/oldarchive/rk322x-box/archive/

What about the most important logs? armbianmonitor -u

Try to update to most recent, try older versions ... If you use EDGE kernels, then you are at the edge and crashing is expected. EDGE is meant for experimenting, trying new HW features. But like @Werner already asked, we need to see logs. Without is not possible to help. For this hardware its recommended to use this image https://dl.armbian.com/khadas-edge2/Noble_vendor_gnome-kisak with preinstalled browser. Anything else is calling for troubles. BTW. This super complex application is developed by https://www.chromium.org/chromium-projects/ and if anyone can debug, are they.

Simple: sudo apt install google-chrome-stable But. Google does not provide Chrome for hardware you have and Armbian nor Ubuntu can't help.

It does work. Sometimes. Out of lets say 1000 packages that are on your OS, you are telling people, who are maintaining 3 of those (that only deals with hardware aspects), to fix a problem on all 1000. Making an OS better then Debian in user-space sense, deal with tens of thousands of packages, that is another level. We "hack" this by providing you Armbian assembled from Ubuntu packages / repo. Which might be better in this. Becoming yet another maintainer of all free software packages is insane. And there is no warranty to control this process better. Exactly. Try upgrade, but be ready to start from a new image is the only advise that is realistic. Personally, I don't even try. When its time to move to a new point release, I do a backup of dot files following by fresh install. What I need to run, I do it with help of scripts & armbian-config, running apt. It takes less time then upgrade, which has great chances of failure. apt.security folder was removed from upstream, from Debian main repo, to tell you that distro is EOL and there are no more security updates of (Debian assembled) packages. Once Debian maintainers decides to stop, there is nothing we / anyone can do about. Some distros claims to maintain this longer, but in reality it only has marketing / sales value. Update and signing mechanism has been changed, not by us, but by upstream. At different time at different user space. If we fix for one, we have to fix for all. There is another aspect of why this software is not perfect. We are heavily under-staff since ever and there is close to no public funding to mitigate this. Join the project, dig into this upgrade problem, and (try to) fix it. Or at least improve, try many of possible scenarios and write instructions of best practices. Not for me/us, but for someone that might run into this.

Yes, that's correct one.

We don't ship Docker by default. Make no sense to bloat users pace, if we have a tool for install / uninstall. If you have already upgraded to v24.11, then it goes this way: https://docs.armbian.com/User-Guide_Armbian-Software/Containers/ armbian-config --cmd CON001

From this I can only see that you are using a code that is not supported on a hardware that is not supported. For some reason you have two kernels installed, legacy and current, and this is causing randomness at upgrade. Uninstall one variant alongside with DT and headers if installed. And upgrade to Buster, or rather start with a clean Bookworm image.

If you only shows symptoms but not providing logs, we are in the dark. Perhaps headers install was not successful ? Or who knows what ... armbianmonitor -u

From Armbian perspective, application image is minimal + official way of installing things. This is how we do it: https://github.com/armbian/os/blob/main/userpatches/extensions/omv.sh This is what they do: https://github.com/OpenMediaVault-Plugin-Developers/installScript/blob/master/preinstall https://github.com/OpenMediaVault-Plugin-Developers/installScript/blob/master/install Some things in this long config are doubled, some deprecated, some makes no sense. I don't think we need to deal with all that. If you can access OMV via WEB interface and if you can upgrade it, that's about it.

That was quick fix to secure compiling. Checking all functions on all devices for each kernel upgrade is impossible, so I don't even try. Automated testing is primitive and only catches fatal problems, while now not even that as its currently broken. And this device is not a part of this. I only have one of such device, probably from pre-production series. Try to use a device-tree from a kernel that works - on 6.6 and 6.11. Then lets diff the code.

This is highly expected. We don't even try to support EDGE kernels at end user level. This kernel is EOL and will be replaced with a v6.12.y in next year Q1 release. But we can't secure you that this problem will be fixed as support budget is negative (we have some support for other boards from Radxa) and we, nobody in the team, can't afford to spent days or weeks resolving this. However, you are welcome to spent at least time and join debugging this - problems is as yours as it is ours. The reasons why we keep build framework in a good state is that you can help resolving problems https://github.com/armbian/build We are and will always be too small to face this mountain of problems that are generated by everyone, compensated by no-one. Not by us, but all community that is poking kernels, and hardware dealers that are flooding this market.

When you cloned our repo, you got 10 years of specific work on common work and that was contributed by 500+ people. Most of people are resolving their specific problems, yes, but we all try to do it the way that is reusable, that person behind has less work. We also got a lot of things prepared. Doing things universal should always be considered. Also because you might get help from someone. Which has absolutely same problems, but is having hardware from another vendor. In our world, SoC defines how things work, not the one that put SoC on PCB and name / sell it. This means that most of the drivers are the same, especially this area is shared - low level communication protocols such as GPIO, I2C, SPI. This is always shared among boards with the same SoC. This goes further. It is shared among same families and we also already have some common generic top level API / libraries that can be used. https://docs.kernel.org/driver-api/gpio/consumer.html (but here my understanding ends, I am not updated with the state of this) Yes, it has no point poking into. WiringPi library is a dead project for many years and its no point dealing with this. What vendors do here is, trying to be "as Rpi as possible", so they are doing their quick and dirty assemblies of that, always with partial functionality and absolute absence of maintenance. Their goal is to sell, regardless what is the quality of software. Is that your goal? I doubt. I am not an expert in this field, so those are general tips, but there are people on and around this forum that knows this stuff well, as they developed those libraries. I am just giving you some ideas / tips. Decision what you will do with your time is yours. Another one that came into my mind, while replying: https://github.com/eclipse/mraa

@going Probably @wwortel means to develop a minimal boot image which would download and dd image to eMMC. I agree that would be nice to have, but develop that requires time / resources we don't have. If you look into the script that installs OS to eMMC (and other media) its pretty complex and hard to maintain https://github.com/armbian/build/blob/main/packages/bsp/common/usr/bin/armbian-install Not to mention that people doesn't pile up to help us around that. There is / always was just a few people that sacrifices their precious family time to provide you current experience. Where we can always find something to fix and improve.

New version (v24.11) with even more targets has been released. Home assistant takes few minutes and might require reboot at first install or there will be some errors related to privileges. This gets away after waiting few minutes and reboot. Testing was done on Odroid M1. Latest: https://github.com/armbian/distribution/releases/tag/24.11.1 Previous: https://github.com/armbian/distribution/releases/tag/24.8.4

We are cleaning those builds as they have very little value. But you were lucky: https://github.com/armbian/community/releases/tag/24.11.0-trunk.351

Take a look at universal projects that are made far better, and are universal by design. https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/ (pinned topics)

They are not needed. We use flash media friendly and more advanced ZSWAP solution by default. https://www.google.com/search?q=zswap If you don't want to have this, you can of course disable this feature in /etc/defaults/ (will be soon added to armbian-config) and add swap file. But that is not recommended.

Try here: https://rsync.armbian.com/oldarchive/ We can't possibly maintain this further, sorry.