SIGSEGV

Just got the notification to update After the reboot all seems good - iSCSI is now supported out of the box. Will wait for the official images to be pushed to the downloads page to try and setup a clean install + overlay FS to document my customizations.

@wurmfood This guide might be a good starting point for you - just replace the lvm2 with your ZFS implementation. I prefer to use targetcli tool to manage my targets, but the concepts are the same.

@jbergler 5.8.x & 5.9.x are working here as well, but I'm not using ZFS, just plain vanilla mdadm RAID and LVM2 formatted as XFS. If you have an extra set of HDDs could you try building a new data pool with mdamd or LVM2 to test your setup? Since you're getting memory related errors, is there a way for you to run a memory test on your board? Have you checked if the heatsink is seated properly over the components of the board?

@Protxch According to the documentation - SATA1 & the M.2 slot are mutually exclusive. Try connecting the HDDs to SATA 2 and 3 and restart your Helios64 as @Werner mentions, check that the board boots with only the microSD card connected (No HDDs or M.2 cards connected) to rule out an SD card gone bad during the flashing procedure.

sda: Seagate BarraCuda ST2000DM006-2DM164 sd[b-e]: Toshiba DT01ACA100

Can you guys share your experience with disk sleep on the Helios64 + Armbian. In my case I haven't seen the disks sleep - they are always spinning (or so they seem) and never on standby. I have a standalone /dev/sda and a RAID5 array with disks /dev/sd[b-e] (created with mdadm) - and XFS formatted logical volumes on top of these. 'iotop' says that nothing is accessing the disks: 'hdparm -B /dev/sd[a-z]' after each reboot is always: sudo hdparm -B /dev/sd[a-e] /dev/sda: APM_level = 254 /dev/sdb: APM_level = off /dev/sdc: APM_level = off /dev/sdd: APM_level = off /dev/sde: APM_level = off 'hdparm -C /dev/sd[a-z]' is always: $ sudo hdparm -B /dev/sd[a-e] /dev/sda: APM_level = 254 /dev/sdb: APM_level = off /dev/sdc: APM_level = off /dev/sdd: APM_level = off /dev/sde: APM_level = off Added a rule to set power management parameters and it seems to be ignored $ cat /etc/udev/rules.d/99-hdd-pwm.rules ACTION=="add|change", KERNEL=="sd[a-z]", ATTRS{queue/rotational}=="1", RUN+="/usr/bin/hdparm -B 63 -S 120 /dev/%k"

@SymbiosisSystems Since your system is crashing often, my guess is that you're not using it on a PROD environment yet. Have you tried the test builds at the bottom of the downloads page with the newer kernel? You might have better luck with those. I'm using the test build from Nov.13 and it has been very stable. I'm not using OMV just the OS and a few packages that I've configured manually to provide SMB, DLNA & iSCSI services.

@barnumbirr Could you share your custom config for /etc/fancontrol?

Now it makes sense why the fans ramp up when login into the system, hahaha. An algorithm that takes into account both the CPU and HDD temperatures would be a nice solution, prioritizing HDD temps since these need to lower than the temp for the SoC. That being said - is there a way to monitor if the HDDs are idle/sleep and the heads parked to save energy? There are periods of inactivity where it might make sense to stop the HDDs from spinning, I'm sure that this will add a bit of startup/lag when they are accessed after being idle, so far I haven't been able to tell if they are have stopped spinning (they only become moderately loud when starting up the NAS).

Thanks for the clarification @gprovost. Looking forward to storing the bootloader on SPI - I believe that looking for the 2nd stage bootloader on the microSD is a perfect way to rescue the system in cases it's needed.

@jbergler It's called cockpit - it listens on port 9090 You can install it with: sudo apt -y install cockpit cockpit-networkmanager cockpit-packagekit cockpit-storaged

For anyone looking to build an iSCSI target on their new Helios64, I can confirm that it's working correctly under the test builds for Armbian 20.11. Thanks to @aprayoga for his comment on the pull request, the kernels modules related to LinuxIO have been added to all boards in the Armbian project.

@ShadowDance Thanks for the input regarding the fans. I'll give it a try if the noise goes up on my system once the ambient temperature starts to rise here in couple of months, for now I'm concerned about the dust.

@Jaques-Ludwig, I'm using the default jumper configuration on the Helios64 board.

@Jaques-Ludwig The following steps worked for me to boot from a USB stick. In order to boot from USB try this steps: Boot from the SD card Plug in the USB stick - use command 'lsblk' to see the device name and write it down. Choose option 3 from the main menu of 'nand-sata-install' tool Choose the right destination (device from step 2) Wait for writing to finish and reboot. It's part of the guide. If you did install on the eMMC, then you can write the image used for initial SD-Card to a USB drive and erase the partition table from the eMMC. The boot loader will still be in the eMMC - but now your system will boot from the USB drive because the root partition has the UUID that the boot loader is looking for.

Hi @Jaques-Ludwig, That page refers to booting once from the SD-Card to install the system onto the eMMC, with armbian-config or directly with the nand-sata-install tool. Afterwards your system should boot without the SD-Card, which is what you are looking to achieve, right?

Yes, you can boot off USB. You need to either have a U-Boot image on the SD card or on the eMMC. From there, if the system partition is not found on the SD Card or the eMMC, it will try to look for it on the USB drives that are connected. My system is booting from a USB drive at the moment - the U-Boot is installed on the eMMC (I erased the partition table afterwards, but the bootloader is still there). If you zero out the eMMC, you loose the bootloader and you need to boot from an SD card. I belive that once we can install the bootloader to the SPI chip you would be able to boot directly from the USB. As @TRS-80 mentioned on the post above - the tool to use for moving your current system from the SD Card to either a USB or eMMC is "nad-sata-isntall". Today, there was a new post on the wiki page for the Helios64 about the process.

Thanks Igor, I'll check the repository and create the PR if needed.

@Igor Would it be possible to enable CONFIG_TARGET_CORE on the kernel so that module 'target_core_mod' is included in the directory /lib/modules/5.8.17-rockchip64 ?? The objective is to enable iSCSI target mode on the installation - making the Helios64 board able to serve as SAN server. At this moment it's missing and the package targetcli-fb fails to work correctly on both Focal and Buster latest images, with error: 'modprobe: FATAL: Module target_core_mod not found in directory /lib/modules/5.8.17-rockchip64'

Can the Helios 64 be used for hosting iSCSI targets?? @gprovost @aprayoga Installing targetcli-fb on 20.08.21 Focal fails with a error about a missing kernel module. #apt install tuned targetcli-fb Setting up python3-rtslib-fb (2.1.71-0ubuntu1) ... Job for rtslib-fb-targetctl.service failed because the control process exited with error code. See "systemctl status rtslib-fb-targetctl.service" and "journalctl -xe" for details. invoke-rc.d: initscript rtslib-fb-targetctl, action "start" failed. ● rtslib-fb-targetctl.service - Restore LIO kernel target configuration Loaded: loaded (/lib/systemd/system/rtslib-fb-targetctl.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2020-11-06 23:11:03 CST; 50ms ago Process: 14105 ExecStart=/usr/bin/mkdir -p /etc/rtslib-fb-target (code=exited, status=0/SUCCESS) Process: 14109 ExecStart=/usr/bin/targetctl restore (code=exited, status=1/FAILURE) Main PID: 14109 (code=exited, status=1/FAILURE) Nov 06 23:11:03 helios64 target[14109]: File "/usr/bin/targetctl", line 47, in restore Nov 06 23:11:03 helios64 target[14109]: errors = RTSRoot().restore_from_file(restore_file=from_file) Nov 06 23:11:03 helios64 target[14109]: File "/usr/lib/python3/dist-packages/rtslib_fb/root.py", line 85, in __init__ Nov 06 23:11:03 helios64 target[14109]: modprobe('target_core_mod') Nov 06 23:11:03 helios64 target[14109]: File "/usr/lib/python3/dist-packages/rtslib_fb/utils.py", line 428, in modprobe Nov 06 23:11:03 helios64 target[14109]: raise RTSLibError(stderrdata) Nov 06 23:11:03 helios64 target[14109]: rtslib_fb.utils.RTSLibError: b'modprobe: FATAL: Module target_core_mod not found in directory /lib/modules/5.8.17-rockchip64\n' Nov 06 23:11:03 helios64 systemd[1]: rtslib-fb-targetctl.service: Main process exited, code=exited, status=1/FAILURE Nov 06 23:11:03 helios64 systemd[1]: rtslib-fb-targetctl.service: Failed with result 'exit-code'. Nov 06 23:11:03 helios64 systemd[1]: Failed to start Restore LIO kernel target configuration. dpkg: error processing package python3-rtslib-fb (--configure): installed python3-rtslib-fb package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of targetcli-fb: targetcli-fb depends on python3-rtslib-fb (>= 2.1.62); however: Package python3-rtslib-fb is not configured yet. dpkg: error processing package targetcli-fb (--configure): dependency problems - leaving unconfigured Processing triggers for man-db (2.9.1-1) ... Processing triggers for dbus (1.12.16-2ubuntu2.1) ... Processing triggers for systemd (245.4-4ubuntu3.3) ... Errors were encountered while processing: python3-rtslib-fb targetcli-fb E: Sub-process /usr/bin/dpkg returned an error code (1)

You might want to check the configuration file for htop. sigsegv@helios64:~$ cat .config/htop/htoprc # Beware! This file is rewritten by htop when settings are changed in the interface. # The parser is also very primitive, and not human-friendly. fields=0 48 17 18 38 39 40 2 46 47 49 1 sort_key=1 sort_direction=1 hide_threads=0 hide_kernel_threads=1 hide_userland_threads=0 shadow_other_users=0 show_thread_names=0 show_program_path=1 highlight_base_name=0 highlight_megabytes=1 highlight_threads=1 tree_view=0 header_margin=1 detailed_cpu_time=0 cpu_count_from_zero=0 update_process_names=0 account_guest_in_cpu_meter=0 color_scheme=0 delay=15 left_meters=AllCPUs Memory Swap CpuTemp left_meter_modes=1 1 1 2 right_meters=Hostname Tasks LoadAverage Uptime CpuFreq Eth0 Eth0stat right_meter_modes=2 2 2 2 2 2 2 # SBC hardware and Kernel specific path. # Editable manually. BoardName= CpuFreq_handler= CpuTemp_handler= CpuVCore_l_handler= CpuVCore_b_handler= GpuVCore_handler= GpuTemp_handler= # Wlan / Eth alias eth0_alias=eth0 eth1_alias= wlan0_alias= wlan1_alias=

Mine is running somewhere around 44 - 52°C - at an ambient temperature of 23°C. CPU frequency for both Big and Little cores are around 408 MHz according to 'htop'

Is the U-Boot image installed on the SPI Flash? If not is it possible to install it there? The instructions on the Wiki page say to write it to the microSD card and have the board boot from the microSD.