Igor

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.

Running Debian bullseye? This is EOL. Edit: Aha, yes, that's it. https://unix.stackexchange.com/questions/669004/zst-compression-not-supported-by-apt-dpkg

Yes, we should probably add REPLACE: neofetch to the control file. Well, there are several reasons for this: - we are patching neofetch on our own to add Armbian branding. As Neofetch is not maintained anymore, we can't add Armbian normal / official ways by opening a PR at their GH - we would like to switch to fastfetch but this has to be resolved first https://armbian.atlassian.net/browse/AR-2336 (we have extreme lack of hands since ever as we focus into kernel space hard problems, so there is no way to proceed on this) - during the switch to new generation of armbian-config there are many things to tackle and this (known problem) simply live somewhere in backlog This is how this transition is made and we could probably remove this double packaging to make it easier. We already pack it at Armbian config repo https://github.com/armbian/configng https://github.com/armbian/build/blob/main/lib/functions/compilation/packages/armbian-config-deb.sh

Test most recent builds: (still in testing) https://rsync.armbian.com/incoming/schwar3kat/rock-5c/archive/

I think it is better to expand script to support those scenarios. https://github.com/armbian/build/blob/main/packages/bsp/common/usr/sbin/armbian-install Worse case, write things here: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install

Headers are released via repository and that is done when images are tested. In about a week.

Great job! Interested for integration into main config tool? https://github.com/armbian/configng Now this tools is properly made. https://docs.armbian.com/User-Guide_Armbian-Software/#adding-example

Can be found in https://github.com/armbian/community

armbian-config provides configuration and installation routines for customizing and automating tasks within Armbian Linux environment. These utilities help streamline setup processes for various use cases. Key Advantages Lightweight: Minimal dependencies for optimal performance. Flexible: Supports JSON, TUI, CLI, and API interfaces. Modern: A fresh approach to configuration. Low entropy: Byte clean uninstall for most targets. Features System Configuration: Kernel management, headers, hardware tweaks. NFS and ZFS storage management. SSH user access tweaks. System updates, rolling / stable, containers update. Network Management: Fixed / dynamic IP configuration. Connecting to wireless network. Access point management. Localization Settings: Configure time zone. Set language and locales. Change hostname. Software Management: Software installation and removal. Native and containerized environment. Standardised, updatable, maintained. Compatibility This tool is tailored to works best with Armbian Linux but it has also been automatically tested on: Debian Bookworm Ubuntu Jammy Ubuntu Noble In theory it should work on all systemd APT based Linux distributions: Linux Mint, Elementary OS, Kali Linux, MX Linux, Parrot OS, Proxmox, Raspberry Pi OS, ... Getting Started Armbian config is preinstalled on Armbian. Open or login into your terminal and run: armbian-config End users: Request new software title Documentation: Armbian config | Optimised software Developers: Adding a new feature or software install title