Search the Community

Hi, I use Helios64 from the begin and this board is very unstable according to my experience and many posts here... After many dialogue here and settings shared about Frequency and Governor Kernel... maybe i find the problem and i ask anyone return of experiences about the procedure and setting belong: - Connect USB Wireless Dongle or USB(-c) Ethernet Plug - Configure it - Disconnect all ethernet cable to the board - Use with last time crash configuration and do a endurance test your helios64 board Have a good day

Dear to all, I have a Helios64 unit with 2 hdd (both WD60EFRX). I have bought also an external enclousure UGREEN 5 Bay Hard Drive Enclosure ( https://eu.ugreen.com/collections/hard-drive-enclosures/products/ugreen-5-bay-hard-drive-enclosure-5-x-18tb-raid-array-hard-disk-docking-station ) and 2 WD140EDGZ and these 2 hdd are mounted inside UGREEN enclousure because I want format and test it (when all will work fine I'll exchange a WD60EFRX with a WD140EDGZ so the drives inside the enclousure will have a backup scope). The enclousure is powered by external adapter, the system image installed is the Armbian 22.02.1 with Linux kernel 5.15.93-rockchip 64 and openmediavault 6.6.0-2 (Shaitan). If I have the enclousure turned off and from open media vault access to smart drive section (storage -> S.M.A.R.T. -> device section), the smart information (related to the 2 WD60EFRX) are showed in about 4-5 seconds but if I turn on the enclousure with the 2 device WD140EDGZ , the smart drive section is showed after 4 minutes. Sometimes the section isn't showed but it's showed an error message "Http failure response for http://192.168.1.44/rpc.php: 504 Gateway Time-out". I'm sure that this problem occur also with the transfer of files (hoping that doesn't occur wrong data information transfer with damaged files also) and I have already googled for this issue on the web but I haven't found nothing that help me to solve the issue. I attach here the 2 dmesg output that I have take from 2 distinct session with putty dmesg of first session dmesg of second session my question is: the problem it's related from standard drivers inside the image, from the kernel or it's necessary take manufacturer driver source and compile it? How can I solve this issue? Hope that somebody help me Best regards

Hi, Today i make upgrade to 23.11 armbian on my Helios64. It's in bookworm version (apt source list is good, no change since 23.08) but now it display this: Welcome to Armbian 23.11.1 Buster with Linux 6.1.63-current-rockchip64 No end-user support: community creations & unsupported (buster) userspace! it's a bug? thank have a nice day

Hello everyone, I would like to know which version of Armbian is recommended to install today to have a stable system ? Indeed, I have reset all my data on my Helios64 and I want perform a fresh install. I do not made any hardware change on my Helios64 and I plan to use OMV6. Thanks all for advices Flolm

Hello everyone, I would like to know which version of Armbian is recommended to install today to have a stable system ? Indeed, I have reset all my data on my Helios64 and I want perform a fresh install. I do not made any hardware change on my Helios64 and I plan to use OMV6. Thanks all for advices Flolm

[ 184.130515] Internal error: Oops - Undefined instruction: 0000000002000000 [#1] PREEMPT SMP [ 184.131281] Modules linked in: rfkill lz4hc lz4 snd_soc_hdmi_codec snd_soc_rockchip_i2s rockchip_vdec(C) hantro_vpu v4l2_vp9 leds_pwm gpio_charger videobuf2_dma_contig pwm_fan rockchip_rga panfrost videobuf2_dma_sg v4l2_h264 gpu_sched v4l2_mem2mem snd_soc_core drm_shmem_helper snd_compress rockchip_rng rng_core snd_pcm_dmaengine videobuf2_memops snd_pcm videobuf2_v4l2 videobuf2_common snd_timer videodev snd soundcore mc zram binfmt_misc gpio_beeper cpufreq_dt ledtrig_netdev lm75 dm_mod ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod r8152 cdc_ncm cdc_ether usbnet realtek fusb302 tcpm typec dwmac_rk stmmac_platform stmmac pcs_xpcs adc_keys [ 184.137145] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G C 6.1.36-rockchip64 #3 [ 184.137890] Hardware name: Helios64 (DT) [ 184.138243] pstate: 000003c5 (nzcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 184.138866] pc : debug_smp_processor_id+0x28/0x2c [ 184.139305] lr : ct_nmi_enter+0x68/0x1a4 [ 184.139663] sp : ffff800009cabb90 [ 184.139963] x29: ffff800009cabb90 x28: ffff000000761e00 x27: 0000000000000000 [ 184.140608] x26: ffff80000901a180 x25: ffff8000093d9e80 x24: 0000000000000001 [ 184.141251] x23: ffff8000099cdc70 x22: ffff0000f777e8f0 x21: ffff8000094797a8 [ 184.141893] x20: 0000000096000007 x19: ffff8000096f68f0 x18: ffff800010813c58 [ 184.142534] x17: ffff8000ee088000 x16: ffff800009ca8000 x15: 0000000000000001 [ 184.143176] x14: 0000000000000000 x13: 00000000000002da x12: 000000000041a201 [ 184.143818] x11: 0000000000000040 x10: ffff000000404470 x9 : ffff000000404468 [ 184.144459] x8 : ffff0000008004b8 x7 : 0000000000000000 x6 : 000000001b4110bc [ 184.145100] x5 : ffff800009cabc60 x4 : 0000000000010002 x3 : ffff8000096e7008 [ 184.145741] x2 : ffff000000761e00 x1 : ffff800009415a68 x0 : 0000000000000004 [ 184.146382] Call trace: [ 184.146606] debug_smp_processor_id+0x28/0x2c [ 184.147004] ct_irq_enter+0x10/0x1c [ 184.147326] enter_from_kernel_mode+0x28/0x74 [ 184.147720] el1_abort+0x24/0x64 [ 184.148016] el1h_64_sync_handler+0xd8/0xe4 [ 184.148397] el1h_64_sync+0x64/0x68 [ 184.148715] update_curr+0x84/0x1fc [ 184.149040] enqueue_entity+0x16c/0x32c [ 184.149387] enqueue_task_fair+0x84/0x3e0 [ 184.149749] ttwu_do_activate+0x78/0x164 [ 184.150106] sched_ttwu_pending+0xec/0x1e0 [ 184.150480] __flush_smp_call_function_queue+0xec/0x254 [ 184.150949] generic_smp_call_function_single_interrupt+0x14/0x20 [ 184.151494] ipi_handler+0x90/0x350 [ 184.151816] handle_percpu_devid_irq+0xa4/0x230 [ 184.152227] generic_handle_domain_irq+0x2c/0x44 [ 184.152648] gic_handle_irq+0x50/0x130 [ 184.152991] call_on_irq_stack+0x24/0x4c [ 184.153349] do_interrupt_handler+0xd4/0xe0 [ 184.153730] el1_interrupt+0x34/0x6c [ 184.154058] el1h_64_irq_handler+0x18/0x2c [ 184.154430] el1h_64_irq+0x64/0x68 [ 184.154738] arch_cpu_idle+0x18/0x2c [ 184.155065] default_idle_call+0x38/0x17c [ 184.155428] do_idle+0x23c/0x2b0 [ 184.155727] cpu_startup_entry+0x24/0x30 [ 184.156085] secondary_start_kernel+0x124/0x150 [ 184.156496] __secondary_switched+0xb0/0xb4 [ 184.156882] Code: 9107c000 97ffffb0 a8c17bfd d50323bf (d65f03c0) [ 184.157427] ---[ end trace 0000000000000000 ]--- [ 184.157841] Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt [ 184.158632] SMP: stopping secondary CPUs [ 184.158993] Kernel Offset: disabled [ 184.159307] CPU features: 0x20000,20834084,0000421b [ 184.159745] Memory Limit: none [ 184.160030] ---[ end Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt ]--- This is getting more and more frequent -- the CPU changes but mostly it is 4 or 5 I have no idea as to where to start/what to do next - So I came here... a friend at work says the boards should be cheap enough - buy a new one --- I don't seem to be able to find a source for this particular board... I think it is a custom "tinkerboard" overall this is/was the Helios64 NAS which Worked rocksolid -- until it didn't I can't remember if I updated the OS and then it started failing -- or what -- at the moment - it is running whatever was the latest 2 weeks ago... above is the dump it leaves when it crashes - I have the board out of the cast and on my test desk -- when it does boot -- ( if / when ) --- I shell into it -- if it stays up - I run BTOP after whatever length of time -- I try to shell in for a second session - and try to run armbian-config don't often get this far... help? if asked I can provide the boot sequence text... Rich Leonard

After happily using my helios64 with armbian buster for years I finally dared to upgrade and everything went smoothly. I found instructions somewhere here in this forum and this is what I did. I first commented out /etc/apt/sources.list.d/armbian.list Then I upgraded to bullseye by replacing everything buster with bullseye in /etc/apt/sources.list (I think I also had to change the url to the security repo) Then I did apt-get update && apt full-upgrade and rebooted. Great success! Then the same for bookworm and again great success. Then reenabled the armbian apt repo with bookworm. again full-upgrade, reboot and again great success. Now I have kernel 6.1.50-current-rockchip64 Now the thing I don't understand: When I ssh to the machine it still lists buster and /etc/armbian-release is untouched. I checked a bit and /etc/armbian-release is part of linux-buster-root-current-helios64 on my system which sounds suspicious. The package seems to contain super integral parts of the system. udev rules, systemd rules etcpp. and is still installed. I don't see an obvious replacement for it. Can somebody shed some light on it? What did I miss?

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?

Hi, I've got a Helios64 device running with OpenMediaVault 6.9.2-1 (Shaitan). kobol@helios64:~$ uname -a Linux helios64 6.1.50-current-rockchip64 #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 aarch64 GNU/Linux It has been stable until I recently install openmediavault-photoprism 6.0.9-1 plugin provided by OMV6 through a podman container. I want to use PhotoPrism to help categorize my photos. The issue is my device systematically reboots during photo folder initial scan: the scan actually loads the system a lot, and in this state of activities, a reboot occurs after about 30 minutes to 4 hours. I first thought of a CPU temperature issue, it seems stabilized at about 64°C. But then, I caught the last journal entry before SSH disconnection: Oct 06 14:17:37 helios64 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Oct 06 14:17:37 helios64 kernel: rcu: 4-...0: (0 ticks this GP) idle=5b4c/1/0x4000000000000000 softirq=564112/564112 fqs=3016 Oct 06 14:17:37 helios64 kernel: (detected by 1, t=15005 jiffies, g=827657, q=216 ncpus=6) Oct 06 14:17:37 helios64 kernel: Task dump for CPU 4: Oct 06 14:17:37 helios64 kernel: task:photoprism state:R running task stack:0 pid:4761 ppid:4235 flags:0x00000802 Oct 06 14:17:37 helios64 kernel: Call trace: Oct 06 14:17:37 helios64 kernel: __switch_to+0xf0/0x170 Oct 06 14:17:37 helios64 kernel: 0xffff80001186bca8 Oct 06 14:17:37 helios64 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Oct 06 14:17:37 helios64 kernel: rcu: 4-...0: (0 ticks this GP) idle=5b4c/1/0x4000000000000000 softirq=564112/564112 fqs=12017 Oct 06 14:17:37 helios64 kernel: (detected by 3, t=60010 jiffies, g=827657, q=445 ncpus=6) Oct 06 14:17:37 helios64 kernel: Task dump for CPU 4: Oct 06 14:17:37 helios64 kernel: task:photoprism state:R running task stack:0 pid:4761 ppid:4235 flags:0x00000802 Oct 06 14:17:37 helios64 kernel: Call trace: Oct 06 14:17:37 helios64 kernel: __switch_to+0xf0/0x170 Oct 06 14:17:37 helios64 kernel: 0xffff80001186bca8 Oct 06 14:17:37 helios64 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Oct 06 14:17:37 helios64 kernel: rcu: 4-...0: (0 ticks this GP) idle=5b4c/1/0x4000000000000000 softirq=564112/564112 fqs=21018 Oct 06 14:17:37 helios64 kernel: (detected by 3, t=105015 jiffies, g=827657, q=681 ncpus=6) Oct 06 14:17:37 helios64 kernel: Task dump for CPU 4: Oct 06 14:17:37 helios64 kernel: task:photoprism state:R running task stack:0 pid:4761 ppid:4235 flags:0x00000802 Oct 06 14:17:37 helios64 kernel: Call trace: Oct 06 14:17:37 helios64 kernel: __switch_to+0xf0/0x170 Oct 06 14:17:37 helios64 kernel: 0xffff80001186bca8 So, I draw a link (possibly wrong) between PhotoPrism preempting the computing power, and the device shuting down. The system then starts again on watchdog signal and boots without issue. My last test was to have the system running with PhotoPrism plugin active, however without scanning activities. At this low workload, the system didn't reboot for the 4 days I let it. Have you got any clue on how I can confirm such preempt signal may cause a system shutdown?

Hello, after some u-boot test, my helios64 don't start the bootloader stage. I can etablish a serial connection on USB Type-c port, but when I tried to start the system, I have no output on it. After I disconnected everything : - I connect usb-c cable, I'm able to connect to serial console with picocom - I connect the power cable, The LED1 (System Rail Power) is on, and the LED9 (Battery Status) flashes. - I press the power botton (without sdcard) : - LED2 and LED3 (Periph. Rail Power and HDD Rail Power) are on - LED4 and LED5 (System ON and HDD Activity) are on. - nothing happen on serial console - If I keep SWI (power botton pressed 5 seconds, i'm able to shutdown the system. I also follow the process of Maskrom Mode (https://wiki.kobol.io/helios64/maskrom/) with success, with no difference at end. > $ sudo tools/rkdeveloptool db rk3399_loader_v1.24_RevNocRL.126.bin > Downloading bootloader succeeded. > $ sudo tools/rkdeveloptool wl 0 /mnt/astav/distrib/Helios64/Armbian_21.05.1_Helios64_buster_current_5.10.35.img > Write LBA from file (100%) > $ sudo tools/rkdeveloptool rd > Reset Device OK. Questions : - What is the role of SPI Flash in the boot process ? - Does the SPI Flash can be erased ? And if yes, this can be affect the boot process ? - Can we supposed to be able to boot the armbian image writen on sd-card with SPI FLash skipped from the boot ? (with P11 jumper closed) - Could the Maskmode procedure help me, or allow me to repair my card ? - u-boot TPL is supposed to be writed on armbian sdcard ? - armbian image (like Armbian_21.05.1_Helios64_buster_current_5.10.35.img) are supposed to be able to boot, even when SPI and eMMc boot are skipped ? Thank you in advance for any help you can give me

I have the Helios64 NAS and am now at the point where I'll either get it working or toss it out and get something else.... it boots and runs and stops most of the time let's get some of the basics out of the way so we can figure out if here is the "best" spot to get help... uname -a returns root@helios64:/home/rmleonard# uname -a Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux cat /etc/os-release root@helios64:/home/rmleonard# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ( I have tried the most current versions of the downloads and it still does about the same) I hope that is enough to help start a conversation.. Rich Leonard

Hello, with the last kernel update I have untimely reboot of my nas. some info : hardware : helios64 os : armbian bullseye based with openmediavault 6 on top kernel : armbian-bsp-cli-helios64-current:arm64 23.8.1 before the update to armbian-bsp-cli 23.8.1 the system have some unexpected restarts, but less than 1 by day. With last version, the system restarts itself sometime only few minutes after the start. With a debug console, I got the following kernel panic : [ 510.791607] Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP [ 510.792174] Modules linked in: xt_nat xt_tcpudp veth xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge rfkill quota_v2 quota_tree snd_soc_hdmi_codec snd_soc_rockchip_i2s snd_soc_core hantro_vpu rockchip_vdec(C) snd_compress v4l2_vp9 leds_pwm videobuf2_dma_contig rockchip_rga v4l2_h264 videobuf2_dma_sg v4l2_mem2mem videobuf2_memops snd_pcm_dmaengine pwm_fan snd_pcm videobuf2_v4l2 gpio_charger videobuf2_common snd_timer videodev panfrost gpu_sched snd mc drm_shmem_helper rockchip_rng rng_core soundcore fusb302 sg tcpm typec lz4hc lz4 gpio_beeper cpufreq_dt zram softdog ledtrig_netdev lm75 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 raid10 raid0 multipath linear raid1 dm_raid raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx md_mod dm_mod realtek dwmac_rk stmmac_platform stmmac pcs_xpcs adc_keys [ 510.800061] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G C 6.1.50-current-rockchip64 #3 [ 510.800866] Hardware name: Helios64 (DT) [ 510.801219] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 510.801840] pc : ct_kernel_enter.constprop.0+0xb8/0x180 [ 510.802323] lr : ct_kernel_enter.constprop.0+0xa8/0x180 [ 510.802794] sp : ffff800009eebd80 [ 510.803094] x29: ffff800009eebd80 x28: 0000000000000000 x27: 0000000000000000 [ 510.803739] x26: ffff000000761e00 x25: ffff800009474298 x24: ffff800009a3dc70 [ 510.804382] x23: fffe800100ee71e0 x22: ffff8000097668f0 x21: ffff8000094ea818 [ 510.805023] x20: 0000000000000000 x19: ffff8000097668f0 x18: 0000000000000000 [ 510.805664] x17: 0000000000000000 x16: ffff0000f7765f00 x15: 0000000000000000 [ 510.806306] x14: 0000000000000001 x13: 00000000000001ef x12: 0000000000000001 [ 510.806946] x11: 0000000000000000 x10: 0000000000000a90 x9 : ffff800009eebd50 [ 510.807587] x8 : ffff0000007628f0 x7 : 0000000000000000 x6 : 00000002f5f32d3a [ 510.808228] x5 : 00ffffffffffffff x4 : 0000000000152374 x3 : ffff800009757008 [ 510.808870] x2 : ffff000000761e00 x1 : ffff8000094868b0 x0 : 0000000000000001 [ 510.809510] Call trace: [ 510.809733] ct_kernel_enter.constprop.0+0xb8/0x180 [ 510.810177] ct_idle_exit+0x1c/0x30 [ 510.810498] default_idle_call+0x48/0x17c [ 510.810864] do_idle+0x23c/0x2b0 [ 510.811164] cpu_startup_entry+0x28/0x30 [ 510.811521] secondary_start_kernel+0x124/0x150 [ 510.811934] __secondary_switched+0xb0/0xb4 [ 510.812322] Code: f8605b00 b8606ac4 d503201f d2800020 (f90006e0) [ 510.812868] ---[ end trace 0000000000000000 ]--- [ 510.813283] Kernel panic - not syncing: Attempted to kill the idle task! [ 510.813877] SMP: stopping secondary CPUs [ 510.814234] Kernel Offset: disabled [ 510.814548] CPU features: 0x40000,20834084,0000421b [ 510.814987] Memory Limit: none [ 510.815273] Rebooting in 90 seconds.. Someone have ideas to have this fixed ? Where to report this problem ? Where to have help to get more informations ? Thank you Note : I have some programming skilled (and debugging), but no kernel development experience.

Dear to all, I'm new on linux environment so be patience with me. I have a helios64 unit with installed Openmediavault 6. When I reboot or turn-off helios64 (both from webgui interface that from power button) the hard disk ( 2 wd60efrx) make a cute sound from head. How can I check that heads are parked correctly? I don't want damage my hard disks Best regards

So I did the upgrade to OMV6 (and associated kernel update Linux 5.15.93-rockchip64). Now in the mornings or after long periods of no interaction, the Helios enters an unresponsive state where none of the docker containers respond and I can no longer ssh in. There is still some sporadic noise comming from hard drives doing things and lights on the front are showing it's not completely frozen. I suspect it's attempting to enter some kind of suspend / hibernate state that is not appropriate for this system. Which would be the appropriate log file to go hunting for answers for sleep/hibernate issues on Armbian? And what would be the recommended way to configure the available sleep options? Thanks.

Dear Forum, I am using a Helios64 with armbian Debian 10 (Buster) Linux-Kernel 5.15.52 and OMV 5.6.26-1. If I want to have further Updates from OMV I need to upgrade to Debian 11, because OMV6 isn't compatible to Buster. Any recomendations how I should upgrade? The H64-System is on a SDD. Should I try a cli system upgrade or installing everything new with a bullseye image, if this is available (Where?)? Best wishes, Greg

Hi, I had to change the Rack 1 HDD because I got an email telling me that this disk was broken. So I ordered new discs to make my replacement. When I put my new disk my problem started. For information my old disk was perfectly visible before I changed it and the led was functional too. I have a strange problem and I'm afraid it's hardware. Currently I have Rack 1 (HDD 1) which no longer detects my disks, there are no more LEDs lighting up, we can clearly hear the HDD lighting up, but it is not visible in the CLI and not via the WebUI. Im using OMV 6.x with kernel 5.15.89 (current) stable RAID 6 with 5 x 8To Have try 2 new HDD in Rack 1 KO Have try to reinstall armbian & omv KO Have you ever had this problem ? Could it be a software problem? Screens : (Only 4 HDD missing /dev/sde) armbianmonitor : http://ix.io/4oQB dmesg : https://paste.yunohost.org/sefecotame.vbs lsblk : "/dev/sde" is missing sda 8:0 0 7.3T 0 disk └─md127 9:127 0 21.8T 0 raid6 sdb 8:16 0 7.3T 0 disk └─md127 9:127 0 21.8T 0 raid6 sdc 8:32 0 7.3T 0 disk └─md127 9:127 0 21.8T 0 raid6 sdd 8:48 0 7.3T 0 disk └─md127 9:127 0 21.8T 0 raid6 Best Regards

Getting free() invalid pointer issue when installing / using python3. Could be dpkg issue as well ! When I did sudo apt update && sudo apt upgrade, it happened and hence I tried to reinstall. This issue occurs when trying to manage it with ansible as well. I think something might be wrong with the latest python. Board: Helios64 (I know, I know CSC) Chipset: RK3399 Apt install logs: Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not upgraded. Need to get 0 B/472 kB of archives. After this operation, 0 B of additional disk space will be used. (Reading database ... 44574 files and directories currently installed.) Preparing to unpack .../python3-pkg-resources_59.6.0-1.2ubuntu0.22.04.1_all.deb ... double free or corruption (out) Aborted dpkg: warning: old python3-pkg-resources package pre-removal script subprocess returned error exit status 134 dpkg: trying script from the new package instead ... dpkg: ... it looks like that went OK Unpacking python3-pkg-resources (59.6.0-1.2ubuntu0.22.04.1) over (59.6.0-1.2ubuntu0.22.04.1) ... Preparing to unpack .../python3-setuptools_59.6.0-1.2ubuntu0.22.04.1_all.deb ... Unpacking python3-setuptools (59.6.0-1.2ubuntu0.22.04.1) over (59.6.0-1.2ubuntu0.22.04.1) ... Setting up python3-pkg-resources (59.6.0-1.2ubuntu0.22.04.1) ... Setting up python3-setuptools (59.6.0-1.2ubuntu0.22.04.1) ... free(): invalid pointer Aborted dpkg: error processing package python3-setuptools (--configure): installed python3-setuptools package post-installation script subprocess returned error exit status 134 Errors were encountered while processing: python3-setuptools E: Sub-process /usr/bin/dpkg returned an error code (1) Ansible logs: ansible_facts: {} failed_modules: ansible.legacy.setup: ansible_facts: discovered_interpreter_python: /usr/bin/python3 failed: true module_stderr: |- free(): invalid pointer Aborted module_stdout: '' msg: |- MODULE FAILURE See stdout/stderr for the exact error rc: 134 msg: |- The following modules failed to execute: ansible.legacy.setup

Hello, when i installed the helios64 initially i had the problem with the fans spinning at 100% (or really loud) and i solved it somehow. It was working fine with the fans spinning for one second when starting and shutting down the device. Now i finally updated the NAS with sudo apt update sudo apt upgrade sudo omv-release-upgrade sudo reboot and after the reboot the fans are now spinning really loud again all the time. Is anyone aware of an easy solution or a quick fix? Someone else had the same problem at https://forum.openmediavault.org/index.php?thread%2F42550-fans-go-on-full-and-stay-there-after-doing-an-update-in-omv-web-control-panel-he%2F= but it seems he either did not solve it or he just forgot to report back. I'm not sure if is related to my problem. alking about changing the fans but mentions the PWM Fan control again. On reddit someone mentions these settings again. I checked and my fancontrol settings seem to be identically or pretty close. In another reddit thread it was mentioned to "I went to armbian-config => System => CPU, set minimum and maximum CPU speed at 1200000 and set "governor" to "performance".". But its just "Fan too loud" and not "Fan spinning at 100%" So, i wanted to ask you guys if you know a fix for that problem 😕

Fresh build edge bullseye image with kernel Linux helios 5.18.0-rockchip64 #trunk SMP PREEMPT Sun May 29 20:19:27 EEST 2022 aarch64 GNU/Linux fancontrol not work, because there no /dev/fan devices How to get fancontrol back to work?

Dear to all, I'm not expert. How can I add kernel header of zfs to linux kernel 5.15.80-rockchip64? I have run the command "apt install dkms zfs-dkms" and I've got the following output: Reading package lists... Done Building dependency tree... Done Reading state information... Done dkms is already the newest version (2.8.4-3). Suggested packages: debhelper Recommended packages: zfs-zed zfsutils-linux linux-libc-dev The following NEW packages will be installed: zfs-dkms 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 2297 kB of archives. After this operation, 18.0 MB of additional disk space will be used. Do you want to continue? [Y/n] Y Get:1 http://httpredir.debian.org/debian bullseye-backports/contrib arm64 zfs-dk ms all 2.1.6-3~bpo11+1 [2297 kB] Fetched 2297 kB in 0s (5427 kB/s) Preconfiguring packages ... Selecting previously unselected package zfs-dkms. (Reading database ... 78864 files and directories currently installed.) Preparing to unpack .../zfs-dkms_2.1.6-3~bpo11+1_all.deb ... Unpacking zfs-dkms (2.1.6-3~bpo11+1) ... Setting up zfs-dkms (2.1.6-3~bpo11+1) ... Loading new zfs-2.1.6 DKMS files... Building for 5.15.80-rockchip64 Building initial module for 5.15.80-rockchip64 Done. zavl.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ znvpair.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ zunicode.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ zcommon.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ zfs.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ icp.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ zlua.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ spl.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ zzstd.ko.xz: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.15.80-rockchip64/updates/dkms/ depmod...... DKMS: install completed. Processing triggers for initramfs-tools (0.140) ... update-initramfs: Generating /boot/initrd.img-5.15.80-rockchip64 update-initramfs: Converting to u-boot format if I try to execute "apt install zfsutils-linux" I've got Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: zfsutils-linux : Depends: libnvpair3linux (= 2.1.6-3~bpo11+1) but 2.1.2-1~20.04.york0 is to be installed Depends: libuutil3linux (= 2.1.6-3~bpo11+1) but 2.1.2-1~20.04.york0 is to be installed Depends: libzfs4linux (= 2.1.6-3~bpo11+1) but 2.1.2-1~20.04.york0 is to be installed Depends: libzpool5linux (= 2.1.6-3~bpo11+1) but 2.1.2-1~20.04.york0 is to be installed E: Unable to correct problems, you have held broken packages. Moreover here https://forum.openmediavault.org/index.php?thread/45376-zfs-version/ ryecoaaron has told me "you really need to make sure the kernel headers are installed first. Then install zfs-dkms. Then install the plugin." How can I install prerequisite so after I can install omv6 zfs plugin also? p.s.1: omv6 zfs-armhf should be installed only in 32 bit instruction set of arm? p.s.2: to mod: if section if thread is wrong please move to right section.

Hi there ... Not sure if anyone has an idea here, but I have the following topic: I have a helios64, equipped with 3 2.5" disk drives, running Debian 10 with Kernel 5.10.43. Usually the system runs stable ... even for days (24/7). But every now and then the disks "fail" - which means, during normal operation suddenly the disk turn of, linux reports "sata link down" ... and the disks are off. As if they were removed. If I reboot I usually here only some "klicks" ... I assume the disks try to spin up, but fail due to not enough power (?). To recover from that situation, I usually disconnect power (incl. the internal UPS) ... try a few times, and sooner or later disks power successfully up again. Then the system run's again for a while without any issues. I already tried to re-cable everything, trying to ensure that the cables are properly connected, but this does not seem to help. I assume that there is an hardware issue with the SATA power rails (both show the same effect). For that reason I'm looking for the schematics, to trace that a little deeper ... anyone an idea if they are somewhere available? Thanks!

Hello, I have recently bought a Helios64 item. I have mounted it, I have done all steps written on wiki here https://wiki.kobol.io/helios64/kit/ and here https://wiki.kobol.io/helios64/install/sdcard/ but when I try to follow this steps https://wiki.kobol.io/helios64/install/first-start/ USB to serial bridge is not detected by my notebooks (I have tried with notebook 1 (windows10 x64 with drivers downloaded and installed with exe setup) and notebook 2 (x86 cpu with last kernel ubuntu and windows xp)). I have unmounted the backplane cover, jumper P10, P11 and P13 (see here jumper description https://wiki.kobol.io/helios64/jumper/ ) are all opened so my question is: what is the problem? p.s. 1: When I have followed this step https://wiki.kobol.io/helios64/install/sdcard/ when i plug the power connector automatically system has booted without that I press power bottom (in the link at step 4 is written "Don't power-up the Power Adapter yet") ... something has been happened that cause the not detection on my notebooks? p.s. 2: the USB to serial bridge can be detected from notebooks with system that is turn off with only plug power connector plugged (with only LED1 lighted https://wiki.kobol.io/helios64/led/)? I make this question because here https://www.youtube.com/watch?v=58coL23Bzzw the dude first turn on helios 2:05, after when is linked with usb and execute picocom command helios is turn off 2:08 and finally he turn on Helios device 2:10 p.s. 3: when I realize that the USB to serial bridge isn't detected by my notebook, I turn off the device from power button. Sometimes is necessary only press button for 1 second and device is turn off, other times I press button for 5 seconds... but in the last case I hear a whistle... something can be damaged in the second scenario? p.s. 4: if I must buy jumper shorting, the spec of 2.54 mm is right? Hoping that somebody help me Best regards