Igor

I have moved status to "Community maintained" as there is nothing we can do at short time. There is always a solution for end users: "Current images doesn't work? Use old images from archive and report to forums ..." You did and lets hope someone will look into. If nobody picks up, there is little we can do. Yearly budget is less then zero. There is a build system https://github.com/armbian/build that we take care of with care and you can build image on your own. You can choose different kernels, debug, etc., perhaps you can find out what is wrong, perhaps someone else will. This hardware suppose to be for advanced users who knows how to fix it. And we provide help with community, build framework, tips. We can't debug all hardware instead of you. Its impossible. I mean, we will fix this eventually, but certainly not anytime soon. We only have testers, but coordinating that is already at extreme end. So much time is lost for that and broken images often slips trough, some versions of devices needs extra touch ... We can't afford to have a dedicated developer for Pinebooks and dev team is overloaded with many other problems. New custom hardware keeps coming in. More new toys you buy, less you support us, quicker your hardware will become obsolete as it needs constant maintenance. Support resources, ours and general community, are small and expensive and our interaction exists mainly when you are unhappy. And people only make donations when they are happy ... your happiness costs us a lot. I am afraid you don't. Core of frustration is almost complete absence of your help. When you are asking us to invest a week of work to fix your software on your computer, check here: https://www.armbian.com/participate/ and match hours of work on what you are asking for. Help us one week, 24/7, help us all the time, ... This is ofc just a suggestion, a tip how you can fight fixing your problems on your computer.

6.1.y works?

Orangepi OS (Arch) is custom / re-branded Manjaro and Manjaro is not doing much else then shipping (selling) their Arch derived OS while taking our and community work on kernel maintainace. This is the story how Orangepi "supports" open source - by primarily supporting code dealers that already mainly have negative contribution to open source development. But who cares other then small group of people called "developers"? In general, HW vendors have interest to block or at least control other OS providers and it is possible they purposefully compiled SPI boot-loader to not load anything else then their OS. This would explain why you can't load our OS. Manjaro already provided (or tried to) this "solution" to Pine64, so average users would have troubles changing OS. Details: https://blog.brixit.nl/why-i-left-pine64/ For us, this is easy to work-around, but bulk of people might still need to stick to their official promo/spy/pirate-ware. Solution? Debian based OS: sudo apt update sudo apt install mtd-utils sudo flash_eraseall /dev/mtd0 Arch based OS: sudo pacman -Syy sudo pacman -S mtd-utils sudo flash_erase /dev/mtd0 Then boot armbian from SD card and run: sudo armbian-install And choose "update MTD boot-loader" or "Install it to NVME", which will also update boot-loader and transfer image to SSD. Tested right now with Opi5 lying on my desk.

Updated images for Khadas Edge2 https://www.armbian.com/khadas-edge-2/ 6.1.y for multimedia 6.10 for experimenting

Hmm, can you give us a bit more information on how to reproduce this? If I start with a clean image, which you have used? Bullseye is not well maintained by upstream, so we don't provide images anymore. Its suggested to use Bookworm from some time. Edit: https://github.com/armbian/build/blob/main/lib/functions/compilation/packages/armbian-zsh-deb.sh#L40-L54 Looks like this doesn't work well in your case. Needs some adjustments, ideas are welcome.

Yes, it is possible. We have to look into this.

It is possible we break it unintentionally while fixing something else. @Alessandro Lannocca Would lately applied changes affect this? It seems its bookworm related.

This part https://github.com/armbian/os/blob/main/userpatches/extensions/ha.sh#L110-L111 is critical. BTW. This hardware will now be officially supported https://www.armbian.com/inovato-quadra/ and there will be dedicated HA image too. Ofc if image is used on some other hardware there is no warranty that things will work.

Armbian framework nor those packages we make are not / should not be touching this, but we could perhaps patch this behaviour if you provide more context, do additional research. How this can be reproduced, where (Jammy, Noble, hardware X, desktop Y) this happens, etc. Without supplying logs, developers needs to use black magic Personally I don't practice that and BTW, I use ZSH.

As its optional (user defined) part of the codebase. This was the decision why its generated at 1st run.

Probably your system time and date is / was invalid, in future. In any case, not something special to Armbian. All Linux systems uses same base software.

Please ignore Ubuntu kernel versions as they are not relevant here. We only use their user space package as its a bit of nonsense to build all those packages from sources on our own. Ubuntu declare LTS support for whole distro. We use packages with long term support combined with our kernel. Which I believe is a perfect combination. Especially in ARM hardware world where Ubuntu kernel can't match with us. As @going also exposed, we look to kernel org and there, latest LTS is 6.6.y ... which we ship with most platforms. There is no more recent one. 6.8.y is not LTS, but its in fact End Of Life. For everyone. If Ubuntu says otherwise, its probably decision of their marketing department. We ship LTS Ubuntu distro with kernel we select and maintain. It is in almost all cases kernel.org latest LTS + our work. Focal userspace (Ubuntu 20.04) is a bit old and it is not so well maintained anymore (by Ubuntu) as they claim, so we decide to stop providing it. We have no interest nor resources to maintain that very old packages instead of them. Kernel 5.15.y is also slowly going out and I would not recommend to use anything lower then 6.1.y on sunxi platforms.

Kernel is taken from www.kernel.org (or from hardware vendors or some other places) and it is heavily modified. Armbian build framework flexibility allow us to ship any combination of user-space with any kernel. We choose what is best, but you are free to change it to something else. We have very little with Ubuntu or Debian when its about kernel. Latest version, stable / LTS user space (in case of Ubuntu smell, rather Jammy then Noble), current kernel. Otherwise, in general, this is custom hardware world - depending on hardware and use use case. Always. This is still valid to this day: https://docs.armbian.com/#what-is-the-difference-between-armbian-and-debianubuntu Armbian kernel lives its independent life. We provide Linux distribution that looks and its compatible with Ubuntu or / and Debian. So you can follow instructions as such https://www.digitalocean.com/community/tutorials and they will work perfectly the same as Debian / Ubuntu. You just need to match upstream Debian / Ubuntu versions. That is Armbian release version: https://docs.armbian.com/Process_Release-Model/#release-naming This is build log for one such release, so you can see what we do: https://docs.armbian.com/Release_Changelog/#v2451-2025-25-5 Which usually include latest LTS version of Ubuntu user space + Armbian kernel or latest Debian stable + Armbian kernel. Our focus is hardware support which means hardware interface on our Debian and Ubuntu is binary identical and also significantly better then from what is shipped by Ubuntu or Debian. Armbian Jammy and Armbian Noble = assembled from Ubuntu user space applications packages., Armbian Bookworm and Armbian Trixie = assembled from Debian user space applications packages. Does this answers your questions?

We are well aware that our download pages are no perfect and generally there is always room for improvements, so we are constantly trying to improve them. Better UX and useful information saves time. Help us saving your time! Things like: https://armbian.atlassian.net/browse/AR-2363

(Armbian) Linux kernel is a common work, product which we maintain in certain areas so you can run Linux on those devices better. Defaults are also where our best effort "warranty" ends - this can be checked with automation, manual testing of *all features or even fixing them is impossible. Linux kernel is a complex machinery and a work of tens of thousands of people. Nobody really knows if feature you are trying to get working in the kernel builds or not and if it works at the end. Ready (def)configs are usually made with a reason that you start with a known-to-work configuration, proceed slowly and fix things on your way. Similar as we do in some areas. Keeping this code build-able and in good shape is already on the very extreme expense end. This is open source and all work is public, value can be reused by everyone, sadly also by competitors that contributes nothing, hardware vendors also don't just help out of humanitarian reasons because we help you using their products. Code quality in Linux kernel is different. Especially if we are talking about vendor kernels. There, only HW features are maintained, nothing else, so this difference is just extreme. But also in mainline Linux, code is usually build-able & usable only until maintainers (largely amateurs) are doing their hard work. Dead and orphaned parts of code are regularly removed, but this functionally deprecation is a process that takes time, a lot of code is broken for long time, decisions are arbitrary. We don't do that as we don't have capacity for patching this megalomaniac chunk of code. We leave things as is. Only upstream Linux does that in small %, here and there, and even they are considered small and under-powered. Most of people in Linux (FOSS) land are sadly not maintaining critical infrastructure such as kernel, but doing some "me too" spin, copy of copy, Linux distribution. Shipping someone code is significantly cheaper that developing and maintaining it. When you start doing what you do, things can quickly become messy and unpredictable. Armbian framework, infrastructure and this community can't do miracles, but provides added value. It doesn't make things worse and that is already a great achievement.

It is. We even use a few of those machines to host build runners. Docker documentation is largely outdated. Now its does everything automatically, but you need to install Docker itself IIRC.

Kernel 6.8.y is hit and miss. We need to separate download links somehow ... for now it was added "Kernel 6.8.y is at experimental support level! Not all features work but it runs fairy stable." to warn you. Its good to be there, as they are usable - where they work. I run several github runners on Rock5 without any troubles for months.

This is probably some (temporally) network issue. Infrastructure shows no signs of troubles.

This. I think the shell / concept is done and adding this should already be possible, but from scratch. We try to get rid of that old spaghetti code that is in old armbian-config. I am not very up 2 date on what is going on there. @Tearran and @schwar3kat are trying hard to push it further and perhaps they can give you some hints how to add this section. Yes. That the idea.

apt.armbian.com is published at point releases, from this branch https://github.com/armbian/build/tree/v24.05 If you check it out, you will get identical what is on stable repository. If you want to go manual way, here https://github.com/armbian/build/blob/v24.05/config/sources/git_sources.json are information about sources. beta.armbian.com is published every x hours from trunk https://github.com/armbian/build If you want to see how this is done, peek into this code. Kernel 6.8 and 6.1 are very very different. Don't expect 6.8 to work better or that all functions will work. Some are not even developed - it is being developed from scratch for around two years now. Code is changing fast, so there is not possible to provide any support. Its too expensive and useless. If you want dig in, but expect troubles and very little response as not many people deal with. 6.1 is different. All 3588 share same problems ... more or less and there is a lot of support in forums.

Can you provide a package or a file associated to this library? So we can find it and add.

There are some issues with Helios64 patches for 6.9.y https://github.com/armbian/build/pull/6691 Please check notes.

Not anymore ZFS, versions that we are adding is now again properly autotested: and this won't be happening in the future. If dependency check fails, packages are not pushed into the repo ...

This is certainly not deliberately and will probably be fixed soon. Open a bug and / or report here.