Igor

Recreated hdmi patches under kernels 6.12 and kernels 6.15 in pcduino-boards-fixes branch.  When attempting to build with current kernel 6.12.30, with drm patches for sun4i_hdmi_enc.c to use drm_hdmi_connector_mode_valid and drm_atomic_helper_connector_hdmi_check fails to compile. when just applying drm_atomic_helper_connector_hdmi_check patch build compilation is successful. Just need to verify this build works.
 
For kernel 6.15, with just the hdmi patches, we get a working HDMI display output:
 

@Igor, all
just like to say that I installed
 
Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.imgArmbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img
from the boards page
https://www.armbian.com/orange-pi-zero-3/
 
apt update works 'out of the box', no PUBKEY errors
 
thanks for the the updates
@vtech,
you may like to try the same for orange pi zero 2

What do you mean by that? Images that are currently available are still from 25.2 ... new will be created soon. But you can anyway update them standard way: apt update + apt upgrade.

What do you mean by that? Images that are currently available are still from 25.2 ... new will be created soon. But you can anyway update them standard way: apt update + apt upgrade.

I would suggest you to download clean Debian minimal image and proceed this way:
https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#home-assistant
 
EVCC can be installed this way - official Docker container:
https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#evcc
 
 
How to deal with EVCC from HA, no idea. This is application level knowledge and I am just an average user of HA. I assume addon will want to connect to the service which runs on some IP address and some port. IMO this part is similar as official HAOS image.
 

Current application images are not yet rebuild with latest stable base, so until then its better going clean Debain + armbian-config way.

Introducing Armbian’s New Cloud Images: Optimized for x86 and aarch64 Cloud Deployments
Armbian is taking a significant step forward in cloud computing support with the introduction of dedicated cloud images tailored for cloud environments. The latest enhancement brings a new ‘cloud’ image set specifically designed to optimize generic x86 and aarch64 deployments, ensuring better performance, security, and compatibility in cloud infrastructures.
Why Dedicated Cloud Images?
As more enterprises and developers deploy lightweight Linux images in cloud environments, the need for a streamlined, cloud-optimized configuration has grown. The new ‘cloud’ images aim to address this by focusing on:
Very Fast Boot Time: Optimized configurations enable boot times as fast as 1-2 seconds, ensuring rapid deployment and responsiveness. No Firmware Package: By eliminating unnecessary firmware packages, the cloud images remain lightweight and focused on essential cloud functionality. Optimized Performance: Stripped of unnecessary hardware drivers, the cloud images are leaner, allowing faster boot times and improved efficiency. Enhanced Compatibility: Fine-tuned configurations ensure that Armbian-based cloud instances run seamlessly across major cloud providers, including AWS and Azure. Security-Focused Design: With a minimal attack surface, the cloud images reduce exposure to vulnerabilities while maintaining essential features. Lightweight Image Size: The uncompressed QCOW2 image is approximately 700MB, ensuring minimal resource usage while maintaining full functionality. Docker Support Enabled by Default: The cloud images come preconfigured with Docker support out of the box, allowing seamless deployment of containerized applications. Lean Debian Bookworm or Ubuntu Noble User Space: Provided images come with a minimal yet powerful user space based on Debian Bookworm or Ubuntu Noble, ensuring stability and efficiency. ZRAM Management: Built-in ZRAM management optimizes memory usage, improving performance in resource-constrained environments. Armbian-Config System Configuration Utility: The powerful armbian-config tool provides an easy way to configure and manage system settings, enhancing user experience and customization. Customize and Brand Your Cloud Image
Armbian makes it incredibly simple to create custom, cloud-optimized images tailored to your needs. Whether you’re an enterprise or an individual developer, you can brand and configure your Armbian cloud images to match your identity and requirements. Have always fresh Armbian OS with your brand!
By leveraging the Armbian build framework, you can easily build your own cloud images with custom configurations, packages, and branding. Get started today by visiting the official Armbian build repository.
Download links
You can find download links at https://www.armbian.com/download/, or use the direct links below.
For the QEMU disk image (QCOW2) format:
https://dl.armbian.com/uefi-x86/Bookworm_cloud_minimal-qcow2
https://dl.armbian.com/uefi-x86/Noble_cloud_minimal-qcow2
https://dl.armbian.com/uefi-arm64/Bookworm_cloud_minimal-qcow2
https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-qcow2
and Microsoft Azure image format:
https://dl.armbian.com/uefi-x86/Bookworm_cloud_minimal-hyperv
https://dl.armbian.com/uefi-x86/Noble_cloud_minimal-hyperv
https://dl.armbian.com/uefi-arm64/Bookworm_cloud_minimal-hyperv
https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-hyperv
How This Benefits Cloud Deployments
This update makes it easier for developers and businesses to deploy Armbian-based instances in the cloud without unnecessary bloat. Whether running on AWS, Google Cloud, Azure, or smaller providers and Qemu KVM / Proxmox, users can expect:
Reduced overhead and better resource utilization Improved stability with cloud-centric optimizations A more agile and lightweight system for containerized applications Faster provisioning and deployment due to the ultra-fast boot times Seamless container orchestration with pre-enabled Docker support Optimized memory management with built-in ZRAM support Customizable and user-friendly system configuration via armbian-config The ability to build fully customized, branded cloud images with ease What’s Next?
Armbian continues to evolve, ensuring that users benefit from its embedded Linux roots, embracing a philosophy of minimalism and efficiency that ensures optimal use of system resources. Community feedback is crucial in refining the cloud images, and we encourage users to test them out and contribute.
For more details, visit the official Armbian GitHub repository and join the discussion!
Stay connected and experience the next generation of Armbian cloud support today!
The post Armbian cloud images first appeared on Armbian.
View the full article

We keep (most of) old images here:
https://fi.mirror.armbian.de/archive/
https://fi.mirror.armbian.de/oldarchive/

Upgrade to 25.5.1 successful (straight-forward).

DKMS is 'quite complicated' , in an attempt to understand all that 'cryptic' stuff, I went googling around
https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support
https://www.linuxjournal.com/article/6896
https://github.com/dell/dkms
https://wiki.gentoo.org/wiki/DKMS
https://www.collabora.com/news-and-blog/blog/2021/05/05/quick-hack-patching-kernel-module-using-dkms/
https://www.baeldung.com/linux/dynamic-kernel-module-support
https://nilrt-docs.ni.com/opkg/dkms_opkg.html
^ surprisingly I found this guide/tutorial from national instruments 'quite intuitive'
and I dug further into how to make a kernel module, well at least a 'hello world'
https://tldp.org/LDP/lkmpg/2.6/html/
https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
The Linux Kernel Module Programming Guide
Peter Jay Salzman
Michael Burian
Ori Pomerantz
Copyright © 2001 Peter Jay Salzman
---
ok I actually tried building that 'hello world'  kernel module and *it works*, for practically 'ancient' 2001 instructions.
so it turns out that to compile a kernel module, you do not need to build it in the kernel source tree itself
and that is *without* DKMS, read that last 2 tldp guides: The Linux Kernel Module Programming Guide
you can try building and inserting the 'hello world' module into your kernel, no DKMS, whatever, after you build your module !
in short is it not necessary to build a kernel module within the kernel source tree itself, but that there are some procedures as spelled out
in that 2 tldp docs.
(but fast forward to today, this same instruction may not work if you are using secure boot, then a lot more complicated things like module signing gets involved, review that dkms link from dell)
-------
now back to DKMS , where does that fit in?
so it turns out that DKMS is a utility / tool / system / automation tool, to help you *rebuild the kernel module* - out of linux kernel source tree (i.e. as like the hello world module above), *without building the kernel from source itself* !
but that you need to ***rebuild the kernel module from source***(e.g. using DKMS), then all the other links above are guides that may be relevant
----
now add more complications / complexities, normally what you wanted is a *driver* , not simply a kernel module
the driver often has several parts - the kernel module itself (this is the 'easy' part, you need to build it - from source), and that does not mean having to build the kernel itself from source, but you need to build the *kernel *** module *** *.
after you build the kernel module successfully, say, then there are more blows and pitfall
these days wifi and many network hardware requires *firmware files* , these *firmware files* can consist of 'bin' (firmware binary) and configuration (some of them text files) some of these firmware stuff lives in /lib/firmware.
then that you need your kernel module, you can deem that the 'driver core' that  interface the OS and interface those firmware. those firmware do not necessary run on the (host) cpu (i.e. your pc) but instead in the wifi chip  itself.
this is the part that is *highly opaque*, there are so many wifi chips that are *undocumented*, the firmware is *undocumented* and if you do not have any source for your kernel module which interface the firmware to the os, you are out-of-luck.
-----
 
to summarise - normally, one cannot hope to take a binary kernel module install it in your current kernel and hope it 'just works'.
if that works, a lot of things such as module versions and various constraints imposed by the kernel matches that in the kernel module itself, i.e. that module is compiled specifically for that specific kernel itself !
DKMS do not solve this, DKMS only *helps you rebuild the (kernel) module *** from source *** *, (and install it optionally).
the idea is this, you have the *source* to your out of kernel source *kernel modules*, when you upgrade the kernel, e.g. such as an apt-upgrade etc, DKMS can be triggered to *rebuild the kernel module from source* (and install it) in the new kernel (binary) tree e.g. copy that into /lib/modules/{kernel version}/xxx
---
if the kernel module is part of the kernel source tree itself, it actually do not need DKMS.  But that if the errors occurs  after building that *kernel module* (i.e. driver) , then congrats - you found a 'bug' in the *kernel module (driver)*, and that is true even if it is out of kernel source as a DKMS build. i.e. the driver sources need to be patched to work in the new kernel.

Hi,
wake-on-lan should be working now due to https://github.com/armbian/build/pull/8235.
Groetjes,

Yes. And we will keep fork maintained as long as possible.
https://community.home-assistant.io/t/feedback-requested-deprecating-core-supervised-i386-armhf-armv7/880968/313

/_\  _ _ _ __ | |__(_)__ _ _ _  
  / _ \| '_| '  \| '_ \ / _` | ' \
 /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|
                                   
 v25.5.1 for Orange Pi Zero2W running Armbian Linux 6.12.23-current-sunxi64
 Packages:     Ubuntu stable (noble)
 Updates:      Kernel upgrade enabled and 17 packages available for upgrade
 Support:      DIY (community maintained)
 IPv4:         (LAN) 192.168.***.***, 192.168.***.*** (WAN) ***.***.***.***
 IPv6:         ***
 Performance:  
 Load:         11%               Up time:       4 min    Local users:   3                
 Memory usage: 24% of 1.93G      
 CPU temp:     45°C                Usage of /:   10% of 58G        
 Commands:
 Configuration : armbian-config
 Upgrade       : armbian-upgrade
 Monitoring    : htop
orangepi@orangepizero2w:~$
 
It boots into xfce wifi works, eth works and hdmi work.
2gb board with keyboard plugged into expansion board.
 

Yes. And we will keep fork maintained as long as possible.
https://community.home-assistant.io/t/feedback-requested-deprecating-core-supervised-i386-armhf-armv7/880968/313

Yes. And we will keep fork maintained as long as possible.
https://community.home-assistant.io/t/feedback-requested-deprecating-core-supervised-i386-armhf-armv7/880968/313

/_\  _ _ _ __ | |__(_)__ _ _ _  
  / _ \| '_| '  \| '_ \ / _` | ' \
 /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|
                                   
 v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64
 Packages:     Ubuntu stable (noble)
 Support:      DIY (community maintained)
 IPv4:         (LAN) 192.168.***.*** (WAN) ***.***.***.***
 IPv6:         ***
 Performance:  
 Load:         4%               Up time:       16 min    Local users:   3                
 Memory usage: 45% of 971M       Zram usage:    47% of 485M       
 CPU temp:     46°C                Usage of /:   11% of 58G        
 RX today:     98 MiB            
 Commands:
 Configuration : armbian-config
 Monitoring    : htop
*** System restart required ***
 Some packages require a reboot (gnome-shell)
orangepi@orangepizero3:~$

Yes. And we will keep fork maintained as long as possible.
https://community.home-assistant.io/t/feedback-requested-deprecating-core-supervised-i386-armhf-armv7/880968/313

We have vendor (v6.1.115) based kernel support here, where hw features usually works fine. I didn't do much of testings, only added board to the test farm. I never tried mainline here, perhaps someone else did.
 
Logs: https://paste.armbian.com/uhofaquguz

We have vendor (v6.1.115) based kernel support here, where hw features usually works fine. I didn't do much of testings, only added board to the test farm. I never tried mainline here, perhaps someone else did.
 
Logs: https://paste.armbian.com/uhofaquguz

Hello, we have tried wifi and it is working fine https://www.armbian.com/armsom-sige5/

After years of thinking, wishing and tinkering - Armbian automated WiFi performance benchmark system:
https://docs.armbian.com/WifiPerformance/
From latest WiFi 7 down to (in)famous xradio XR819.

The software used by the Orange Pi "team" is, to a very large extent (estimates go as high as 99.9%), based on the work of developers from the Armbian project (and beyond). Their contribution mainly includes adding basic support for new boards, but unfortunately, without further maintenance or long-term support – which practically means that the entire burden of maintenance and support falls on the community.
 
It should be noted that systems such as Orange OS Ubuntu and Debian on ARM architecture are the result of years of work by more than 500 people gathered around the Armbian project. Orange Pi only makes minor adjustments. In the past ten years, we have not seen a single contribution from any member of the Orange Pi team to the development of these key components. Absolutely nothing, while they keep signing under our work (even changed to some degree) ... on top of stealing software support. Which they don't provide in any way.
 
The work of the Orange Pi team (which appears to be just one individual), on top of some old Armbian, can be tracked here:
https://github.com/orangepi-xunlong/orangepi-build/commits/next (they removed other board configs)

Everything is good, thanks for the help and sorry for confusion, I only should to change PiRogue default interface after installation, this is PiRogue interface detection problem...

From logs I can only conclude that problems are at your side - wrong configuration. Anyone can help you - problem is almost certainly not Armbian specific.
 
May 10 21:05:09 pirogue systemd-helper[8502]: dnsmasq: unknown interface end0 May 10 21:05:09 pirogue dnsmasq[8502]: unknown interface end0  
I am not an expert of application you try to install, in fact I never heard about until now. 

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