Active threads

Problem is in Balena decompression of xz files. Use USB imager or something else (or 2 years old version of Balena). It will work. We filed bug when it was discovered, but it was not fixed by this day. We can't fix this app for them ... BTW. Its all here: https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card

Thanks for the tips. The following overlay works on a c2 /dts-v1/; / { compatible = "amlogic,meson-gxbb"; fragment@0 { target-path = "/aliases"; __overlay__ { i2cA = "/soc/bus@c1100000/i2c@8500"; }; }; fragment@1 { target-path = "/soc/bus@c1100000/i2c@8500"; __overlay__ { #address-cells = <1>; #size-cells = <0>; pcf8563: rtc@51 { compatible = "nxp,pcf8563"; reg = <0x51>; status = "okay"; }; }; }; };

Turns out the secret was getting the address and symbols right in the device tree. I create the following as meson-pcf8563.dts, compiled into meson-pcf8563.dtbo, moved to /boot/dtb/amlogic/overlay, and added pcf8563 to the "overlays" line in armbianEnv.txt. /dts-v1/; / { compatible = "amlogic,meson-gxbb"; fragment@0 { target-path = "/aliases"; __overlay__ { i2cA = "/soc/bus@c1100000/i2c@8500"; }; }; fragment@1 { target-path = "/soc/bus@c1100000/i2c@8500"; __overlay__ { #address-cells = <1>; #size-cells = <0>; pcf8563: rtc@51 { compatible = "nxp,pcf8563"; reg = <0x51>; status = "okay"; }; }; }; };

6.6 is LTS kernel https://www.kernel.org/category/faq.html When some security issue is found, it goes into all LTS kernels. Higher version number does not guarantee bigger safety. Most recent has more functional bug fixes and new features and is generally more fragile - bugs / holes yet to be found. Yes, v25.11.1 with 6.12.y https://www.armbian.com/odroid-hc4/ doesn't have those problems. At least I could not recreate them. Booting HC4, plugged in two usb devices, all good: https://paste.armbian.com/ibifozegof P.S. Life is deadly dangerous

It is now.

Hi, In 2025, Helios64 is now stable for me and for my brother, who also uses it. The only thing to do is, just after installation or after any upgrade, you must reinstall the special file rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp because I think the specific tuning in this file is not included in the official image. For me, I suggest keeping it, using it, and saving your money for other things. Bye.

should be fixed with https://github.com/armbian/build/pull/8980

Good day all, After compiling a build for my TV box and burn it to the SD boot process stuck to Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems Can someone help please solving the problem?

I switched to the Armbian version of Debian Triexie and now it's OK

I was just about to rebuild the source package, but today's upgrade delivered everything turnkey since my development team was faster and had done everything for me. The previously referenced description does provide a working result, but it does not use the most current available releases. This script runs the NPU with the latest working releases: #!/bin/bash WORKBENCH="." python3.11 -m venv ${WORKBENCH}/python/3.11 source ${WORKBENCH}/python/3.11/bin/activate pip install numpy==1.26.4 pip install pillow==12.0.0 pip install tflite-runtime==2.14.0 TEFLON_DEBUG=verbose ETNA_MESA_DEBUG=ml_dbgs python ${WORKBENCH}/classification.py \ -i ${WORKBENCH}/grace_hopper.bmp \ -m ${WORKBENCH}/mobilenet_v1_1_224_quant.tflite \ -l ${WORKBENCH}/labels_mobilenet_quant_v1_224.txt \ -e /usr/lib64/libteflon.so deactivate classification-3.11.log

I saw that the photos were deleted by mistake, so I added them back. Here is a photo of the two cases: Here is a photo of the motherboards of both cases: Here is a photo of the X96Q-Armbian-H313 V4.0 boot screen: Here is a photo of the X96Q-Armbian-H313 V4.1 boot screen:

RPCbind enabled and running.

Bad News: same issue with 25.11.1 / 6.12.58, and a few others... Worse News: The issue affects all rk3588's (Orange Pi 5/5B/5+, Rock 5A/5B/5C, etc.). Good News: PR is a permanent fix for all images, and also identifies an immediate workaround that only requires a reboot (add "overlays=panthor-gpu" to /boot/armbianEnv.txt). https://github.com/armbian/build/pull/8979

Hello, I'm from China. I bought an H96 Max M9S (8GB+128GB) for 500 RMB. After reading your discussions, I've learned how to use RKDevTool to flash the Android system via USB. However, I've been struggling for several days and still cannot boot the Armbian system. Could you please tell me how to boot Armbian? Is it possible to flash the Armbian system directly to the eMMC of my M9S using RKDevTool? I really need your help. Thank you very much!

I purchased the device after reading your thread and am currently porting it to my hardware with Copilot (Claude Sonnet 4.5). You can refer to my work results in the repository below. So far, the following parts have been confirmed to work: HDMI (no need to reconnect after Linux kernel boot) Ethernet Built-in eMMC Currently working on: Wi-Fi / Bluetooth (in my case, the model uses AIC8800D80) Not yet verified: GPU Install to eMMC As suggested in your thread, I based my work on the Hinlink HT2 and Radxa Rock 2F, using the DTB extracted from my device’s firmware and processing it with Copilot. I’d appreciate it if you could take a look if you’re interested. IMG_1597.HEIC https://github.com/wwwhana/armbian-build

> if that minimal package were part of the stock system, so the armbian-install doesn't break did your system break following the f2fs-tools install or were you able to format with f2fs and install your system in armbian-config?

Tried to get it running on the Rock PI S, which has the same chip, but it somehow doesn't seem to work... I think it has different conflicts maybe? It's kinda hard to debug. Originally I used the following (on 24.*): /dts-v1/; /plugin/; / { compatible = "rockchip,rk3308"; fragment@0 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; spidev@0 { compatible = "rockchip,spidev"; status = "okay"; reg = <0>; spi-max-frequency = <10000000>; }; }; }; }; But it stopped working on upgrade to 25.11. I was able to get it to load again until I adjusted the compatible field to "armbian,spi-dev". But the the connected chip just wouldn't answer. I now tried rk3308-spi1-spidev.dts from this thread, with the codec modification and then even tried to fix the correct conflicts for the Rock PI S' different pinout: /dts-v1/; /plugin/; /{ metadata { title = "Enable spidev on SPI1"; compatible = "radxa,rockpis", "radxa,rock-s0"; category = "misc"; exclusive = "GPIO2_B1", "GPIO2_A4", "GPIO2_A5", "GPIO2_A7"; description = "Enable spidev on SPI1."; }; fragment@0 { target = <&spi1>; __overlay__ { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi1_clk &spi1_csn0 &spi1_miso &spi1_mosi>; #address-cells = <1>; #size-cells = <0>; spidev@0 { compatible = "rockchip,spidev", "armbian,spi-dev"; reg = <0>; spi-max-frequency = <10000000>; }; }; }; fragment@1 { target = <&i2c3>; __overlay__ { status = "disabled"; }; }; fragment@2 { target = <&uart3>; __overlay__ { status = "disabled"; }; }; }; But it still doesn't communicate. It's there, but not receiving any data from my chip like it did in the past. I can't find anything in dmesg, so I'm not sure how one can find out what's wrong with it.

We don't have resources to deal with this question, but I think, in case of this hardware, there is just firmware package (armbian-firmware / linux-firmware) that fits into this. Perhaps some other util. There must be some scripts to scan Debian packages and tell? From my head, I remember iozon3 package (might not be by default on minimal) that is non-free https://packages.debian.org/bookworm/iozone3

Great reply , I'll knock up a connection! much easier than anything else. I work in modern/future vehicles so the spikes and dips are not an issue for me as none of them have engines.

@Hqnicolas thanks for your presentation. I found I made an error : mkdir -p ./build/userpatches/kernel/archive/rockchip64-6.12 should be : mkdir -p ./userpatches/kernel/archive/rockchip64-6.12 as the current directory is build at that point. For wsl installation @NicoD made a great video here :

rk3326 and rk3328 are not the same thing, neither is px30. Definitely no chances to run this on those SoCs; I don't know if there are images for boards using px30/rk3326 in armbian.

For SBCs without own audio I use networked pulseaudio. I never got it to work in newly installed Jammy and Bookworm, also not in Bookworm upgraded in-place to Trixie. It worked in Buster, BuIlseye and allways worked in Opensuse Tumbleweed. I already had all pipewire user sockets and services disabled and pulseaudio enabled, also de-installed pipewire-pulse as that one is the problem I believe (but is more than a year ago I looked at it). Now it turns out that doing 'pactl load-module module-zeroconf-discover' did add remote audio sinks. GUI based paprefs in Ubuntu/Debian should do it, but that is all grey since years, cannot be selected nor changed. So NanoPi-R6C with Armbian Trixie edge kernel now also plays audio via Armbian Trixie NanoPi-NEO SPDIF enabled with long simple wiring to an amplifier that takes coaxial SPDIF as input. I also had it working analog, but way too much issues with noise etc. 'the long simple wiring' is 1 lead of a low-quality twin analog audio cable, shielding=GND, core=signal.

I think @NicoD meant tasksel.

@fabiobassa thank you, it is worth a try.

debug boot issues: https://debug.armbian.de