pdieguez

Well, since it is already installed and working as expected, besides this issue of the my post above, what are my options? What could I do to fix this?

Hello everyone, I use my Orange Pi 5 board to run Open Media Vault with Wireguard installed. But there is a known issue with Wireguard that, when installing it, you have to manually reinstall the correct kernel into the board again, otherwise it won't be able to boot. However, ever since it has been installed, during apt update / apt ugrade of my board, it keeps recognizing the wrong kernel to be updated and changing the symlinks inside the /boot/ folder, rendering the board unbootable. If I see this happening, I can change the symlinks and it works normally after that. However, sometimes the symlinks changes unnoticed and I cannot boot anymore. I have to take the SD Card to another device, chroot into it, and change the links again. How can I prevent this from happening again and let the updates recognize the correct kernel version? In the image attached, you can see that uInitrd is pointing to uInitrd-6.11.5+bpo-arm64-16k, which is incorrect. I have to manually point it to uInitrd-6.1.99-vendor-rk35xx Sometimes, dtb and Image point to the wrong files as well. I have tried holding back linux-image-arm64-16k from being updated with apt hold, and I have also turned off automatic kernel updates inside armbian-config, but there is still something more to be done. I have just run apt update / apt upgrade, and I think that the part that is breaking my boot is the Processing triggers for initramfs-tools, as can be seen logged below: Setting up linux-u-boot-orangepi5-vendor (25.5.1) ... Armbian 'uboot-orangepi5-vendor' for '2017.09-S3e40-P187d-H0b1f-V023f-Bb703-R448a': 'postinst' starting. Armbian 'uboot-orangepi5-vendor' for '2017.09-S3e40-P187d-H0b1f-V023f-Bb703-R448a': 'postinst' finishing. Setting up systemd-sysv (252.38-1~deb12u1) ... Setting up libicu72:arm64 (72.1-3+deb12u1) ... Setting up linux-dtb-vendor-rk35xx (25.5.1) ... Armbian 'linux-dtb-vendor-rk35xx' for '6.1.115-vendor-rk35xx': 'postinst' starting. Armbian: DTB: symlinking /boot/dtb to /boot/dtb-6.1.115-vendor-rk35xx... 'dtb' -> 'dtb-6.1.115-vendor-rk35xx' Armbian 'linux-dtb-vendor-rk35xx' for '6.1.115-vendor-rk35xx': 'postinst' finishing. Setting up armbian-firmware-full (25.5.1) ... Setting up python3-ruamel.yaml.clib:arm64 (0.2.7-1+b2) ... Setting up libnss-systemd:arm64 (252.38-1~deb12u1) ... Setting up linux-image-vendor-rk35xx (25.5.1) ... Armbian 'linux-image-vendor-rk35xx' for '6.1.115-vendor-rk35xx': 'postinst' starting. update-initramfs: Generating /boot/initrd.img-6.1.115-vendor-rk35xx W: Possible missing firmware /lib/firmware/regulatory.db for built-in driver cfg80211 W: Possible missing firmware /lib/firmware/regulatory.db.p7s for built-in driver cfg80211 update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-6.1.115-vendor-rk35xx Image Name: uInitrd Created: Sun Jul 20 10:39:28 2025 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 13880399 Bytes = 13555.08 KiB = 13.24 MiB Load Address: 00000000 Entry Point: 00000000 update-initramfs: Armbian: Symlinking /boot/uInitrd-6.1.115-vendor-rk35xx to /boot/uInitrd '/boot/uInitrd' -> 'uInitrd-6.1.115-vendor-rk35xx' update-initramfs: Armbian: done. Remove unused generated file: /boot/uInitrd-6.1.99-vendor-rk35xx Remove unused generated file: /boot/initrd.img-6.1.99-vendor-rk35xx Armbian: update last-installed kernel symlink to 'Image'... '/boot/Image' -> 'vmlinuz-6.1.115-vendor-rk35xx' Armbian: Debian compat: linux-update-symlinks install 6.1.115-vendor-rk35xx boot/vmlinuz-6.1.115-vendor-rk35xx I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.115-vendor-rk35xx I: /initrd.img is now a symlink to boot/initrd.img-6.1.115-vendor-rk35xx Armbian 'linux-image-vendor-rk35xx' for '6.1.115-vendor-rk35xx': 'postinst' finishing. Setting up linux-headers-vendor-rk35xx (25.5.1) ... Armbian 'linux-headers-vendor-rk35xx' for '6.1.115-vendor-rk35xx': 'postinst' starting. Configuring kernel-headers (6.1.115-vendor-rk35xx) - please wait ... HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/menu.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/util.o HOSTLD scripts/kconfig/conf # # configuration written to .config # Compiling kernel-headers scripts (6.1.115-vendor-rk35xx) using 8 CPUs - please wait ... SYNC include/config/auto.conf.cmd HOSTCC scripts/dtc/dtc.o HOSTCC scripts/dtc/flattree.o HOSTCC scripts/dtc/fstree.o HOSTCC scripts/dtc/data.o HOSTCC scripts/dtc/livetree.o HOSTCC scripts/dtc/treesource.o HOSTCC scripts/dtc/srcpos.o HOSTCC scripts/dtc/checks.o HOSTCC scripts/dtc/util.o LEX scripts/dtc/dtc-lexer.lex.c YACC scripts/dtc/dtc-parser.tab.[ch] HOSTCC scripts/dtc/libfdt/fdt.o HOSTCC scripts/dtc/libfdt/fdt_ro.o HOSTCC scripts/dtc/libfdt/fdt_wip.o HOSTCC scripts/dtc/libfdt/fdt_sw.o HOSTCC scripts/dtc/libfdt/fdt_rw.o HOSTCC scripts/dtc/libfdt/fdt_strerror.o HOSTCC scripts/dtc/libfdt/fdt_empty_tree.o HOSTCC scripts/dtc/libfdt/fdt_addresses.o HOSTCC scripts/dtc/libfdt/fdt_overlay.o HOSTCC scripts/dtc/fdtoverlay.o HOSTCC scripts/dtc/dtc-lexer.lex.o HOSTCC scripts/dtc/dtc-parser.tab.o HOSTLD scripts/dtc/fdtoverlay HOSTLD scripts/dtc/dtc HOSTCC scripts/resource_tool HOSTCC scripts/kallsyms HOSTCC scripts/sorttable HOSTCC scripts/asn1_compiler HOSTCC scripts/genksyms/genksyms.o YACC scripts/genksyms/parse.tab.[ch] HOSTCC scripts/selinux/genheaders/genheaders HOSTCC scripts/selinux/mdp/mdp LEX scripts/genksyms/lex.lex.c HOSTCC scripts/genksyms/parse.tab.o HOSTCC scripts/genksyms/lex.lex.o HOSTLD scripts/genksyms/genksyms Compiling kernel-headers scripts/mod (6.1.115-vendor-rk35xx) using 8 CPUs - please wait ... CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig CC scripts/mod/devicetable-offsets.s MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o UPD scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/mod/modpost MODPOST scripts/mod/Module.symvers Done compiling kernel-headers (6.1.115-vendor-rk35xx). Done compiling kernel-headers tools (6.1.115-vendor-rk35xx). Armbian 'linux-headers-vendor-rk35xx' for '6.1.115-vendor-rk35xx': 'postinst' finishing. Setting up armbian-bsp-cli-orangepi5-vendor (25.5.1) ... Armbian 'armbian-bsp-cli-orangepi5-vendor' for '1-PC5315-V4064-H21c6-B1e5d-R756d': 'postinst' starting. Armbian 'armbian-bsp-cli-orangepi5-vendor' for '1-PC5315-V4064-H21c6-B1e5d-R756d': 'postinst' finishing. (...) Processing system modifications ... Processing triggers for initramfs-tools (0.142+deb12u3) ... update-initramfs: Generating /boot/initrd.img-6.11.5+bpo-arm64-16k update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-6.11.5+bpo-arm64-16k Image Name: uInitrd Created: Sun Jul 20 10:43:32 2025 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 54963626 Bytes = 53675.42 KiB = 52.42 MiB Load Address: 00000000 Entry Point: 00000000 update-initramfs: Armbian: Symlinking /boot/uInitrd-6.11.5+bpo-arm64-16k to /boot/uInitrd '/boot/uInitrd' -> 'uInitrd-6.11.5+bpo-arm64-16k' update-initramfs: Armbian: done. Any help appreciated. Thank you all

Thank you very much Ojay. By the way, are your kernel upgrades still frozen? Haven't you updated any since you installed Wireguard?

Which exact options did you choose on armbian-config after installing wireguard? I can see "Headers_install" under system. Is that it? What else? Thanks,

I used armbian-config. Way easier than I expected. Thank you. I did not try that before because it says "deprecated" But anyway, thanks.

Hello all, I have noticed that whenever I reboot my Orange Pi 5 board, all the 8 cpus slow down to 408 Mhz with no range, as stated by cpufreq-info: I have created a cronjob script in order to bring the frequency back to acceptable range. I don't even know if this is the correct way to solve this, but I am running the following: echo performance | sudo tee /sys/devices/platform/dmc/devfreq/dmc/governor cpufreq-set -c 0 -u 1800000 cpufreq-set -c 4 -u 2260000 cpufreq-set -c 6 -u 2300000 cpufreq-set -c 0 -g schedutil cpufreq-set -c 4 -g schedutil cpufreq-set -c 6 -g schedutil However, even though I set the frequency for processors 6 and 7 for 2.30 Ghz using this method, they never go that high, as stated by cpufreq-info: analyzing CPU 6: driver: cpufreq-dt CPUs which run at the same hardware frequency: 6 7 CPUs which need to have their frequency coordinated by software: 6 7 maximum transition latency: 324 us. hardware limits: 408 MHz - 2.26 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.26 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 408 MHz and 2.26 GHz. The governor "schedutil" may decide which speed to use within this range. current CPU frequency is 408 MHz (asserted by call to hardware). cpufreq stats: 408 MHz:80.22%, 600 MHz:1.90%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:3.98%, 1.42 GHz:2.08%, 1.61 GHz:1.47%, 1.80 GHz:1.01%, 2.02 GHz:1.17%, 2.21 GHz:0.86%, 2.26 GHz:7.30% (2110) analyzing CPU 7: driver: cpufreq-dt CPUs which run at the same hardware frequency: 6 7 CPUs which need to have their frequency coordinated by software: 6 7 maximum transition latency: 324 us. hardware limits: 408 MHz - 2.26 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.26 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 408 MHz and 2.26 GHz. The governor "schedutil" may decide which speed to use within this range. current CPU frequency is 408 MHz (asserted by call to hardware). cpufreq stats: 408 MHz:80.22%, 600 MHz:1.90%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:3.98%, 1.42 GHz:2.08%, 1.61 GHz:1.47%, 1.80 GHz:1.01%, 2.02 GHz:1.17%, 2.21 GHz:0.86%, 2.26 GHz:7.30% (2110) Those last two processors only go that high if I run sbc-bench one time, than I get the desired speeds: analyzing CPU 6: driver: cpufreq-dt CPUs which run at the same hardware frequency: 6 7 CPUs which need to have their frequency coordinated by software: 6 7 maximum transition latency: 324 us. hardware limits: 408 MHz - 2.30 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.30 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 408 MHz and 2.30 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 2.30 GHz (asserted by call to hardware). cpufreq stats: 408 MHz:0.00%, 600 MHz:0.00%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.42 GHz:0.00%, 1.61 GHz:0.00%, 1.80 GHz:0.00%, 2.02 GHz:3.63%, 2.21 GHz:5.86%, 2.30 GHz:90.50% (1538) analyzing CPU 7: driver: cpufreq-dt CPUs which run at the same hardware frequency: 6 7 CPUs which need to have their frequency coordinated by software: 6 7 maximum transition latency: 324 us. hardware limits: 408 MHz - 2.30 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.30 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 408 MHz and 2.30 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 2.30 GHz (asserted by call to hardware). cpufreq stats: 408 MHz:0.00%, 600 MHz:0.00%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.42 GHz:0.00%, 1.61 GHz:0.00%, 1.80 GHz:0.00%, 2.02 GHz:3.63%, 2.21 GHz:5.86%, 2.30 GHz:90.50% (1538) What is the correct way to solve this? What is sbc-bench doing in order to achieve these frenquencies?? Best regards,

Hello all, I am running an Orange Pi 5 board with Armbian on a SD Card and I realized that my /var/log path is constantly full, with it being at /dev/zram1 It gets full at 50Mb with the file /var/log/samba/cores/smbd/core taking up all the space I have not managed to read this file, so I can't tell what kinds of errors are showing up. My OpenMediaVault and samba setup are running perfectly fine, and even though I delete this core file, it shows up again during reboot. I have tried to set enable core files = no in smb.conf With no sucess. The file continues to show up during reboot. Any ideas how to solve this? Best regards