All Activity

Board: Orangepione Testing results for the three available images. Should there be more images available? Armbian_26.5.1_Orangepione_resolute_current_6.18.33_minimal.img Tested working: Boot from SD card with uboot and then to a USB SSD. Reboot Connect via ssh iperf3 after installing iperf3 gpio after installing gpiod HDMI video HDMI audio after installing mpg123 Used usb keyboard/mouse to test HDMI. Note that resolute now uses gpiod for gpio instead of sys. Gpiod had to be installed whereas trixie minimal comes with gpiod installed. Armbian_2Armbian_26.5.1_Orangepione_trixie_current_6.18.33_minimal.img Tested working: Boot from SD card with uboot and then to a USB SSD. Reboot Connect via ssh iperf3 after installing iperf3 gpio HDMI video HDMI audio after installing mpg123 Used usb keyboard/mouse to test HDMI. Armbian_26.5.1_Orangepione_resolute_current_6.18.33_xfce_desktop.img Tested working: Boot from SD card with uboot and then to a USB SSD. Reboot On HDMI connecter screen with usb keyboard/mouse Using terminal emulatori tested perf3 and gpio HDMI audio with vlc media player. Not working: Ran chromium to get to Armbian download page but took over a minute for each page to load and then the system crashed. With only 512MB RAM this system is under powered for general purpose desktop use. ubuntu_resolute_minimal.txt debian_trixie_minimal.txt ubuntu_resolute_xfce.txt

The longer answer is that for standard releases, updates only occur with each release cycle (i.e. every three months in Feb, May, Aug, and Nov each year. So you will get new kernel release on that schedule. Armbian also has rolling release repositories and these put out new versions on a frequent basis. And you should be able to switch between stable releases and rolling release apt repositories using armbian-config. Note that rolling releases don't get any testing (other than automated builds) and therefore may not be suitable for many users needs. But those are your two options.

We're in the middle of the May release, so new packages should eventually hit repo in a few days/weeks.

Hi, I have been running armbian with the minmal debian trixie image on a odroid M1 for a few month now and I noticed that since I installed the image there has not been a single kernel upgrade. the kernel is still at 6.18.10 despite current debian install image for this board being shipped with 6.18.28 so I am assuming I am doing something wrong. The apt update and apt dist-upgrade logs show clearly all current package information are being downloaded from both debian and the armbian mirrors, and both armbian-config updates and upstream debian packages have been upgraded whenever I run the apt dist-upgrade commands, but the kernel is still the same old version from several month ago. Any clue what I should look at to find the issue? Thanks

Board: MKS-Klipad50 Images: * Armbian_26.5.1_Mksklipad50_resolute_current_6.18.33_minimal.img.xz * Armbian_26.5.1_Mksklipad50_trixie_current_6.18.33_minimal.img.xz Passed tests: * gpg and sha checksum files * boot from emmc, leds, display, touch, usb, internal wifi * initial setup, uboot-console, reboot Result: All expected images do exist, verify and work properly. Sidenote: The Klipper ecosystem does not yet run on Ubuntu-Resolute (Python-3.14 incompatibility), but that shouldn't be a stopper for the release.

You can send your DTB, that has wi-fi?

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

I recognize this is an old thread - but there are no newer ones open and I figure having one thread instead of many is best. I'm trying to do the same thing as you OP, getting a raspberry pi DSI display working on a rockpi 4b+. I tried to adapt Radxa's DTS in a similar way you did from Armbian's Base DTS, and seeing what definitions changed and I came up with this non working DTS: Which gives the following DMESG error, very similar to yours: `[ 21.477004] rpi-ts-dsi ff960000.dsi.0: failed to attach dsi to host: -517 [ 21.477086] mipi-dsi ff960000.dsi.0: deferred probe pending: (reason unknown)` You'll note various differences between our DTS, like panel_in instead of panel_in_dsi, and mipi_dsi instead of mipi_dsi1. I based these off looking at the base DTS in Armbian kernel 6.18.32, but also on this project I found recently that brings support for 7 and 10 inch Osoyoo brand of DSI panels to the RockPi 4b+. I think that's really promising and will help with bringing DTS support to the raspberry pi panel (and others that are compatible). I recommend you look into it. I will continue iterating and update this thread with results if any. I don't think OP was pinning the problem on Armbian. OP was asking how to configure a custom DTS to work with the hardware they have. This is the community support forum, which is the correct place for this kind of discussion.

You could flash armbian to an SDcard, then set Jumper P10 to force UBoot to skip booting from EMMC and pick the sdcard instead. From there you can directly mount the internal storage and chroot into it to run armbian-config and enable the overlay.

Hello, I flashed the latest KDE version to the SD card of my Orange Pi 3B using Armbian Imager, but for some reason the USB ports are not working at all. There's no power coming from the USB ports, and the keyboard backlight isn't working at all. What could be the reason? Can you help me? I've never experienced anything like this before.

https://libre.computer/products/roc-rk3399-pc/ Can the computer run entirely on free software which is software you can use, share, modify and redistribute? The question includes firmware, microcode, etc, any piece of software that is running on the computer. If some devices on the computer requires non free software in order to work then what devices are they? And will the computer still work if you choose to not install the pieces of non free software in question? Thank you.

For those who want to compile from source: a) locate file ~ /armbian-build-mxpro/patch/kernel/archive/sunxi-6.12/series.conf b) delete the following lines before issuing ./compile.sh: spi-rockchip-Fix-runtime-PM-and-other-issues and spi-fixes c) save the file and proceed to compilation (./compile.sh) Note: if you want to upgrade the Armbian firmware be aware that: linux-dtb-current-sunxi64/trixie 26.5.1 arm64 [upgradable from: 26.02.0-trunk] linux-image-current-sunxi64/trixie 26.5.1 arm64 [upgradable from: 26.02.0-trunk] will render the ethernet interface inoperable. You can prevent this by issuing sudo apt-mark hold armbian-firmware before sudo apt upgrade -y

Is it possible to change the boot order? For my use case, I would like the boot priority to be: eMMC, NVMe, and microSD card. Can this be configured?

I've created a guide here how to run a Home Assistant OS suprisingly it run mostly natively. Didn't do anything except replacing the DTB. Also right away flashed it into a emmc. On my board emmc is from Samsung and has a read speed on 180Mb/s...

Tested orangepi5 current and vendor. works as expected

Known issue on multiple older 64 bit Allwinner socs Try these: https://fi.mirror.armbian.de/incoming/igorpecovnik/pine64/archive/

Armbian 26.05 Test images: https://fi.mirror.armbian.de/incoming/igorpecovnik/ Tested by me: - x86 and arm64 UEFI images - Odroid M1 - Radxa 5T https://paste.armbian.com/jizuhuweru - Inovato Quadra - RPi 400 - Musepipro ..

I'd like to run the mainline kernel https://github.com/nickfox-taterli/avaota-a1-mainline-linux The board used to have a page and downloads here: https://armbian.com/boards/avaota-a1 but it's gone. Has support for this board been dropped?

@Sancho this is amazing! If you have the test image ready I will be really glad to test it out. I have more than 1 iSG Box SE so I can test it on multiple devices.

Hello , i have used now for some year armbian for this board, very many thanks for that; lately have updated to newer version Debian Trxiie and found that "htop" report a higher CPU usage after freshboot (around 50%) whereas previously it sat a 10% probably; now when evoking htop it gives (CPU offline for core 2-3-4) also nproc report "1" instead of "4"=? not sure if this an error ; noticed a similar report of nproc also with a build of volumio; thank you very much;

@savznkvo your rv2 boots from nvme? wich slot? what nvme model and vendor? wich kernel?

Ask AI to fix problems at repo level: https://github.com/armbian/supervised-installer so we can all benefit. I don't have capacity to maintain this alone.

Sitrep / confirmed fix for “unhealthy: privileged” on Armbian Home Assistant Supervised After installing Home Assistant Supervised via Armbian on an Orange Pi 4 LTS, Supervisor was blocking add-on installation with: ‘AppManager.install’ blocked from execution, system is not healthy - privileged ha resolution info showed: unhealthy: privileged unsupported: os However Docker itself showed the Supervisor container was already privileged: docker inspect hassio_supervisor –format ‘{{.HostConfig.Privileged}}’ Output: true So the problem was not Docker missing –privileged. The Supervisor log also showed: Not privileged to run udev monitor! I checked the Supervisor AppArmor profile: sudo grep -n ‘deny network raw’ /var/lib/homeassistant/apparmor/hassio-supervisor It returned: 8: deny network raw, 70: deny network raw, Removing those deny network raw, lines from the AppArmor profile, reloading the profile, and restarting Supervisor fixed it. Commands used: sudo cp -a /var/lib/homeassistant/apparmor/hassio-supervisor /root/hassio-supervisor.apparmor.bak.$(date +%Y%m%d-%H%M%S) sudo sed -i ‘/^[[:space:]]deny network raw,[[:space:]]$/d’ /var/lib/homeassistant/apparmor/hassio-supervisor sudo apparmor_parser -r /var/lib/homeassistant/apparmor/hassio-supervisor sudo docker restart hassio_supervisor After restart: ha resolution info ha supervisor info Now shows: unhealthy: [] healthy: true unsupported: os supported: false I also tested the failing udev/netlink path directly: sudo docker exec hassio_supervisor python3 -c ‘import pyudev; pyudev.Monitor.from_netlink(pyudev.Context())’ It returned silently with no error. Conclusion: on this install, the “privileged” unhealthy state was caused by AppArmor blocking raw netlink access via deny network raw, in the hassio-supervisor profile. Docker was already privileged. Removing that AppArmor deny rule fixed Supervisor health and cleared the add-on install blocker. The remaining unsupported: os warning is expected for Armbian/Supervised and is separate from the privileged health failure.

I've got error unhealthy system - not privileged, asked claude opus to fix it. now everything works. Aked to make script to repeat fixes, here it is: https://github.com/limorte/armbian_trixie_v26.2.1_6.12.71_orangepi3lts-fix_ha_unprivileged_error/blob/main/fix-hassio-privileged.sh can't confirm it working

I extracted DTB/DTS from the Android FW (files attached). For whatever reason they are signed in the image as rk3568. No ideas why. 02_dtbdump_rockchip,rk3568-evb.dtb 02_dtbdump_rockchip,rk3568-evb.dtb.dts Attention: They are for Android! Linux might not boot with them!