Active threads

@Nick A I compiled the image for version 6.18.19 using the parameters you preset, but the system fails to boot correctly on the A7S. Upon power-up, the green LED stays solid for about 15 seconds. Then, the green LED flashes once, and the blue LED turns solid (unlike the official system where the blue LED blinks). After that, the system becomes unresponsive. There is no signal output on the DP interface, and the Ethernet port indicator light does not turn on even when a cable is connected. Here is the hash value of the compiled file. I'm not sure if there was an issue with my compilation process, as the network connection dropped several times, and it took a few attempts to finally complete the build. Image: Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a7s_trixie_edge_6.18.19_xfce_desktop.img sha256: a7c6baf463b233bad0abb08d2fcfde7ac107509d69fada77ebaafc2bd00979c5

perhaps the patch is no longer necessary once this lands upstream. We will see once we get there

It is not that one. The 2.0 load was just cosmetic, the CPU was actually idle. But with this one it is actually doing something, which is also increasing heat (if no fan). With the expanded core list, you can see the CPU5 and CPU7 have "system" load of 49% and 36%. On a fully idle system. Interrupts file attached. It seems pretty normal to me. interrupts

Hi Werner. I have done so already around half an hour ago.

Please note that it is a known issue that Turnip / Vulkan broken on Snapdragon SM8550 / Adreno 740 on Mesa 25.3.x. See https://gitlab.freedesktop.org/mesa/mesa/-/work_items/14656 The workaround is to apply patch from https://github.com/batocera-linux/batocera.linux/blob/master/board/batocera/patches/mesa3d/001-fix-freedreno-vulkan.patch and rebuild 001-fix-freedreno-vulkan.patch

duplicate https://forum.armbian.com/topic/59601-sd-card-boot-cant-find-my-sda1hdd-after-warning-and-fsck/?do=findComment&comment=237240

That's default Debian behavior. Ubuntu includes sbin in PATH afaik. In any case Armbian does not alter this.

Hi guys, I too have one of these paperweights I'd like to use for a real HA instance to have as a backup if my actual server takes a dump. I was hoping for root access as I'm not a novice when it comes to custom bootloader and roms on other devices but this is a whole different monster. Any tips would be appreciated.

Just as an update, for anyone who cares. The above setup worked well, but I couldn't help but attempting to get video hardware acceleration in a browser. Since my post above, Armbian support for the Nanopi R6S went platinum (thanks to @Efe Çetin), kernel 7 came out and mesa 26 should provide all that is needed for vaapi/v4l2 support in firefox. Unfortunately, minimal Armbian Debian with kernel 7 combined with mesa 26 looks to be some time away - that would allow me to run sway, and likely with firefox using video decode acceleration. OTOH, vendor kernel at 6.1 doesn't seem to allow sway to run at all. So I tried Armbian Debian 13 minimal with kernel 6.18, which runs sway just fine, but the mesa version is stuck at 25.2 which in the standard Debian package does not by default support the rockchip hardware yet, I think. In addition, there seems to be some incompatibility with the repository provided here (or I am doing something wrong, which I wouldn't deny). Fortunately, looking at the Armbian git files I saw that the standard Armbian Ubuntu Noble with vendor 6.1 and Gnome (KDE version doesn't run well) appears to a) work fine with wayland, and b) automatically uses the Amazingfate (liujianfeng1994) PPA. This provides chromium with video hardware decode support, and I can still set up jellyfin. So at this point, without having to compile everything myself from scratch, this is the best setup from my perspective. Shout out to @Efe Çetin for making it this convenient - which it truly is, even though Gnome isn't my preferred DM.

I have a Orange Pi Zero2W with Armbian. I flashed a SD-card, and then I copy the system and boot to a usb- hdd (sda) and the system boot to sda Want hdd because It write much data and USB 2 don't take mush more speed. But I get a warning about a file-error or something so I run fsck on sda(hdd) that was a systemdisk, but when I run I choose to do it read-only, but anyway it does not boot any more. I think I can take the usb-hdd and run fsck from another computer? I have one system with Ubuntu on a Intel 6 gen, and Raspberry pi 500 and 5. The Pi-machine have raspberry-pi OS and the other Ubuntu 24.04.Does the machine or system have any significans? Or is there another fix to fix so the /boot on SD-card can find sda on USB? /Cheers /Edit. I posted under Orange Pi Zero2, but that was wrong place, and get moved, but at the same time get my thread classed as solved, but the solving was just to get the question on right place. I have also cleared my question a little bit and I can not take away the other.

I started to have similar issue with recent rolling release (after 26.2.1) mainline kernels: 6.18.2x, 7.0.x, 7.1.0-rc. https://paste.armbian.com/yobewudugo The log seems having all previous boot logs of this board and 6.18.10, 6.18.8 and 6.1.115 can enumerate NVMe SSD but others can't. I did a PCI rescan with 7.1.0-rc2 after booting the board and NVMe SSD was found and corresponding kernel log can be found in the 1st kernel log. I have Armbian image on SD card, btw. sudo bash -c "echo 1 > /sys/bus/pci/rescan"

@Gwainer If you haven't bought a TV box yet, stay where you are. Direct your resources to supporting companies that keep open source running. Here is a list of where you should spend your resources. https://armbian.com/partners

this is my [fix plan](https://github.com/icecreamzhao/rock5b-plus-fan-fix)

Hello everyone, I urgently need help, as I am on the verge of throwing my Khadas out the window. I bought a used Khadas Vim3L HTPC Kit (S905D3) and want to use it for Navidrome and Audiobookshelf. The FLAC files are located on an external 2.5" WD Elements hard drive, first I intended to format this hard drive to ext4 and set it up in the setup process but it doesnt work and the first thing now is to setup the system,i will add the hd later. Currently, the Vim boots into CoreELEC (which appears to be installed on the internal storage of the vim). Im a total noob and thats my first vim / Board. I just can't seem to get it to work; no matter what I do, it always boots into CoreELEC. I have flashed the recommended Debian 13 (Trixie) → Minimal / CLI image (Armbian_25.11.1_Khadas-vim3l_trixie_current_6.12.58_minimal.oowow.img.xz) using balenaEtcher—onto two different SD cards as well as a USB stick, and I am attempting to boot from them. I have tried various key combinations, but nothing works. For example, when I attempt the method suggested by ChatGPT: Recovery Button Method Unplug the power supply Insert the SD card Hold down the FUNCTION button Briefly press RESET Continue holding the FUNCTION button for another 2–3 seconds I briefly see the Khadas logo, and then it reboots; this process then gets stuck in a loop. I tried using three different power adapters and usb-c cables, thinking that might be the issue... but it was always the same result. I tried a different SD card and various USB sticks and different formats always the same outcome. As a test, I even selected a different image just to see if it would progress any further, but again, I just saw the Khadas logo followed by a boot loop. As soon as I remove the SD card or USB stick, it boots back into CoreELEC from the internal storage. Now I’ve read on another site that I shouldn't use BalenaEtcher, but instead format the SD card/USB stick to FAT32 and place the image in the root directory. I did exactly that and tested it on both the USB 3.0 and 2.0 ports and with the SD because it boots before usb ?!?. Then: disconnect the power supply. Insert the USB stick. Connect HDMI + keyboard. Hold down the FUNCTION button. Plug in the power supply. Immediately press RESET briefly. Continue holding FUNCTION for another 3–5 seconds. And once again, I only see the Khadas logo for a sec and am stuck in a boot loop. Could someone please give me a direct link or the name of the correct image, and tell me the right key combination I need to press or let me know what I'm doing wrong? A step by step guide for an idiot would be great and sorry if the question is stupid, i watched youtube videos, read in the forum etc. but i dont get it, i need really your help. Thank you

@ebin-dev good idea, I can try that. For the moment I seem to have a stable system running 25.11.2 with the 6.12.58 kernel and the l2-cache and op1-opp patches loaded as kernel overlays. My use case for the Helios64 is as a NAS with OMV8 and ZFS. Who is the maintainer of this board now ? I'm happy to test images on my hardware and it would be good if the latest builds worked out of the gate without having to patch them.

I have just cleaned-up / changed (again) things w.r.t. network names for my Nanopi-R6C. Same as Nanopi-R4S, it has 'wan' and 'lan', where wan is on-chip ethernet and lan is external PCIe connected. Double check for the R4S, but I am almost sure. So a mainline kernel in principle just numbers them eth<x> depending on timing and other things. New kernel behavior is that the on-chip gets named end0 and for my Nanopi-R6C the external gets named enP3p49s0, as that represents how it is HW connected via PCI-e. That is 7.0.<x-flavor> generic distro kernel. Then Armbian has 2 udev rules to rename to wan? and lan?. That is where the problem was and is for me as I use various different bootloader/firmware. I removed those udev rules as I run standard main distros as well and I need the names for bridges and vlans etc future proof and I don't care about names wan and lan (not using it as router). But if you want to keep that naming, check bootloader version (U-Boot I guess for you) and also udev rules and maybe other patches for RK3399 and/or R4S.

I prefer to stay on stable release. I updated an old version because of copy fail CVE . It's very strange that i'm the only one with this bug. Can I update only the uboot part?

Today I realized a higher version of zfs-dkms(2.4.1) was actually offered in the Armbian repository. So I entered the command below to upgrade zfs-dkms to 2.4.1 and it was successful:

Maybe because it's a "zombie" system with systemd removed and the monitor tools fails to address Here's the dmesg of current system blank

Seems like the same "issue" like here. tl;dr: upstream uses "otg" to allow user to change the usb port behaviour as they like. https://forum.armbian.com/topic/59094-usb-2-port-not-available/#comment-237191

Search root for this motherboard. The device is tvbox Fobem Duo

Bleedingedge Kernel 7.1 rc2 fixed it [ 12.686942] panfrost fde60000.gpu: clock rate = 594000000 [ 12.686994] panfrost fde60000.gpu: bus_clock rate = 500000000 [ 12.710029] panfrost fde60000.gpu: mali-g52 id 0x7402 major 0x1 minor 0x0 status 0x0 [ 12.710053] panfrost fde60000.gpu: features: 00000000,00000df7, issues: 00000000,00000400 [ 12.710062] panfrost fde60000.gpu: Features: L2:0x07110206 Shader:0x00000002 Tiler:0x00000209 Mem:0x1 MMU:0x00002823 AS:0xff JS:0x7 [ 12.710070] panfrost fde60000.gpu: shader_present=0x1 l2_present=0x1

Hello! I noticed that x96q lpddr v1.3 is now an official (or something close to that) release, as it appears on the main page when searching. I used to use @sicxnull fork but now I have the impression that his changes were incorporated and he is the official maintainer of this device. I installed the Armbian 26.02 in an SD card and tested it in my X96Q lpddr v1.3 device and it works great! The problem is when I installed it to the internal eMMC, it will not boot anymore. I have the serial cable attached and I can see that very very early in the boot process u-boot cannot read from flash and the boot hangs. I know this has been discussed to some extent in another thread but I wanted to start fresh on this one since now we're talking about the Armbian official release and not the fork anymore. My intent with this thread is focus exclusively on fixing eMMC on the official release. My tests: Test 1 Download latest release, from here, more specifically this one. Direct link to the image here (name: Armbian_community_26.2.0-trunk.858_X96q_resolute_current_6.18.27_xfce_desktop.img.xz). Write to SD card using balena etcher, boot in my x96q device. It works well, boots through the initialization process, create user account, etc. The, run armbian-install and install it to internal eMMC. Remove SD card. Reboot. It will not boot, with the following error: Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device 1. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Booting from SD card again, re-running the installer and forcing to update the eMMC bootloader does not help. Test 2 I swapped only u-boot for the one from miniarch/minimyth2 project, compiled for the same hardware. Miniarch project can be found here. An image that works on this hardware (in my specific device) can be found here, more specifically this one. This image works well, and it also works well when installed to eMMC. The reason I don't use it is that I prefer Ubuntu over Arch, which I can get with Armbian instead. Download that image, and extract the file u-boot-sunxi-with-spl.bin from the first partition of that image. I used unxz + losetup + loopback mount the image's first partition in linux, but it may be easier for you to just write that image to an SD card, then copy the file from it. It is in the first partition in the path /bootloader/u-boot-sunxi-with-spl.bin. Copy it to a usb stick and plug it into the x96q device or scp it directly. Now, boot the x96q with the SD card, go through all initial setup. Run armbian-install, and install it to eMMC. Finish the installer (quit). Copy the file you extracted from miniarch to the booted system in x96q (using the usb stick or scp'ing it directly). Overwrite the file with the same name at /usr/lib/linux-u-boot-current-x96q/u-boot-sunxi-with-spl.bin with the new one. Run the armbian-install command again, this time chose to update the bootloader in the eMMC. Mount the eMMC temporarily at /mnt and edit the /mnt/boot/armbianEnv.txt file, add this line: fdtfile=allwinner/sun50i-h313-x96q-lpddr3.dtb This is because the hardcoded path for the DTD file in miniarch is different from the one from armbian, so you need to override it. It can also be done in realtime on the u-boot boot prompt if you have serial cable attached. Reboot, remove the SD card and let it boot from the eMMC. It should work, now you have a working Armbian on the eMMC. This will get undone if the bootloader is updated again with the original one (and is not meant as a permanent fix). Thoughts Miniarch uses 2025.04 u-boot while Armbian x96q board is using 2024.01 but I'm not sure this is really relevant. My guess is that the difference is in some of the patches they apply and not in the improvements of this new version of u-boot itself. But I could be wrong. You can find the list of patches that miniarch applies over to stock u-boot here. Many of those patches do not exist in Armbian. I wonder if it is any of those that is making the difference. Question to @sicxnull: do you have a good idea of what is going on and have any direction for further testing? I wanted to ask before I start applying the extra patches one by one, that would take quite some time. Thanks!

Is it possible on a Banana Pi M4 Zero to reboot Armbian running from SD card, so that the next time it boots from the internal storage, without removing the SD card? (and without modifying sdcard boot sector) I want to create an automatic backup internal storage - so that the system (booted from emmc) reboots, starts from the SD card, backs up content emmc to sdcard, and then reboots again, booting from emmc. Is it possible some how?

@epost.deb Hmmm, I am a bit skeptical about that; mainly because the SoC (on my board <-- this is important!) does not peek for sdcard at all during boot, thus u-boot is not involved; moreover if I read the SARADC2 from userland, I get it in the range of the eMMC-only boot configuration. I emphasize this is on my board, because the manufacturer can chose the boot configuration placing a pair of resistors on the board. The manufacturer of my board choose the eMMC-only boot configuration. If I find the two resistors, and remove the "pull-down" one, my board would try booting from all the options.