Active threads

Dont run the entire script at once. Run one section at a time for each step at a time and monitor the output. Example: Run the lines under 1A and monitor the output, Proceed to 1B and monitor. The only changes made to /etc/apt/sources.list are enabling the Debian unstable/experimental repos (which do not require public keys to be manually added. Full disclaimer: This was something I did as an experiment. Full Vulkan support for the Mali g610 is still not officially supported in Debain stable. To be completely honest, I personally rolled back this change by restoring a Timeshift backup taken before the changes. The dependencies installed by Debain Experimental for the latest Mesa version will also break dependencies used by Armbian for firmware updates. Please be smart and remember to make backups before making updates like this. Personally, I'm fine with waiting a few years for Debian to eventually apply compatibility to the stable branch

Hi all! I am entirely new to Armbian. I see Radxa's Rock5B RK3588 based SBC is suppored and its Armbian page is https://www.armbian.com/rock-5b/ . Can you give me a small crash course on your experience with Armbian on the Radxa Rock5B? If you have an idea of any of the points I raise below, please share. 1. Super stable? Generally to use and to upgrade Armbian, how stable has it been to you? 2. Which image should I pick? I see both Debian and Ubunto are offered. I'll pick Debian. Then there are "Desktop", "Server" and "Minimal/IOT"and "Dedicated applications" images, and some are listed as "Linux v6.1" and some as "Linux v6.12". Which one of v6.1 and v6.12 should I take? 12 means twelve and 1 means one, right, so 6.12 sounds a lot preferable. Under "Server", there is no Debian option at all. Any idea why? What does "Dedicated applications" mean here? If I would just guess my way through, I would probably take the "Desktop" variant with 6.12 kernel and then on the first boot I'd disable the GUI permanently by running "systemctl set-default multi-user.target". It sounds like "Desktop" should include a lot of drivers. Who knows, perhaps one of those drivers would be needed for a PCI or USB peripheral. In respect of drivers, "Minimal/IOT" sounds risky. Did I get it right? 3. Armbian SPI flash image with particular u-boot?? Radxa distribute a SPI flash image with their latest u-boot. Typically you flash a MicroSD card with their whole Debian distribution on it, then you run "rsetup" and pick the SPI flash option. But, their wiki contains the manual flashing instructions based on "dd" also. Ref https://docs.radxa.com/en/rock5/rock5b/download . I was told that Armbian has its own u-boot for Rock5B, is it true? Where is it, and where are the installation instructions? 4. Peripherals, drivers, all OK? Firstly what about the peripherals such as the onboard Realtek 8125 2.5gbe NIC, is it always stable? Does everyone only have good experiences with using the 22x80mm M.2 slot on the bottom which has 4x PCIe v3 lanes? All good experiences with the 22x30mm A+E key M.2 slot on the top, which has 1x PCIe v2 lane? 5. PD? About the USB-C PD power supply protocol negotiation for voltage, the main Armbian page https://www.armbian.com/rock-5b/ says "PD is broken for the 5B model (background) on most revisions that are in the wild and is causing boot loop. Workaround is to use a stupid / fixed 5-24 volts USB-C power supply." and links to https://www.spinics.net/lists/linux-usb/msg239175.html . I presume here, just using a USB-C power supply that supports up to 5A in the default 5V mode will do, normally. But to not negotiate to 20V sounds quite limited especially as the Rock5B has the hardware to take 20V DC input. Radxa themselves have implemented support for hte USB-C PD protocol negotiation in their Debian distribution. What about just bring in their code as pragmatic solution? 6. "aptitude update; aptitude upgrade" OK & safe? Is "aptitude update; aptitude upgrade" always safe on Armbian, so any kernel offered will be properly patched? Did anyone's system break down permanently after doing "aptitude update; aptitude upgrade"? 7. Kernel version? Just for recap, which kernel version is provided right now? I think someone said 6.12. Via "apt upgrade" will it pick a newer kernel automatically now or when one is released? Via "apt install" are there any optional even newer kernels avaiable? 8. URL to the Rock5B/RK3588 specific patches? Just curious, where is Armbian's sourcecode that's specific to Rock5B and RK3588 actually? 9. Mainlining status? Does anyone have a notion of what status there is to including Rock5B & RK3588 specific patches to mainline Linux? Ideally over time custom patches should go to zero, right. However also occasionally for some device it seems like the mainlining work just grinds to a halt. How is it here. 10. Armbian-Debian packages What is the relation between Debian's packages repository and Armbian's - does Armbian copy essentially everything? 11. ARM64 CPU optimizations? Are sensible ARM64 CPU optimizations enabled so generally Armbian operates at a really high speed? I'd guess yes. Many thanks.

If the u-boot on the unit supports USB Boot, yes. GXL:BL1:9ac50e:bb16dc;FEAT:ADFD318C:0;POC:3;RCY:0;EMMC:800;NAND:81;SD:800;USB:8;LOOP:1;EMMC:800;NAND:81;SD:800;USB:8;LOOP:2;EMMC:800;NAND:81;SD:800;USB:8;LOOP:3;EMMC:0;READ:0;0.0;CHK:0; The above looks like USB Mode. This Mode is for flashing vendor or custom imgs to the unit via USB. This is for recovery.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

@mvpwar for RK3566 NPU you will need to use an armbian fork from Joshua Riek https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/page/16/#findComment-211031 I think you will need to fork and rebuild it, the files got expired

Forget about it. The problem was the switch at my work desk which seems to be dead. So no physical connection...

Where exactly is it? Can you send me a download link? I have already damaged many units, according to your instructions git clone --depth=1 https://github.com/armbian/build.git cd build ./compile.sh 构建 BOARD=rk3328-heltec BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=no EXPERT=no KERNEL_CONFIGURE=yes KERNEL_GIT=shallow RELEASE=bookworm

Thanks for the logs. Do you have tested PCIe extension ? My personal project is to create one NAS with one PCIe-to-SATA add on

I've got Orange Pi 2W board and installed Debian 12 Home Assistant image to it (image link). There is a huge problem with it. Very often there is no bluetooth module appeared in system. I need to reboot system for 10-15 timer to make it work. What can be a reason? I attached 2 boot logs (with good BT appears and no BT appears), I hope it will help to find out the issue. boot_log_bt_good_02.zip boot_log_bt_bad_02.zip

Packages `base-files` 25.* are not not built for Debian Trixie, which prevents upgrades and in my case installing new software. Managed to upgrade my system with some manual labour, but apt.armbian.com/pool/trixie-utils/b/base-files/ Results in errors like: /etc/armbian-image-release:

You are going down the wrong path. You should start here with understanding the Armbian build framework: https://docs.armbian.com/Developer-Guide_Overview

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.

update: if disconnect TX from USB-UART adaptor - then there is infinite output that changes every microsecond with more strings: ESC[1;47rESC[46;1H[ 45.827723][ Tible6] [dhd-wlan0] w l_ext_iapsta_evefs.readdy=1 (/system/etcb/init/hw/init.uo sr not foun db^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1Hnt : [S] Link UP with c8::ca:98^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1HESC[1;46rESC[46;1H ESC[1;47rESC[46;1H[ 45.827747][ T6] [dhd-wlan0] wconsole:/ $ ^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1Hl_notify_connect_status : wl_bss_conn.127^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1Hect_done succeeded with c8:ca:98 ^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1HESC[1;46rESC[46;1H ESC[1;47rESC[46;1H[ 45.843270][ T6] [dhd-wlan0] wl_notify_connect_sonso le:/ $ c^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1Htatus : wl_bss_connect_done succeeded127|^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1H with c8:7f:54:e0:ca:98 vndr_oui: 00-90-127|^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1H4C 00-0C-43 00-0C-E7 ^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1HESC[1;46rESC[46;1H ESC[1;47rESC[46;1H[ 45.881840][ T165] type=1400 audit(1699712132.610:14conssole:/ $ ^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1H4): avc: denied { open } for comm="FD655_Demo" path="/sys/class/fd655/fd65console:/ $ ^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1H5_vpause_127|y^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1Hflag" dev="s127fig=|^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1Hysfs" ino=19647 sc[ 82.040633][ T386] read descriptors^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1H[ 82.040698][ T386] read strings^MESC[1;46rESC[46;1H ESC[1;47rESC[46;1H[ 82.043097][ T1] init: processing action (sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1) f82.045159][ T1] init: Co mmand 'symlink /coESC[46;159HnESC[46;159HfESC[46;159HiESC[46;159HgESC[46;159H But still no active shell session

just wanted to check if there is plan to have an image for the Rock 3B model? update: just tested the latest image for Rock 3A, and it is working ok. version: Armbian 25.2.1 Bookworm Minimal/IOT Kernel: 6.12.13, Size: 266.4 MB, Release date: Feb 13, 2025 I will run a few docker containers to see if there are any issues.

HDMI audio has been merged into 6.15. Board may need additional device tree nodes to make it work. Analog audio should work already as well bug may also need additional nodes. Collabora sent for Rock5B and 5B+ only upstream. https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

if NAMESERVER is not set it falls back to default 1.1.1.1 A while ago I made a hack to enforce using whatever hosts nameserver is:https://github.com/armbian/build/blob/e03b1b543cda430fbffcb62c979aecabee42b044/config/templates/config-example.conf.template#L25

hello. Armbian 25.08 for Rockpi 4a executed dtc -O dtb -o rockchip-pwm-gpio.dtbo -b 0 -@ rockchip-pwm-gpio.dts. copied dtbo to /boot/dtb/rockchip/overlays. There is none in /sys/class/pwm/pwmchip1 . /sys/class/pwm/pwmchip0 is available. I can't create the pwmchip1 pwmchip2 folder. Operation not permitted

After the last update/upgrade USB BUS 7 has completely disappeared! So no life at all on the USB-C port. The following packages were upgraded : linux-dtb-edge-rockchip64, armbian-bsp-cli-odroidm2-edge, linux-image-edge-rockchip64, linux-u-boot-odroidm2-edge, armbian-firmware I suspect linux-dtb-edge-rockchip64 is not the M2 specific package and it has over written the dtb. Also I can't seem to install the kernel headers from armbian-config. It appears to go through the motions but nothing is installed. Also where can I find a documentation on what each device overlay (in armbian-config) is for?

@rickg i send you a private message

This reminds me of old issue on rpi forum, back to Debian10 times more or less when RPL did not support initramfs and I have been using Btrfs for RPis since Buster (or for sure Bullseye) timeframe. I loop mounted Armbian rolling rpi4 trixie image and ran it via systemd-nspawn -b -D <mountpoint> Then it turns out what I thought: the installed firmware package includes the script same as on Raspberry Pi OS from RPL themselves to copy/rename standard Debian kernel+modules install patch to the FAT boot partition. root@localhost:~# apt list | grep raspi raspi-config/trixie,trixie,now 20221214-0ubuntu1 all [installed] raspi-firmware/trixie,trixie,now 1:1.20250430-1 all [installed] raspi-gpio/trixie 0.20231127 arm64 raspi-utils/trixie,trixie 20250314-1 all root@localhost:~# dpkg -L raspi-firmware | grep z50 /etc/initramfs/post-update.d/z50-raspi-firmware /etc/kernel/postinst.d/z50-raspi-firmware /etc/kernel/postrm.d/z50-raspi-firmware And it is this part of z50-raspi-firmware flavour="$(echo "$initrd_version" | rev | cut -f1 -d- | rev)" case $flavour in v6|v7|v7l|v8|2712) ;; *) echo "ERROR: Unsupported initramfs version ($initrd_version)" exit 0 ;; esac On 1 of my RPi4 I had also the standard Debian kernel 'linux-image-arm64' besides the RPi kernel 'linux-image-rpi-v8' and grub-efi. So when the bootFAT parttition is tagged 0xEF00 (ESP) I could run the image/SD-card unmodified in virt-manager selecting the vanilla Debian kernel in GRUB. I have thought a lot about what to do with those hook scripts in /etc/initramfs, also created various own ones, for Raspberry Pi OS and Raspbian and Armbian. The latter as it is U-Boot (on Rockchip/Allwinner) but just recently I put EDK2-UEFI v1.1 in SPI-flash and that makes all the efforts void as I now use default grub to load Armbian (and Opensuse) on RK3588. For RPi (3, 4, 5) this won't work unless some intermediate efi binary loader is used like is done in Opensuse, for Fedora maybe as well, I don't know. Still this won't work for RPi5 (yet) as its RP1 chip is a bottleneck for upstream support (complex PCI-E DeviceTree handling, see patches efforts done by Suse people AFAIR). With introduction of Bookworm, the RPi firmware can load standard names for initramfs for all RPi HW variants back till 2012. But still no way to select a specific kernel adhoc at boot time via serial console for example (like extlinux.conf for U-Boot). The U-Boot v.s. RPI-firmwarebootloader feels a bit like UNIX pathnames v.s. MS-DOS pathnames, e.g. "/tmp" v.s. "C:\TEMP" or "Image" v.s. "kernel8.img" or "uInitrd" v.s. "initramfs8". Maybe the option is to patch z50-raspi-firmware, maybe remove it from the .deb package. But also it is just a warning, so who cares one could think. Other option is to use the vanilla Debian variant of raspi-firmware root@localhost:/etc/apt/sources.list.d# apt list -a raspi-firmware raspi-firmware/trixie,trixie,now 1:1.20250430-1 all [installed] raspi-firmware/testing 1.20240424+ds-6 all That older version has other script implementation (very different), also uses upstream_kernel=1 in config.txt, which selects other firmware DTB names for Pi3. Now writing this, I think 'vendor' could be downstream RPL based, so new firmware package and 'current' and 'edge' could be upstream mainline. But that also would mean almost no RPi5 functionality as long as that RP1 I/O chip functionality is not upstreamed. I don't know what status is, latest I know is that the wired ethernet still does not work, workaround is to use a RJ45 USB2 dongle on the USB-C connector.

Interesting, didnt realize that.

Thank you for reporting. If current images have troubles, you can try to use previous ones. There is a link on the download pages or you can find them this way. https://forum.armbian.com/topic/52406-helios-64-fails-to-boot-since-upgrading-to-bookworm/#comment-219614 Which works best for your case, you will need to find on your own. We don't store this information / forum search might help. Similar goes with 3rd party images - most are Armbian based and none is in perfect state, things break apart all the time. By providing logs (if possible) someone might give you hints to workaround the problem, without hardly. As I understand from your report - image boots, but USB port doesn't work to enter password? And also network is down, so you can't login remote. I haven't tested HC4 on last builds, but C4 works just fine. In any case, fixing the problem can take some time - Hardkernel never supported our work, so we don't have active maintainer at stand by. It depends on volunteers that read this forum. When they notice and found time to look into this.

As the Armbian project transitions from spring into summer, the final week of May 2025 brought a dense flurry of development activity, delivering improvements across kernel support, bootloader updates, system performance, and user experience enhancements. With over 35 pull requests merged, this week showcased the Armbian community’s continued dedication to modernizing and stabilizing its build framework and board support packages. Performance & Build System Optimizations A notable performance enhancement arrived via #8248, where build engineer @rpardini delivered a major speed-up in Docker extension handling, cutting processing time by over 50%. Complementing this, PR #8249 addressed inefficiencies in rootfs-to-image by avoiding --sparse, significantly improving I/O speeds on various filesystems. Kernel version parsing and custom kernel description functionality also landed with #8152, thanks to @Grippy98, enabling displaying kernel versioning within build branches. Board Support Enhancements & Bootloader Upgrades A slew of boards received attention this week. The NanoPC-T6 series saw a key modernization in #8219 and #8239, switching to mainline Arm Trusted Firmware and bumping U-Boot to v2025.04 final. The Quartz64A board followed suit in #8250, while the Odroid HC4, Khadas VIM3, and Mixtile Blade3 all received U-Boot updates or reverts to improve stability. Legacy and edge kernel support was also improved. Notably, Rockchip64 edge kernel configuration gained CONFIG_NETKIT=y (#8237), and fixes for display mode handling on RK3588 boards were added (#8253). Meanwhile, the Orangepi 5 Ultra switched to a mainline kernel source (#8252), reinforcing Armbian’s ongoing effort to shed legacy components and embrace upstream compatibility. Infrastructure & Usability Improvements Behind the scenes, @igorpecovnik contributed multiple usability tweaks, including a fix for HiDPI detection (#8236) and @rpardini added improved serial console fallback behavior in GRUB (#8247). The GPG key placement was standardized across distros (#8128), simplifying build reproducibility. Device Tree and Service Fixes The smart am40 received a long-needed RTC node and U-Boot bump (#8214), while the Helios4‘s wake-on-LAN service was fixed (#8235), reinforcing Armbian’s commitment to community-requested board maintenance. Wrapping Up This week’s burst of activity highlights the Armbian community’s tireless commitment to refinement and modernization. Whether through performance enhancements, kernel bumps, or quality-of-life fixes, the project continues to evolve rapidly. Users can expect a more responsive, stable, and future-proof experience across a growing roster of supported hardware. Stay tuned for further updates as June unfolds. The post Armbian Development Highlights: End of May 2025 first appeared on Armbian. View the full article

code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-install should be able to do that. Though since there is no option to select WHICH version, if there are multiple installed, to write, I suggest to first check with code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dpkg -l which uboot package/s is/are installed and make sure there is only the one that you want to write.

config is there: https://github.com/armbian/build/blob/main/config/boards/orangepi5-ultra.csc DIY: https://docs.armbian.com/Developer-Guide_Overview/ Go for edge