All Activity

I'm flashing the image to a microSD card using Armbiam Imager doesn't boot: works OK:

my model without emmc (3 ram + 0 emmc). Could that be the reason? I apologize for the misinformation; I checked my board, and the revision number isn't listed there either.

Could you tell me where you found the revision number? I don't see anything written on my board.

no, it have secureboot, emcp 1,5gb instead 1 or 2gb ram, i tried to boot x96q lpddr3 + secure patch + orangepi zero3 1,5gb patch but at uboot it allway say 2gb ram 0g effective. uboot spl load 1,5gb ram correctly

Hi @Jean-Francois Lessard Thanks for sharing the new openvfd option for Armbian. I am using a Allwinner H618 Android 12 TV box that got FD6551 controller. I have verified the chip model by opening the box. The headers of respective version is also installed and I have double checked that. apt install -y linux-headers-edge-sunxi64 Reading package lists... Done Building dependency tree... Done Reading state information... Done linux-headers-edge-sunxi64 is already the newest version (25.11.2). From the Android dts file I can find the following. I have tried the configuration mentioned here as well but there is no VFD output. Is there any other configuration I have to check or modify for the VFD to work? leds { leds_clk = <0x23 0x08 0x0b 0x00>; leds_dat = <0x23 0x08 0x0c 0x00>; status = "okay"; }; fd655_para { device_type = "fd655_para"; compatible = "Ik,fd655_dev"; fd655_clk_io = <0x23 0x07 0x06 0x01>; fd655_dat_io = <0x23 0x07 0x07 0x01>; status = "okay"; }; ald-colorleds { compatible = "elebao,colorleds"; dev_name = "ald-colorleds"; pinctrl-0 = <0x70>; colorleds_data_gpio = <0x23 0x07 0x02 0x01>; status = "okay"; }; I tried to make the module as you have instructed, however I am getting the below given error messages. /tm16xx-display# make module make EXTRA_CFLAGS="-DCONFIG_TM16XX -DCONFIG_TM16XX_KEYPAD -DCONFIG_TM16XX_I2C -DCONFIG_TM16XX_SPI -include /root/tm16xx-display/drivers/auxdisplay/tm16xx_compat.h -I/root/tm16xx-display/include/" -C /lib/modules/6.12.11-edge-sunxi64/build M=/root/tm16xx-display/drivers/auxdisplay CONFIG_TM16XX=m CONFIG_TM16XX_KEYPAD=y CONFIG_TM16XX_I2C=m CONFIG_TM16XX_SPI=m CONFIG_LINEDISP=m modules make[1]: Entering directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' CC [M] /root/tm16xx-display/drivers/auxdisplay/line-display.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_core.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_keypad.o LD [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_i2c.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_spi.o MODPOST /root/tm16xx-display/drivers/auxdisplay/Module.symvers CC [M] /root/tm16xx-display/drivers/auxdisplay/line-display.mod.o In file included from /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:2: /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:13:41: error: expected ‘)’ before ‘LINEDISP’ 13 | KSYMTAB_FUNC(linedisp_attach, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:13:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 13 | KSYMTAB_FUNC(linedisp_attach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:13:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 13 | KSYMTAB_FUNC(linedisp_attach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:14:41: error: expected ‘)’ before ‘LINEDISP’ 14 | KSYMTAB_FUNC(linedisp_detach, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:14:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 14 | KSYMTAB_FUNC(linedisp_detach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:14:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 14 | KSYMTAB_FUNC(linedisp_detach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:15:43: error: expected ‘)’ before ‘LINEDISP’ 15 | KSYMTAB_FUNC(linedisp_register, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:15:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 15 | KSYMTAB_FUNC(linedisp_register, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:15:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 15 | KSYMTAB_FUNC(linedisp_register, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:16:45: error: expected ‘)’ before ‘LINEDISP’ 16 | KSYMTAB_FUNC(linedisp_unregister, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:16:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 16 | KSYMTAB_FUNC(linedisp_unregister, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:16:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 16 | KSYMTAB_FUNC(linedisp_unregister, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ make[3]: *** [scripts/Makefile.modfinal:31: /root/tm16xx-display/drivers/auxdisplay/line-display.mod.o] Error 1 make[2]: *** [/usr/src/linux-headers-6.12.11-edge-sunxi64/Makefile:1870: modules] Error 2 make[1]: *** [Makefile:224: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' make: *** [Makefile:50: module] Error 2 root@homeassistant2:~/tm16xx-display# make-module install make-module: command not found root@homeassistant2:~/tm16xx-display# make module-install make -C /lib/modules/6.12.11-edge-sunxi64/build M=/root/tm16xx-display/drivers/auxdisplay CONFIG_TM16XX=m CONFIG_TM16XX_KEYPAD=y CONFIG_TM16XX_I2C=m CONFIG_TM16XX_SPI=m CONFIG_LINEDISP=m modules_install INSTALL_MOD_PATH= make[1]: Entering directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' DEPMOD /lib/modules/6.12.11-edge-sunxi64 Warning: modules_install: missing 'System.map' file. Skipping depmod. make[1]: Leaving directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' root@homeassistant2:~/tm16xx-display# make service-install modprobe tm16xx modprobe: ERROR: could not insert 'tm16xx': Exec format error make: *** [Makefile:60: service-install] Error 1

Armbian's next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others. UFS, the storage class that replaced eMMC in phones, is packet-based and full-duplex with command queuing. The practical gain over an SD card shows up in random I/O, in latency under concurrent load, and in write endurance that holds up over years of deployment. FriendlyElec ships UFS on the M5 because the RK3576 has a native UFS controller, a sensible choice for any board destined for kiosks, robots, or industrial gateways. What mainline was missingThe UFS controller IP itself had a partial driver in mainline U-Boot. Everything around it was not wired: PHY init sequencing, the regulator rails the device needs before it responds, the device-tree glue that tells U-Boot "yes, this board has UFS." For the M5, none of it existed. There is also a cosmetic detail that catches every newcomer, namely that Rockchip's loader tooling labels UFS as SATA in the RKDevTool storage dropdown. Flashing goes through upgrade_tool, not the more familiar rkdeveloptool, because rkdeveloptool has never had UFS support. How it came togetherThree workstreams had to converge. Jonas Karlman's kwiboo/rk3576 branch carried the upstream RK3576 U-Boot enablement, pinctrl, clocks, storage controller bindings, and has been merging into mainline through 2026. The rockchip-linux/rkbin tree had to ship a UFS-capable MiniLoader, which the RK3576MINIALL.ini recipe assembles from the DDR init, the UFS-aware loader, and the OP-TEE/ATF blobs. The Armbian side was the integration: a board config on U-Boot v2026.04, a U-Boot DT overlay that brings the UFS regulators and PHY up at the right moment, and a flashing path that upgrade_tool accepts. None of these were individually hard. Making them line up is what took the time. On the device, the stack does its job cleanly. The BootROM reads the IDB off UFS and pulls in the TPL; the TPL initialises DDR and the UFS host controller, sequences the regulators, negotiates the link, and reads the next stage; ATF jumps to U-Boot; U-Boot enumerates ufs 0 and loads the kernel; the kernel re-probes the same controller it just booted through. The work, almost all of it, lived at the TPL stage. Controller fine, PHY fine, but the device sits silent if regulator sequencing is wrong by a handful of milliseconds. Once that is right, the upper layers see a clean SCSI-shaped block device and the rest is unsurprising. What it leaves us withFor users with a UFS-equipped M5, the next release image flashes through the FriendlyElec Rockchip workflow with upgrade_tool, BOOT switch on UFS/SD, storage dropdown labelled "SATA". The board boots without an SD card or eMMC involvement, and armbian-install writes the same image to UFS in place once the system is running from another medium. Against microSD on the same hardware the difference is felt rather than benchmarked: small reads land faster, the system stays responsive under concurrent I/O, and the write endurance is in a different ballpark. A few rough edges remain. The vendor tooling will keep calling UFS "SATA" until either Rockchip relabels the GUI or rkdeveloptool grows a cs ufs opcode, neither on the immediate horizon. The BOOT switch is a hardware gate with no software override. And upgrade_tool ships only as a Linux x86_64 ELF, so flashing from an Apple Silicon Mac means a Linux VM with USB passthrough or a Windows host running the GUI. The same plumbing now unlocks every other UFS-equipped RK3576 board in the catalogue. The M5 reached the line first because the hardware was available and the upstream pieces were the most complete. The others should be substantially less work, now that the integration pattern exists and the loader path has been proven on real silicon. View the full article

Armbian's next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others. UFS, the storage class that replaced eMMC in phones, is packet-based and full-duplex with command queuing. The practical gain over an SD card shows up in random I/O, in latency under concurrent load, and in write endurance that holds up over years of deployment. FriendlyElec ships UFS on the M5 because the RK3576 has a native UFS controller, a sensible choice for any board destined for kiosks, robots, or industrial gateways. What mainline was missingThe UFS controller IP itself had a partial driver in mainline U-Boot. Everything around it was not wired: PHY init sequencing, the regulator rails the device needs before it responds, the device-tree glue that tells U-Boot "yes, this board has UFS." For the M5, none of it existed. There is also a cosmetic detail that catches every newcomer, namely that Rockchip's loader tooling labels UFS as SATA in the RKDevTool storage dropdown. Flashing goes through upgrade_tool, not the more familiar rkdeveloptool, because rkdeveloptool has never had UFS support. How it came togetherThree workstreams had to converge. Jonas Karlman's kwiboo/rk3576 branch carried the upstream RK3576 U-Boot enablement, pinctrl, clocks, storage controller bindings, and has been merging into mainline through 2026. The rockchip-linux/rkbin tree had to ship a UFS-capable MiniLoader, which the RK3576MINIALL.ini recipe assembles from the DDR init, the UFS-aware loader, and the OP-TEE/ATF blobs. The Armbian side was the integration: a board config on U-Boot v2026.04, a U-Boot DT overlay that brings the UFS regulators and PHY up at the right moment, and a flashing path that upgrade_tool accepts. None of these were individually hard. Making them line up is what took the time. On the device, the stack does its job cleanly. The BootROM reads the IDB off UFS and pulls in the TPL; the TPL initialises DDR and the UFS host controller, sequences the regulators, negotiates the link, and reads the next stage; ATF jumps to U-Boot; U-Boot enumerates ufs 0 and loads the kernel; the kernel re-probes the same controller it just booted through. The work, almost all of it, lived at the TPL stage. Controller fine, PHY fine, but the device sits silent if regulator sequencing is wrong by a handful of milliseconds. Once that is right, the upper layers see a clean SCSI-shaped block device and the rest is unsurprising. What it leaves us withFor users with a UFS-equipped M5, the next release image flashes through the FriendlyElec Rockchip workflow with upgrade_tool, BOOT switch on UFS/SD, storage dropdown labelled "SATA". The board boots without an SD card or eMMC involvement, and armbian-install writes the same image to UFS in place once the system is running from another medium. Against microSD on the same hardware the difference is felt rather than benchmarked: small reads land faster, the system stays responsive under concurrent I/O, and the write endurance is in a different ballpark. A few rough edges remain. The vendor tooling will keep calling UFS "SATA" until either Rockchip relabels the GUI or rkdeveloptool grows a cs ufs opcode, neither on the immediate horizon. The BOOT switch is a hardware gate with no software override. And upgrade_tool ships only as a Linux x86_64 ELF, so flashing from an Apple Silicon Mac means a Linux VM with USB passthrough or a Windows host running the GUI. The same plumbing now unlocks every other UFS-equipped RK3576 board in the catalogue. The M5 reached the line first because the hardware was available and the upstream pieces were the most complete. The others should be substantially less work, now that the integration pattern exists and the loader path has been proven on real silicon. View the full article

Hi @Marvin-03, could you try the latest build? It looks like your board is still using the BSP MMC driver, but we migrated to the mainline MMC driver last week. That should at least resolve the issue you're currently seeing. Also looking forward to your testing on the eMMC side, since the A7Z does not have eMMC support.

I tried to boot via EMMC using alexc's/Nick's BSP Kernel (6.18) and had a kernel panic: https://pastebin.com/aPhDfFzr The crash occurs in thread T77 (a background worker) while it is attempting to scan for SD cards (mmc_rescan). More specifically, the crash occurs when calling sd_uhs2_power_up, which is requested by mmc_attach_sd_uhs2. Here, the kernel is attempting to power up the power supply for the UHS-II SD card protocol.

Board: Orangepi3-lts Images: * Armbian_26.5.1_Orangepi3-lts_trixie_current_6.18.33_minimal.img.xz Passed tests: * SHA-256 passed All below testing done via wired and wireless console connection(headless) * initial setup passed * create main user passed * update/upgrade check as root passed * log in as created user pass * update/upgrade check as the created user passed Result: All tested images do exist, are verified, and work properly

Hi @JamesCL. You cannot change the boot order of the SoC (SD -> eMMC -> MTD / SPI flash), thus i.e. the SD card is always booted if inserted. You can probably change the root file system's UUID, i.e. change the /boot/extlinux/extlinux.conf to give the kernel the command to use eMMC as root file system. HTH // Sven-Ola

I'll check tonight which revision i have.

@Logan yes, Fanxiang S500Pro 256GB, 6.18.30

Try erase emmc or flash it directly

I tested it personally and works, so the issue is on your side.

looks like mainline uboot doesn't work now on rolling releases

Hi @SuperKali! 26.8.0-trunk.52 resolute GNOME + vendor 6.1.115 - unbootable, UART doesn't work 26.2.5 resolute CLI + edge 7.0.1 - unbootable, UART doesn't work 26.2.1 noble CLI + vendor 6.1.115 - boot OK, HDMI OK, UART OK

Perhaps you can try to build Yamagi from source, as I pointed out, a developer has really optimized OpenGL ES. Here you can see it on a VisionFive 2, RISC-V SBC, hitting almost 200fps at 1080p! You can also try PS1 emulation with PCSXR (works without PS1 BIOS). I assume it's just: sudo apt install rpcsx .If you have a PS1 BIOS, you can also try Duckstation. If you need a game for testing, you can try Magic Castle. It was released for free. http://netyaroze.com/Media/Magic-Castle https://archive.org/details/magic-castle-2021-07-may Regarding eDuke32, did you try disabling compressed textures? https://wiki.eduke32.com/wiki/Frequently_Asked_Questions

I can confirm the 5GHz operation on DQ08 board. Now it's time to have a closer look at the kernel source and the non-matching DTS mess.

orangepi zero3 and 3w have, besides the confusing name, nothing in common. There is no support for any Allwinner A733 device in the framework yet. Best chance is to get in touch with Nick A since he tries to bring up support for raxda a7a, a7z, a7whateever devices which also use this SoC.

@Nick A Thanks for releasing the wonderful Armbian image for the Allwinner H618 and for supporting the community with your valuable suggestions. I recently purchased a TV box with 4GB of RAM and 64GB of storage running Android 12. I downloaded Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_server.img.xz from here and flashed it to an SD card using BalenaEtcher. The box boots successfully, and I can configure it via the CLI. However, this motherboard is different from the ones previously posted here. The silkscreen on the board reads "X3Plus_H618_4bit_V3.0". Based on the naming convention and the appearance of the device, it seems to be the model available here. This board uses an FD6551 chip for the front VFD display. I have managed to extract .img file from the stock android. Are there any modifications I need to make to get the Wi-Fi, USB ports, and front VFD working? Could you please suggest? Things that are working: HDMI Display LAN Controller 1 out of the 2 USB ports. The port near to SD Card slot more precisely Things that are not working: WiFi - The chip got a metal shield. On top of the shield it is written with W804S1, inside the shield I could find AIC8800D40 chip. 1 x USB Port - Near the top left hand corner Front VFD display.

I recently got an Orange Pi Zero 3W, and I noticed that the official Ubuntu image is still based on the sunxi BSP stack, using the sun60iw2-6.6.98 kernel, while the bootloader is also using an older version of U-Boot. Right now, I’m wondering whether it would be feasible to use AI agents to help compile an Armbian image for the Orange Pi Zero 3W with a mainline kernel, while still keeping the old vendor U-Boot for compatibility. Has anyone here experimented with a similar approach or have any good suggestions or ideas? I also really hope the official team can eventually provide a proper Armbian image for the Orange Pi Zero 3W, because I’ve run into quite a few issues with the stock official image.

Oh I just downloaded Yamagi from Snap but OpenGLES was glitchy so I switched the settings to OpenGL 1.4 and it works great so I don't especially want to risk what might happen if I switch it to OpenGL 3.4 lol I also gave eduke32 a try and the flatpak version would launch Duke3D, Ion Fury, BloodCM, etc but have sound & no video despite what resolution I set it to or if it was on OpenGL vs Software. So I compiled the eduke32 mobile version which will launch my Duke Nukem 3D Plutonium Edition's duke3D.grp but give a CON file compilation error when I try those other build engine games.

NanoPi M5 test report for 26.5.1 vendor images Board: NanoPi M5 Boot media: SD card Kernel branch tested: vendor 6.1.115 Test scope: quick first-boot / first-login / desktop smoke test only. I mainly tested the vendor kernel images because my intended use case requires vendor kernel support, especially for NPU-related use later. 1. Image: `Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_gnome_desktop.img.xz` Result: OK What worked: * Booted from SD card successfully. * Armbian initial configuration completed successfully. * After initial configuration, the GNOME desktop started normally. * I was able to enter the desktop and open a few basic applications. Notes: * I did not do a full hardware validation in this round. * I did not collect serial logs because the image reached the desktop successfully. 2. Image: `Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_kde-plasma_desktop.img.xz` Result: FAILED What worked: * Booted from SD card successfully. * Armbian initial configuration started normally. What did not work: * The system got stuck at the Armbian first-login / initialization screen when it was supposed to start the desktop. * It did not proceed to a usable KDE Plasma desktop. Notes: * I only did a basic desktop startup test. * I have not collected serial logs yet, but I can retest and provide logs if needed. 3. Image: `Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img.xz` Result: CLI OK, XFCE installation failed What worked: * Booted from SD card successfully. * Armbian initial configuration completed successfully. * Login to the terminal worked normally. * Basic CLI usage appeared normal. What did not work: * I tried installing XFCE through `armbian-config`, using the XFCE mid option. * The desktop package dependencies appeared to download successfully. * After that, the screen switched to a black screen with a blinking terminal cursor in the top-left corner. * I waited for about 10 minutes, but it stayed stuck there and did not continue to a usable desktop. Notes: * The base minimal image itself seemed to work correctly from the terminal. * The issue happened during or after the XFCE installation/startup process via `armbian-config`. * I have not collected detailed logs yet, but I can retest and provide logs if needed. Summary: * `resolute_vendor_6.1.115_gnome_desktop`: boots from SD card and reaches GNOME desktop successfully. * `resolute_vendor_6.1.115_kde-plasma_desktop`: boots from SD card, but gets stuck at the Armbian first-login / initialization screen and does not reach KDE Plasma. * `trixie_vendor_6.1.115_minimal`: boots from SD card and CLI works, but installing XFCE mid through `armbian-config` gets stuck on a black screen with a blinking cursor.

First of all, spamming balance on an SSD will significantly lower the lifespan of it. What you do is ask btrfs to relocate data-chunks that are occupying the % of a block, so that 1 goes fast is because they are very small (1%), but when you ask it to scan and look for a position to move chunks that occupy +50% it WILL take a long time, a veeeeery long time, not to mention 95%. You are basically just moving around data slowly killing your SSD. Read here: https://btrfs.readthedocs.io/en/latest/Balance.html#compact-under-used-chunks Btrfs will do this automatically in the background constantly when your computer is having extra cycles to do so. The only time it will be useful is if you remove massive amounts of data, then you can notice neither data nor metadata freeing up space. It can also be useful if you are using RAID because then it can move data between the disks. IIRC -susage is irrelevant for most users, what you want to move is the data and metadata, ie -musage & -dusage. If ever run a balance, it's when I remove big, and I mean BIG chunks of data, like 25% of the drive, and when I do, I start with 5, increment by 5 up to 35, NEVER more. But it is ONLY if I actually need the space immediately for something else, otherwise I just wait and let btrfs handle it by itself. So, with what you are doing with your cron running every day is literally killing your ssd... You should probably stop, IMMEDIATELY. With a --full-balance, you rewrite ALL DATA on the ENTIRE DRIVE! Better to have a scrub running once per month or every second week or so to know that your drive is in healthy condition... So what you are experiencing is not a bug, it's how it works, and in worst case scenario it might be your ssd about to give up... This link, albeit reddit describes it pretty good: https://www.reddit.com/r/btrfs/comments/hfpot9/what_does_balance_actually_balance BTW, you can check what it is doing while running by typing: sudo watch -n1 'btrfs balance status /path' But again, I HIGHLY discourage you do balance unless you ABSOLUTELY need to. Edit I missed that the filesystem has become read only when responding to this at 4am so lets edit this with a bit more info. Well, I'm sorry, it looks like you killed your drive, or at least the filesystem. The best you can do is try to copy all files on it to another drive (probably not worth trying to save the filesystem), format this one and pray that it's only your filesystem that became corrupt. But after reading how you treated that drive I think you should be prepared for it being damaged beyond a reformat, or that if you manage to format it, it will become corrupted pretty soon again, so I would not rely on that drive for backups... I have found SMART to not be reliable when it comes to health. If you like btrfs, I would recommend buying a rpi, a 6TB spinning drive, a hd case and run urbackup on that. That is what I use (rpi4 8gb, which is overkill, it never utilizes more than 2-3G memory on it, even though I use it as a backup server, nfs network drive AND is running a plex server on it) and it has been running flawlessly for years. (that reminds me, I might want to install something newer than rpi os bullseye on it, maybe armbian xD) I only make file backups, no images. Not very fast, but what does that matter when you only use it for backups. (I run the NFS network drive from another storage device, but that is beside the point) If you also use btrfs on the system you backup from, it creates a snapshot at runtime that it transfers files from, so there is no risk of corrupting files while the backup is running due to files changing during the backup. You would probably get all that for the same price as one ssd, or at least close to, spinning dives cost close to nothing. I have 5 clients connected to that backup solution, with 4 backups daily saved for about 2,5 months (one backup every 5hrs and backups paused between 3am-7am), and one archived every month to save for three years. ie 240 incremental backups per device. One of the clients backing up 1.13T (the others are smaller, between 100-350G each) but all of it only taking up about 5.5TB, and backups runs fast af, only copying changed data due btrfs and de-duplication (COW). I have NEVER had to run a balance on that device (only done it once before for testing). But since it is getting close to the threshold, let's make an experiment and run a balance on it with chunks up to 30%. There are 987 snapshots on that device (not all 5 clients has reached 240 backups due to not being constantly turned on, my laptop and my installed "fallback" os for example) $ sudo btrfs subvol list /media/backup | wc -l 987 This is before balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B The balance up to 20% took about 5 seconds, then on 25 and 30 it took a while, about 10 minutes (I forgot to run it with time so this is an estimate with me looking at the clock when starting and when saw it had it ended) It only moved a minimum amount of chunks $ sudo bin/btrfs-balance.sh --backup If balancing takes a long time, open another terminal and run: sudo watch -n1 'btrfs balance status /path' btrfs balance will run on /media/backup Do you want to continue? [y/n] y Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=5 SYSTEM (flags 0x2): balancing, usage=5 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=5 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=10 SYSTEM (flags 0x2): balancing, usage=10 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=10 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=15 SYSTEM (flags 0x2): balancing, usage=15 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=15 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=20 SYSTEM (flags 0x2): balancing, usage=20 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=20 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=25 SYSTEM (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks This is after balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B As you can see, no change whatsoever because btrfs does this in the background all by itself. And running higher % would not save any space, only take a ton of time, I'm pretty sure of that. If you want the script I used, here you go: (I have two btrfs filesystems on that rpi, modify to your liking if adopting) !/usr/bin/env bash # Check if script is run as root if [ "$EUID" != 0 ]; then echo 'THIS SCRIPT MUST BE RUN AS ROOT! (WITH SUDO)' exit 1 fi if [ "$1" == '--backup' ]; then METHOD='/media/backup' elif [ "$1" == '--usr' ]; then METHOD='/media/usr' else METHOD='all' fi echo 'If balancing takes a long time, open another terminal and run:' echo -e "sudo watch -n1 'btrfs balance status /path'\n" echo "btrfs balance will run on $METHOD" read -p "Do you want to continue? [y/n] " -n 1 -r if ! [[ "$REPLY" =~ ^[Yy]$ ]]; then echo '' echo 'Aborting...' exit 4 fi echo '' if [ "$METHOD" == '/media/usr' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/usr btrfs balance start -v -dusage=5 /media/usr btrfs balance start -v -musage=10 /media/usr btrfs balance start -v -dusage=10 /media/usr btrfs balance start -v -musage=15 /media/usr btrfs balance start -v -dusage=15 /media/usr btrfs balance start -v -musage=20 /media/usr btrfs balance start -v -dusage=20 /media/usr btrfs balance start -v -musage=25 /media/usr btrfs balance start -v -dusage=25 /media/usr btrfs balance start -v -musage=30 /media/usr btrfs balance start -v -dusage=30 /media/usr btrfs balance start -v -musage=35 /media/usr btrfs balance start -v -dusage=35 /media/usr fi if [ "$METHOD" == '/media/backup' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/backup btrfs balance start -v -dusage=5 /media/backup btrfs balance start -v -musage=10 /media/backup btrfs balance start -v -dusage=10 /media/backup btrfs balance start -v -musage=15 /media/backup btrfs balance start -v -dusage=15 /media/backup btrfs balance start -v -musage=20 /media/backup btrfs balance start -v -dusage=20 /media/backup btrfs balance start -v -musage=25 /media/backup btrfs balance start -v -dusage=25 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup fi exit 0 This probably means I should manually remove some snapshots, because I did make a few massive changes that caused a lot of new data to be created, I do NOT want it to become filled. Conclusion: Don't run btrfs balance unless absolutely necessary, especially on SSD:s!