Search the Community

After a recent update to non-kernel stuff, my Helios64 will no longer boot. When attempting to, I get this error: [ 32.425508] xhci-hcd xhci-hcd.3.auto: Host halt failed, -110 [ 35.019496] xhci-hcd xhci-hcd.3.auto: Host halt failed, -110 [ 35.020028] xhci-hcd xhci-hcd.3.auto: Host controller not halted, aborting reset. I had been using the eMMC on board to boot with the SD card as a backup, but now neither one is working. Anyone know if there's a way to fix this? Here's more, using verbosity=4 in the armbianEnv.txt.

Hello, I received recently an Helios64 from a new friend, However, when I get home, I plug it in, turn it on (already I have to press the power button for 4 seconds to get some life) and I get the following LEDs lit up: - LED1 - LED2 - LED3 - LED5 - LED6 i got nothing on the serial line (tested on MacOS and Windows), and no reaction when I do quick and long press on Recovery nor Reset. Is there some electronic schematic that could help me to debug hardware or procedure to get JTAG access to the RK3399 ? Regards,

Hey guys. I have helios64 with 5x WD14tb red pro.... and ZFS fs. but currently im out of free space I want to extend somehow my storage pool. I'm wonder if it's possible to buy additional storage enclosure like from QNAP ( TL-D800C) - JBOD 1 x USB 3.2 Gen 2 type C and put additional 8x HDD I wanted to create additional ZFS pool raidz1 Do You think it will work?

Not sure if this is the place for this since it isn't really a software issue, but... So I decided to take apart my Helios64 to apply the 2.5Gb/1Gb Ethernet fix and things went badly. I ended up accidentally destroying the 402 caps on one of the SATA ports by scrapping the board against the standoffs as I was pulling it out of the case. As far as I can tell, they should be part of the SATA standard, 10nF DC blocking caps, so I have a rough idea of what they might have been but I don't know for sure since they are simply gone. Does anyone happen to know what those caps were or have access to a circuit diagram or BOM I could reference? It would be nice to replace them with the original part number. I did find the information for the Helios4, but I don't know if those are the same and that exact part seems impossible to get anyway. Thanks for reading.

even though I disabled DVFS : $ cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR=conservative MAX_SPEED=1416000 MIN_SPEED=1416000 I had a few random reboot. I disabled zswap and , since I get this kind of trace about it: mars 30 22:15:29 helios64 kernel: ------------[ cut here ]------------ mars 30 22:15:29 helios64 kernel: kernel BUG at mm/zswap.c:1313! mars 30 22:15:29 helios64 kernel: Internal error: Oops - BUG: 0 [#1] PREEMPT SMP mars 30 22:15:29 helios64 kernel: Modules linked in: binfmt_misc softdog veth xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter br_netfilter bridge governor_performance aufs zram quota_v2 quota_tree ftdi_sio r8152 usbserial snd_soc_hdmi_codec leds_pwm snd_soc_rockchip_i2s snd_soc_rockchip_pcm gpio_charger pwm_fan snd_soc_core panfrost gpu_sched snd_pcm_dmaengine snd_pcm snd_timer snd hantro_vpu(C) soundcore rockchip_vdec(C) rockchip_rga rockchip_iep v4l2_h264 fusb302 videobuf2_dma_contig sg videobuf2_vmalloc v4l2_mem2mem videobuf2_dma_sg tcpm videobuf2_memops videobuf2_v4l2 videobuf2_common typec videodev mc gpio_beeper cpufreq_dt nfsd dm_mod auth_rpcgss nfs_acl lockd grace sunrpc ledtrig_netdev lm75 ip_tables x_tables autofs4 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear realtek raid10 uas dwmac_rk stmmac_platform mars 30 22:15:29 helios64 kernel: md_mod stmmac pcs_xpcs adc_keys mars 30 22:15:29 helios64 kernel: CPU: 4 PID: 3214 Comm: containerd-shim Tainted: G C 5.15.29-rockchip64 #trunk.0010 mars 30 22:15:29 helios64 kernel: Hardware name: Helios64 (DT) mars 30 22:15:29 helios64 kernel: pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) mars 30 22:15:29 helios64 kernel: pc : zswap_frontswap_load+0x320/0x330 mars 30 22:15:29 helios64 kernel: lr : zswap_frontswap_load+0x218/0x330 mars 30 22:15:29 helios64 kernel: sp : ffff80000e363b10 mars 30 22:15:29 helios64 kernel: x29: ffff80000e363b10 x28: 000000000000094b x27: ffff0000f5526080 mars 30 22:15:29 helios64 kernel: x26: ffff800009b3d700 x25: 0000000000002690 x24: 00000000ffffffea mars 30 22:15:29 helios64 kernel: x23: ffff00000f2e9980 x22: ffff00000f2e9988 x21: ffff8000094f49c8 mars 30 22:15:29 helios64 kernel: x20: fffffbffeffcb170 x19: ffff00003319e4d0 x18: 00000000000000ff mars 30 22:15:29 helios64 kernel: x17: 00000000ffffffff x16: 0000000000000001 x15: 5165ca840ace4dcb mars 30 22:15:29 helios64 kernel: x14: ffff80000b7e257e x13: ffff80000b7e257e x12: 0000000000000001 mars 30 22:15:29 helios64 kernel: x11: ffff80000b08d6ad x10: 000000000000000b x9 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x8 : 0000000000000209 x7 : ffff80000e363a70 x6 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x5 : 0000000000000001 x4 : 0000000000000030 x3 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x2 : 0000000000000000 x1 : ffff000004f50e80 x0 : 0000000100000000 mars 30 22:15:29 helios64 kernel: Call trace: mars 30 22:15:29 helios64 kernel: zswap_frontswap_load+0x320/0x330 mars 30 22:15:29 helios64 kernel: __frontswap_load+0x88/0x168 mars 30 22:15:29 helios64 kernel: swap_readpage+0x1a8/0x3c0 mars 30 22:15:29 helios64 kernel: do_swap_page+0x4e0/0x6c8 mars 30 22:15:29 helios64 kernel: __handle_mm_fault+0x5e4/0xdd0 mars 30 22:15:29 helios64 kernel: handle_mm_fault+0xe8/0x278 mars 30 22:15:29 helios64 kernel: do_page_fault+0x1e0/0x448 mars 30 22:15:29 helios64 kernel: do_translation_fault+0x58/0x68 mars 30 22:15:29 helios64 kernel: do_mem_abort+0x40/0xb0 mars 30 22:15:29 helios64 kernel: el0_da+0x24/0x58 mars 30 22:15:29 helios64 kernel: el0t_64_sync_handler+0x68/0xb8 mars 30 22:15:29 helios64 kernel: el0t_64_sync+0x180/0x184 mars 30 22:15:29 helios64 kernel: Code: 12800174 a9446bf9 17ffffc4 d4210000 (d4210000) mars 30 22:15:29 helios64 kernel: ---[ end trace 240751e909ea5fbc ]--- like https://bugzilla.kernel.org/show_bug.cgi?id=192571 . I was able to reproduce the above a few times with: stress -c 1 -m 16 --vm-keep but am unable today. As it seems zswap is useless on zram a swap, maybe it should be turned off either way. I disabled it by adding: extraargs=zswap.enabled=0 to /boot/armbianEnv.txt

Hi to all, after the 16GB of the eMMC is slowly reaching my limits, I installed a 128GB M.2 SSD and wanted to use the kobol tutorial to transfer the system data on it... https://wiki.kobol.io/helios64/install/transfer/#transfer-rootfs-from-emmc-to-sata-or-usb ... unfortunately I see at position 4 only /dev/md0 instead of the M.2 Sata on /dev/sda root@helios64:/dev# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk sdb 8:16 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 raid5 /srv/dev-disk-by-label-nas sdc 8:32 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 raid5 /srv/dev-disk-by-label-nas sdd 8:48 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 raid5 /srv/dev-disk-by-label-nas mmcblk2 179:0 0 14.6G 0 disk └─mmcblk2p1 179:1 0 14.4G 0 part / mmcblk2boot0 179:32 0 4M 1 disk mmcblk2boot1 179:64 0 4M 1 disk root@helios64:/dev# does anyone know what my error is here? I use OMV and have 3 hard disk running in RAID 5. Previously the hard drives were connected to SATA 1, SATA 3 and SATA 5. I had to change the hard drive on SATA 1 to 2, because the M.2 needs the SATA 1. Is it perhaps because of this?

Like many others, I get constant reboots with my Helios. I'm not sure it's worth me posting logs as a number of people already seem to be doing that. My question is, does anyone have a stable system? If so what OS and kernel are you using? I don't care about latest and greatest features, I just want it to stop hard rebooting.

Hi! I am trying the vanilla 5.15 kernel which has support for helios64. The system is booting, disks, MMC and network are working. But fancontrol fails. It seems the /sys entries have changed and the udev rules are not working. I've tried to understand the wiki page in order to adapt the udev rules and fancontrol config file but I am a little bit lost. Is there updated versions of those config files? Kind regards, Xavier Miller.

Using P14 in the documentation (https://wiki.kobol.io/helios64/usb/#serial-console) I am unable to get a serial connection to work. Has anyone been able to get UART2 debug Serial working using P14 and an FT232 USB cable? With Kobol plug pulled looking to just have this run in DAS mode over USB-C to still get use without fear but still need to maintain serial console to monitor booting as it sometimes locks up on boot. Downclocking to 1Ghz or below conservative seems to do a lot better but still looking to have remote debug console. When I try to connect I just get the follow error and no output. pl2303_get_line_request - failed: -32

I've gotten the following messages/error the past 2 mornings. Any ideas what the problem is? CRON-APT RUN [/etc/cron-apt/config]: Sat Jan 22 07:35:28 EST 2022 CRON-APT SLEEP: 1394, Sat Jan 22 07:58:42 EST 2022 CRON-APT ACTION: 0-update CRON-APT LINE: /usr/bin/apt-get update -o quiet=2 E: Failed to fetch https://stpete-mirror.armbian.com/apt/dists/buster/main/binary-armhf/by-hash/SHA512/5d6932f3c06c2c055d95b7a09e2bd4686b4bf8756d10bb52c9c9b96b33f1adde18116d55152d9c103d1e24ef83acecdddfc32a945b60812b6818b2be5a48458c 404 Not Found [IP: 130.225.254.116 80] E: Failed to fetch https://imola.armbian.com/apt/dists/buster/main/by-hash/SHA512/1b7ba13d5e752b8c1035070d43466f71960018c32426f5f8724c9d49fe7a33a4389e818f2b86b74355a57eedb76e1cf8e4d15c980ec3843ca07061d08a540ab5 404 Not Found [IP: 130.225.254.116 80] E: Failed to fetch http://mirrors.dotsrc.org/armbian-apt/dists/buster/main/by-hash/SHA512/609db1af113c6958edd2e1b95c5d94b8f47bb919fe1dd9612a5f9747ad45fc888f849e044f8a0d46de9b2692932bf498302505ac91a06023ea3029e71c8515b6 404 Not Found [IP: 130.225.254.116 80] E: Some index files failed to download. They have been ignored, or old ones used instead.

This is a continuation of ata1.00: failed command: READ FPDMA QUEUED noted by @djurny. I've experienced the same issue, and have some additional data points to provide. My observations so far: I'm using WDC WD60EFRX (68MYMN1 and 68L0BN1) drives The drives were working without issue previously behind a ASMedia ASM1062 SATA Controller, I've also used some of them behind ASM1542 (external eSATA enclosure) I can reproduce the issue on a clean install of Armbian 20.08.21 Buster and Focal I can reproduce via simple `dd` to `/dev/null` from the drive so filesystem does not seem to be the underlying cause Every drive is affected (i.e. each SATA slot) At what point dd produces an error varies from SATA slot to SATA slot (not drive dependent), SATA slot 4 can reproducibly produce the error almost immediately after starting a read The problem goes away when setting `extraargs=libata.force=3.0` in `/boot/armbianEnv.txt` [1] [1] However, even with SATA limited to 3 Gbps, the problem did reappear when hot-plugging a drive. This reset happened on drive slot 3 when I hot-plugged a drive onto slot 5. This seems weird to me considering they are supposed to be on different power rails. This may suggest there is in general a problem with either the PSU or power delivery to the drives. Here's an excerpt from the reset: [152957.354311] ata3.00: exception Emask 0x10 SAct 0x80000000 SErr 0x9b0000 action 0xe frozen [152957.354318] ata3.00: irq_stat 0x00400000, PHY RDY changed [152957.354322] ata3: SError: { PHYRdyChg PHYInt 10B8B Dispar LinkSeq } [152957.354328] ata3.00: failed command: READ FPDMA QUEUED [152957.354335] ata3.00: cmd 60/58:f8:00:f8:e7/01:00:71:02:00/40 tag 31 ncq dma 176128 in res 40/00:f8:00:f8:e7/00:00:71:02:00/40 Emask 0x10 (ATA bus error) [152957.354338] ata3.00: status: { DRDY } [152957.354345] ata3: hard resetting link And the full dmesg from when the error happened is below:

If Helios/Kobol is out of business - What "specs" should I use to define a replacement board - a rockchip 3399 board with the dimensions ? Help please -- (I'm getting an increased number of memory errors and of late an increased number of USB faults) I'm running (at the moment) - the system as a simple NAS with exported NFS4 volumes - the entire lot of 5 drives are formatted at BTRFS -- I'm working on archiving the data off and once done I'll format all as ext4 and try using simple RAID. Rich Leonard

A few Armbian packages were updated (armbian-bsp-cli-helios64, armbian-config, armbian-firmware &armbian-zsh) to version 21.05.08. At some point I noticed that the fancontrol service had failed to start up after the reboot - it was complaining about a file missing(/dev/thermal-cpu). If you run into this after the update, just update your /etc/fancontrol to the content below and your fancontrol should go back to normal. # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu # After 21.05.08 [2021.08.10] # Temp source : /dev/thermal-board INTERVAL=10 # FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input # After 21.05.08 [2021.08.10] FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-board/temp1_input /dev/fan-p7/pwm1=/dev/thermal-board/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=20

Posting here following what was recommended on twitter. After updating my helios64 earlier this week and rebooting to get the new kernel, I realized it was suspiciously silent. A quick check to sensor temps readings and physical check made me realize the fan were not spinning. After a quick read on the wiki, I checked fancontrol which was indeed failing: root@helios64:~ # systemctl status fancontrol.service ● fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/fancontrol.service.d └─pid.conf Active: failed (Result: exit-code) since Fri 2021-05-28 00:08:13 CEST; 1min 42s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 2495 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=0/SUCCESS) Process: 2876 ExecStart=/usr/sbin/fancontrol (code=exited, status=1/FAILURE) Main PID: 2876 (code=exited, status=1/FAILURE) May 28 00:08:13 helios64 fancontrol[2876]: MINPWM=0 May 28 00:08:13 helios64 fancontrol[2876]: MAXPWM=255 May 28 00:08:13 helios64 fancontrol[2876]: AVERAGE=1 May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: At least one referenced file is missing. Either some required kernel May 28 00:08:13 helios64 fancontrol[2876]: modules haven't been loaded, or your configuration file is outdated. May 28 00:08:13 helios64 fancontrol[2876]: In the latter case, you should run pwmconfig again. May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Failed with result 'exit-code'. Basically fancontrol expect a device in /dev to read the sensors value from, and that device seems to be missing. After a bit of poking around and learning about udev, I managed to manually solve the issue by recreating the device symlink manually: /usr/bin/mkdir /dev/thermal-cpu/ ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input systemctl restart fancontrol.service systemctl status fancontrol.service Now digging more this issue happen because udev is not creating the symlink like it should for some reason. After reading the rule in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and a bit of udev documentation, I managed to find how to test it: root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] Reading rules file: /etc/udev/rules.d/90-helios64-hwmon-legacy.rules Reading rules file: /etc/udev/rules.d/90-helios64-ups.rules [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0 USEC_INITIALIZED=7544717 run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0 ' <-- something is wrong here, there is no target Unload module index Unloaded link configuration context. After spending a bit more time reading the udev rule, I realized that the second argument was empty because we don't match the ATTR{type}=="soc-thermal" condition. We can look up the types like this: root@helios64:~ # find /sys/ -name type | grep thermal /sys/devices/virtual/thermal/cooling_device1/type /sys/devices/virtual/thermal/thermal_zone0/type /sys/devices/virtual/thermal/cooling_device4/type /sys/devices/virtual/thermal/cooling_device2/type /sys/devices/virtual/thermal/thermal_zone1/type /sys/devices/virtual/thermal/cooling_device0/type /sys/devices/virtual/thermal/cooling_device3/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert1/type root@helios64:~ # cat /sys/devices/virtual/thermal/thermal_zone0/type cpu <-- we were expecting soc-thermal! and after rewriting the line with the new type, udev is happy again # Edit in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and add the following line after the original one ATTR{type}=="cpu", ENV{HWMON_PATH}="/sys%p/temp", ENV{HELIOS64_SYMLINK}="/dev/thermal-cpu/temp1_input", RUN+="/usr/bin/mkdir /dev/thermal-cpu/" root@helios64:~ # udevadm control --reload root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0/temp HELIOS64_SYMLINK=/dev/thermal-cpu/temp1_input USEC_INITIALIZED=7544717 run: '/usr/bin/mkdir /dev/thermal-cpu/' run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input' Unload module index Unloaded link configuration context. Apparently for some reason the device-tree changed upstream and the thermal type changed from soc-thermal to cpu?

Hello to everybody ! I'm new to this forum and to linux. After installing my Helios64 recently, I had a few problems and had to go with the eMMC maskrom installation which were fine. PS : I've installed on top of the linux kernel (4.4) Open Media Vault (latest version). After installing everything, I've noticed that the fans were not functioning. I've checked the documentation on kobol.io site and went to the /etc/fancontrol config file and set the values as it was shown on the doc. I've restarted the fancontrol service, but still nothing. I've tried to read the pwm of my fans (has fan P7 were linked to the hwmon0 : cat /sys/class/hwmon0/pwm1) and i had the following message "No such file or directory" Can somebody help me : I'm scared about this issue and will shut down the NAS until I found a solution. Best regards, Pramil

Hi! I'm trying to install NUT because I connected a UPS device. I'd like to get it working so that the server is shutdown safely when there is a power interruption and that I get an e-mail notifying me as soon as there is an interruption. Already after installing via sudo apt install nut nut-client nut-server I get the following warnings: Setting up nut-client (2.7.4-8) ... Job for nut-monitor.service failed because the service did not take the steps required by its unit configuration. See "systemctl status nut-monitor.service" and "journalctl -xe" for details. invoke-rc.d: initscript nut-client, action "restart" failed. ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Sat 2021-12-11 16:33:11 CET; 24ms ago Process: 24611 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS) Dec 11 16:33:11 helios64 systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller... Dec 11 16:33:11 helios64 upsmon[24611]: upsmon disabled, please adjust the configuration to your needs Dec 11 16:33:11 helios64 upsmon[24611]: Then set MODE to a suitable value in /etc/nut/nut.conf to enable it Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Failed with result 'protocol'. Dec 11 16:33:11 helios64 systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller. And the output of systemctl status nut-monitor.service is: ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Sat 2021-12-11 16:33:11 CET; 5min ago Dec 11 16:33:11 helios64 upsmon[24611]: upsmon disabled, please adjust the configuration to your needs Dec 11 16:33:11 helios64 upsmon[24611]: Then set MODE to a suitable value in /etc/nut/nut.conf to enable it Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Failed with result 'protocol'. Dec 11 16:33:11 helios64 systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller. Dec 11 16:33:12 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:13 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:13 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:14 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:15 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat And I can't use stuf like nut-scanner so the packages aren't completely installed. Googling around just confused me because it's not even clear to me where the mistake is or how to fix it. Any help is appreciated, even if just in form of "go there and ask them".

Hello, I have a Helio64 not yet configured and I would like to be able to install the latest image available on https://armbian.hosthatch.com/dl/helios64/archive/ and especially to install the latest OpenMediaVault 6 version. Do you think this is possible ? Or will OpenMediaVault 6 not be available from armbian-config? As I write this post, the latest image available for Helios64 is Armbian_21.05.9_Helios64_bullseye_current_5.10.63.img.xz I thank you for your help Flolm

Hi my Helios 64 do not boot up anymore. In serial console i can see U-boot crc problem. So what can i do?

Hi guys, I have been using my Helios64 for more than a year now. I have it connected with the 1Gbps NIC. I have been reading about network bonding and getting both NICs up and running. The main purpose would be to have it running in mode "Adaptive Transmit Load Balancing" (mode 5). First I've discovered the issue with the 2.5Gbps not being able to keep a consistent (and performant) speed. So I've soldered the missing pin from the capacitor to the NIC (more on this later). I've checked the speed and now it is up to specs, getting very close to 1000Mbps (960-980Mbps). But here it comes the problem that I'm facing, if I enable both independently I do not get the 2.5Gbps to even appear all the time... at some point I did get it to work and that is when I performed the test of speed. I'm running current (stable) 5.10.63-rockchip64 #21.08.2 (and I have tried with no more success 5.13.x and 5.14.x) On the logs I find these lines that are a good idea that the 2.5Gbps NIC is having some issues: [50618.607406] usb 2-1.4: reset SuperSpeed Gen 1 USB device number 96 using xhci-hcd [50618.735965] r8152 2-1.4:1.0 eth1: v2.15.0 (2021/04/15) [50618.735975] r8152 2-1.4:1.0 eth1: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625. [50675.867182] r8152 2-1.4:1.0 eth1: get_registers -19 [50675.867653] r8152 2-1.4:1.0 eth1: Get ether addr fail So: 1.- has someone else seen these issues in the logs? If yes, has anyone been able to find a solution? 2.- the soldering went well, but the cable I used is a very small one, "hook-up calbe 32 AWG" (will try to update with a pic), could it be this the source of trouble? can both NICs run at the same time? (electric constrains, power rails limit, etc). Has anyone else attempted the soldering fix? Anyone can share a picture of their working setup? Thanks! Rob

Hi together, iam realy desperate and hope someone can help me with my problem. I think something crashed while I disconnected the USB-Cable in U-Boot Mode with helios64. Now Iam not able to see my m.2 SATA SSD in U-Boot Mode as USB Storage in my PC. I use the U-Boot mode from a SD-Card with a boot image. When I start some armbian System from SD-Card the m.2 SSD is visible and ready to use. I dont know what kind of logs do you need for my Problem. Sorry for that. :-( The only thing I want to do is to use my SATA m.2 SSD as armbian system drive with OpenMediaVault again. best regards sommer11 Infos to my device: https://wiki.kobol.io/helios64/intro/ SD-Card Image for U-Boot Mode: https://wiki.kobol.io/helios64/files/u-boot/helios64_sdcard_u-boot-only.img.xz

I was wondering if anybody had an STL or the like for the drive sleds. I haven't broken one yet, but was thinking about making some in different colors on my 3D printer if they're available. Thanks.

Hi folks, I am puzzled. When I am away for a few days I usually shut down my nas. It does indeed shut down but over night comes up again. Now I would like to know what triggers that unwanted restart here... I am currently on 21.08.3 Buster with Linux rockchip64 5.10.63 and do have OMV running... I could unplug the battery next time but I'd rather solve the issue the correct way. It's strange to me because I did not change any system parameters in OMV or via SSH. I do believe that an update to the latest kernel did mess things up. Where do I have to have a look?

Kia ora. I am aware that the external USB ports on the Helios are able to deliver up to 900mA per port. I am wondering whether it is possible to find a power source inside the Helios64 that would be able to deliver, say, 2.5A at 5v? Maybe somewhere quite soon after the 12v power in...? 🤔 Jon

Helios64 network activity light no longer flashes (always off). I have one ethernet cable attached to eth0 and enabled. Otherwise eth0 is working fine Helios64 is rebooted each 24 hours. If I echo "1" to /sys/class/leds/helios64:blue:net/brightness then LED lights up OK. Contents of /sys/class/leds/helios64:blue:net/trigger [none] usb-gadget usb-host kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 activity default-on panic mmc1 mmc2 netdev stmmac-0:00:link stmmac-0:00:1Gbps stmmac-0:00:100Mbps stmmac-0:00:10Mbps rc-feedback tcpm-source-psy-4-0022-online gpio-charger-online rfkill-any rfkill-none phy0rx phy0tx phy0assoc phy0radio rfkill0 System level Linux Helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux PRETTY_NAME="Armbian 21.08.2 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/"

Hi folks, I am wondering if somebody with a mac enviroment has a decent / performant samba connectivity? After I upgraded to Big Sur I have severe issues with the samba protocol when accessing my shares on the helios running openmediavault. I know that Apple had made some changes with samba but there might be some users that dug a little bit deeper and could give me a hint. I did try it with different settings in the extra options over the past weeks but with no luck so far. Sidenote: Also NFS is terribly slow and laggy. I am back with AFP connection now that does the job perfectly and fast.