All Activity

Armbian uses Netplan by default to manage network settings. But when it uses NetworkManager as renderer, it silently changes iptables rules—without asking, without telling. *Neither Netplan nor NetworkManager are supposed to manage firewall settings.* But they do it anyway, behind the scenes. That kind of behavior—making security changes without user consent—feels a lot like what malware does.

@Nick A full log (failed): [💲|🌱] Starting main configuration [💲|🌱] Using REVISION from [ main VERSION file: '25.05.0-trunk' ] [💲|🌿] Enabling extension [ armbian-config ] [💲|🌱] Sourcing family configuration [ /home/nguye/build/config/sources/families/sun50iw9.conf ] [💲|🌿] Enabling extension [ sunxi-tools ] [💲|✅] change-tracking: after sourcing family config [ KERNEL_MAJOR_MINOR='6.12' ] [💲|✅] change-tracking: after sourcing family config [ KERNELBRANCH='tag:v6.12.11' ] [💲|✅] change-tracking: after sourcing family config [ LINUXFAMILY='sunxi64' # (was: 'sun50iw9') ] [💲|✅] change-tracking: after sourcing family config [ KERNELPATCHDIR='archive/warpme-6.12' ] [💲|✅] change-tracking: after sourcing family config [ BOOTBRANCH='tag:v2025.01' ] [💲|✅] change-tracking: after sourcing family config [ BOOTPATCHDIR='u-boot-h616' ] [💲|✅] change-tracking: after sourcing family config [ ATFBRANCH='tag:lts-v2.10.14' ] [💲|✅] change-tracking: after sourcing family config [ NETWORKING_STACK='network-manager' ] [💲|🌱] Sourcing arch configuration [ arm64.conf ] [💲|✅] change-tracking: after sourcing arm64 arch [ ATFDIR='arm-trusted-firmware' ] [💲|🌱] Using NETWORKING_STACK [ NETWORKING_STACK: network-manager ] [💲|🌱] Adding networking extensions [ net-network-manager, net-chrony ] [💲|🌿] Enabling extension [ net-network-manager ] [💲|🌿] Enabling extension [ net-chrony ] [💲|🌱] Extension manager [ processed 17 Extension Methods calls and 27 Extension Method implementations ] [💲|🌱] x96q-lpddr3 [ Using allwinner/sun50i-h313-x96-q-lpddr3.dtb for edge ] [💲|💥] Error 1 occurred in SUBSHELL [ SUBSHELL at /home/nguye/build/lib/functions/configuration/config-desktop.sh:48 ] [💲|💥] Cleaning up [ please wait for cleanups to finish ] [💲|🌿] ANSI log file built; inspect it by running: [ less -RS output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans ] [💲|🌱] Share log manually: [ use one of the commands below (or add SHARE_LOG=yes next time!) ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.armbian.com/log ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.armbian.de/log ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.next.armbian.com/log ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.armbian.eu/log ] nguye@DESKTOP-IFEAUMD:~/build$ EDIT: it continued while i tried Debian 12 Next i choosed xfce config_base (onlyone) internet

@Nick A i choosed x96q-lpddr3 (csc) Allwinner H313 TVB with 2gigs of ram and emmc (my box uses emmc) debian 11 image with desktop enviroment

by the way i don't see any options with allwinner h313 and 1gb ram, can i just choose the 2gb x96q?

@Nick A Oh..

@Ducdanh Nguyen on the other side of the board it has two capacitors. I don’t think that’s it.

hey @Nick A, i think i found the serial port look at the yellow mark on the image

Could this be a power supply issue? Unfortunately, there is no official maintainer for your board. None of the core devs will be able to verify your issue.

Hi, thanks for the tip, here's the link of the amrbianmonitor results: https://paste.armbian.de/okeqakeval

Thanks, I am aware of that. But that's an Ubuntu that's using the barebones vendor kernel. I need a fuller kernel than that, and Debian. As it turns out, in looking at recent updates here, it looks like the audio issue has been addressed within the past few days, and that it's an easy fix (as I thought it would be): https://patchwork.kernel.org/project/linux-rockchip/list/ I have yet to try that out, but it looks like I can either wait for the update in the bleeding edge kernel (if it's not already present) or modify the devicetree myself with the fix they discovered.

That seems to have gone away. ? SNILMERG... Now using very small but 1920x1080 screen, xfce terminal text is about 7 microns tall, way too small for my ancient eyes, Simplified keyboard. ctrl&shift&+ magnify's text but when big enough to read, bottom of xfce4 terminal is offscreen below bottom of screen, so cannot see command line. Is there a keycode combo that expands text independently from terminal window size? Thank you.

The most interesting thing is that everything works fine for joshua-riek Ubuntu 24.04 with the 6.1 kernel https://joshua-riek.github.io/ubuntu-rockchip-download/boards/orangepi-5-plus.html

Armbian kernel and BSP Debian/Ubuntu userland

With the armbian build system, you can build either Bookworm or Trixie You will always get the latest Bookworm or the latest Trixie packages in a freshly built armbian OS. This is what's meant by "always rolling release"... not to be understood as "always sid or Trixie". Independently, the armbian build system will let you choose a stable Linux version, or the latest available from Armbian (edge).

You are still using an old Linux. You need Linux 6.13 or newer. You need to build your own Armbian OS. Also, don't forget the cma=256M kernel argument

Ho ! That's a new thing isn't it ? And IMHO, a strange choice. Is there a way to disable that rolling release during the image building process?

Stable images can only be built by Armbian. All user built images are essentially rolling releases. But once booted into an image, you can use armbian-config to switch to the stable apt repositories, which means you won't get bug fixes or security updates to the kernel, but instead you get a stable kernel build released once every three months.

Hi there! Made some further research. It seems I was wrong assuming hw GPU/VPU is used. The reduced CPU load is more likely a result of the lower fps when using -hwaccel drm (aka v4l2request) and the v4l2 layer falls back to soft decoding. I also tried now mpv but just with null output (as it can't fbdev) and captured the debug trace like so mpv Big_Buck_Bunny_720_10s_10MB.mp4 -vo=null --msg-level=all=trace [vd] Codec list: [vd] h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [vd] h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper [vd] Opening decoder h264 [vd] Looking at hwdec h264-drm... [vd] Could not create device. [vd] No hardware decoding available for this codec. [vd] Using software decoding. no hw accel used! I also captured a ffmpeg trace. ffmpeg -v trace -re -hwaccel drm -i Big_Buck_Bunny_720_10s_10MB.mp4 -f null - Maybe its in fact a duo2 only device tree related? Could someone try the same on any other H3 and provide thr results? If it really works with hwaccel and the org. 30fps I would like to have the trace logs, ideally the ffmpg* or both. lsmod | grep ced sunxi_cedrus 40960 0 v4l2_mem2mem 16384 1 sunxi_cedrus videobuf2_dma_contig 16384 1 sunxi_cedrus videobuf2_v4l2 16384 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_memops,v4l2_mem2mem,videobuf2_v4l2 videodev 188416 3 sunxi_cedrus,v4l2_mem2mem,videobuf2_v4l2 mc 36864 5 sunxi_cedrus,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2 *ffmpeg has been installed from below as the compiled 8x throws errors with -hwaccel. # Install the precompiled # ffmpeg version 5.1.6-0+deb12u1 Copyright (c) 2000-2024 the FFmpeg developers # built with gcc 12 (Debian 12.2.0-14) # https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/ # As root, no sudo # APT REPOSITORY SETUP wget http://apt.undo.it:7242/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc . /etc/os-release && echo "deb http://apt.undo.it:7242 $VERSION_CODENAME main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list echo -e "Package: *\nPin: release o=apt.undo.it\nPin-Priority: 600" | sudo tee /etc/apt/preferences.d/apt-undo-it # We only install ffmpeg. mpv doesn't work anyway with framebuffer # INSTALL FFMPEG AND MPV PACKAGES apt install ffmpeg

I was just wondering if there would be an issue because of different U-Boot and kernel combination in the 2 tests, but that does not seem to be the case. I think there might be some issue with the controller in the eMMC module that is starting to reveal when wear-level is or is getting higher. What fsck commands are done? So how is it fixed and is it fixed or is only metadata corrected and might there be corrupted data-blocks still without knowing. I don't use Ext4, I use Btrfs for rootfs and all other storage devices. In doubt, I use DUP profile for meta data, that is more for HDDs. As said Btrfs allows adhoc or regular scrubs, you will be able to detect where corrupt blocks are if that is the issue. It also might be that there is an issue in the 6.6 kernel that reveals itself when higher write delays or so, maybe update the OS. Maybe mmc-utils can show some issue (I have no experience with it).

reopening after moving to "Software / Applications / Userspace"

You realized the wrong thing: the topic is actual but this is not a forum where to discuss about Android or stock firmwares

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

@Nick A thank you.

Very bad advice. You just made all files under /home/odroid executable. Don't run server software unless you have at least a rudimentary understanding of Linux, especially if accessible from the internet. Better get hosting and not pwned and part of a botnet. This topic is not specific to Armbian and thus more suitable to be discussed elsewhere.

Hi @dale What is your DTS node for your display? My first guess is that your DT node is not being picked up/inexistent since the module loads but the display device is not present. You can use dtc /proc/device-tree to see your loaded DT and find your display node, if any. Then, have you checked dmesg for any tm16xx kernel message? Then, you can ls /sys/class/leds to see if any device were created. The display-service/display-utils scripts expect /sys/class/leds/display. That should not be your issue here, but I'm not sure that aip1688 is the same as tm1628 variants. Googling aip1688 list it besides aip1618, so that would be the tm1618 variant. Whatsoever, I think you should have partial working display if using tm1628. To be 100% of which compatible string to use, we would need the aip1688 datasheet but I couldn't find it online. Good luck with your experimentation! Let me know how you results.