Active threads

Great news! So a simple apt update/upgrade will fix it for me?

Hi, Thanks for sharing details about the Armbian on x88 Pro and your DIY Cooling Solution. Really useful. May I know what is the name of the image that you have used for this setup from https://www.armbian.com/station-m2/. I tried the recent and archived images. Post burning to SD card, the box is not booting with any of the image.

Hello team, I encountered a dependency conflict while trying to upgrade the package armbian-bsp-cli-panther-x2-current to version 25.8.2. The issue seems to be a mismatch in the required version of base-files. Here's a summary of the issue: Attempted upgrade command: apt install armbian-bsp-cli-panther-x2-current Error message: armbian-bsp-cli-panther-x2-current : Depends: base-files (>= 25.8.2) but 25.8.1-12.4+deb12u11-bookworm is to be installed Currently installed version of base-files: base-files: 25.8.1-12.4+deb12u11-bookworm (installed) Available versions for base-files from the repository (apt policy base-files): Installed: 25.8.1-12.4+deb12u11-bookworm Candidate: 25.8.1-12.4+deb12u11-bookworm Version table: 25.8.1-12.4+deb12u11-bookworm 500 25.5.1-12.4+deb12u11-bookworm 500 ... It appears that the repository ( http://apt.armbian.com/pool/bookworm-utils/b/base-files ) does not provide the required version of base-files (25.8.2) for the arm64 architecture. Only the armhf architecture package is available, but armbian-bsp-cli-panther-x2-current depends on the arm64 version. Could you please help investigate the issue or confirm whether the repository will be updated to include version 25.8.2 of base-files? Thank you for your support!

@WINEDS@Hqnicolas Thank you for your help. I will try to see if it can work properly，

Don't use etcher. https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card

Armbian 25.8.1 Noble XFCE (BSD Kernel: 6.1.115) + PanVk - mesa 25.3 (https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + wine-10.19-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.19) + DXVK-sarek-stripped v1.11.0 (https://github.com/pythonlover02/DXVK-Sarek/actions) ~60fps@1080p Cat Quest II

i use a usb to 3.5mm headphone adapter.

Just today I ran into an error "aplay: no soundcards found" I decided to follow the sequence of actions below, log in to root: ### **Symptoms** * `aplay -l` → **no soundcards found** * in `/proc/asound/cards' — empty * there is no "analog-codec" item in `armbian-config` * The sound through the mini jack does not work * the DT output ('dtc -I fs') indicates that the codec is present but not active The reason is always the same: **the kernel/DT does not include AHUB + codec machine-driver**, so ALSA does not create maps. --- > I also created the default alsa config ``` nano /etc/asound.conf ``` Inserted there so far: `` pcm.!default { type hw card 0 device 0 } ctl.!default { type hw card 0 } ``` # **Solution** ## **1. Set the desired audio overlay: `sun50i-h616-audiogpu`** ### 1.1 Cloning the repository ```bash cd /root git clone https://github.com/hviana/orangepizero2w-audio.git cd orangepizero2w-audio ``` ### 1.2 There is already a ready-made file in the repository: ``` sun50i-h616-audiogpu.dtbo ``` You don't need to compile anything. ### 1.3 Copying the overlay to the desired location ```bash mkdir -p /boot/dtb/allwinner/overlay cp sun50i-h616-audiogpu.dtbo /boot/dtb/allwinner/overlay/ ``` --- ## **2. Configure `/boot/armbianEnv.txt `** Open: ```bash nano /boot/armbianEnv.txt ``` And set **two required lines**: ```ini overlay_prefix=sun50i-h616 overlays=audiogpu ``` Delete old attempts like `analog-codec`, `sun8i-h3-codec`, etc. Save → Exit. --- ## **3. Reboot** ```bash reboot ``` --- ## **4. Check the sound after downloading** ```bash aplay -l ``` It should appear: ``` card 0: audiocodec [...] card 1: ahubi2s0 [...] card 2: HDMI [...] ``` If there are cards, the sound is restored. important! WORKING WITH SOUND (for example, playback) SHOULD BE DONE NOT FROM UNDER THE root USER, BUT FROM UNDER THE REGULAR USER! If PulseAudio, for example, is running from the system from root, then the devices may not be available. Also, if you use Home Assistant Supervised, then docker will have a self-healing hassio_audio container that will run Pulse Audio from root on the host machine and thereby block all devices. You won't be able to control the sound in this case. There's an addon that's supposed to kill this container every time it starts, but it doesn't work properly for me. Literally now, I've run out of nerves, and I've taken down my system. I will try installing Proxmox or in Docker

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"; }; }; }; };

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