Active threads

I switch to vendor kernel 6.1.115 - its work

Hi All Well I am getting nowhere fast. When plugging the board into a Rpi Zero 2w , i2cdetect -l shows i2c-1 and i2c-2 i2cdetect -y 1 shows 00x48 i2cdetect -y 2 shows oox49 (my second board) and a few others like 3a,50,59 Re-wrote the image on the Opi Zero 2w to Debian as I was getting tired of the booting problems with ArmBian. Followed the manual on ALL the instructions. i2cdetect -l shows i2c-0 i2c-1 ,i2c-2 and i2c-3 i2cdetect -y 0 does not show any adapters connected i2cdetect -y 1 shows UU on 36 i2cdetect -y 2 shows 30 and 50 i2cdetect -y 3 does not show any adapters VERY SLOWLY. Orangepi-config /system/Hardware has been tried with just i2c-0 ticked or all three ticked. Tried ticking phi2c-0 to 3 but that made no difference, still no 00x48 visible anywhere. I have tried about 6 different OS Images, all to no avail. Even tried the Rpi image shown on the Opi site. So, I have to conclude (unless someone corrects me) that it is the board that is the problem or some firmware on the board. Not sure if I should learn how to upgrade the firmware. Regards

@Igor When I first start it up, I get an error! Even if I install the packages manually, the GNOMRlE interface does not switch to Portuguese! That's strange!

I recently had to modify a device tree file for a different reason. I showed what I did (and how I did it) here: https://forum.armbian.com/topic/52118-hdmi-audio-and-analog-audio-do-not-work-on-opi5plus/?do=findComment&comment=224923 To summarize, I used the device-tree-compiler package (command line: dtc) to convert the device tree binary (.dtb) file to a device tree source (.dts) file. Then I edited the .dts file, then converted it back. The process won't show you all the variable names, but the resulting .dts is readable enough to likely see what and where you need to change... and even moreso if you have the original (pre-compiled) .dts file to compare it with. If you need to match variable names with specific numbers, they will likely be #defined in the #includes at the top of the original .dts file.

This will cause update-grub to add the following a devicetree line to all menu entries. This example is based on Debian Trixie's grub-efi. This example will expect dtb directories (or links) to be in the /boot directory, using the convention that I've seen Armbian use. Here is an example of a /boot directory listing for (pure) Debian Trixie with two kernels: -rw-r--r-- 1 root root 336036 Aug 27 04:10 config-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 343394 Sep 6 12:48 config-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 42 Sep 20 16:17 dtb -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ lrwxrwxrwx 1 root root 43 Sep 20 16:17 dtb-6.12.43+deb13-arm64 -> ../usr/lib/linux-image-6.12.43+deb13-arm64/ lrwxrwxrwx 1 root root 42 Sep 20 16:18 dtb-6.16.3+deb13-arm64 -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ drwxr-xr-x 3 root root 4096 Sep 20 15:13 efi drwxr-xr-x 5 root root 4096 Sep 20 16:26 grub lrwxrwxrwx 1 root root 29 Sep 15 21:30 initrd.img -> initrd.img-6.16.3+deb13-arm64 -rw------- 1 root root 42521317 Sep 20 16:26 initrd.img-6.12.43+deb13-arm64 -rw------- 1 root root 43760872 Sep 20 16:25 initrd.img-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 30 Sep 15 20:38 initrd.img.old -> initrd.img-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 83 Aug 27 04:10 System.map-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 92 Sep 6 12:48 System.map-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 26 Sep 15 21:30 vmlinuz -> vmlinuz-6.16.3+deb13-arm64 -rw-r--r-- 1 root root 37449664 Aug 27 04:10 vmlinuz-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 41507328 Sep 6 12:48 vmlinuz-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 27 Sep 15 20:38 vmlinuz.old -> vmlinuz-6.12.43+deb13-arm64 Note: The relative pathways of the dtb links above assume that the /boot directory is part of the main OS partition, not on its own boot partition. Otherwise you'd need to copy those directories to /boot/ as Armbian does. For The Current Partition's OS Entries (each devicetree will be specific to the respective kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/10_linux 2. Find every line that looks something like this (currently on my system, there is only one, and it's line 189) linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args} 3. Just above it, add your own system's version of this line: devicetree ${rel_dirname}/dtb-${version}/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree ${rel_dirname}/dtb-${version}/rockchip/rk3588-orangepi-5-plus.dtb Specific Example from the resulting grub.cfg, of the current trixie-backport kernel, again on the OrangePI-5-Plus: devicetree /boot/dtb-6.16.3+deb13-arm64/rockchip/rk3588-orangepi-5-plus.dtb For Other Partitions' OS Entries, via os-prober (I'm unfamiliar with the variables in this so each devicetree will be the same generic path, regardless of kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/30_os-prober 2. Find every line that looks something like this (currently on my system, there are two, lines 277 and 297) linux ${LKERNEL} ${LPARAMS} 3. Just above it, add your own system's version of this line: devicetree /boot/dtb/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb Then run update-grub, and take a look at the resulting /boot/grub/grub.cfg

Yes, current broke at some point. More up to date packages should be available via apt. In general the support for rk3588 in 6.12 (current as of today) is barely there but there won't be updates regarding that matter, bug fixes only due to its LTS nature. Better use vendor or edge.

Great, svvolf! This fix boot problem on OPI Zero v1 (Armbian v25.8.1, Linux 6.12.43-current-sunxi) 😁 Thank you!

T'is one reason to prefer boards that take 12V power. and yes, barrel-connectors, but I can't think of any recent boards that use 5V and barrel connectors. NanoPi-M4 vs NanoPC-T4, with a WD Blue SN500, the T4 was stable. the M4 was not. yes, the M4 used the official power supply.

As far as I know, the permissions of /var/log/postgresql after a reboot are recreated from those on /var/log.hdd/postgresql. So if you modify those as well (remove the sticky bit), the workaround should be permanent. Thanks for highlighting this problem, I've encountered the very same issue, but didn't realize it was caused by this somewhat peculiar directory permission. So I just applied your workaround (plus my extension) and hope it will fix this once and for all.

I think there are some userspace drivers needed as well. Armbian provides the kernel module only. Not exactly sure what's needed but I think the stuff is from here: https://github.com/airockchip/rknn-toolkit2/tree/master/rknpu2

I see. Well there is a similar topic, maybe this can give some clues: https://forum.armbian.com/topic/50228-i2s-audio-not-working-on-orange-pi-zero-2w-allwinner-h618-with-max98357a/

Hi goodfvh _YT_. I wanted to know if you are using Dupont wires?

If someone interested on this tv box: I've managed to download original firmware image (update.zip) from backup partition. Also I cleaned it from malware (at least I think so) and packed as modified update.zip. Files are located here: https://drive.google.com/drive/folders/1etPmH8ZG4UtPHI3Vf1U9MUHl5_gK_s-E Further info available here (in Russian): https://4pda.to/forum/index.php?showtopic=1016510&view=findpost&p=139209499

Join us next week in Paris for Kernel Recipes! We're delighted to sponsor this kernel-focused event and contribute with a talk on GPU drivers. View the full article

Hello @Eks Ma, how are you? Unfortunately not. I gave up trying. The TV box is just sitting here at home.

It may or may not work to use a Tinkerboard image for your Chromebook. Same processor or manufacturer does not mean much, though, in terms of compatibility.

Also note that if you are on a community build or anything that points to the "beta" armbian apt repository, you will get a new linux kernel image pushed out to you each day, which would then trigger the need for a reboot (depending on settings) for that new kernel to be run.

unfortunately, your board has no maintainer in Armbian, it is only supported by the community

what version of OS are you guys running? are you possibly affected by the hardening of fancontrol in trixie?

After like a week of trying to make my tinkerboard rk3288 play videos I finally found the holy grail: https://users.armbian.com/jmcc/output/ Find the latest version and install that with all his dependencies, all the dependencies are in the debian archive: deb http://archive.debian.org/debian buster main contrib non-free deb http://archive.debian.org/debian buster-updates main contrib non-free deb http://archive.debian.org/debian buster-backports main contrib non-free deb http://archive.debian.org/debian-security buster/updates main contrib non-free deb [signed-by=/usr/share/keyrings/armbian.gpg] https://github.armbian.com/configng stable main deb http://apt.armbian.com buster main buster-utils buster-desktop I managed to play 4k hevc dolby atmos 5.1 movie streaming from my jellyfin server at my parents house using kodi-gbm and it worked flawlessly! I couldn't do the same with mpv yet. I hope this helps ppl with this ancient (2017) sbc.

I also upgraded from bookworm to trixie and saw this warning. I can confirm that Igor's suggested workaround addresses it: wget https://apt.armbian.com/armbian.key gpg --dearmor < armbian.key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null apt is now happy with the armbian repo.

I flashed same image to a SD card and tried to boot from it. Following is the result of `grep mmcblk1p2 /var/log/syslog` 2025-09-17T09:52:44.015489+00:00 rock-5-itx armbian-resize-filesystem[947]: ### [resize2fs] Trying to resize ext4 filesystem on /dev/mmcblk1p2: 2025-09-17T09:52:44.015493+00:00 rock-5-itx armbian-resize-filesystem[947]: Running 'resize2fs /dev/mmcblk1p2' now... 2025-09-17T09:52:44.015508+00:00 rock-5-itx armbian-resize-filesystem[947]: Filesystem at /dev/mmcblk1p2 is mounted on /; on-line resizing required 2025-09-17T09:52:44.021891+00:00 rock-5-itx kernel: EXT4-fs (mmcblk1p2): mounted filesystem with writeback data mode. Quota mode: none. 2025-09-17T09:52:44.021891+00:00 rock-5-itx kernel: EXT4-fs (mmcblk1p2): unmounting filesystem. 2025-09-17T09:52:44.021893+00:00 rock-5-itx kernel: EXT4-fs (mmcblk1p2): mounted filesystem with writeback data mode. Quota mode: none. I will try booting from a different medium and running `fsck mmcblk1p2` too.

Sorry, it's working now.

Hi, In the documentation (https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-kernel-config) it says: "User provided kernel config: If the file userpatches/linux-$LINUXFAMILY-$BRANCH.config exists, it will be used instead of the default one from config." Is there a way to define only the desired changes to the kernel parameters?

@SteeMan That is actually a good question, to which I do not have the answer. Here's a picture of the chip itself: I have not been able to find any information on that particular chip, so it may as well be nand...