TDCroPower

I flashed to both as you recommended.... root@helios64:~/bootloader/linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64# dd if=idbloader.bin of=/dev/mmcblk1 seek=64 conv=notrunc 424+1 records in 424+1 records out 217372 bytes (217 kB, 212 KiB) copied, 0.0135302 s, 16.1 MB/s root@helios64:~/bootloader/linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64# dd if=uboot.img of=/dev/mmcblk1 seek=16384 conv=notrunc 8192+0 records in 8192+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.539218 s, 7.8 MB/s root@helios64:~/bootloader/linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64# dd if=trust.bin of=/dev/mmcblk1 seek=24576 conv=notrunc 8192+0 records in 8192+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.485736 s, 8.6 MB/s root@helios64:~/bootloader/linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64# dd if=idbloader.bin of=/dev/mmcblk0 seek=64 conv=notrunc 424+1 records in 424+1 records out 217372 bytes (217 kB, 212 KiB) copied, 0.037369 s, 5.8 MB/s root@helios64:~/bootloader/linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64# dd if=uboot.img of=/dev/mmcblk0 seek=16384 conv=notrunc 8192+0 records in 8192+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.399514 s, 10.5 MB/s root@helios64:~/bootloader/linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64# dd if=trust.bin of=/dev/mmcblk0 seek=24576 conv=notrunc 8192+0 records in 8192+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.405223 s, 10.4 MB/s Test booted from SD... root@helios64:~# for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done root@helios64:~# Test booted from eMMC... root@helios64:~# for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done root@helios64:~# It now looks as if this has worked. I'll transfer the status of the SD to the eMMC and try to install OMV 7 RC1 again. edit: after transfer SD to eMMC the check fails with "Segmentation fault"... root@helios64:~# for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done Segmentation fault I'll try to reflash the bootloader booted from the eMMC to see if that helps. edit2: Ok after I booted from the eMMC and flashed the bootloader into both partitions again the test works... root@helios64:~# for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done root@helios64:~# Let's try the OMV 7 RC1 installation now !! edit3: Finally... the OMV 7 installation was success ! We now have a stable Bookworm image version with which OMV 7 can also be installed. Thank you both for your help! I will extend the instructions above with further tips so that everyone can set it up in the same way.

@ebin-dev I have just booted from the SD again. The SD partition is on mmcblk0, so mmcblk1 should be the eMMC partition, right? root@helios64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.8G 0 1.8G 0% /dev tmpfs 380M 6.2M 374M 2% /run /dev/mmcblk0p1 59G 2.3G 56G 4% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 47M 1.7M 42M 4% /var/log tmpfs 380M 0 380M 0% /run/user/0 booted from eMMC... root@helios64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.8G 0 1.8G 0% /dev tmpfs 380M 1.3M 379M 1% /run /dev/mmcblk1p1 15G 2.6G 11G 20% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp tmpfs 380M 0 380M 0% /run/user/0 i think the u-boot version on eMMC is correct... root@helios64:~# strings /dev/mmcblk1p1 | grep U-Boot U-Boot version: %s 6U-Boot Env 6U-Boot U-Boot TPL 2022.07-armbian (Jun 28 2023 - 19:50:29) U-Boot SPL 2022.07-armbian (Jun 28 2023 - 19:50:29 +0000) U-Boot FIT image for U-Boot with bl31 (TF-A) U-Boot (64-bit) %U-Boot ** Invalid partition type "%.32s" (expect "U-Boot") scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done U-Boot.armv8 U-Boot console U-Boot 2022.07-armbian *** U-Boot Boot Menu *** U-Boot U-Boot 2022.07-armbian (Jun 28 2023 - 19:50:29 +0000) - boot a sample Hello World application stored within U-Boot ^C booted from SD the python3 check fails... root@helios64:~# for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done free(): invalid pointer Aborted

@prahal I don't quite understand the status of the issues. They are closed or merged so far, would we have to flash a higher kernel or something else on u-boot? when I look at the commit only one entry in the config was changed... - BOOT_SCENARIO="blobless" + BOOT_SCENARIO="tpl-blob-atf-mainline" Do we then have to explicitly start a build?

I tried to install OMV 7 RC1 on the Bookworm image, but I get a lot of "Segmentation fault" and "free(): invalid pointer" error messages. My Installation for the Bookworm image... Is the problem due to the Bookworm image or the 6.6.8 kernel or should I contact the OMV team? Here is the complete log of the OMV 7 RC1 installation...

@ebin-dev yes you can install them but you cannot update them completely because a package is no longer available for Bullseye. I will open a new topic for the OMV 7 installation.

@ebin-dev are these OMV problems or are they caused by the Helios64 installation, which is not yet clear to me. Many successful installations with RC1 have already been reported and unfortunately we currently have no chance of installing OMV 6 with Bullseye, as we can no longer install Bullseye properly on Helios64.

@ebin-dev do you have any tips on how I can solve the problem with the OMV 7 installation? Do I have to switch to an earlier kernel or do you have another idea?

Has anyone tried to install OMV 7 with the modified image from @ebin-dev? When installing via OMV install script some things go wrong and you get some "Segmentation fault" and "free(): invalid pointer" messages in the log. Here the complete OMV log...

@FlolmI am currently also reinstalling a Helios64 and following the instructions of @ebin-dev from here. As soon as i'm done i'll share a more detailed tutorial for dummies edit: thx to @ebin-dev for your instructions, I was able to run it successfully on my Helios64 and have written down the individual steps in more detail so that others can also do it without major problems. 1. image Armbian_23.5.4_Helios64_bookworm_current_6.1.36 flashing: Download and flash the image on your microSD with balenaEtcher or something similar... https://fi.mirror.armbian.de/archive/helios64/archive/Armbian_23.5.4_Helios64_bookworm_current_6.1.36.img.xz 2. set CPU limits: Run armbian-config -> System -> CPU And set: Min CPU speed = 408000 MHz Max CPU speed = 1200000 MHz CPU governor = on demand 3. disable Armbian Updates: you can either rename the source file or deactivate the line in the file with # at the beginning... root@helios64:~# cd /etc/apt/sources.list.d root@helios64:/etc/apt/sources.list.d# ls -l total 4 -rw-rw-r-- 1 root root 117 Jun 30 2023 armbian.list root@helios64:/etc/apt/sources.list.d# mv armbian.list armbian.list.disabled root@helios64:/etc/apt/sources.list.d# ls -l total 4 -rw-rw-r-- 1 root root 117 Jun 30 2023 armbian.list.disabled root@helios64:/etc/apt/sources.list.d# cat armbian.list.disabled # deb [signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop 4. Download and copy rtl_nic firmware files: Download this 9 files... rtl8125b-2.fw rtl8153a-2.fw rtl8153a-3.fw rtl8153a-4.fw rtl8153b-2.fw rtl8153c-1.fw rtl8156a-2.fw rtl8156b-2.fw rtl8168h-2.fw ... from here... https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rtl_nic ... and copy & replace the files to the directory /lib/firmware/rtl_nic on your helios64. 5. Upgrade kernel to 6.6.8: Download the 6.6.8 deb files from here... https://www.dropbox.com/scl/fi/9s2saibn9oezqmhfwyu3i/debs-6.6.8.zip?rlkey=hkkrxjelitsto0f0zw6wft6pq&dl=1 ... and copy the 3 files to your helios64. Execute these 4 commands one after the other... apt install libelf-dev dpkg -i linux-dtb-edge-rockchip64_24.2.0-trunk.225_arm64__6.6.8-S4c96-Dbc51-Pb65c-C891dHfe66-HK01ba-Vc222-B1743-R448a.deb dpkg -i linux-image-edge-rockchip64_24.2.0-trunk.225_arm64__6.6.8-S4c96-Dbc51-Pb65c-C891dHfe66-HK01ba-Vc222-B1743-R448a.deb dpkg -i linux-headers-edge-rockchip64_24.2.0-trunk.225_arm64__6.6.8-S4c96-Dbc51-Pb65c-C891dHfe66-HK01ba-Vc222-B1743-R448a.deb 6. update bootloader on eMMC: Download the deb file from here... https://imola.armbian.com/apt/pool/main/l/linux-u-boot-helios64-edge/linux-u-boot-edge-helios64_22.02.1_arm64.deb ... and copy the file to your helios64. Execute these 6 commands one after the other... dpkg -x linux-u-boot-edge-helios64_22.02.1_arm64.deb linux-u-boot-edge-helios64_22.02.1_arm64/ cd linux-u-boot-edge-helios64_22.02.1_arm64/usr/lib/linux-u-boot-edge-helios64_22.02.1_arm64/ dd if=idbloader.bin of=/dev/mmcblk1 seek=64 conv=notrunc dd if=uboot.img of=/dev/mmcblk1 seek=16384 conv=notrunc dd if=trust.bin of=/dev/mmcblk1 seek=24576 conv=notrunc reboot now 7. Set nic offload options: Select the LAN port you are using... For end0 - 1 GB Port: ethtool -K end0 tso on gso on gro on For eth1 - 2,5 GB Port: ethtool -K eth1 tso on gso on gro on ... and change the value in the ethtool command after the "-K". Execute the command ... root@helios64:~# ethtool -K end0 tso on gso on gro on Actual changes: tx-tcp-segmentation: off [requested on] tx-tcp-ecn-segmentation: off [requested on] tx-tcp-mangleid-segmentation: off [requested on] tx-tcp6-segmentation: off [requested on] 8. Fix hs400 support and L2 cache information: Download the dtb file from here... https://www.dropbox.com/scl/fi/nif2k0027whxky25djqll/rk3399-kobol-helios64.dtb-6.6.8-L2-hs400.zip?rlkey=zq7zw91oem4ugmgmaqfyuxqsa&dl=1 ... extract the rk3399-kobol-helios64.dtb-6.6.8-L2-hs400.zip ... rename rk3399-kobol-helios64.dtb-6.6.8-L2-hs400 to rk3399-kobol-helios64.dtb ... copy & replace the rk3399-kobol-helios64.dtb into /boot/dtb/rockchip 9. execute sbc-bench script: Execute these 3 commands one after the other... wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh chmod +x sbc-bench.sh ./sbc-bench.sh -r sbc-bench output.. 10. boot from eMMC: Run armbian-config -> System -> Install -> 2 Boot from eMMC -> erase eMMC: Yes -> 1 ext4 -> poweroff -> remove microSD -> boot hopefully from eMMC 11. update Debian packages: apt update && apt upgrade

@ebin-dev the most stable setting for me is the following, so far the Helios64 has been running for over 92 days... helios@helios64:~# cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR=ondemand MAX_SPEED=1200000 MIN_SPEED=408000 helios@helios64:~# helios@helios64:~# uptime 18:54:55 up 92 days, 21:20, 1 user, load average: 0.00, 0.00, 0.00

@prahal thanks for the explanation, which packages have to be set to onhold if you just don't want to update the kernel? Or is the kernel bound to the os release?

can anyone tell me how I can continue to update with a freezed kernel? I would like to leave the kernel on my Helios64 at 5.15.93 and continue to install updates. When I freeze the kernel with armbian-config under System >>> Freeze the background color changes from blue to red. If I then go to "Firmware" below, is the kernel still updated during the update? The kernel is also updated with "apt update && apt upgrade" !? Currently I have an unpleasant situation, because I have installed the kernel again via armbian-config to 5.15.93-rockchip64 #23.02.2... root@helios64:~# uname -a Linux helios64 5.15.93-rockchip64 #23.02.2 SMP PREEMPT Fri Feb 17 23:48:36 UTC 2023 aarch64 GNU/Linux root@helios64:~# apt update && apt list --upgradable Hit:1 http://deb.debian.org/debian bullseye InRelease Hit:2 http://deb.debian.org/debian bullseye-updates InRelease Hit:3 http://deb.debian.org/debian bullseye-backports InRelease Hit:4 https://download.docker.com/linux/debian bullseye InRelease Hit:5 http://armbian.hosthatch.com/apt bullseye InRelease Reading package lists... Done Building dependency tree... Done Reading state information... Done 3 packages can be upgraded. Run 'apt list --upgradable' to see them. Listing... Done armbian-bsp-cli-helios64/bullseye 23.11.1 arm64 [upgradable from: 21.08.2] linux-dtb-current-rockchip64/bullseye 23.11.1 arm64 [upgradable from: 23.02.2] linux-image-current-rockchip64/bullseye 23.11.1 arm64 [upgradable from: 23.02.2] edit: I found something about this with the command "apt-mark hold". If I compare my 2 Helios64 installations with "apt-mark showhold", the following was blocked on one of them via armbian-config... root@helios64:~# apt-mark showhold armbian-bsp-cli-helios64 armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64 and on the 2nd one... root@helios64:~# apt-mark showhold armbian-bsp-cli-helios64 armbian-firmware why wasn't the linux* updates also marked in the 2nd one?

@bunducafe no in this case OMV is not installed, only armbian. Do you do an update with "apt update && apt upgrade" or do you start it via armbian-config >>> System >>> Firmware "Update all packages and firmware" ?

@bunducafe I just tried it, first flashed the 21.08.2, then increased the kernel to 5.15.93, then set the freeze. Now when I do an "apt update" the 6.1.50 is displayed and also installed as soon as I run "apt upgrade". How exactly did you do it so that it does not update the kernel during an "apt upgrade"? What I also wonder, when I updated to 23.8.1 + 6.1.50 and then downgrade to 5.15.93 with image 23.02.2, afterwards when the kernel freeze this was also shown to me in the welcome message and an apt upgrade did not update it.

@bunducafe i will give it a try. Anyway, I now have an active system copied to the SSD, so I can run a fresh test again with the microSD. Found the downgrade variant itself is not good, because thereby in the root directory broken symlinks are.

@bunducafe that's strange, because exactly with your setting the system crashes for me. I was able to finally install OMV yesterday with Min + Max set to 1416000 + ondemand and the system stayed active the whole time. I have now set to Min=408000 and Max=1200000 ondemand and see if the system continues to survive that. If so, I can finally transfer it to the SSD and take it live permanently. I started with the image Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz and with "apt update && apt upgrade" updated it to 23.8.1 + 6.1.50. Then downgraded via armbian-config to Kernel 5.15.93 with image 23.02.2, set the cpu freq and freeze the kernel. I also added this... cpufreq.off=1 ... to the /boot/armbianEnv.txt which was recommended from @prahal on the end of the "freeze" thread. However, I could not find out exactly what these settings are supposed to be good for. Maybe someone has an idea? edit: I have just found something interesting here which fits perfectly to our hardware. Here a min/max is not simply set over all CPUs, but separately on the different types of installed CPUs. With the following command you can see the CPU limits and it fits to the suggested configs...

@bunducafe ok that sounds good, I found your kernel at.... https://mirror.yandex.ru/mirrors/armbian/apt/pool/main/l/linux-5.15.93-rockchip64/ this is probably included in the image 23.02.2. Is this still available somewhere as a bullseye image or how do I get from Image: 21.08.2 + Kernel: 5.10.63 to Image: 23.02.2 + Kernel: 5.15.93. Or in the case with frozen kernel to the current 23.8.1 ? edit: ok, i have found it under armbian-config -> System -> Other... edit2: I think I have an idea where the problem comes from, it probably has something to do with the cpu freq as described here in the thread. What values do you use ?

@bunducafe thanks for your information. Can you please describe your steps how you froze the kernel and how you went back to the last kernel? Your kernel 5.15.93 is newer than the 5.10.63 I used in the test !?? Or is 5.10.63 also broken?

@phidauex I am currently only testing via the microSD, not via eMMC or my SSD. It always hangs in the same place as described above and crashes so that the Helios64 restarts. i opened a omv thread for this: https://forum.openmediavault.org/index.php?thread/49873-helios64-with-armbian-install-omv-6-problems

@phidauex which image version + kernel did you use? I tried with the ready image Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz and also with the image including update to 23.8.1 + 6.1.50. With both, the installation fails at the same point... [...] Setting up Salt environment ... Setting up system ... Deploying service configurations ... I could continue the installation after reboot and with the command "dpkg --configure -a", so that I could use OMV but then the reboots started again.

Yes at Armbian-Config the same script is stored, which is recommended there. So the script in version 2.0.0 has some problem, strange only that also an update from OMV fails. I will open a thread in the omv forum to get to the bottom of the cause. I try tonight also times the manual variant to finally have a running system again. I have already created a backup with omv-regen, hope that this is not already defective.

@going Sorry had added the note above in edit3 that I could boot from the SSD image directly and was active for about 15 minutes, so I could install the old kernel without need of chroot. Unfortunately without positive result or do I need anything else except the 3 packages.... linux-dtb-current-rockchip64_21.05.4_arm64.deb linux-headers-current-rockchip64_21.05.4_arm64.deb linux-image-current-rockchip64_21.05.4_arm64.deb edit: I ran some more tests today, all via the microSD. In the first test I started the image Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz and with "apt update && apt upgrade" updated it to 23.8.1 + 6.1.50. After that I tried to install OMV via "armbian-config", the system crashes in the area of... Setting up Salt environment ... Setting up system ... Deploying service configurations ... in the second test I started again with the image Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz and only updated the armbian-config with "apt update && apt install --only-upgrade armbian-config" so that it installs OMV 6 instead of 5. Again, the system crashes in a similar area as test 1. I pulled out all three WD hard drives during testing. The question remains, is the OMV installation currently incompatible for armbian? @phidauex could you also try to install OMV on a fresh image via microSD, whether it also fails?

@going thanks for the tutorial, i used /dev/sda1 in step 4 as it is my m.2 ssd partition. Was that not correct? Is not /dev/mmcblk2p1 the partition of the emmc ? root@helios64:~# fdisk -l Disk /dev/mmcblk2: 14.56 GiB, 15634268160 bytes, 30535680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x728863aa Device Boot Start End Sectors Size Id Type /dev/mmcblk2p1 32768 30230303 30197536 14.4G 83 Linux Disk /dev/mmcblk1: 59.69 GiB, 64088965120 bytes, 125173760 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x8b029f90 Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 32768 123895807 123863040 59.1G 83 Linux Disk /dev/sda: 119.24 GiB, 128035676160 bytes, 250069680 sectors Disk model: NT-128 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x0182fc84 Device Boot Start End Sectors Size Id Type /dev/sda1 2048 250069679 250067632 119.2G 83 Linux Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/sdc: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68W Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/sdd: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: WDC WD40EFRX-68N Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/md127: 7.28 TiB, 8001302822912 bytes, 15627544576 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 524288 bytes / 1048576 bytes Disk /dev/zram0: 1.89 GiB, 2025508864 bytes, 494509 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram2: 1.89 GiB, 2025508864 bytes, 494509 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes To your important question: I now have Armbian 21.08.2 Bullseye with Linux 5.10.63-rockchip64 running stably via the microSD for over 60 minutes without reboots. I haven't had time to open the case today to look for the battery but as I understand it on the Kobol wiki there is no battery installed as the UPS takes over this task... https://wiki.kobol.io/helios64/rtc/ Since also other kernel leads to the similar problem, I suspect that it is perhaps the update of the OMV to 6.9.1? The first time it crashed was after the update when I wanted to apply the settings in the OMV web frontend. @phidauex Did you also install OMV and update it to version 6.9.1? edit: I installed the latest image Armbian 23.8.1 Bookworm with Linux 6.1.50-current-rockchip64 on the microSD for further testing and again the system remains stable, currently over 90 minutes. edit2: i didn't have to remove the motherboard from the case to look for the battery, you can remove the front cover and see the battery connector from there. The battery is not installed as described in the kobol wiki.

@going I am not quite sure if I can use my instructions from back then for the problem. Is this variant correct to change the kernel? If so which one is best to use? edit: unfortunately the switch to the following previous kernel probably didn't work, after installing the debs the image still boots from 6.1.50 ? https://mirror.yandex.ru/mirrors/armbian/apt/pool/main/l/linux-6.1.11-rockchip64/ In the root filesystem you can also see symlinks to it... root@helios64:/# ll total 64448 lrwxrwxrwx 1 root root 7 Aug 30 2020 bin -> usr/bin/ drwxr-xr-x 2 root root 4096 Mar 30 2022 boot/ drwxr-xr-x 2 root root 4096 Oct 3 01:11 dev/ drwxr-xr-x 114 root root 12288 Sep 29 02:15 etc/ drwxr-xr-x 3 root root 4096 Apr 4 2022 export/ drwxr-xr-x 5 root root 4096 Jun 10 2021 home/ lrwxrwxrwx 1 root root 41 Sep 27 01:11 initrd.img -> boot/initrd.img-6.1.50-current-rockchip64 lrwxrwxrwx 1 root root 41 Sep 27 01:11 initrd.img.old -> boot/initrd.img-6.1.50-current-rockchip64 -rwxr-xr-x 1 root root 0 Mar 21 2022 inxi* lrwxrwxrwx 1 root root 7 Aug 30 2020 lib -> usr/lib/ -rw-r--r-- 1 root root 304640 Feb 25 2023 linux-dtb-edge-rockchip64_23.02.2_arm64.deb -rw-r--r-- 1 root root 12522640 Feb 25 2023 linux-headers-edge-rockchip64_23.02.2_arm64.deb -rw-r--r-- 1 root root 53078604 Feb 25 2023 linux-image-edge-rockchip64_23.02.2_arm64.deb drwx------ 5 root root 4096 Oct 5 2020 lost+found/ drwxr-xr-x 5 root root 4096 Apr 2 2022 media/ drwxr-xr-x 2 root root 4096 Apr 2 2022 mnt/ drwxr-xr-x 4 root root 4096 Dec 2 2020 opt/ dr-xr-xr-x 2 root root 4096 Mar 30 2022 proc/ drwx------ 9 root root 4096 Sep 29 01:44 root/ drwxr-xr-x 2 root root 4096 Apr 2 2022 run/ lrwxrwxrwx 1 root root 8 Aug 30 2020 sbin -> usr/sbin/ drwxrwxr-x 2 root root 4096 Oct 5 2020 selinux/ drwxr-xr-x 6 root root 4096 Apr 3 2022 srv/ dr-xr-xr-x 2 root root 4096 Mar 30 2022 sys/ lrwxrwxrwx 1 root root 42 Sep 29 02:15 thermal_zone0 -> /sys/devices/virtual/thermal/thermal_zone0 drwxrwxrwt 2 root root 4096 Apr 2 2022 tmp/ drwxr-xr-x 12 root root 4096 Nov 27 2020 usr/ drwxr-xr-x 14 root root 4096 Oct 6 2020 var/ lrwxrwxrwx 1 root root 38 Sep 27 01:11 vmlinuz -> boot/vmlinuz-6.1.50-current-rockchip64 lrwxrwxrwx 1 root root 38 Sep 27 01:11 vmlinuz.old -> boot/vmlinuz-6.1.50-current-rockchip64 here the install log... root@helios64:/# dpkg -i *.deb Selecting previously unselected package linux-dtb-edge-rockchip64. (Reading database ... 92306 files and directories currently installed.) Preparing to unpack linux-dtb-edge-rockchip64_23.02.2_arm64.deb ... Unpacking linux-dtb-edge-rockchip64 (23.02.2) ... Selecting previously unselected package linux-headers-edge-rockchip64. Preparing to unpack linux-headers-edge-rockchip64_23.02.2_arm64.deb ... Unpacking linux-headers-edge-rockchip64 (23.02.2) ... Selecting previously unselected package linux-image-edge-rockchip64. Preparing to unpack linux-image-edge-rockchip64_23.02.2_arm64.deb ... stat: cannot statx '/proc/1/root/.': No such file or directory Unpacking linux-image-edge-rockchip64 (23.02.2) ... Setting up linux-dtb-edge-rockchip64 (23.02.2) ... Setting up linux-headers-edge-rockchip64 (23.02.2) ... Compiling headers - please wait ... grep: /proc/cpuinfo: No such file or directory Setting up linux-image-edge-rockchip64 (23.02.2) ... update-initramfs: Generating /boot/initrd.img-6.1.11-rockchip64 W: Couldn't identify type of root file system for fsck hook W: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays. W: mdadm: failed to auto-generate temporary mdadm.conf file. update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-6.1.11-rockchip64 Image Name: uInitrd Created: Tue Oct 3 01:14:25 2023 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 15116959 Bytes = 14762.66 KiB = 14.42 MiB Load Address: 00000000 Entry Point: 00000000 update-initramfs: Armbian: Symlinking /boot/uInitrd-6.1.11-rockchip64 to /boot/uInitrd '/boot/uInitrd' -> 'uInitrd-6.1.11-rockchip64' update-initramfs: Armbian: done. edit2: i have just try another kernel from here... https://mirror.yandex.ru/mirrors/armbian/apt/pool/main/l/linux-5.10.63-rockchip64/ root@helios64:/# dpkg -i *.deb dpkg: warning: downgrading linux-dtb-current-rockchip64 from 23.8.1 to 21.08.2 (Reading database ... 121330 files and directories currently installed.) Preparing to unpack linux-dtb-current-rockchip64_21.08.2_arm64.deb ... Unpacking linux-dtb-current-rockchip64 (21.08.2) over (23.8.1) ... dpkg: warning: downgrading linux-headers-current-rockchip64 from 23.8.1 to 21.08.2 Preparing to unpack linux-headers-current-rockchip64_21.08.2_arm64.deb ... Armbian 'linux-headers-current-rockchip64' for '6.1.50-current-rockchip64': 'prerm' starting. Cleaning directory /usr/src/linux-headers-6.1.50-current-rockchip64 ... Armbian 'linux-headers-current-rockchip64' for '6.1.50-current-rockchip64': 'prerm' finishing. Unpacking linux-headers-current-rockchip64 (21.08.2) over (23.8.1) ... dpkg: warning: downgrading linux-image-current-rockchip64 from 23.8.1 to 21.08.2 Preparing to unpack linux-image-current-rockchip64_21.08.2_arm64.deb ... Armbian 'linux-image-current-rockchip64' for '6.1.50-current-rockchip64': 'prerm' starting. Armbian 'linux-image-current-rockchip64' for '6.1.50-current-rockchip64': 'prerm' finishing. stat: cannot statx '/proc/1/root/.': No such file or directory Unpacking linux-image-current-rockchip64 (21.08.2) over (23.8.1) ... Armbian 'linux-image-current-rockchip64' for '6.1.50-current-rockchip64': 'postrm' starting. Armbian 'linux-image-current-rockchip64' for '6.1.50-current-rockchip64': 'postrm' finishing. Setting up linux-dtb-current-rockchip64 (21.08.2) ... Setting up linux-headers-current-rockchip64 (21.08.2) ... Compiling headers - please wait ... grep: /proc/cpuinfo: No such file or directory grep: /proc/cpuinfo: No such file or directory Setting up linux-image-current-rockchip64 (21.08.2) ... update-initramfs: Generating /boot/initrd.img-5.10.63-rockchip64 W: Couldn't identify type of root file system for fsck hook W: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays. W: mdadm: failed to auto-generate temporary mdadm.conf file. update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-5.10.63-rockchip64 Image Name: uInitrd Created: Tue Oct 3 01:42:41 2023 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 16200156 Bytes = 15820.46 KiB = 15.45 MiB Load Address: 00000000 Entry Point: 00000000 update-initramfs: Armbian: Symlinking /boot/uInitrd-5.10.63-rockchip64 to /boot/uInitrd '/boot/uInitrd' -> 'uInitrd-5.10.63-rockchip64' update-initramfs: Armbian: done. i am still a little confused about the symlinks of initrd.img, initrd.img.old, vmlinuz and vmlinuz.old which still point to 6.1.50. Should these be changed as well? Because when I look in the mounted boot directory, I see both installed kernels... root@helios64:/# ll boot/ total 128664 -rw-r--r-- 1 root root 221500 Sep 8 2021 config-5.10.63-rockchip64 -rw-r--r-- 1 root root 239553 Feb 18 2023 config-6.1.11-rockchip64 lrwxrwxrwx 1 root root 22 Oct 3 01:41 dtb -> dtb-5.10.63-rockchip64/ drwxr-xr-x 6 root root 4096 Oct 3 01:41 dtb-5.10.63-rockchip64/ drwxr-xr-x 3 root root 4096 Oct 3 01:13 dtb-6.1.11-rockchip64/ lrwxrwxrwx 1 root root 26 Oct 3 01:42 Image -> vmlinuz-5.10.63-rockchip64 -rw-r--r-- 1 root root 16200156 Oct 3 01:42 initrd.img-5.10.63-rockchip64 -rw-r--r-- 1 root root 15116959 Oct 3 01:14 initrd.img-6.1.11-rockchip64 -rw-r--r-- 1 root root 5840624 Sep 8 2021 System.map-5.10.63-rockchip64 -rw-r--r-- 1 root root 4907435 Feb 18 2023 System.map-6.1.11-rockchip64 lrwxrwxrwx 1 root root 26 Oct 3 01:42 uInitrd -> uInitrd-5.10.63-rockchip64 -rw-r--r-- 1 root root 16200220 Oct 3 01:42 uInitrd-5.10.63-rockchip64 -rw-r--r-- 1 root root 15117023 Oct 3 01:14 uInitrd-6.1.11-rockchip64 -rw-r--r-- 1 root root 28580352 Sep 8 2021 vmlinuz-5.10.63-rockchip64 -rw-r--r-- 1 root root 29295104 Feb 18 2023 vmlinuz-6.1.11-rockchip64 edit3: i seem to have managed to switch to the old kernel.... root@helios64:/# uname -a Linux helios64 6.1.50-current-rockchip64 #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 aarch64 GNU/Linux i booted from the ssd for this and did the installation directly in the running system.... root@helios64:/# dpkg -i *.deb (Reading database ... 93629 files and directories currently installed.) Preparing to unpack linux-dtb-current-rockchip64_21.08.2_arm64.deb ... Unpacking linux-dtb-current-rockchip64 (21.08.2) over (21.08.2) ... Preparing to unpack linux-headers-current-rockchip64_21.08.2_arm64.deb ... Unpacking linux-headers-current-rockchip64 (21.08.2) over (21.08.2) ... Preparing to unpack linux-image-current-rockchip64_21.08.2_arm64.deb ... Unpacking linux-image-current-rockchip64 (21.08.2) over (21.08.2) ... Setting up linux-dtb-current-rockchip64 (21.08.2) ... Setting up linux-headers-current-rockchip64 (21.08.2) ... Compiling headers - please wait ... Setting up linux-image-current-rockchip64 (21.08.2) ... update-initramfs: Generating /boot/initrd.img-5.10.63-rockchip64 update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-5.10.63-rockchip64 Image Name: uInitrd Created: Tue Oct 3 02:21:00 2023 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 16595743 Bytes = 16206.78 KiB = 15.83 MiB Load Address: 00000000 Entry Point: 00000000 update-initramfs: Armbian: Symlinking /boot/uInitrd-5.10.63-rockchip64 to /boot/uInitrd '/boot/uInitrd' -> 'uInitrd-5.10.63-rockchip64' update-initramfs: Armbian: done. Free space after deleting the package linux-image-current-rockchip64 in /boot: 3.5G root@helios64:/# root@helios64:/# ll /boot/ total 100344 lrwxrwxrwx 1 root root 26 Oct 3 02:21 Image -> vmlinuz-5.10.63-rockchip64 -rw-r--r-- 1 root root 5840624 Sep 8 2021 System.map-5.10.63-rockchip64 -rw-r--r-- 1 root root 4805119 Aug 30 18:33 System.map-6.1.50-current-rockchip64 -rw-r--r-- 1 root root 166 Oct 3 01:52 armbianEnv.txt -rw-r--r-- 1 root root 1536 Oct 15 2020 armbian_first_run.txt.template -rw-r--r-- 1 root root 38518 Oct 15 2020 boot.bmp -rw-r--r-- 1 root root 3113 Apr 2 2022 boot.cmd -rw-r--r-- 1 root root 3185 Apr 2 2022 boot.scr -rw-r--r-- 1 root root 221500 Sep 8 2021 config-5.10.63-rockchip64 -rw-r--r-- 1 root root 238929 Aug 30 18:33 config-6.1.50-current-rockchip64 lrwxrwxrwx 1 root root 22 Oct 3 02:19 dtb -> dtb-5.10.63-rockchip64/ drwxr-xr-x 6 root root 4096 Oct 3 02:18 dtb-5.10.63-rockchip64/ drwxr-xr-x 3 root root 4096 Sep 27 01:09 dtb-6.1.50-current-rockchip64/ -rw-r--r-- 1 root root 16595743 Oct 3 02:21 initrd.img-5.10.63-rockchip64 lrwxrwxrwx 1 root root 26 Oct 3 02:21 uInitrd -> uInitrd-5.10.63-rockchip64 -rw-r--r-- 1 root root 16595807 Oct 3 02:21 uInitrd-5.10.63-rockchip64 -rw-r--r-- 1 root root 28580352 Sep 8 2021 vmlinuz-5.10.63-rockchip64 -rw-r--r-- 1 root root 29792768 Aug 30 18:33 vmlinuz-6.1.50-current-rockchip64 in the time as I write this, the helios unfortunately just restarts by itself

@going Unfortunately, I have no knowledge of how to do that. Do you have something ready for me? Can I do this in 5 minutes maximum, because more time I have not yet access to the OS.