All Activity

Good that this is made default now for various boards. If a board/computer has no factory written bootloader, so only bootROM/maskROM, then this allows way more flexibility and also will get rid of endless topics and support issues that have their root cause in SD-card (failing, or worse fakes, fake brands, etc). As a scrub either done automatically or as support request on-demand/ad-hoc will tell. Also many operations can be done while the board/computer is kept running, no reboot needed. Like transferring rootfs OS from SD-card to NVME and many more great things. Like replacing an SD-card without reboot. Or rollback to know-good older snapshot after faulty update. I see I wrote some things about it here: https://forum.armbian.com/search/?q=CONFIG_CMD_BTRFS&quick=1 For boards/computers with factory written bootloader, so PCs with UEFI or BIOS or the strange Raspberries with their boot(EEP)ROM that need a 1st FAT, it is a different story. I figured out that for my computers that already use Btrfs for rootfs for years, even tiny/old RPi0/1, it is currently better alignment, so that I stick to heaving an extra boot partition still. It can be very small, I had defaulted to 40MiB some years ago for a single Linux OS VM (x86 or ARM), but just for some bootaa64.efi file that is already a lot. For RPi, 3MiB was enough, so you store only a bootcode.bin start* fixup* config.txt uboot.bin bootaa64.efi. But that extra boot partition is also easily very confusing, especially for RPi like methods where kernel+initramfs+DTB are copied. Also, I had Btrfs enabled U-Boot, an Ext4 bootpartition and Btrfs rootpartition while doing experiments (booting from Btrfs raid1 straight from U-Boot) on QEMU and AllwinnerH3. kernel+initramfs+DTB were accidentally read from Ext4 (/) instead of Btrfs (/boot) and more such confusion. So then I recompiled U-Boot without Ext4 (so only FAT,Btrfs), then fine. But generally I would keep Ext4 of course. With just 1 partition, then those issues are is avoided. Then simply 'U-Boot object' and 'rootfs object', where the latter can still be chosen Ext4. Btrfs U-Boot + rootfs also would make raw/flat images viable maybe. xz-compressed will certainly have smaller download file, but for full desktop variant images, there might be an overall advantage. If rootfs is written by Armbian build with let's say compress-force=zstd:9, only first MBR+bootloader sectors, the Btrfs metadata and some filesystem slack is not compressed. I think some statistics are needed first, maybe it is not worth the effort for mass-downloads also via torrents, mirrors, etc, but for own local builds I certainly see benefits. At least I force compress almost all newly written block-devices, so also a restore from backups. It can keep thin-provisioned volumes/images very small, also roughly halves the write-time for (slower/older) SD-cards.

Hi I am trying to build an image for kickpi k2b. Mine is version 2.2. I am using build repo of Armbian project. The image that I have prepared is not able to boot. So I have attached an ftdi module and the console shows: U-Boot SPL 2025.07_armbian-2025.07-Se37d-P526e-H8869-Vbdbf-Bbf55-R448a (Nov 30 2025 - 04:16:12 +0000) DRAM:This DRAM setup is currently not supported. resetting ... My build options are like this: ./compile.sh build BOARD=kickpik2b BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=yes RELEASE=trixie Please help me with proper configuration/build options. R,

Hello. I get an error when compiling. Can you please help? I'm using the following command: ./compile.sh BOARD=vontar-h618 BRANCH=edge BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base KERNEL_CONFIGURE=no RELEASE=trixie git clone https://github.com/NickAlilovic/build.git --branch v20251014 Log file in attachment log-build-14db644f-d9db-4a13-ae47-79423f220cb6.log

This is not recommended. https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card

I built Debian 13 (Trixie) branch v20251014 running Transpeed-8k618t and tested it for general use. The system ran smoothly, so I started testing Bluetooth and the included IR remote control. Bluetooth doesn't detecting a signal. I've read in previous posts about this and found that Bluetooth still doesn't compleworking. Is this correct? IR remote control works properly when used image on an sd card. But when installed to emmc from image of sd card and ran it. IR remote doesn't work at all. I've tested it several times. Does anyone else have the same problem as me?

btrfs on Helios4 is now on by default and there is a uboot-btrfs extension to easily enable this for other boards or even at compile time.

With the latest changes in Armbian and most importantly the update of u-boot to v2025.10 for Helios4, it is now possible to boot SATA and USB from u-boot flashed to SPI NOR flash, with the dip switch set to SPI boot mode. This even includes booting straight from u-boot to btrfs now.

Yes, give me a couple days as I am in the middle of project.

Hello, I have the same issue. UART output: Trying a 2023 build to see if it starts, but looking online it looks like this is caused by a kernel build being incomplete and when it's wrong the device specific kernel files are smaller than usual. I noticed the 2023 image is about double the size. Same error on that, though channel 0 CS = 0 MR0=0x98 MR4=0x3 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0xS = 1 MR0=0x18 MR4=0x3 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 R0=0x988 MR4=0x1 MR5=0xFF MR8=nel 1 training pass! change freng done channel 0, cs 1, advanced training done ng done ng done change freq to 856MHz 1ng done ng done ng done ng done ddr_set_rate to 416MHZ,Boot1 Release Time: May 29 2020 17:36:36, version: 1.26 CPUId =mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000 mmc: ERROR: Card dOR: SDHCI ERR:cmd:0x102,stat:0x1mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000 mmc: ERROR: Card did not respond to voltage select! SdmmcInit=2 1 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 Us2000 , 0 StorageInit ok = 58036adLba = 2000 8fa0 NOTICE: BL31: v1.3(release):845ee93 NOTICE: BL31: Built : 15:INFO: plat_rockchip_pmu_init(1196): pd status 3e INFO: BLded by BL2 boot loader, Booting device without OPTEE initializatError initializing runtime service opteed_fast INFO: BL31: Pit to normal world INFO: Ent U-Boot 2022.04-armbian-2022.04-Se4b6-Pbcc6-Hc48d-V50f4-Bb703Model: Clockworkpi A06 DRAM: 3.9 GiB PMIC: RK808 Core: 215 devices, 18 uclasses, devicetree: separate MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC..USB EHCI 1.00 Bus usb@fe3c0000: USB EHCI 1.00 scanning bus usb@3 USB Device(s) found scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found scce Scanning mmc 1:1...s #0, OK Found U-Boot script /boot/boot.scr 3906 bytes read in 5 ms (762.7 K500000 Boot script loaded from 144 bytes read in 4 ms (35.2 KiB/s) 16738941 bytes read in 711 ms (22.5 MiB/s) 38343168 bytes read in 1625 ms (22.5 MiB/s) ip/rk3399clockw_qkpi-a06.dtb' 2825 bytes read in 12 ms (229.5 ## Loading init Ramdisk from Legacy Image at 06000000 ... ImOK ERROR: Did not find a cmdline Flattened Device Tree

Images shall only be written with imaging tools that validate burning results. This saves you from corrupted SD card contents. Approved Tools: USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool (may contain spyware)

Can you run a uefi-x86 image in a VM and see if you can reproduce the behaviour? I doubt this is specific to your board but an error somewhere else.

Hi I dd the Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img to a SD card (/dev/sdc) and then run a fsck -f /dev/sdc1 and got errors: sudo fsck -f /dev/sdc1 fsck from util-linux 2.39.3 e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Entry '.' in ??? (1065) is duplicate '.' entry. Fix<y>? .... Tried few SD cards, same result. Tried those SD cards with other images, i.e. Armbian_24.8.4_Rock-5c_bookworm_vendor_6.1.75_minimal.img no problems. Could anybody verify this behavior? Thanks Chris Armbian_25.11.1_Rock-5c_trixie_vendor_6.1.115_minimal.img image generates the same problem.

You can find them here https://imola.armbian.com/cache/artifacts/ In case you / someone want to help fixing this - this script https://github.com/armbian/armbian.github.io/blob/main/.github/workflows/generate-web-index.yml needs to be adjusted to add additional entries to the download JSON file for those three variants https://github.com/armbian/armbian.github.io/blob/main/.github/workflows/generate-web-index.yml#L140-L142 Few months ago GitHub introduced limitations on number of artifacts per release to 1000. And in order to keep providing CLI + desktop combo - especially for - community targets, we had to drop uploading sha, asc and torrent files to GitHub release storage. Instead, they are moved to cache.armbian.com under predicted structure, but links are missing from JSON as they don't exists on the release page where current script is scrapping from.

I type the root password once, press enter to retype it, but it jumps straight to the login prompt. Do not pass Go, do not collect $200. I’ve been dealing with this for the past month. At first, I thought it was just my 2GB model acting weird, but today I had two 4GB units do the same thing. It only happens with the Debian 13 Minimal/IOT image. I didn't want the overhead, but I am using the Debian 12/XFCE Desktop image that works.

As a follow up. Armbian doesnt seem to have proper pinebook pro support in its firmware package (i.e `armbian-firmware`) Someone was up until recently keeping track of different firmwares on the pinebook pro (link https://github.com/cobratbq/pinebook-pro) On mine I have just symlinked the raspberry pi4 versions, which has improved wifi and bluetooth. As far as i can tell, an appropriate pull request is needed against this repo? https://github.com/armbian/firmware/tree/master/brcm I was also able to update to trixie without any problems.

the software i used to flash the sd card, was balenaEtcher and Rufus, i did not validate the checksum both the SHA ASC are 404 file not found.

Are you saying you are missing further steps in between setting root passwd and being logged in?

How did you flash the Armbian image? Did you validate the checksum for the image? What software did you use for flashing the image?

I don't even have an HDMI device connected. Running it headless. And when you say Debian 13, are you describing a way to convert Armbian to Debian in-place? Because honestly, with its inability to set time and missing i2c buss, I've lost confidence in Armbian. But I don't understand the effect of your commands. Is this converting Armbian to Debian 13? Is there any way to just build Debian 13 on the SD card or internal EMMC?

Ok, will try wiFi by doing that. I posted more testing in the thread of my device.

hi, im trying to make my radxa 4d in to a open media vault server, iv down loaded the file from armbian's web side but it wont boot, pluging it in to one of my raspberry pi's and useing gparted, i can only see one partision for it and can view it, dose this need a boot loader? iv also tryed downloading Debian 14 (Forky) from the armbian web site and got that to boot, but the script from armbian-config is broken ( missing stuff like php) and iv tryed the script from open media vault but that errors with eth0 missing. do i need to install a boot loader on the armbian open media vault image ?

Hi, I've tried to setup the latest Debian 13 (Trixie) for the Renegade board. I can flash the image with no issue. The problem comes it boots up, prompts for root password. I can type in then press enter, and then it goes to login. This only happens on the Debian 13 (Trixie). I am using the Debian 12 XFCE imange no issue. I am not sure if this is a bug or what, but I loved to use Debian 13, I am trying to setup Docker with the latest OS.

thanks~

I Installed radxa os (debian) again which works fine and tried to scan SPI flash via terminal but It was sequences of all zeros and then all ones, so no I presume no information stored in SPI, just to be safe I also erased it. After some experimentation I found that I cannot control armbian terminal through UART and that's why I thought it hanged but I managed to connect via SSH (ty @eselarm) with ethernet to my laptop and custom DHCP and everything worked okay. The only problem is that HDMI still does not work. HDMI shows connected but I get this error from dmesg:

I guess this should do: