Jump to content

Helios64 unstable with 23.8.1 Bullseye and 6.1.50-current-rockchip64

TDCroPower

By TDCroPower
in Rockchip

 Share

Recommended Posts

TDCroPower

TDCroPower

Posted
Posted (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?

IMG_1911.jpg

IMG_1913.jpg

Edited by TDCroPower
0
Link to comment
Share on other sites
phidauex

phidauex

Posted
Posted

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
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted (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 by TDCroPower
0
Link to comment
Share on other sites
going

going

Posted
Posted
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
Link to comment
Share on other sites
going

going

Posted
Posted
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
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted (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 by TDCroPower
0
Link to comment
Share on other sites
going

going

Posted
Posted
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
Link to comment
Share on other sites
phidauex

phidauex

Posted
Posted
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
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted (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 by TDCroPower
0
Link to comment
Share on other sites
going

going

Posted
Posted
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
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted (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 by TDCroPower
0
Link to comment
Share on other sites
going

going

Posted
Posted
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
Link to comment
Share on other sites
phidauex

phidauex

Posted
Posted (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 by phidauex
clarify bullseye
0
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted

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
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted

@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
Link to comment
Share on other sites
phidauex

phidauex

Posted
Posted
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
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted (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 by TDCroPower
0
Link to comment
Share on other sites
phidauex

phidauex

Posted
Posted

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
Link to comment
Share on other sites
bunducafe

bunducafe

Posted
Posted

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
Link to comment
Share on other sites
bunducafe

bunducafe

Posted
Posted
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
Link to comment
Share on other sites
TDCroPower

TDCroPower

Posted
  • Author
Posted (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...

ChangeKernel.thumb.png.36b4ced8ff53a6795775f4d906e42b9f.png

 

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 by TDCroPower
0
Link to comment
Share on other sites
bunducafe

bunducafe

Posted
Posted
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
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept