All Activity

Anyone got the dedicated Fan header working correctly? It won't spin at all. Enabled the fanctrl overlay. changed pwm rate,the fan won't budge.. Tried stress the CPU but this only cause shutdown

Hi, Here what I do 1°) Flash the minimal - IOT image (trixie) for Odroid N2+ on my EMMc 2°) setup Root password and user 3°) Set up locale 4°) use armbian-config to switch on kernel 6.19.0 5°) Reboot - After Reboot I can see this : v26.2.1 for Odroid N2 running Armbian Linux 6.19.0-edge-meson64 6°) use armbian-config to add linux header 7°) reboot 8°) use these commands: # grep -r "iptables" /lib/modules/. grep: /lib/modules/./6.19.0-edge-meson64/kernel/net/ipv4/netfilter/ipt_rpfilter.ko : fichiers binaires correspondent grep: /lib/modules/./6.19.0-edge-meson64/kernel/net/bridge/br_netfilter.ko : fichiers binaires correspondent # grep -r "ip_tables" /lib/modules/. -- nothing # find /lib/modules/ -name ip* lot of filkes but no ip_tables.ko 9°) use armbian-upgrade 10°) reboot 11°) retry commands grep et find: same result 12°) Try to launch # iptables -L command not found 13°) Install iptables # apt install -y iptables # iptables -v iptables v1.8.11 (nftables): no command specified # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # update-alternatives --set iptables /usr/sbin/iptables-legacy update-alternatives: utilisation de « /usr/sbin/iptables-legacy » pour fournir « /usr/sbin/iptables » (iptables) en mode manuel # update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy update-alternatives: utilisation de « /usr/sbin/ip6tables-legacy » pour fournir « /usr/sbin/ip6tables » (ip6tables) en mode manuel # iptables -L modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.19.0-edge-meson64 iptables v1.8.11 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. 14°) Reboot 15°) Try # iptables -L modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.19.0-edge-meson64 iptables v1.8.11 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. Do I made something wrong ? Thanks

I installed the patch files with "Pb143" in the name on Friday, but unfortunately there was no improvement. Here are the logs: https://paste.armbian.com/dovedafali Can you tell me if I can test something with this? If so, what exactly do I need to do?

Did you perhaps upgrade kernel and forgot to reboot?

Module name is "ip_tables"

Thanks for your answer. I very sorry to ask you one more things please. How can I check if module is present. In modules files in "/lib/modules/6.18.10-current-meson64" ? I tried to do this : # cd /lib/modules/6.18.10-current-meson64 # grep -r "iptables" . Answer grep: ./net/ipv4/netfilter/ipt_rpfilter.ko : fichiers binaires correspondent grep: ./net/bridge/br_netfilter.ko : fichiers binaires correspondent I not an expert PS : I'am on Minimal / IOT version. Maybe it's the reason ? Thanks

logs are incomplete. dmesg is missing completely which would be the most relevant. moved to staging

https://github.com/armbian/build/blob/b8eab09ef561f2d03956098d26351d323a3b2d7b/config/kernel/linux-meson64-current.config#L355 Check your /lib/modules directory if it is present. It should be.

Why would you use an image for the Zero 3 for the 5B? You cannot simply shove an image for a random board into yours and assume it works...

This is latest edge version 6.18. Should be easily reproducible on your end, effects all rock 5B+ boards and this board is a platinum supported board.

Hi all, Over the past few months working on the A7Z, I’ve successfully ported a number of BSP drivers to Linux 6.18. The code is available here: https://github.com/alexcaoys/allwinner-bsp/tree/linux-6.18.y It’s currently tested on 6.18.19 and should, in theory, work with newer 6.18.y releases. I’ve tried to reuse as much upstream (mainline) drivers as possible, and have also upstreamed support for PCK600 and ET7304 used on the A7Z. Hopefully this helps accelerate ongoing mainline efforts. Feedback, issues, and PRs are very welcome. I may also look into creating branches for Linux 7.x in the future.

Hello. It seems there is an issue with iptables in the 6.18.10-current-meson64 kernel. I can't start Docker because of this. ``` ~# iptables -L modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.18.10-current-meson64 iptables v1.8.11 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. ``` As I run a docker version 28.X.X, it does not support nftable. (Cannot upgrade at the moment). What can I do to solve the problem ? Thanks

Sorry I'm not able to find the sub category for M4V2 so I chose R4S instead. But please keep in mind that this is a bug report for NanoPi M4V2. So my box has been running well for 5 years without any issue, through multiple system upgrade from armbian buster to trixie. However after I upgrade the kernel from 6.12.58 to 6.18.10 just a couple of days ago, the system started to have some weird behavior. The main symptom is that I'll lose the network connection from the box once it starts up, and it could happen after just a few minutes, or a couple of hours. I have to power cycle the box to get it back online as I don't have any peripherals, and soon I will lose the connection again. Other symptoms I've observed so far: - Once I lost the connection and powered cycle the box, the timestamp in the log looks confusing. Somehow the system clock paused at the moment when system froze. When it boots up, there could be a large gap between the NTP server and it will have to sync up, and I don't even seem to be able to find any logs before this reboot - The line `fdtfile=rockchip/rk3399-nanopi-m4v2.dtb` in `/boot/armbianEnv.txt` looks to be missing, so I added it back but it didn't fix the issue Eventually I downgraded to 6.12.58 with armbian-config, by timing the time window between the bootup and system freeze. After that the issue seems to be gone. Please find the results for `armbianmonitor -u` at https://paste.armbian.com/werujijedo For those who has the same model as mine, please think twice before upgrading. Do backup your data if you'd like to take the risk.

mar 22 2026 build. system seems to boot up, lights on, fans on at boot but no hdmi output

Pami, I have not personally found any LLM capable of generating working DTS files no matter what. It seems to be too niche for the LLM to understand. This DTS could potentially be a good starting ground for the pi, replacing "bcm2835" which refers to the pi zero 1, with "bcm2710" which refers to the pi zero 2. The github repository I linked is a good guide to getting the red displays working for a voron printer using panel-mipi driver, and I referenced it to create the DTS I use for the rock pi 4b. Also, try lowering the SPI speed to 20, 16, or 10 MHz, then raise it when you verify it works. I was frustrating myself for weeks thinking my DTS was broken, when it was fine the entire time, just my SPI speed was too high. robertoj: I appreciate your help, but I believe the issue I have with the red display (I have the same one as pami sent) is a combination of SPI commands being sent at the wrong interval (at the end of the clock cycle instead of in line), as well as insufficient SPI speed - where the display freezes above 24 MHz, and shows extreme visual tearing below it. At RGB666, its too much data for a measly 20MHz SPI rate, and the board does not support any other RGB modes in SPI. Since the TE pin is not exposed on the board, I cannot sync the SPI writes to the display. At least, that is my theory. I've given up on using an SPI display, and instead transitioned to an RGB Parallel display, which uses one gpio pin per color bit. Note that, at least in the display datasheet I received, the display actually does have the pins needed to drive it over DPI RGB Parallel. You can drive the board in 16, 18, or 24 bit mode over DPI RGB Parallel. These pins are not exposed on the board, but you could use an FPC breakout board to interface with these pins, and drive the display in DPI RGB parallel instead (accounting for the backlight voltage needed). The advantage of using RGB Parallel is it natively uses the GPU (RGB Parallel is the same technology as VGA) and has very fast refresh rate. For anyone here in future, any DPI hats that exist, like the adafruit kippah or othermod dpi topper, do not have the correct pinout to interface with this specific ili9486/8, but if you were to rearrange the pins on either the HATS or with an intermediary FPC PCB, then they would work plug and play.

Hello, i tried "Armbian_community_26.2.0-trunk.606_Radxa-cubie-a5e_trixie_edge_6.19.8_minimal.img" and wlan didn't work, i think the device tree is broken Radxa-cubie-a5e kernel 6.19.x as a quick fix, I copy the kernel 6.18.x "sun55i-a527-cubie-a5e.dtb" file to the /boot/dtb/allwinner directory to get wlan working.

@sven-ola there are 3 ways to boot the R2S: 1. Press the boot button before applying power. White USB port connected to a PC. Apply power. It goes into fastboot mode like an android. Theoretically this should let you flash the on-board eMMC. I can successfully put it in fastboot mode but the flashing has not worked. 2. Boot from eMMC 3. Boot from USB. The eMMC has two boot partitions that are fixed size and one large main partition. My project uses the u-boot environment but also does a few minor things. It prioritizes USB if it finds a bootable medium there. It also safely flashes the boot blocks on the eMMC and then the main blocks. It adds some safety checks before flashing. Nothing else.

hi, I installed in usb the last version and boot. something wrong happen here, only left these two upgrades, I tried again with backup-img and falied to boot again

Hello @lewa_j, there already is a CONFIG_POWERVR_ROGUE=y in the 6.18 kernel. This was required for Wayland and subsequently for Spacemit-GPU-Binary-Support (see https://github.com/armbian/build/pull/9515). What exactly will work additionally with this option (I am not a GPU expert)? Hello @1111Windows, doing "apt-get upgrade" on my GPU demo image this will downgrade the kernel from 6.18.18 to 6.6.99. Probably b/c recently the 6.6.99 was changed "current->legacy" and the 6.18 changed "edge->current". Also, OpiRV2 is not a really / full official Armbian image right now. So we probably need to wait until build pipelines catch up. I'll place a "apt-mark hold linux-image*" on my todo for those images. @maxsub The R2S does not have a NOR flash (or "MTD") that it boots from in the first place? That little project of yours does not look like an Armbian fork ready to be merged in. I may need some time to dig in and understand how it works. Have you considered changing the u-boot enviroment (...that can be save with "env save")?

just tested with a clean image, featuring 6.18.y and works just fine. This may be an issue if your setup is quite old, because at some point upstream changes caused Armbian kernel to break IIRC and this was worked around. The warning is persistent but doesn't actually matter. Please verify that a clean system boots normally.

hi, when upgrade I found these errors https://paste.armbian.com/utesitikah.sql what else logs do you need? var/log boot.log?

hard to tell without any logs whatsoever

hi, using rpi5, sometimes swap with rpi400, I have problem with the last upgrade, after reboot kernel does not boot, stuck in starting system. One or two of theses pkg fail. Thanks in advance

[ 5.092655] CPU1: failed to come online [ 5.092666] CPU1: failed in unknown state : 0x0 [ 10.217311] CPU2: failed to come online [ 10.217324] CPU2: failed in unknown state : 0x0 [ 15.341948] CPU3: failed to come online [ 15.341961] CPU3: failed in unknown state : 0x0 Yes we're aware of this, since it affects all H5 and H6 devices. We have a few ideas about what could be the cause like added logging (yes, sounds odd but..oh well) or certain ATF version. https://github.com/armbian/build/issues/9555

moved to off-topic since not directly related to armbian.