Igor

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.

https://armbian.atlassian.net/browse/AR-2192 Fixed in latest release.

Change to "vendor" kernel 6.1.y is recommended.

I have (hopefully) fixes ZFS on all variants yesterday, but haven't tested on Debian yet. Works fine on Ubuntu based builds, ZFS v2.2.4. If you have time to test, beta.armbian.com should have proper packages: https://k-space.ee.armbian.com/beta/pool/bookworm-utils/z/zfs-linux/

Here you can make a donation. Thank you. That "Ubuntu" was in 99.99% developed by Armbian and other open source projects. Orangepi is HW dealer. They only care that hw features works. They never pushed fixes to common code. We have to spent our private time if we want to port / fix their HW bugs & features to better common code which is the only one maintained and which is in your interest to run it. Software you are so happy to use is on this level. We are maintaining software together and this issue was not closed. Do you really believe unmaintained promo software have only one problem? 😁 There is a new release out tomorrow. Every download page has daily assembled images with latest updates and fixes, where you should check if this problem was resolved. Did you check that before?

That is O.K., but Armbian build framework does not accept HW related tickets. Forum is right place where you can bring this up and discuss what to do. Then open a PR if solution emerges ... Without this patch, PCI probing will randomly fail. Which is worse then 100% going up in 1x. This is my 2c. I understand that you would like to have a perfect functioning PCI system on this hardware platform and if you cover someone several weeks of R&D, this can probably be done. Since this will not happen, we have partial solution/workaround in place, this forum and we have each other.

Or install attached with dpkg -i armbian*.deb armbian-config_24.5.0-trunk_all__1-SA8477-B2b14-R448a.deb

Perhaps this is a solution? https://github.com/armbian/build/pull/6652

Planned point release and images rebuild date is upcoming Saturday, 25th. There are three problems, that would be nice to fix before. People working on are very busy and might not be able to deal with, so help is needed here: Debian bookworm XFCE lacks wallpaper and lockscreen Compile from sources and pack Chromium for aarch64 on PPA Resolving Noble incompatibility with amazingfated-rk3588 extension Thank you all that participated in this release!

Two desktops needs additional testing: https://github.com/armbian/build/pull/6626 https://github.com/armbian/build/pull/6625 ... we are high on closing existing tasks and very low on time dealing with this. There are several other bugs that needs attention: https://www.armbian.com/participate/

Soon, in less then two weeks.

This forum is related to Armbian. For general Orangepi questions consider asking in their forums. We don't use Android nor Batocera here.

Testing ... 3588 vendor 6.1: Do we have a working? 3D hw support via panfork wiringpi support? npu? 4k youtube video playback under Chromium? 4k under MPV video player? https://github.com/armbian/os/blob/main/userpatches/targets-release-standard-support.yaml other rockchips. Enabling extensions? - v4l2loopback-dkms,mesa-oibaf What about amlogic, allwinnner? - v4l2loopback-dkms,mesa-oibaf Nice to have: rock-5-itx edge kernel Manually tested: - Bananapi M2PRO Gnome desktop with 4l2loopback-dkms and mesa-oibaf

I would not use ZFS with this kernel if I were you. This kernel is provided by hw vendor, by people / business that only cares about (selling) hardware features to work. Everything else is unmaintained and open source community (not just Armbian) developers are not even thinking to maintain this kernel outside that as its concorde fallacy. FYI - it is highly possible ZFS implementation is affected, but you are FREE to do whatever. 90% of solutions, not workarounds, Armbian team (a few people) is unable to integrate into OS with their private resources, public (thousands of you) are simply not there. I can estimate, we could integrate about 30% of resolved suggestions this community generate with few full time engineers. Which costs money. Until you are satisfied with reporting problems only, until you don't care that a lot of value is wasted, there is nothing we can do but keep trying to provide "best effort" support with what we have and explaining this situation. Users perspective will always be like we refuse to help ... but people that are working on / helping Armbian are already long maxed out in efforts of helping everyone, even our competitors. Also. Hardware vendors have exploit of open source community build into their business model. If it happens that you are using hardware with terrible vendors reputation, bugs can be written, but are last to be resolved, some bugs are never resolved ... If you really wanna help everyone, start here: https://github.com/armbian/os/wiki/Import-3rd-party-packages Study and implement a solution. We also have automated dependency testing, which should prevent this problem in first place, but ain't working well and it wouldn't help much in this case. ZFS package is imported from Trixie and yes I understand that upstream package dependency has been recently changed. Until a month ago, we didn't have this problem, everything was working right and now, there is little we can do except disabling importing (which will also delete packages from repository). We don't compile those packages on our own and I am aware that this is not the best way. There are more workarounds - like using Trixie or Noble user space ... Its sadly under-powered, too small. Math is simple - I would very much like to help, but costs are the one that are killing us. Imagine that fixing a problem costs 1000 USD. You are willing to pay 5 USD (or not even that), which is fair if there would be more people contributes their share that you cover all costs. This never happens. They come with another and another problem for 1000 USD (often a lot more, sometimes a lot less) instead. Then its expected that we pay the rest, 995 USD for costs of resolving community software problem, this is simply not sustainable way of cooperation. Even the bug was made by us. I am trying to keep ZFS available. Do you have any idea how much time loss this service already caused with no benefits whatsoever? There are thousands of bugs in open source software and most of people pin everything on us after they download "Armbian image" and images that are produced by copycats as they claim "its Armbian". This particular problem was introduced by us, yes, but alternatively would be not providing ZFS that is capable of working with recent kernels. Which touches to the core of embedded Linux experience and logic. Often we can't match user space and kernel like this is done on 1st class x86 desktop / server / hw Linux world. Even they, often breaks critical things too, even with thousands of full time employees (Redhat). We can't provide that level of services with close to nothing from your side.

Which SoCs and on which branch can have extensions enabled? 4l2loopback-dkms mesa-oibaf here: https://github.com/armbian/os/blob/main/userpatches/targets-release-standard-support.yaml#L40-L95 Mapping config: https://github.com/armbian/os/blob/main/userpatches/targets-extensions.map