gprovost

Media info:
https://arstechnica.com/gadgets/2020/12/openzfs-2-0-release-unifies-linux-bsd-and-adds-tons-of-new-features/
 
Remarks: 32bit support is broken in Debian Stretch, no upgrade there. Also this upgrade is needed to bump kernel to 5.10.y

@Werner Hahaha yes we are working at improving the design ;-) More news soon.

@fr33s7yl0r Updated your title to make it more friendly.
 
If we could have made it 6x SATA port at that time, with one port dedicated to the M.2 slot, you can be sure we would have done it.
We could have taken a different approach using a PCIe Switch, but it would have increase significantly the board.
 
Any board design is about finding the best recipe within a budget for a list of use cases with the less tradeoffs possible.
The M.2 SATA port on our Helios64 was an addition to support more use cases to the product, even though yes it wasn't perfect that the port has to be shared.
 

@Werner Hahaha yes we are working at improving the design ;-) More news soon.

ZFS was just upgraded to v2.0.1 https://armbian.atlassian.net/browse/AR-614 which is a preparation for pushing a kernel on and above 5.10.y. Upgrade was tested on Armbian Buster/Bullseye/Focal/Hirsute. My test ZPOOL was always loaded without any troubles.

We only support upgrade troubles - for ZFS functional problems, please check / file a bug report here https://github.com/openzfs/zfs/issues
 

I literally registered to post this complaint here.
How STUPID it is to have a M.2 SATA SHARED WITH HDD1!!
IT DEFEATS THE WHOLE PURPOSE OF THIS ENCLOSURE. PERIOD!!!!
 
My mistake was that I did not know what it meant that M.2 was SHARED before I purchased this enclosure and now, I have a need to expand beyond the measly 16GB of your eMMC and I found out THE PAINFUL WAY that IT IS NOT POSSIBLE because of the shared SATA port. IT"S BEYOND FRUSTRATION.
 
YOU CANNOT EVEN IMAGINE HOW STUPID THIS DECISION OF YOURS IS.
IT JUST LITERALLY DOWNGRADED YOUR NAS FROM AN EXCELLENT ENCLOSURE TO AN OVERPRICED JUNK THAT I HAD TO WAIT FOR FOR MORE THAN 6 MONTHS.
 
AND THERE IS NO WAY TO RETURN IT TO YOU AND GET MY MONEY BACK.
 
What should I do with my RAID now, once I want to install an SSD drive?
Should I now use RAID drive as a slow storage and have symbolic links to make sure that I don't run out of space on eMMC?
 
IF THERE WAS SOME WAY TO RATE YOUR ENCLOSURE SO NOBODY ELSE MAKES THE SAME MISTAKE I DID, I WOULD CERTAINLY DO THAT.
 
 
 

In general any electronic device should be plugged in to a proper electrical outlet with a circuit breaker.  The circuit breaker is critical in cutting the current in case of a short, therefore preventing a fire.

@allen--smithee
if you need to modify the bootloader, you can start from these lines
https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip64-mainline/add-board-helios64.patch#L1671-L1687
You can add parameter checking there. Maybe check certain U-Boot environment variable, maybe check for certain file in the filesystem.
You could also remove it completely and modify /boot/boot.scr instead, to enable/disable the HDD power.
 
Another thing to explore, you could remove the afromentioned u-boot function and also remove the power rail nodes from linux device tree
https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-current/add-board-helios64.patch#L239-L259
and then when you need to enable it, just access the gpio from sysfs.
 

@gprovostHit up the local computer mall for a replacement power supply.  Closest they had was 12v 10A to barrel, and then a barrel to 4-pin adapter.
 
Anyways, everything checked out correctly, and no more errors.  Thanks!

You can also check all the certification and conformity document for the PSU we provide with Helios64 : https://wiki.kobol.io/helios64/docs/#psu
 
We have designed Helios64 with safety and protection in mind... no shortcut.

Hello I was finishing setting up my Helios64 (system installed on emmc) with Openmediavault (luks + snapraid + mergerfs + samba) on 3 disks, everything was working and I thought I should reboot to make sure that it is indeed the case (especially making sure that luks locked disks would not be an issue). An what a surprise, after booting up I couldn't ssh in so I connect the serial to log in as root. It seems that all services are dead like below.
 
# service ssh status ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab Active: inactive (dead) Docs: man:sshd(8) man:sshd_config(5)  
And once I manually restarted the ssh service I get: 
"System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8)." Connection closed by 192.168.0.3 port 22  
 
Could anyone give me some directions on how I can start debugging this? 

You can use DAS mode on Kernel 5.9 using device tree overlay
It is not as seamless as in LK 4.4 where you can just change to cable to switch the usb role but it work.
I gave you a like, it should lift the limitation.
 
1. correct
2. Yes, you'd need to use filesystem that can be recognized by both, Linux and Mac.
With FAT32 there is maximum partition size and maximum file size (4GB) limitation.
With exFAT, it might put some load to cpu during NAS because of FUSE but it might be change in future where in kernel module used instead of FUSE.
4. I don't have experience with SnapRaid.
 
 
There is another method you can explore to use the DAS mode, expose the system as MTP device. It should not have issue with exclusive access to block device and the filesystem type.

@ShadowDance
Finally, I installed the original fans which were already very good,
but this time I pushed further by adding a MAXPWM line limiting the maximum rotation of the fans.
This changed my life

I feel terribly stupid !!

 
# Helios64 PWM Fan Control Configuration # /etc/fancontrol # /usr/sbin/fancontrol # /var/run/fancontrol.pid # Command # ls -l /sys/class/hwmon | grep fan # cat /sys/class/hwmon/hwmon4/pwm1 && cat /sys/class/hwmon/hwmon5/pwm1 # systemctl stop fancontrol.service # systemctl start fancontrol.service # echo 255 > /sys/class/hwmon/hwmon4/pwm1 && echo 255 > /sys/class/hwmon/hwmon5/pwm1 # hdparm -H /dev/sdd | grep celsius # hddtemp /dev/sd[a-e] INTERVAL=10 # Temp source : /dev/thermal-cpu FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input # temp1_critique = 85° < big downclock 1.8Ghz > 1.62Ghz # P6 => Fan down (2HDD+CPU) | P7 => Fan Up (3HDD) #Temp Limit PWM increase MINTEMP=/dev/fan-p6/pwm1=55 /dev/fan-p7/pwm1=65 #Temp Limit PWM = MAXPWM MAXTEMP=/dev/fan-p6/pwm1=85 /dev/fan-p7/pwm1=85 #Fan Type "C" 350-3600 PWM = 25 = 350 RPM| PWM = 255 = 3600RPM #Fan Start PWM = 25 MINSTART=/dev/fan-p6/pwm1=30 /dev/fan-p7/pwm1=30 #Fan Stop PWM = 15 MINSTOP=/dev/fan-p6/pwm1=35 /dev/fan-p7/pwm1=35 #PWM Minimal < MINSTOP (SSD P7 = 0 / HDD P7 = 35) MINPWM=/dev/fan-p6/pwm1=35 /dev/fan-p7/pwm1=0 #PWM Maximal (78°< Tcpu100% <85°) #T = 20° PWM = 120 | T = 25° PWM = ?? | T = 30° PWM = ?? MAXPWM=/dev/fan-p6/pwm1=120 /dev/fan-p7/pwm1=65  

This looks like the same issue as I’ve been having, it’s possibly due to the SATA cables in the harness. I’ve tested with other SATA cables and can’t reproduce the issue with those. So I believe it’s not likely to be bad disks but that is a possibility of course. You can start by trying to limit SATA speed to 3 Gbps and see if that helps, if it does it’s very likely the same issue. I also recommend doing SMART scans and scrub _after_ limiting the SATA speed.
 
See my other topic for more information: 

Good luck!

Success-ish?
I have now been able to get u-boot loaded through the serial console, and have booted from both USB flash drive and a SATA attached drive.
I cannot say why the bootloader on the board fails to launch u-boot from anywhere but the serial port.
 
Attempting more discovery, shaving of yaks and whacking of moles now that I have a full OS at hand.

We will have some spare stock to sell soon.
Yes we ship to China.
 
As for the next batch we will announce our plan soon.

In case you haven't looked up this section of our wiki : https://wiki.kobol.io/helios64/usb/#helios64-as-direct-attached-storage-das-device

@aprayoga will help answer in details @retrack question on what is the blocker right now to have WoL working on Heliso64. But in a nutshell is because suspend mode is not supported yet properly.
 
I think we all understood that the question is addressed to us Kobol team, no one was expecting the core Armbian team to follow up on this.
So let's move on and not hold any grudge against each other...we are only one to blame to not have answer quickly enough this thread.
 
@Igor Maybe we could delete this exchange above, put that being us.

@aprayoga will help answer in details @retrack question on what is the blocker right now to have WoL working on Heliso64. But in a nutshell is because suspend mode is not supported yet properly.
 
I think we all understood that the question is addressed to us Kobol team, no one was expecting the core Armbian team to follow up on this.
So let's move on and not hold any grudge against each other...we are only one to blame to not have answer quickly enough this thread.
 
@Igor Maybe we could delete this exchange above, put that being us.

Aight, I will lock this then.
If you have any further Helios64 to sell by chance you can then use our brand new section for this purpose: https://forum.armbian.com/forum/55-market-place/

We have it, it works, but we don't provide it for end users yet: https://github.com/armbian/build/blob/desktop/config/distributions/hirsute/name This development branch will be merged to main branch in about 2 weeks, which means one could easily build images without much extra efforts, but don't know when we will switch groovy for hirsute on nightly builds. Its (will be) a matter of adjusting files as such https://github.com/armbian/build/blob/desktop/config/targets-cli-beta.conf Not much work for that, but someone has to pay attention and do it. Can also be done automagically, but then someone would need to script it ...  
 
 
Anything is possible if expenses for R&D are covered. Also if we would do everything users asks on this forum, we would need to work strait for several years and then this idea of yours will get in front for realisation. I agree it is nice to have, but there are many nice to have ideas, some are even critical problems and has to wait for our life to catch up. It's up to you how bad you need this - if you help project with your know-how, resources, cash .... it can be done much faster.
 
Also we never support or dug into distribution upgrades. Too many things, that are outside our domain & control, can go wrong. We have no intention to fix more of Debian or Ubuntu bugs. Our focus is to keep devices as such, usable, alive, supported https://docs.armbian.com/#what-is-armbian and build-able from sources.
 

Running Kodi on Linux is generally troublesome. With legacy kernels is just like with other RK3399 boards:
... but I would recommend you modern kernel. But here Kodi might not yet work OOB. IHMO NAS should do different job in 1st place ...

Google knows something about which would suggests its a generic issues, unrelated to Helios64 or Armbian.
https://www.google.com/search?q=starting+90-second+grace+period&oq=starting+90-second+grace+period

Hi.
 
My helios64 always crashes with this method : 
 
[environment]
 1TB m.2 sata ssd for system
 16TB seagate exos on data drive
 18TB WD Ultrastar DC550 on data drive
 Linux helios64 5.9.14-rockchip64 #20.11.4 SMP PREEMPT Tue Dec 15 08:52:20 CET 2020 aarch64 aarch64 aarch64 GNU/Linux
 
 about 620,000 files on data drive.
 
 
[method1]
 #sync
 #sysctl -w vm.drop.caches = 3
 #ls -CFR [datadir] > [tmp dir]
 #ls -1lFR [datadir] > [tmp dir]
 #zip -j [tmpdir] filelist.zip
 #sync >>>>>>> Crash (blinking Red LED)
 
[method2]
 (First step) via samba , on Windows , see property of all 620,000 files.
 (Second step) on SSH "sysctl -w vm.drop_caches = 3" >>>>>> Crash(blinking Red LED)
 
 

Yes for the next batch we will finally offer board only purchase option ;-)

Yes for the next batch we will finally offer board only purchase option ;-)