TDCroPower Posted September 27, 2023 Posted September 27, 2023 (edited) I updated my Helios64 last night and now it keeps rebooting. Every now and then it runs for a few minutes so I can log in via ssh and then it reboots all at once. Installed on the system is only OMV 6.9.1-1 (Shaitan) and Docker with the image of Emby. the system runs on an installed M.2 SSD on slot 1. 4TB WD Reds are installed in slots 2, 3 and 5. Welcome to Armbian 23.8.1 Bullseye with Linux 6.1.50-current-rockchip64 No end-user support: community creations System load: 9% Up time: 4 min Memory usage: 17% of 3.77G IP: 172.18.0.1 172.17.0.1 192.168.180.5 CPU temp: 42°C Usage of /: 7% of 117G helios@helios64:~# uname -a Linux helios64 6.1.50-current-rockchip64 #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 aarch64 GNU/Linux helios@helios64:~# helios@helios64:~# cat /etc/os-release PRETTY_NAME="Armbian 23.8.1 bullseye" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" ARMBIAN_PRETTY_NAME="Armbian 23.8.1 bullseye" the limits set for the CPU... helios@helios64:~# cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq 1416000 1800000 helios@helios64:~# cat /sys/devices/system/cpu/cpufreq/policy*/scaling_min_freq 408000 408000 helios@helios64:~# cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq 1008000 408000 does anyone have an idea where I can start looking for the error? Edited September 27, 2023 by TDCroPower 0 Quote
TijuanaKez Posted September 28, 2023 Posted September 28, 2023 Yeah, totally hosed my whole setup. Can't ssh in anymore, and the serial output seems to have stopped working so it's a pretty pink paperweight till further notice 0 Quote
TDCroPower Posted September 28, 2023 Author Posted September 28, 2023 Because I can get into the system from time to time, I can fortunately clean up or copy data away to start from scratch in the worst case. Unfortunately, I can't find any information on what the problem could be. I hope someone still gets lost here and can give us tips 0 Quote
going Posted September 28, 2023 Posted September 28, 2023 27.09.2023 в 22:30, TDCroPower сказал: does anyone have an idea where I can start looking for the error? Information on your screen. But I can't read it. Something in the core. 0 Quote
TDCroPower Posted September 28, 2023 Author Posted September 28, 2023 @going if you click on the picture you can see it in more detail, could only shoot pictures of it in a hurry. 0 Quote
phidauex Posted September 28, 2023 Posted September 28, 2023 If you setup the serial console to another machine and connect using a terminal emulator (picocom, putty, etc.), you can capture more of the crash log (and in a place where you can copy/paste). Instructions here: https://wiki.kobol.io/helios64/install/first-start/ Likewise, if you can get in long enough to edit the file, changing verbosity to 7 in /boot/armbianEnv.txt can provide more information. What I see on your photo looks similar to a crash log I captured the other day, but I'm not getting very far yet on figuring out what is actually happening. 1 Quote
TDCroPower Posted September 28, 2023 Author Posted September 28, 2023 (edited) @phidauex ah, that's right, I totally forgot, I used it to track and log the startup problems back then. I will record it and post it here.... edit: the first failed start... https://pastebin.com/3N5d0ZEv edit2: another failed start, but with verbository = 7... https://pastebin.com/m5mAacbM and after rebooting a good start... https://pastebin.com/y5HK5Csy and after a few minutes a crash and reboot... https://pastebin.com/18a8YFVc edit3: maybe we should open ticket? https://armbian.atlassian.net/jira/software/c/projects/AR/issues/?filter=allissues Edited September 29, 2023 by TDCroPower 0 Quote
TDCroPower Posted September 29, 2023 Author Posted September 29, 2023 @prahal do you have any idea what the error is? 0 Quote
going Posted September 29, 2023 Posted September 29, 2023 18 часов назад, TDCroPower сказал: edit: the first failed start... https://pastebin.com/3N5d0ZEv edit2: another failed start, but with verbository = 7... https://pastebin.com/m5mAacbM and after rebooting a good start... https://pastebin.com/y5HK5Csy and after a few minutes a crash and reboot... https://pastebin.com/18a8YFVc An ambiguous situation. I wouldn't deal with this core. Today v6.1.55. Try to build this version yourself. You must first check the correctness of the application of patches. 0 Quote
TDCroPower Posted September 30, 2023 Author Posted September 30, 2023 @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. 0 Quote
going Posted October 1, 2023 Posted October 1, 2023 11 часов назад, TDCroPower сказал: Unfortunately, I have no knowledge of how to do that. Do you have something ready for me? I always have advice for such a case. Download an image with an early kernel or\and later. Write it to the SD card and boot from it. If the operation of the device is stable, you will be able to mount your root partition from which the device is usually loaded and in the chroot environment you will be able to reinstall a stable kernel that you have tested. 1 Quote
TDCroPower Posted October 2, 2023 Author Posted October 2, 2023 (edited) @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 Edited October 3, 2023 by TDCroPower 0 Quote
going Posted October 3, 2023 Posted October 3, 2023 10 часов назад, TDCroPower сказал: 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? The fourth point should look like this: 4. $ sudo su root@helios64:~# mkdir -p /mnt/system root@helios64:~# mount /dev/mmcblk2p1 /mnt/system root@helios64:~# mount --bind /sys /mnt/system/sys root@helios64:~# mount --bind /proc /mnt/system/proc root@helios64:~# mount --bind /dev /mnt/system/dev root@helios64:~# mount --bind /dev/pts /mnt/system/dev/pts root@helios64:~# chroot /mnt/system/ .... ## install, reinstall ~# exit ## exit "chroot" ~# umount /mnt/system/dev/pts ~# umount /mnt/system/dev ~# umount /mnt/system/proc ~# umount /mnt/system/sys ~# exit ## exit "root user" If I understood correctly, booting from the system disk leads to periodic failure and reboot. But loading from the SD card does not lead to such an effect? It is important. Please confirm or refute. When loading occurs from the SD card, your raid array is not connected. The disks were just determined and they are mounted as /dev/*. The system does not access them (does not read or write). Energy consumption is at a minimum level. When booting occurs from: 27.09.2023 в 22:30, TDCroPower сказал: the system runs on an installed M.2 SSD on slot 1. 4TB WD Reds are installed in slots 2, 3 and 5. there may be short-term drawdowns of the supply voltage that lead to short-term inactivity of some chips (resetting the clock, failure of the hard disk controller ....). Your operating system at the time of reading or writing to the disk at the same time may be in the past or cannot read from the disk and as a result, the failure stack is printed, each time different. Fault repair: 1) Replace the watch battery on the board. 2) Open the power supply and look at the date of manufacture of the electrolytic capacitors of the output stage (they are the largest barrels in size). If the age is more than 5 years, replace them with new ones. 1 Quote
phidauex Posted October 3, 2023 Posted October 3, 2023 Quote Fault repair: 1) Replace the watch battery on the board. 2) Open the power supply and look at the date of manufacture of the electrolytic capacitors of the output stage (they are the largest barrels in size). If the age is more than 5 years, replace them with new ones. This is a great suggestion - I was wondering why everyone's Helios64s were starting to act up seemingly all at once, and the realtime battery is an interesting potential culprit. It is a CR1225, 3V lithium, I'll get a replacement and test mine shortly. I'll also see if I can get my scope hooked up to the power supply and subject it to some load, gradually failing original supplies could be another culprit impacting multiple people. I'm currently running 5.10.63 which I had run for a long time last year with 30 day typical uptimes, but now getting crashes and seg faults at least once a day - really suggests a hardware issue. I'll see if I can take some measurements and bring some answers... 0 Quote
TDCroPower Posted October 3, 2023 Author Posted October 3, 2023 (edited) @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/ Zitat However if your setup has the UPS battery connected, then RTC battery is not required since the RTC clock can also be kept powered by the UPS battery. 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. Edited October 3, 2023 by TDCroPower 0 Quote
going Posted October 5, 2023 Posted October 5, 2023 04.10.2023 в 00:17, TDCroPower сказал: thanks for the tutorial, i used /dev/sda1 in step 4 as it is my m.2 ssd partition. Was that not correct? The key here is to mount the system folders /dev, /sys, /proc and enter the chroot environment using the chroot command. Mount the disk you need. If there is a separate boot partition, mount it in the /mnt/system/boot folder as well. Then these commands: root@helios64:~# mount --bind /sys /mnt/system/sys root@helios64:~# mount --bind /proc /mnt/system/proc root@helios64:~# mount --bind /dev /mnt/system/dev root@helios64:~# mount --bind /dev/pts /mnt/system/dev/pts root@helios64:~# chroot /mnt/system/ As a result, you will get a full command prompt with superuser rights and any system commands for you will be executed correctly. Update the apt cache. Install, reinstall the packages, including the headers of the new\other kernel. Enable or disable system services. Recompile your custom applications..... 0 Quote
TDCroPower Posted October 5, 2023 Author Posted October 5, 2023 (edited) @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? Edited October 6, 2023 by TDCroPower 0 Quote
going Posted October 6, 2023 Posted October 6, 2023 11 часов назад, TDCroPower сказал: 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? I am not an expert on "OMV". Sorry. installation/on_debian - Use this documentation if "armbian-config" fails. 0 Quote
phidauex Posted October 6, 2023 Posted October 6, 2023 (edited) 23 hours ago, TDCroPower said: 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? In the two fresh-reinstalls I've had to do recently, I was able to install OMV successfully using their "install over Debian" method. I wasn't able to get armbian-config installs working, probably just something out of date in the script. First, get the system running stable on the clean Bullseye install, then follow these instructions (naturally skipping the part about trying armbian-config, which you already tried): https://docs.openmediavault.org/en/latest/installation/on_debian.html Edited October 6, 2023 by phidauex clarify bullseye 0 Quote
TDCroPower Posted October 7, 2023 Author Posted October 7, 2023 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. 0 Quote
going Posted October 7, 2023 Posted October 7, 2023 1 час назад, TDCroPower сказал: strange only that also an update from OMV fails. "OMV" is strictly tied to the Debian distribution version. This is written in the documentation. https://docs.openmediavault.org/en/6.x/releases.html#releases 0 Quote
TDCroPower Posted October 7, 2023 Author Posted October 7, 2023 @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. 0 Quote
phidauex Posted October 9, 2023 Posted October 9, 2023 On 10/7/2023 at 5:40 PM, TDCroPower said: 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. I think in my various experiments I tried both of those methods - the raw image without updates, and the image updated to 23.8.1. Are you running the install before or after transferring to the eMMC? I did it before, installing directly onto the SD card. Can you tell if the install is hanging due to a crash? Or just hanging but the system can be used normally from another ssh shell? 0 Quote
TDCroPower Posted October 9, 2023 Author Posted October 9, 2023 (edited) @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 Edited October 9, 2023 by TDCroPower 0 Quote
phidauex Posted October 9, 2023 Posted October 9, 2023 I'll monitor the other thread to see if I can figure anything else out, but the troubleshooting here is exceeding my skillset fast, and I got a good price on an HPE ML30 Gen10 which might replace both my NAS and my virtualization server. I'm limping the Helios64 along OK for sharing media files, but the instability means I'm not successfully running my offsite backups or my TimeMachine backups, which is really putting a time limit on the solution for me. I really want the Helios to work, it is such a cool little machine, but without OEM support I'm running out of ideas. 0 Quote
bunducafe Posted October 12, 2023 Posted October 12, 2023 Just a quick one: Accidentally updated the machine three days ago and it got stuck in a boot loop. I forgot to freeze the kernel to 5.15.93 and that's what caused the issue. I reverted back to the old kernel, froze the kernel and then did the update via OMV and everything works as expected. I know, not a real solution to the problems (I did not hook the laptop in order to get the console working) but a workaround for those who have a running backup (here with SD cards) 0 Quote
TDCroPower Posted October 12, 2023 Author Posted October 12, 2023 @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? 0 Quote
bunducafe Posted October 12, 2023 Posted October 12, 2023 vor 28 Minuten schrieb TDCroPower: 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? Freezing the kernel is easy within armbian-config. Just go to System / Security and hit Disable Kernel updates (Freeze) Yes, I often started with a blank 5.10.63 system and then performed the updates to 5.15.93 accordingly. You can also set the kernel via armbian-config first, then let the machine do it's job and afterwards you freeze the kernel and do all the updates. Meanwhile I have a bunch of "old" images here of working SD-cards that I can always revert back to. That saved my ass also in the latest update trouble. For me 5.10.63 was not entirely stable but 5.15.93 is rock solid. So I would give it a go. Also: I will probably never update the kernel anytime soon and stick to my running system. I might compile it one day with a newer kernel but this is a bit farer away as I had no success with my first attempts and do not have the time to dig deeper into that. 0 Quote
TDCroPower Posted October 12, 2023 Author Posted October 12, 2023 (edited) @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 ? Edited October 12, 2023 by TDCroPower 0 Quote
bunducafe Posted October 13, 2023 Posted October 13, 2023 vor 15 Stunden schrieb TDCroPower: 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 ? I usually run the machine between 400 and 1400 MHz ondemand governor. Yesterday it was set to full speed while performing a SnapRaid scrub... you may have to figure out what's best for your setup, but the mentioned range was the one I ran the helios64 for over 2 months without any issue whatsoever. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.