gprovost

@TDCroPower Here the small hardware tweak ;-)
 
WARNING Please understand we are not responsible for any damage you might do to the board !
 

 

@wurmfood and @357up it could be an issue with the wire harness. Can you do more try by swapping the cable between the bay slots and sata ports in order to narrow down the problem to the wire harness. If it's the case then you can contact us to support@kobol.io and we will help you from there.
 
@AurelianRQ Regarding the issue for 2.5GbE port that doesn't perform properly when used in 1000Mb mode, unfortunately there is no fix that can be done by software. But it's actually pretty easy to fix on the board itself, it only requires to solder one wire between 2 points. Our mistake is that we didn't connect center tap of the 2.5Gb MAGJACK to 2.5V power rail (connected to ground instead) in order to provide common mode for MDI signals which is required for 1000Mb mode somehow. We will post a PCN bulletin to explain better this limitation and how to fix it for people who are up for a bit of soldering.
 
@aegiap Unfortunately your link aggregation is going to be impacted to the issue mentioned above. The 2.5GbE doesn't perform properly in 1000Mb mode.
 
 
 

Hi All, we finally figured out the issue with the latest build (20.08.13) and actually it wasn't related to the Kernel. There was a silly mistake in Armbian hardware optimization script that ended up skipping applying all the required performance and stability tweak for Helios64. This has been fixed. Now we need to wait new image and dpkg are generated and propagated on the repos.
 
Actually the instructions we gave on our latest blog post, were a bit pointless since it wasn't bound to kernel version We will post something on our blog as soon as new Armbian version is ready.
 
 
 
@djurny Thank for the Snapraid feedback and suggested tweak on SATA speed to avoid I/O errors. We will to look that closely to confirm it's not rather an issue with your harness cable. SATA 1 port is the one with the longest cable could be look closely here.
 
@fromport Yeah I think at the end it wasn't really a DVFS issue but just missing hw optimization tweak as stated above. For now stick to performance governor and once new armbian dpkg for Helios64 are ready and you upgraded then you can try to revert to on-demand governor (default settings) and let us now how it works.
 
@eClapton Noted on the instructions / clarification required. We are improving our Wiki every week.
Hot swap procedure is a good point ;-) Didn't have this one on our TODO list.
We also welcome any contribution to your wiki : https://github.com/kobol-io/wiki
 
@Dmitry Antipov Thanks for the pointer we will look at it. Doesn't seem anyone try to port rockchip RNG engine to mainline. I guess we could add it via patch to Armbiam @piter75
In a kind of similar topic people asked us how crypto engine works on RK3399, it's something we will address soon.
 
@Jaques-Ludwig Yeah as pointed by @Werner you can refer to official install doc
You can also look for some pointer to an old guide we did for our previous product, it's the same steps, just that the components version are older : https://wiki.kobol.io/helios4/nextcloud/
But anyhow would be great that the install via armbian-config works properky. Let's put that on the TODO list.
 
@dancgn You should create a dedicated Armbian thread on Mayan install via armband-config since it's not really related to hardware. Would be easier to troubleshot other it's going to get lost here.
You can also rise an issue on here with detailed logs.   Armbian-config tool is in big need of contributors, so don't expect it will be fix so soon, maybe you can try to figure it out yourself and fix it in armbian-config ;-)
 
 
 
 

You right. No excuse on our side, we are behind schedule and not up to expectation on the software maturity, maybe we should have stick LK4.4 (from rockchip) and forget about Linux mainline for now :-/
However we are still working at improving the stability and we are optimistic that very soon, it will get better.
 
Right now as you know LK5.8.16 is for some reason (we still can't figure out) unstable vs 5.8.14
We also realized that OMV install was removing some tx offloading tweak. So a lot of little things here and there that we only discover along the way.
 
BTW regarding this crash are you sure tx offload on eth1 was disable ?
 

@FredK, the LED problem has been fixed in AR-491 [https://github.com/armbian/build/pull/2283]. They will work again with the next bugfix release and 20.11. Thanks for reporting the issue.

This afternoon (eg around 7h) i will put some smaller old disks in helios64 to keep an eye on the progress.

I can start those containers there again.

If you want me to provide any additional info just tell me.

As it will sit there with test data only i can give you root access too in case you are interested.

Gesendet von meinem CLT-L29 mit Tapatalk

Hi FredK,
 
The contradicting armbian version numbers are thing open to discussion. Basically armbian uses many packages and not all of them get updated everytime -> different version number exist. This is synced at every major release.
 
The fact alone that the linux kernel 5.8 was released with 20.08.xx was a mistake on armbian side. Sorry for the problems we caused. If you can live with the LEDs not working a fix will be available at the latest for the 20.11 release (end of November).
If you need the LEDs working now you can switch to kernel version 5.4.xx (via armbian-config, pick it by the kernel version on the right. Not the armbian version) there everything should work. ( I tested and can confirm the bug is not yet present in LK5.4.69).
 
As said the release of 5.8 on 20.08.xx was a mistake. Sorry.
 
Heisath

You right. No excuse on our side, we are behind schedule and not up to expectation on the software maturity, maybe we should have stick LK4.4 (from rockchip) and forget about Linux mainline for now :-/
However we are still working at improving the stability and we are optimistic that very soon, it will get better.
 
Right now as you know LK5.8.16 is for some reason (we still can't figure out) unstable vs 5.8.14
We also realized that OMV install was removing some tx offloading tweak. So a lot of little things here and there that we only discover along the way.
 
BTW regarding this crash are you sure tx offload on eth1 was disable ?
 

Thank you! I canceled delivery of the psu I ordered and then ordered the one you linked, It has arrived today and the issue is now resolved! Thank you for saving me from making a grave mistake!

@barnumbirr Not really sure what happened to your setup and it's going to be hard to help will all those sequence of event you posted.
I would suggest you just do a fresh install. You can find previous build here :  https://archive.armbian.com/helios64/archive/

Before going any further, yes you need a multi-meter to narrow down the issue which is probably just a faulty PSU and need to be replaced.

No this is not related to tx offloading. For now we still don't know why tx offloading needs to be disabled on LK5.8, while on LK4.4 it works without issue.

Could you try edit the /boot/armbianEnv.txt and add idVendor and idProduct of your drive to usbstoragequirks ?
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x174c:0x5106:u,0x1e68:0x003a:u reboot the system and see whether your external USB drive can be recognized.
 

The LED brightness is not adjustable. You would need to use semi transparent plastic/tape to reduce the brightness, or change the resistor on front panel board.
 
Does FTDI USB serial still connected to your PC? That image should switch USB MUX to RK3399 internal USB and you would see the FTDI disconnected on your PC.
On Windows, if you ever installed rockusb driver then you would need uninstall it otherwise it will be recognized as rockusb device instead of usb drive.
 
 
How did you test? After remove the file, shutdown the system and unplug the power supply, then the system would automatically power on without need to press power button when power supply re-plugged.
Ah i just remember, do you have RTC battery or the UPS battery? the batteries is needed to make auto power on working correctly.
More info will be described on the wiki.
 
As mentioned by @flower, those are just symlinks generated by udev rules. The reason is similar like we have done in Helios4, the hwmon order could be changed depend on kernel version or kernel module loading order.
With this symlink, fancontrol configuration can just refer to /dev/fan-*.
 
The first boot should not take time more than 5 minutes, unless you were using 64GB/128GB card. As suggested by other, you need to shave the cable so it can connect properly. You definitely need access to serial console for system setup.
 
You could get supply for your fan from pin 1 or 2 and pin 3 on GPIO header but i'm not sure whether the additional fan would help much.
 

It might be that one side of front panel (the side with red LEDs) touch a bit the metal opening shorting the LED therefore lighting them up.
Could you trip to loosen a bit the 2x screws holding the front panel, then push a bit back the PCB, then tighten again the screw.
Otherwise putting a piece of tape on the PCB side that touch the metal opening, to isolate the LED, could help.
 
For next batch we will have to increase more the gap because mass production doesn't seem to meet exactly our tolerance requirement  :-/

It might be that one side of front panel (the side with red LEDs) touch a bit the metal opening shorting the LED therefore lighting them up.
Could you trip to loosen a bit the 2x screws holding the front panel, then push a bit back the PCB, then tighten again the screw.
Otherwise putting a piece of tape on the PCB side that touch the metal opening, to isolate the LED, could help.
 
For next batch we will have to increase more the gap because mass production doesn't seem to meet exactly our tolerance requirement  :-/

After several weeks of testing and trying I finally put my Helios64 into production.
With the 20.08.10 and the possibility to run the firmware over the eMMC I can finally sleep more calmly again.
 
The front view mounted:

 

 
The back view connected:

 
And to prevent my wife from killing me because there is a lighting party going on in the hallway I taped the front LEDs with insulating tape...

 
 
And for all who have problems with the included USB-C cable at the USB-C port of the Helios64.
You have to remove the plastic so that the connector looks like this...

 

 
The black plastic of the USB-C cable must NOT touch the backside of the Helios64, this ensures that the Cable is 100% plugged in.

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.

if someone wants to shutdown their unit on powerloss:
 
create file: /etc/udev/rules.d/15-gpio-charger.rules
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/sbin/halt"  
i'd love to know a way to start that unit when power is available again though.
 
on 4.4 the system crashes on halt. but as it does this after all services are stopped and the disks are synced this is not really a problem.
on 5.8 the system stops and "system halted" appears on serial console - BUT it is still on and fans are spinning.

@gprovost FYI: I've had zero issues past 6 months after starting umounting MacOS NFS mounts when no longer using them. When I forget to do this (which is often) & Mac goes to sleep a few times there will be tens of NFS daemons running on the Helios/Debian server.  I do believe there is an issue related to NFS between MacOS & Debian.  Issuing 'netstat | grep nfs' every now and then might help to confirm this.

@sandeepnd Most probably it's again a dying PSU not providing enough voltage for the HDD to spin-up, it you read this thread you will see that it has been a recurrent problem. We provided instruction in the past posts to check the voltage on the Molex connector. Which country are you located ? Can provide you a link of a good replacement.
 
Yes you can plug your HDD on any other machine that run Linux, you might need to install mdadm package if not present already : https://wiki.kobol.io/helios4/mdadm/#import-an-existing-raid-array
 
 
@bramirez Good to see you fixed it. Out of curiosity when you say update, you mean upgrade from what version to what version ?
 

Not sure whether it's a good idea to bump this thread but just my 2cts on this:
CESA is quite good for use cases such as LUKS. Obviously you will need to use aes-cbc (use 128 bits for maximum perf).
In this mode the CPU usage is quite low (you can see two kernel workers doing 10% on each CPU and a ton of interrupts, but other than that works well) which is awesome to keep the load of the CPU which is already limited. In comparison on using pure CPU, in my current setup I get:
 
 - Plain access to disk: 180MB/s
 - LUKS2 + CESA: 140MB/s
 - LUKS2 (no CESA): 52MB/s
 
I tuned LUKS using sector size= 4096 and keysize=128, as well as using aes-cbc-plain64.
For me this is quite good already even tho CESA only supports some "relatively old" ciphers.
 
Hope this helps other people!

Here is my guide to upgrade omv4to5. Hopefully this will help out others looking to do the same.
 
Was able to upgrade omv4 to 5. Here is my posts and the github bash script from the omv site: I downloaded the scripts then changed to executable.
https://forum.openmediavault.org/index.php?thread/27909-omv-5-0-finally-out/&pageNo=2  
https://forum.openmediavault.org/index.php?thread/27909-omv-5-0-finally-out/&pageNo=22
https://github.com/OpenMediaVault-Plugin-Developers/installScript/blob/master/upgrade4to5
https://forum.openmediavault.org/index.php?thread/33219-upgrade-to-5-x-failure/&pageNo=1
 
Steps to reproduce:
1. Remove incompatible plugins
2. Switch over to dockers that are incompatible
3. Download the two bash scripts:
wget https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/upgrade4to5
wget https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install
4. chmod +x the upgrade4to5 chmod +x install
5. Run the upgrade4to5 as root
6. omv and plugins will fail. as describes here: https://forum.openmediavault.org/index.php?thread/33219-upgrade-to-5-x-failure/&pageNo=1
7. Remove failed packages not purge since we want config files from omv They should print out.
8. Reinstall openmediavault only
9. Reboot
10. Run this command : apt-get purge openmediavault-omvextrasorg resolvconf
11. Reboot again
12. Run the install script as root. this will install omv extras.
13. apt update
14. apt dist-upgrade
15. omv-salt deploy run nginx
16. omv-salt deploy run phpfpm
17. But remove or move upsschedule-cmd from usr/bin and bin then run  apt-get install usrmerge
18. apt install docker
19. https://forums.docker.com/t/fa…te-nat-chain-docker/78269
The docker installer uses iptables for nat. Unfortunately Debian uses nftables. You can convert the entries over to nftables or just setup Debian to use the legacy iptables.
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
dockerd, should start fine after switching to iptables-legacy.
sudo service docker start
20. Switch to 5.4 kernel using armbian-config refer to kobol blog: 
https://blog.kobol.io/2020/03/13/armbian-new-release/
Hopefully this helps others out.
Thanks 
 

Not sure which country you are but on amazon you can find the following good replacement : https://www.amazon.com/dp/B07NCG1P8X
You might have to look for the same product ref. on the correct market place according to your country.
 
 
While for sure our bandwidth is more focus on Helios64, we are still supporting Helios4, and no plan to change that ;-)
For instance latest Armbian 20.05 Kagu still actively includes Helios4. Ok we will still need to put a post on our blog about that and link the image in our wiki :/
 
 
 

Not sure which country you are but on amazon you can find the following good replacement : https://www.amazon.com/dp/B07NCG1P8X
You might have to look for the same product ref. on the correct market place according to your country.
 
 
While for sure our bandwidth is more focus on Helios64, we are still supporting Helios4, and no plan to change that ;-)
For instance latest Armbian 20.05 Kagu still actively includes Helios4. Ok we will still need to put a post on our blog about that and link the image in our wiki :/