antsu

So, I went hunting for the PR where this got merged, found the reference to kernel module "ledtrig-netdev", noticed the module wasn't loaded on my Helios 64 (no idea why), loaded it via modprobe, restarted the service unit I mentioned in the post above, and now it works.
I've added ledtrig-netdev to /etc/modules-load.d/modules.conf, so now it should hopefully work automagically on every boot.

@ShadowDance It's a regular swap partition on sda1, not on a zvol. But thanks for the quick reply.

@ShadowDance I think you're definitely on to something here! I just ran the Rsync jobs after setting the scheduler to none for all disks and it completed successfully without crashing.
I'll keep an eye on it and report any other crashes, but for now thank you very much!
 
Update: It's now a little over 3 hours into a ZFS scrub, and I restarted all my VMs simultaneously *while* doing the scrub and it has not rebooted nor complained about anything on dmesg. This is very promising!
 
Update 2: Scrub finished without problems!

@antsu you could try changing the IO scheduler for those ZFS disks (to `none`) and see if it helps, wrote about it here: 
 

Light dimming stickers
I use them all over the place
 
https://www.amazon.com/LightDims-Black-Out-Electronics-Appliances/dp/B00CLVQG68/ref=sr_1_2?dchild=1&keywords=blackout+stickers&qid=1605561893&sr=8-2

This is what I do as well , although I had to create a dummy zfs-dkms package to prevent it from being pulled in by zfsutils-linux.

I have tested both the legacy and current images, and I can definitely see some stability improvements with 20.08.8, but unfortunately none of the images is able to fulfil my needs.
The "current" image, with Linux 5.8.13, seems to be the most stable so far, no crashes and everything just works, except I can't for the life of me get zfs-dkms to install, which is a deal breaker for me.
On "legacy", ZFS builds fine, but this image has a worrying bug that's not present in "current": Trying to shutdown always causes a kernel panic,  which causes the board to remain on with fans at full speed, which means in the occasion of a power cut the system would stay on until running out of battery, instead of performing a graceful shutdown.

A little advice for anyone planning to use nand-sata-install to install on the eMMC and has already installed and configured OMV:
nand-sata-install will break OMV, but it's easy to fix if you know what's happening. It will skip /srv when copying the root to avoid copying stuff from other mounted filesystems, but OMV 5 stores part of its config in there (salt and pillar folders) and will throw a fit if they're not there when you boot from the eMMC. Simply copy these folders back from the microSD using your preferred method.
If you have NFS shares set in OMV, make sure to add the entry /export/* to the file /usr/lib/nand-sata-install/exclude.txt BEFORE running nand-sata-install, or it will try to copy the content of your NFS shares to the eMMC.
Lastly, if you're using ZFS, which by default mounts to /<pool_name>, make sure to add its mountpoint to /usr/lib/nand-sata-install/exclude.txt before nand-sata-install as well.

Use kernel 5.8 and follow the instructions on the thread above.

These won't be exact instructions, since I decided to switch to focal (mostly for other reasons).
 
mkdir zfs-scratch cd zfs-scratch apt-get download linux-headers-current-rockchip64 git clone -b zfs-0.8.5 https://github.com/openzfs/zfs.git docker run --rm -it -v $(pwd):/scratch ubuntu:focal # inside the container cd /scratch apt update apt install build-essential autoconf automake bison flex libtool gawk alien fakeroot dkms libblkid-dev uuid-dev libudev-dev libssl-dev zlib1g-dev libaio-dev libattr1-dev libelf-dev python3 python3-dev python3-setuptools python3-cffi libffi-dev dpkg -i linux-headers-current-*.deb cd zfs sh autogen.sh ./configure make -s -j$(nproc) deb  
At that point you can exit the container (it'l vanish because of the --rm) and inside zfs-scratch/zfs you should have a bunch of Debian packages you can install
 

@KiSMI had the same kind of issue with the legacy image. It seems anything that puts a constant load on the system eventually causes a kernel crash, and sometimes a reboot.
The current image (kernel 5.8) however is rock solid. I've been using it now for 2 days and really stressing both the CPU and disks on my Helios64 without a single problem.

A little advice for anyone planning to use nand-sata-install to install on the eMMC and has already installed and configured OMV:
nand-sata-install will break OMV, but it's easy to fix if you know what's happening. It will skip /srv when copying the root to avoid copying stuff from other mounted filesystems, but OMV 5 stores part of its config in there (salt and pillar folders) and will throw a fit if they're not there when you boot from the eMMC. Simply copy these folders back from the microSD using your preferred method.
If you have NFS shares set in OMV, make sure to add the entry /export/* to the file /usr/lib/nand-sata-install/exclude.txt BEFORE running nand-sata-install, or it will try to copy the content of your NFS shares to the eMMC.
Lastly, if you're using ZFS, which by default mounts to /<pool_name>, make sure to add its mountpoint to /usr/lib/nand-sata-install/exclude.txt before nand-sata-install as well.

A little advice for anyone planning to use nand-sata-install to install on the eMMC and has already installed and configured OMV:
nand-sata-install will break OMV, but it's easy to fix if you know what's happening. It will skip /srv when copying the root to avoid copying stuff from other mounted filesystems, but OMV 5 stores part of its config in there (salt and pillar folders) and will throw a fit if they're not there when you boot from the eMMC. Simply copy these folders back from the microSD using your preferred method.
If you have NFS shares set in OMV, make sure to add the entry /export/* to the file /usr/lib/nand-sata-install/exclude.txt BEFORE running nand-sata-install, or it will try to copy the content of your NFS shares to the eMMC.
Lastly, if you're using ZFS, which by default mounts to /<pool_name>, make sure to add its mountpoint to /usr/lib/nand-sata-install/exclude.txt before nand-sata-install as well.

A little advice for anyone planning to use nand-sata-install to install on the eMMC and has already installed and configured OMV:
nand-sata-install will break OMV, but it's easy to fix if you know what's happening. It will skip /srv when copying the root to avoid copying stuff from other mounted filesystems, but OMV 5 stores part of its config in there (salt and pillar folders) and will throw a fit if they're not there when you boot from the eMMC. Simply copy these folders back from the microSD using your preferred method.
If you have NFS shares set in OMV, make sure to add the entry /export/* to the file /usr/lib/nand-sata-install/exclude.txt BEFORE running nand-sata-install, or it will try to copy the content of your NFS shares to the eMMC.
Lastly, if you're using ZFS, which by default mounts to /<pool_name>, make sure to add its mountpoint to /usr/lib/nand-sata-install/exclude.txt before nand-sata-install as well.

1/ in IDLE around 40C. But beyond that it's hard to define an "expected" temperature too many factors in place.
I guess we could give the temperature numbers for each use cases listed in our power consumption table : https://wiki.kobol.io/helios64/hardware/#power-consumption
 
2/ Thermal pad.
 
3/ Heatsink is in contact will all key ICs, PMIC and inductors
(The "center" square is the SoC)
 

 
4/ You can experiment, but i really don't think it would benefit much.

Operating temperature for the Rockchip RK3399K SoC is -20°C~85°C. Don't know about the rest of your questions as I haven't taken my Helios apart (yet ;) ).