Igor

@Igor
Fans working great with fancontrol. I have 92 MM Noctua Fan attached and it is working perfectly. I can adjust the configuration as described here https://wiki.kobol.io/helios4/pwm/
@all
I also edited the default 2.5 inch drives case provided from helios4  (replaced fan mounts from default 70 mm fan to 92 mm fan) and added holes to mount ssds horizontally as well using 3.5 to 2.5 metal adapter from aliexpress .. It looks like this.. Very quiet and the drives stay cool.

Many thanks for fixing this!

I also tested on my side, works now. We can eventually put this board back to supported list. (board config .csc -> .conf)

There are few other things that would be nice to get working - I notice WOL service erroring out, fan support is unknown. I only have PCB without anything attached to it, for testing.
 
Merging both patches shortly.

@Igor
 
> There are few other things that would be nice to get working - I notice WOL service erroring out, fan support is unknown.
 
Regarding "fan support":
Fan was working correctly after installing fancontrol, see
https://forum.armbian.com/topic/44379-fancontrol-bookworm-solved/#findComment-209055
 
(Thread is in Standard support->Other families->Helios 4)
 
 

Hi there,
Now two pull requests are awaiting review:
- https://github.com/armbian/build/pull/8166#issuecomment-2867147049
   Update the boot.scr script to calculate load addresses in case `setexpr` is available on the U-Boot monitor.
- https://github.com/armbian/build/pull/8170#issuecomment-2867915659
   Enable the `setexpr` command on the U-Boot monitor, to unlock load address calculation in combination with the boot.scr update.
 
Both are now tested OK using a built armbian 'minimal' image based on Bookworm.
 
Groetjes,

I am still here  but as we all know our time is precious and I am currently using all my time for other projects. So I am not currently maintaining this board.
On the whole I think armbian is moving too fast, for me, with new features in the build system and kernel which has somewhat discouraged me from further investing my time. ARM is IMHO not a stable platform, unfortunately.
 
@djurny solution looks good - I might test this later and try to integrate it. But everyone else, if you can, please make it a PR on github
 
It should only be necessary to adjust this file https://github.com/armbian/build/blob/main/config/bootscripts/boot-mvebu.cmd

Welcome on board.
 
 
This will be a huge difference, so be open for learning, have a lot of patience.
 
https://docs.armbian.com/User-Guide_Board-Support-Rules/
One of the key challenges we face is that maintaining older hardware is both time-consuming and costly. With limited financial and community support, the resources we have are already stretched thin across the entire project.
 
Our team is very small—currently, we have only one dedicated maintainer for the Allwinner software stack that is focused into latest 64bit Allwinner family (H6/H6xxx). Other projects often face similar constraints, often relying on a single contributor who can do anything. For example, in our collaboration with LibreELEC (LE), we benefit from some shared efforts, but both sides are still primarily driven by individual volunteers working on a best-effort basis. If priorities shift, progress can be delayed significantly—and unfortunately, Armbian doesn't have the capacity to pick up.
 
I’m sharing this openly in the hope that it raises awareness. Personally, I would love to see continued support for legacy devices. But to make that happen, we need to ask: who is willing and able to invest weeks or months each year required to maintain these older platforms?

What you can do? Try to understand how this works, connect with people that share your problem (all similar board owners with interest that it is maintained) - invest time to learn.
 
 
Probably USB ports are just not enabled - check this: https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-overlays

@Werner thanks for your time.
 
I found the solution in this post:
I'll never be able to say it, but this community is the best I've ever seen.
I want to thank you because once again, I couldn't have solved the problem without it.
Thanks @djurny@Igor and the all the people of this post.
 

This is everyone's problem.
 
Buy boards that are supported and maintained. We have not received any support from Orange Pi, contrary, their business model is very damaging to us and donations only pays coffee and beer. We do not maintain or officially support hardware you have, and AFAIK it is not maintained by anyone else - but if it is, it will get to Armbian too. However, given the similarities across these boards and the nature of open source, it’s difficult to prevent Orangepi and their customers (you) from abusing open source development.
 
 
This is everyone's problem. Stop buying hardware that we don't and won't support as making a pressure to open source developers is worse thing you can do. Hardware dealer abuse is already big enough.
 
 
Just a polite reminder that you are not a customer, so adjust your over-expectations.

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 ...

In case you get "Unsupported system warning", replace 
PRETTY_NAME
with
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
inside /etc/os-release
following by reboot.

Key is not deprecated, method is. On Noble / Sid and future.
 
sudo wget https://apt.armbian.com/armbian.key -O key sudo gpg --dearmor < key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null sudo chmod go+r /usr/share/keyrings/armbian.gpg sudo echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com $(lsb_release -cs) main $(lsb_release -cs)-utils $(lsb_release -cs)-desktop" | sudo tee /etc/apt/sources.list.d/armbian.list apt update  

Hello all, I have returned to my topic with a righteous update!!! I started with Armbian Server Noble.

This is my PI5.....It needs camera support and libinput/weston for touch.  However, I have run this .sh script
#!/bin/bash sudo apt update -y && sudo apt upgrade && sudo apt install lightdm && sudo apt upgrade && sudo apt update -y && sudo apt install linux-headers-current-bcm2711 linux-headers-edge-bcm2712 && sudo apt update -y && sudo apt upgrade && sudo apt install gnome* ffmpeg qgnomeplatform-qt5 qt5-image-formats-plugins qt5-qmltooling-plugins qtvirtualkeyboard-plugin qttranslations5-l10n libqt5svg5 qt5-gtk-platformtheme qtwayland5 alsa* pavucontrol vulkan-tools mesa-vulkan-drivers xdg-desktop-portal-gnome libspa-0.2-bluetooth qv4l2 v4l2loopback-dkms obs-plugins obs-studio gnome-tweaks rpi-imager to produce my media script aswell as edit
config.txt after flashing.


 
 
Touch and Camera next friends....

SATA Works without any issues on 6.12

Most likely P2P wireless, not necessarily functional. This is automatically present by a (wireless) kernel driver. Use the device that works and ignore the other. If bogus device gets to your nerves, dig into the code, find a way how to disable it and sent a patch.

It is. I have workaround it, but updating process needs some improvements. Once mirrors get in sync, it should be operational.

Honestly, the way it works right now is good enough, it just seemed weird for me since I couldn't find much info about this topic online (both the armbian-config thing, and the btrfs thing) I'll just post the issue on github after writing up some proper documentation behind it! Thanks again!

I didn't express myself clearly: I meant that I am "the advocate of more serious and supported solutions", I meant precisely ARMbian, as opposed to Arch where BananaPI and OrangePI are not officially supported. Sorry for the confusion.
 
For OrangePI, I can see that nothing changed since their beginning, where they were starting their business by simply cloning LeMaker website and all the efforts the community did for the original BananaPI board 🤐

Until only you, me and those few people that will read this thread knows about this .... doesn't make any sense. Our current download logic and UX is very bad at this state, almost as bad as Debian  It is very difficult to know that such image exists, what are their advantages (this part I have some draft and will be sent to the docs eventually), then telling them that they can choose between .xz .qcow2 .xz.qcow2 ... while ISO (what people understand) is nowhere to be found.

Enabling a feature at build framework. This is trivial and I think it's even supported with a switch already "KEEP_UNCOMPRESSED_IMAGE" or similar, but its not supported at CDN. When compressed qcow2 was replaced with uncompressed, redirection followed as it doesn't carry file extensions https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-qcow2 which means we don't have support for .xz at this moment. Changing this? Chain of command and execution is slow, I can't deal with everything, and people are busy. I still wait that https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-hyperv.zip (HyperV Azure) started to work. As you can see, compressed is even bigger then qcow2 image and apparently it has to be zip (don't know that yet). Once re-director is extended, now hard coded values goes out of the code, so its small refactoring - easier job for the future. When re-director is fixed, we need to adjust (already messy) web page. Which is now half broken, those cloud images are mixed with minimal / IOT. You don't know until you click on the link.
 


 

That cloud kernel supports features required to run Docker. Something like this:
 
curl https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh | bash  
 
Already have some draft ready, but wanted to do more tests before. On some clouds.

Yes. Cloud providers, those that accept direct qcow2 images loading, expect uncompressed variant. It is handy if you can just pass URL or upload image without any additional handling.
 
 
This should address the problem.
https://github.com/armbian/build/pull/8046

Always use main branch, older branches are here for reference and to build with sources at the state of initial build. We had several bug fix builds after point release, but they were made from main branch ... as we don't backport commits to frozen branch. Not enough people ...
 
OS version is not determined by build framework, but externally. https://github.com/armbian/os/blob/main/stable.json Which version is bumped when any new Armbian package is sent to the repository. You can also set version with a parameter IMAGE_VERSION=25.2.3 ...

In theory, if we would have "endless" computing / storage resources, we could make RT kernels for all variants. Currently, this is a bit insane  as there are too many kernels. 

Correct, but I also haven't tried it yet.
 
 
https://docs.armbian.com/Developer-Guide_Build-Preparation/
Once you get it running, choose this:
 

 
and enable what needs to be enabled (there must be guides around the internet and AI also usually knows). Make sure to freeze this custom kernel, so update won't be replacing it later.

I have an odroid xu4 and want to thank you for the great work ...
 
_ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.2.2 for Odroid XU4 running Armbian Linux 6.6.75-current-odroidxu4 Packages: Debian stable (bookworm) IP addresses: (LAN) IPv4: 192.168.178.24 IPv6: fd0b:5278:d32e:0:1d4d:933a:afcc:c02 (WAN) 188.136.105.135 Performance: Load: 1% Up time: 27 days 5:26 Memory usage: 4% of 1.94G CPU temp: 47°C Usage of /: 5% of 29G storage/: 3% of 234G Tips: Support our crowdfunding project https://forum.armbian.com/crowdfunding/project/16-help-armbian-grow-support-joi n-our-team/ Commands:  
Danke ...

Also documentation (related to this topic) is now in right state of mind: https://docs.armbian.com/User-Guide_Armbian-Software/#adding-example 
 
It is hard to add software title we never tried, installed and / or know nothing about, then expert user of this software adding it to (armbian-config) installer. We focused to make this task as simple as possible, to encourage you doing that and not opening us tasks (we already have 1000 x too many and won't ever complete).
 
We added popular titles to the system, which have some value for us, while everything else is mocked by more important tasks in other sections. 
 
But mechanism is there - use it, its user / developer friendly. Also its a nice and easy way to contribute to the open source.

But you can step up and maintain this for everyone? We don't provide direct contact email, as we don't have capacity to deal with all packages that exists in open source world and as you discovered by yourself, some maintainers are not longer with us, so many packages doesn't really have anyone doing this.
 
In our system - all you need to do is changing / bumping numbers and open PR. If build and test succeeds, someone with merge rights, merge it into the system and within few hours, packages are available on repository.

PR:
https://github.com/armbian/os/pull/300
 
Pool and test install was successful:
https://github.com/armbian/os/actions/runs/14016836904/job/39243546741
Merge follows, packages will be out with next repo sync.

I guess you read the next major version number (6) of `libzpool` and `libzfs` on Ubuntu 25.04 (Plucky) then.. I see