SIGSEGV

I ordered a replacement MOSFET (same model), including a drop-in replacement from vishay with better power ratings (just in case it should happen again). Unfortunately shipping is taking longer than it should. I temporarily bypassed the MOSFET to get all the hard drives to boot up so I could transfer the more important data. I was hoping fixing it would be faster than receiving a replacement board - and for me dealing with UPS is playing Russian roulette. Fixing it by replacing a 13-14 cent component is the better option for us both. Hopefully I won't ruin the board in the process!

Angel,
Most SATA drives should work out of the box - it's possible that at the time when the specs were written the Kobol team only had access to drives up to 16TB in size.
18TB drives should be no problem for modern filesystems (EXT4,XFS, ZFS, etc.) - The only real issue you might have would be the power drawn from the power supply at startup.
Give it a try - connect the drive into the NAS and it should be listed as a device with the command 'lsblk'.

This discussion is interesting because I can relate to both sides.
As an end user - having multiple filesystems to choose from is great, choosing the right one is where I need to spend my time choosing the right tool for the task. Having a ZFS DKMS is great, but if after an update my compiler is missing a kernel header, I won't be able to reach my data. Shipping a KMOD (with the OS release) might give me access to my data after each reboot/upgrade. The ECC/8GB RAM myth is getting old but it has garnered enough attention that most newbies won't read or search beyond the posts with most views.
 
Armbian as a whole is always improving - a few weeks ago iSCSI was introduced for most boards (and helped me replace two x86_64 servers with one Helios64) - and an implementation of ZFS that works out of the box will be added soon enough. That being said, this is a community project - if a user wants 24x7 incident support, then maybe the ARM based SBCs + Armbian are not the right choice for them. Having a polite discussion with good arguments (like this thread) is what gets things moving forward - We don't have to agree with all the points, but we all want to have stable and reliable systems as our end goal.

This discussion is interesting because I can relate to both sides.
As an end user - having multiple filesystems to choose from is great, choosing the right one is where I need to spend my time choosing the right tool for the task. Having a ZFS DKMS is great, but if after an update my compiler is missing a kernel header, I won't be able to reach my data. Shipping a KMOD (with the OS release) might give me access to my data after each reboot/upgrade. The ECC/8GB RAM myth is getting old but it has garnered enough attention that most newbies won't read or search beyond the posts with most views.
 
Armbian as a whole is always improving - a few weeks ago iSCSI was introduced for most boards (and helped me replace two x86_64 servers with one Helios64) - and an implementation of ZFS that works out of the box will be added soon enough. That being said, this is a community project - if a user wants 24x7 incident support, then maybe the ARM based SBCs + Armbian are not the right choice for them. Having a polite discussion with good arguments (like this thread) is what gets things moving forward - We don't have to agree with all the points, but we all want to have stable and reliable systems as our end goal.

This discussion is interesting because I can relate to both sides.
As an end user - having multiple filesystems to choose from is great, choosing the right one is where I need to spend my time choosing the right tool for the task. Having a ZFS DKMS is great, but if after an update my compiler is missing a kernel header, I won't be able to reach my data. Shipping a KMOD (with the OS release) might give me access to my data after each reboot/upgrade. The ECC/8GB RAM myth is getting old but it has garnered enough attention that most newbies won't read or search beyond the posts with most views.
 
Armbian as a whole is always improving - a few weeks ago iSCSI was introduced for most boards (and helped me replace two x86_64 servers with one Helios64) - and an implementation of ZFS that works out of the box will be added soon enough. That being said, this is a community project - if a user wants 24x7 incident support, then maybe the ARM based SBCs + Armbian are not the right choice for them. Having a polite discussion with good arguments (like this thread) is what gets things moving forward - We don't have to agree with all the points, but we all want to have stable and reliable systems as our end goal.

My bad, a Cable was Preventing the fan from spinning, this topic could be closed!

From the wiki:
Source: https://wiki.kobol.io/helios64/sata/#sata-controller-diagram

@snakekick, having the kernel swappiness set to 100 on systems where the swap is implemented as compresses RAM is normal.
You want the pages that have been swapped out to be compressed and stored in RAM to make the swap-in operation as fast as possible (decompressing the page is faster than reading it first from disk). Since the storage for some of these devices is on the slow side (microSD, eMMC) - having the swap on RAM tends to speed up the memory operations (swap-in & swap-out), while at the same time helping to avoid unnecessary wear on your flash storage.

@SIGSEGV I did compile zfs 2.0.0 and its up and running.  Rsynced 1.4TB to Helios box after that. Seems to be working. Next, home assistant, after that's up and running I'll get rid of my ATX computer that has been doing those jobs...

I actually managed to get the zfs working, by following the post by  @grek in this very thread. I've been running some fio tests to see if everything is dandy. Seems to be. :-) 
root@helios64:/ironwolf # zpool --version
zfs-2.0.0-rc6
zfs-kmod-2.0.0-rc6
root@helios64:/ironwolf # zfs version
zfs-2.0.0-rc6
zfs-kmod-2.0.0-rc6
root@helios64:/ironwolf #
 
I've noticed that zfs 2.0.0 has been released, so that means that I'll be compiling it after the fio runs are done (they've been running for a day or two now...) . 

I agree with @TRS-80.
Some topics are better documented with a small How To post or even within the Wiki pages of the Kobol/Helios64 projects.
That being said - I will post how to get iSCSI targets published on Armbian - now that the new kernels has been released, hopefully it will be made sticky for others wanting to do the same.
 
Regarding the recent release of ZFSon Linux - let's try out and document our findings.
I will for sure test it out and come back here to document how it went.

That's a good point, and I suspect maybe (probably?) so.  However a quarterly release was just made, so it will probably be some time until this makes it into Armbian.  Maybe next quarterly release, maybe one after that (I have no idea, and please don't take that as any sort of promise, or ask "when" etc. because that's not how any of this works).
 
I realize that you guys have purchased a commercial product, and therefore may have certain expectations.  At the same time I sense that this may be some people's first introduction to how a true Free Software, community based project works.  So what I will say in this post applies to Armbian (the community project) itself.  You also have your support from your vendor (Kobol) who are working on things, in fact they work hand in hand with the Armbian project, and in general such partnerships are a Good Thing (for lots of reasons).  But I am part of Armbian project and so I can only speak for our part, not Kobol your vendor you bought the hardware from.
 
Now, gotten that out of the way, understand there is no big company, business model, or anything else behind Armbian.  It's just us, you and me, little guys like us all over the world.  You guys are doing great job in here helping each other out and figuring things out, together.  And this is why we have forums and everything is humming along nicely as it should so far.
 
Now the next step, for those who have an interest in this board, and in ZFS (and I detect a lot of interest in this thread), along with the requisite technical ability, would be to get involved in figuring how to get this into upstream Armbian, for the benefit of everyone.
 
For example, already in another thread a young man figured out the build steps, distilled that down into some bash script, and shared his results publicly.  That is based on current stuff, and should be a good stop-gap / workaround to point people to in the meantime.  And it's a great example of how F/LOSS development marches forward, one little step at a time, slowly but steadily, based on work of individuals.  Which is the only way any of this works.
 
Which leaves the question of new development going forward.  @SIGSEGV raises a good point about OpenZFS 2.0.  I cannot speak to specifics because I do not own this hardware and I am not a dev anyway so I cannot help out in that way.  However if any of you want to give it a try, by all means please do.  Make another forum post about getting that working, share your results with one another, test, test, and when it gets stable, I am sure it makes it into Armbian.  And probably faster than waiting for someone else to do it.
 
The "core devs" as mentioned further up thread should get around to it, but I can't say when.  There are only so many of them, remember all part time and mostly unpaid.[0]  I'm just trying to paint a realistic picture here of the resources we have to work with, which are scant (especially considering people's apparent expectations).  But also I want to make the point that you too, can become a "core dev" simply by sharing what you have learned, and contributing that back to the project in whatever form.  And every little step forward helps.  If you investigate, share your results.  Test, and share your results (good or bad!).  Many hands make light work, and thus the development (and maintenance) burden is shared and we all move forward together.
 
I hope this post was helpful in giving a broader picture of why it's against the (Armbian) rules[1] to ask "when" and similar questions.  In fact, feel free to point people towards this post when such questions come up.  Even by doing this, you are helping.  By hanging out around forums.  This is all I do, I am not a dev.  I also start contributing to docs lately, in fact I plan to re-work the relevant part of the docs touching on similar themes as this post.  I have a whole list of things I want to add or re-work in the docs.  We each do our own little part, as much as we are able (and perhaps more importantly, willing).
 
Cheers! 
 
[0] In case this comes up, yes Kobol have contributed financially to Armbian development and have been doing so for years.  They are a great company and partners and do things The Right Way.
[1] Those rules only apply to the Armbian forums overall, we take a much more hands off approach here in Kobol Club, as this is official support forum for some commercial products which are based on Armbian (i.e., rules are different here, and set by Kobol).

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.
 

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.
 

@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.

@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.
 

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.
 

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.