All Activity

Armbian v25.5: Expanding Horizons, Honoring Community, and Powering the ARM Ecosystem The Armbian team is proud to announce the release of Armbian v25.5—a significant update that reinforces the project’s commitment to delivering a reliable, high-performance Linux experience for ARM-based devices. This release highlights continued progress across the system, including deeper hardware support, enhanced tooling, and growing application modularity through armbian-config. In addition to the technical achievements, the community has received international recognition for its leadership and innovation in open-source infrastructure: Armbian has been awarded the 2025 NetBox Hero Award by NetBox Labs, joining a prestigious list of projects that have demonstrated meaningful impact in automation and open infrastructure practices. What’s New in v25.5 This release brings dozens of contributions from across the Armbian community, targeting system performance, configuration management, and hardware enablement. Noteworthy improvements include: Extended board support: The release introduces or improves compatibility for several boards including the TI SK-AM69 (PR #7885), Banana Pi M2+ (PR #8127), BeagleBone AI-64 (PR #7918), BeaglePlay (PR #7917), and PocketBeagle2 (PR #7897). These additions reflect Armbian’s growing footprint across both legacy and cutting-edge single-board computers (SBCs). Upstream firmware integration: Rockchip devices like the Rock 5B and Youyeetoo R1 now enjoy better audio and HDMI support (PR #7925, PR #7934). U-Boot versions were bumped for key platforms to align with upstream. Kernel upgrades: Devices based on Rockchip64 now run on Linux kernel 6.14 (edge branch), bringing better performance and peripheral support. Additionally, kernel patching logic is now configurable (PR #8149), allowing developers to build plain mainline kernel. Filesystem and boot enhancements: Improvements to EFI partition alignment (PR #8053) and BTRFS subvolume support further refine system boot behavior and make image generation more flexible for custom installations. Stability and quality improvements: Updates include boot script fixes, enhanced serial console support, and a simplified logging framework, all designed to improve diagnostics and system reliability during early boot and provisioning phases. armbian-config: Simplifying Post-Install System Management One of the biggest areas of growth in Armbian v25.5 is the continued evolution of armbian-config—a system utility for configuring Armbian images after installation. Whether setting up a home automation server or managing Docker containers at the edge, armbian-config now offers an impressive set of tools in a modular and approachable interface. Application library: Users can now deploy popular self-hosted applications directly from armbian-config, including Home Assistant (PR #235), Stirling PDF (PR #295), Navidrome (PR #367), Grafana (PR #351), NetData (PR #289), and Immich (PR #575). These modules are installed in isolated environments, making them easy to deploy, manage, and remove. Network and system settings: A more robust Wi-Fi station detection system improves wireless setup reliability (PR #286). New schematics and better documentation provide helpful context during network interface configuration (PR #278, PR #280). Overlay and BSP switching: Logic for board-specific overlays is now dynamically loaded, ensuring options are shown only where supported (PR #285). The BSP switching tool has been patched to correctly detect the branch being used (PR #281), and header installation logic was refactored to reduce redundancy (PR #277). These improvements reinforce armbian-config as a trusted utility for both new users and experienced developers building production or custom systems. NetBox Hero Award: Community Excellence Recognized Armbian’s impact reaches beyond code. In this release cycle, the project was selected as one of the winners of the 2025 NetBox Hero Awards by NetBox Labs. This award celebrates the community’s dedication to infrastructure innovation, automation, and transparency. Armbian was recognized specifically for its “elegant and extensible use of NetBox in support of a broad set of infrastructure needs.” This acknowledgment affirms the project’s alignment with modern infrastructure tooling and its unique role at the intersection of embedded systems and open infrastructure platforms. Read more: https://netboxlabs.com/blog/announcing-the-netbox-hero-award-winners-for-2025/ Recognized Contributors This release wouldn’t be possible without the contributors who authored the pull requests featured in v25.5. We thank: @amazingfate • @anarsoul • @andyshrk • @ArendJan • @Ayush1325 • @belegdol • @benhoff • @chainsx • @CodeChenL • @dependabot • @djurny • @efectn • @EvilOlaf • @FantasyGmm • @glneo • @Grippy98 • @HeyMeco • @iav • @ig3 • @igorpecovnik • @JohnTheCoolingFan • @juanesf • @kageurufu • @KubaTaba1uga • @lanefu • @leggewie • @libiunc • @mickeprag • @mlegenovic • @palachzzz • @paolosabatino • @plumbeo • @pyavitz • @q4a • @qbisi • @rpardini • @schmiedelm • @SeeleVolleri • @squassina • @ssp97 • @SuperKali • @The-going • @TheSnowfield • @timsurber • @torte71 • @trappiz • @useful64 • @retro98boy We also extend our appreciation to those who helped through bug reporting, testing, translations, documentation, and community moderation. Get Involved Armbian is open to all. Whether you want to contribute code, write documentation, test releases, or just ask questions—there’s a place for you. Download images: https://www.armbian.com/download Join discussions: https://forum.armbian.com Report issues or contribute PRs: https://github.com/armbian/build Read developer guides: https://docs.armbian.com Looking Ahead Armbian v25.5 is not just a technical milestone—it’s a testament to the collaborative power of open source. With a stronger foundation, broader hardware support, and a growing ecosystem of modular tools, Armbian is well-positioned to lead the future of ARM-based Linux computing. Full change logs: build framework, armbian-config The post Armbian 25.5 first appeared on Armbian. View the full article

Testing on Nanopi R2S revealed that U-Boot there does not have setexpr built-in. I expect it will be the same on the 'Rock64' board you have? To make sure - as I do not have your hardware here - can you check if the following commands work on your U-Boot monitor commandline: setenv b setenv c setenv a "a/b" setexpr b sub "a/" "" a echo ${b} setexpr c 1 + 1 echo ${c} fdt Also, to give a workaround (hopefully), the output of the following on the U-Boot monitor commandline: echo ${fdtfile} echo ${fdt_addr_r} echo ${kernel_addr_r} echo ${ramdisk_addr_r} ver Thx, Groetjes,

/dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@5011000"; }; }; fragment@1 { target = <&spi1>; __overlay__ { status = "okay"; #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&spi1_pins>,<&spi1_cs1_pin>; spidev1_1: spidev@1 { compatible = "armbian,spi-dev"; status = "okay"; reg = <1>; spi-max-frequency = <1000000>; }; }; }; }; sun50i-h616-spidev1_1.dtso

I'm dealing with a very annoying problem. Every iso I seem to get for bookworm minimal have the same problem that everytime I try to run nano the screen goes black. How to fix this?

/* * PPS-GPIO for H616 */ /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target = <&pio>; __overlay__ { pps_pins: pps_pins { pins = "PC9"; // Zero2 & 3 // pins = "PI5"; // Zero2w function = "pps"; }; }; }; fragment@1 { target-path = "/"; __overlay__ { pps@0 { compatible = "pps-gpio"; pinctrl-names = "default"; pinctrl-0 = <&pps_pins>; gpios = <&pio 2 9 0>; /* PC9 */ // Zero2 & 3 //gpios = <&pio 8 5 0>; /* PI5 */ // Zero2w status = "okay"; }; }; }; };

I have built and used it with the latest source and still HDMI audio and analog audio does not work. Is there any way to get HDMI audio to work other than using the vendor kernel?

More attempts: As suggested by DeepSeek (ChatGPT was less helpful), I also tried changing the bluetooth service script to ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=a2dp --noplugin=avrcp --noplugin=player and then restarting systemd itself and the bluetooth service, but no luck. I tried adding monitor.bluez.properties = { bluez5.roles = [ ] } to /usr/share/pipewire/pipewire.conf and restarting wireplumber, but no luck. I tried menu advertise uuids 0x1200 0x1800 0x1801 0x180a in bluetoothctl, to disable advertising the audio profiles, but no luck. But when in bluetoothctl, it really shows the audio connection being made when the phone connects.

When I change the country and keyboard settings with armbian-config, the keyboard change from qwerty to azerty but after a reboot, the keyboard is qwerty again. The country code stay correct as set in the config.

Hi there, Ok, after some walking back and forth, typos, reboots, rewriting entire images, multiple armbianEnv.txt files, looking into U-Boot sources, googling (of course) I managed to find some things and got U-Boot on my Helios64 to boot properly again. In short, the aarch64 requirements to the linux kernel, the way U-Boot sometimes will move the loaded kernel image in memory might overwrite the starting point of the inital ramdisk. The load addresses for kernel and initial ramdisk are mostly hardcoded in U-Boot but can be overridden by armbianEnv.txt or the bootscript. As Helios64 uses Rockchip rk3399 from the aarch64 family, the attached boot.scr might also work for you. This bootscript will only work on aarch64 systems, as it assumes the kernel is uncompressed! If you test this, make sure to make a backup of your existing boot.scr or read up on how to regenerate the boot.scr from your boot.cmd. Make sure you have serial console available Copy the attached bootscript to /boot Add verbosity=1 (if not already there) to your armbianEnv.txt Reboot Would be great that if you test, to share the serial console output here to see it it also works for you. I will also test and verify on one of my Nanopi R2Ss somewhere today or tomorrow. Will put all the details into a pull request. Groetjes, Update: Removed boot.scr as testing on Nanopi R2S showed some misbehavior.

I don't know your plans for how things are supposed to proceed. But if you plan to continue using my firmware build, I would suggest transferring it to the SPI flash, provided you are not wanted to use any other firmware in there. - This relieves you from having to pay attention to restoring my firmware build when changing an image. - You have two firmware versions available to you, between which you can switch with the SPI-MMC boot switch. - Even without the eMMC module, you can boot an OS from another connected storage device. - The U-Boot console is also available with an HDMI monitor and a USB keyboard and can be used for analysis in the event of startup problems. Of course, it is also used to select various boot options if autoboot is interrupted.

Thank you that worked. Awesome, what a pitty that the plain armbian image doesn't work. Maybe this is something for a developer but not sure how to reach them.

Use: dd bs=512 seek=1 conv=notrunc,fsync if=odroid-n2/u-boot-meson.bin of=/dev/${entire-device-to-be-used} as outlined in the referenced post to replace the existing firmware on the eMMC. Firmare is residing outside of partition layout structures so you can only write it by absolute access.

I'm not an expert about it - could you tell me how I would do that? I currently see only the armbi_root partition on my emmc.

How would that work? I just downloaded your u-boot-meson.bin file. Where would I have to place it?

Do they use the same U-Boot or different version? It could be the server image is just composed in a faulty way, some detailed failure somewhere. I would build something for the specific SBC myself or copy the boot area from the HA image into your image/emmc. Or maybe wipe it an use an SD-card with only a U-Boot blob that you want or build yourself maybe from latest U-Boot denx.de. I have done that for QEMU variat, also did some non-standard changes and that works. In a working Armbian, I have checked/installed 3 variants (vendor, current, edge) and EDK3-UEFI for my ROCK5B and then also switching kernels. No eMMC, but only SPI-flash using flashcp and dd for SD-card. But that is Rockchip, Amlogic I do not know, do not have.

Certainly, but I don't know if anyone has taken the effort to integrate a current version so far. The mainline U-Boot project always provides the source codes for the latest versions. You can build it by yourself with the Armbian build framework, or use my build for a quick test.

Isn’t uboot coming with the armbian image on the emmc? Could you tell me where I find the most recent uboot? The last is from 2022?

The log is telling that the firmware can't operate the eMMC: Furthermore, the alternatively attempted BOOTP and PXE boot are also unsuccessful because it seems that a server is found, but the necessary bootflow is not configured correctly. As you are running a quite dated U-Boot, maybe using a cureent release has better support for the eMMC.

My NanoPC-T4 is still alive: For a quick test, I used my NVME with my latest OS, which usually powers a different SBC: Please do not let it bother you that the NanoPC-T4 uses an outdated kernel to run the OS. This is due to my negligence in building the current kernel without the necessary hacks needed for proper HDMI functionality. Some of the hacks have now been proper implemented in mainline, while others are still in flight. Until this process is completed, I have decided out of laziness to temporarily use an outdated kernel, as I do not miss any functionalities that a current kernel could provide me. My status LED is not blinking at boot at all. To debug boot problems, blinking LEDs are the worst possible option. Only proper console logs are of value. During OS runtime, it is configured as an HDD LED to indicate access to the microSD, as this is important information for when it is safe to remove it. I am still running my firmware from the microSD, again out of laziness to copy it to the eMMC. But any of nessesary support for the NanoPC-T4 is availabe and maybe some boring day or some spezial demand let me revisit to configure it properly. Until then, the bitrottining configuration is sufficient to serve more or less as an always-on terminal server for several USB serial adapters, which provide me with console access to my other SBCs if necessary.

What do you think....? still needs touch and cam.

I've spent a couple of days googling and "all the AI'ng" this and I just can't find anything that will get my Orange Pi 5 or Orange Pi 3 Zero Pin 3 or 5 to do anything at all. First, I'm running: v25.2.3 for Orange Pi 5 running Armbian Linux 6.1.99-vendor-rk35xx (similar for the zero) $ ls /dev/i2c* /dev/i2c-0 /dev/i2c-10 /dev/i2c-2 /dev/i2c-6 /dev/i2c-7 /dev/i2c-9 $GPIO readall SDA.5 | IN | 3 SCL.5 | IN | 5 (it says OFF on the zero) $sudo i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- I've tried.. \boot\ overlays=i2c2 I've also tried overlay .dts to turn off uart_a (shares the same pins) /dts-v1/; /plugin/; / { fragment@0 { target = <&i2c2>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&uart_A>; __overlay__ { status = "disabled"; }; }; }; No matter what I do the pins are all high, zero signal at all ever. What am I missing? Thanks!

Thank you so much. 🤗 Let's buy the board, then.

Latest image: patrick@bananapif3:~$ sudo docker run hello-world [sudo] password for patrick: Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 2382d725750e: Pull complete Digest: sha256:dd01f97f252193ae3210da231b1dca0cffab4aadb3566692d6730bf93f123a48 Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly.

Hello… Jayson here ...and I have installed the image of Armbian Gnome Desktop for RPI5. Next I get up to par with this command: sudo apt install linux-headers-edge-bcm2711 alsa* pavucontrol pithos vulkan-tools mesa-vulkan-drivers xdg-desktop-portal-gnome gnome-remote-desktop libspa-0.2-bluetooth qv4l2 obs-plugins obs-studio pipewire-alsa pipewire-audio pipewire-audio-client-libraries pipewire-bin pipewire-pulse gnome-shell gnome-shell-common gnome-shell-extensions gnome-shell-extension-manager libpipewire-0.3-* gnome-remote-desktop gnome-settings-daemon* x11* git qgnomeplatform-qt5 qt5-image-formats-plugins qt5-qmltooling-plugins qtvirtualkeyboard-plugin qttranslations5-l10n libqt5svg5 qt5-gtk-platformtheme qtwayland5 xdg-desktop-portal-gnome qv4l2 rpi-imager gnome-tweaks snap && sudo snap install chromium && sudo apt install inux-headers-current-arm64 linux-headers-current-bcm2711 linux-headers-current-bcm2712 && sudo apt install v4l2loopback-dkms Then obs will work with: MESA_GL_VERSION_OVERRIDE=4.2 obs More soon!!!

I'm using Bluetouch in my iPhone as a bluetooth mouse (rarely when needed) for my OrangePi/Armbian/Kodi setup. All fine with that… except… with my iPhone paired to the OrangePi, it also connects all its audio to the OrangePi, *all the time* when in range, unless I completely disable bluetooth from the iPhone. According to the only instructions I've found, I've tried setting [General] Enable= in `/etc/bluetooth/main.conf`, and restarting the bluetooth service, but the only effect this has is that there's no audible output. The phone still connects its audio to the box, just with no audible output. How to completely disable Armbian from advertising itself as a bluetooth audio device, while being able to connect bluetooth peripherals?