19 19

About This Club

Dedicated section for talk & support for the Helios4 and Helios64 open source NAS. Lead and moderated by the Kobol Team.
  1. What's new in this club
  2. I have bisected the issue for helios64. See: Could you try to revert this commit and check the issue vanish ? You could also try to revert those commits against latest kernel : 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 and probably also aea6cb99703e17019e025aa71643b4d3e0a24413 (both commits are related). Point is that helios64 is not a mainline supported architecture (the patches for it are not upstream but only Armbian) so maybe you will be in a better position to report the regression upstream and have one investigate the roots of the regression.
  3. UPDATE: Even changing the cables, the disks keep failing over time. I wasn't able to have my NAS running more than a day or two without a failure on the disks. After buying an APC UPS with Boost and Trim Automatic Voltage Regulation (AVR), my NAS is now running without any failure over more than a week! So the problem was the unstable energy in my house. Maybe I'll try to put back the original ones to see if it works.
  4. Cheese - it's already sold. PLEASE can anybody contact me who wants to sell his/her Helios64 - I want to keep that project alive and donate the board to the devs here!
  5. I'm selling my complete, fully functional Helios64 bundle as well. Unfortunately, I don't have time to take care of the NAS properly. Here a link to the German ebay-Kleinanzeigen (english description below): https://www.ebay-kleinanzeigen.de/s-anzeige/kobol-helios64-arm-open-source-nas/1989458235-168-8929 I'm open to send it to abroad on your own costs. Cheers, Simón
  6. If Helios/Kobol is out of business - What "specs" should I use to define a replacement board - a rockchip 3399 board with the dimensions ? Help please -- (I'm getting an increased number of memory errors and of late an increased number of USB faults) I'm running (at the moment) - the system as a simple NAS with exported NFS4 volumes - the entire lot of 5 drives are formatted at BTRFS -- I'm working on archiving the data off and once done I'll format all as ext4 and try using simple RAID. Rich Leonard
  7. May I ask to which x86 system you are moving? Thanks.
  8. I would like to buy TWO (bundles of) HELIOS 64: - ONE to DONATE to the developers of ARMBIAN (my first priority). - the SECOND for me myself and I ;-) since I need a backup because my setting is a bit flaky. Since I am an egoist - I would donate the device as soon as I am able to get hold of a second helios64 (I hope this increases the chances a little bit to get one.) - of course I would take over all costs to deliver it to the ARMBIAN devs. Thanks, Amix
  9. I want to buy a HELIOS64 NAS, is there any to buy, please contact me with private message.
  10. Hi, Thks for your patch, i think it's more "clean" than my "Kiss workaround" Have a good day
  11. Did you ever checked what Armbian do for you on their expense? Consumers and HW vendor are always depending heavily on community, on our investment (which creates nothing but expenses). It is your problem that you believe in something that is complete fabrication, a fat lie if that term suits better. There are three sides in this game and two of them - consumers and HW vendor are abusing the 3rd. There is no magic in this. This is just how this business works. Do you really think other players in this field are any better?
  12. I can understand that you are disappointed. But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all. All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.
  13. They were. But you should also see the other side: I purchased Helios64 with the assumption of buying a solid and reliable NAS system - which is linux based = open. I also had the assumption that Kobol will support the device for at least 2-3 years ... What I got was: A definitively cool and powerful Linux NAS system where Wake on Lan does not work (although it was advertised) ... and prop. never will work (one of my reasons to buy!) where the 2.5 GB LAN port only works reliable with 2.5 GB ... (except you're willing to solder SMD - and risk to mess it up completely)(I was under the - reasonable - assumption that this port will also work well with GB LAN ... one reason to buy!) where the SATA Ports / cables seem to have troubles (at least my btrfs degrades every now an then, according to the forum, others have the same issue ...) ... a solution will never be available! where it is hard to get a running updated system, as you're in the risk of losing functionality where you will get no spare parts, etc. anymore ... also no second (replacement) unit (unless you want to buy an used one - which is not that easy, as they are rare). where you will get no real support anymore (also "support" and "warranty" was rather limited anyhow). ... My personal conclusion: A rather mixed feeling ... I did not really get what I bought. I'm now sitting on an island, which I have to take as it is, depending on "the community" for each upgrade (and for security reasons sometimes you need to update!). Technically the best thing to do would be to sell the unit. I expected that these type of products, coming from China/Singapur, heavily relaying on the community, have "limited" durability. But - for me - less than a year, was really unexpected to me! So even if Kobol team would return, not sure if I ever would buy from them again ...
  14. They were honest in this decision, weren't they? Can't say this is a general practice in the world where leaning to community resources and reselling "Linux" is the way to sell hardware. We have support know-how and we would take their customers, but the problem is that we can't afford doing that and pay for everything. End users (also vendors doesn't like) are not willing to compensate for the damages such support service will create. Frustration and violence from end users generates stress and people that waste weeks and months staring into the code and solve problems has to eat. I understand you would expect support service from vendors, but they expect that community will fill the gap they are not able to cover. None of vendors has that ability and most of other vendors would remain in the cave if there would not be community support. Just this device doesn't attract enough people since it's too special. Great hw, indeed. Sources are available, Armbian even provide high-end build framework to support R&D and maintenance activities, forum for finding people with the same problems ... Now, someone needs to sponsor support lead and hire let's say two full time developers to proceed with support. We provide and maintain expensive infrastructure, which vendor saw as advantage. Perhaps this is the way to start with developing resources to get what you need.
  15. The question is, if you would trust them again ... they pulled the trigger already once and let their customers alone.
  16. Still not work with fresh-build edge images. No simlink /dev/thermal-cpu, fancontrol start to work if manualy do ln -s /sys/devices/virtual/thermal/thermal_zone0/hwmon0 /dev/thermal-cpu TL;DR: in /etc/udev/rules.d/90-helios64-hwmon.rules an line 16 set ATTR{name}=="cpu|cpu_thermal".instead of ATTR{name}=="cpu" ... and I see two extra simlinks in root: hwmon0 -> /sys/devices/virtual/thermal/thermal_zone0/hwmon0 thermal_zone0 -> /sys/devices/virtual/thermal/thermal_zone0 I look for /sys/devices/virtual/thermal/thermal_zone0/hwmon0 in udev: udevadm info -q all -a /sys/devices/virtual/thermal/thermal_zone0/hwmon0 Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/virtual/thermal/thermal_zone0/hwmon0': KERNEL=="hwmon0" SUBSYSTEM=="hwmon" DRIVER=="" ATTR{name}=="cpu_thermal" ATTR{power/control}=="auto" ATTR{power/runtime_active_time}=="0" ATTR{power/runtime_status}=="unsupported" ATTR{power/runtime_suspended_time}=="0" ATTR{temp1_crit}=="100000" ATTR{temp1_input}=="34444" looking at parent device '/devices/virtual/thermal/thermal_zone0': KERNELS=="thermal_zone0" SUBSYSTEMS=="thermal" DRIVERS=="" ATTRS{available_policies}=="user_space step_wise bang_bang fair_share " ATTRS{cdev0_trip_point}=="1" ATTRS{cdev0_weight}=="0" ATTRS{cdev1_trip_point}=="0" ATTRS{cdev1_weight}=="0" ATTRS{cdev2_trip_point}=="1" ATTRS{cdev2_weight}=="0" ATTRS{integral_cutoff}=="0" ATTRS{k_d}=="0" ATTRS{k_i}=="0" ATTRS{k_po}=="0" ATTRS{k_pu}=="0" ATTRS{mode}=="enabled" ATTRS{offset}=="0" ATTRS{policy}=="step_wise" ATTRS{power/control}=="auto" ATTRS{power/runtime_active_time}=="0" ATTRS{power/runtime_status}=="unsupported" ATTRS{power/runtime_suspended_time}=="0" ATTRS{slope}=="1" ATTRS{sustainable_power}=="0" ATTRS{temp}=="33888" ATTRS{trip_point_0_hyst}=="2000" ATTRS{trip_point_0_temp}=="85000" ATTRS{trip_point_0_type}=="passive" ATTRS{trip_point_1_hyst}=="2000" ATTRS{trip_point_1_temp}=="95000" ATTRS{trip_point_1_type}=="passive" ATTRS{trip_point_2_hyst}=="2000" ATTRS{trip_point_2_temp}=="100000" ATTRS{trip_point_2_type}=="critical" ATTRS{type}=="cpu-thermal" I see there ATTR{name}=="cpu_thermal" have to be choosed. an line 16 set ATTR{name}=="cpu|cpu_thermal". Victory, now /dev contains link thermal-cpu -> /sys/devices/virtual/thermal/thermal_zone0/hwmon0 fancontrol works @Heisath? upd: checked in https://github.com/armbian/build/commit/37662d8ed3cbcdb8c975e21bc2e709c365441d1e
  17. Kobol stopped operations (partly due to the chip shortage) and @gprovost himself did not exclude that Kobol may resume operations some time again. I am still hoping that we will see a follow-up of Helios64 based on a successor of the rk3399 developed by Kobol.
  18. I have been very sad that Kobol is finished. I really think these products were great, and I really love the idea that they were open source. Speaking of which, since these products are now discontinued, would it be possible to publish the CAD / Gerber files for these boards? I know there are diagrams and schematics, but if the actual source files are available it would be possible to have another company continue producing and maybe improving these. That would make this TRULY open hardware.
  19. Hello Benoît, As I am unable to drop you a private message (only one per day although I haven sent any mail yet) I am answering here: Yes, its still available and I can reserve it for you. Drop me a private message with your country and city. I will check the shipping then and reply to you asap. Cheers, R.
  20. Is it still available ? If so, I'm interested. How much should I add for the shipping ? Kind regards, Benoît
  21. oh, thanks! I will take a look on this release of Armbian :-)
  22. Hello, yes, -> Welcome to Armbian 21.08.6 Hirsute with bleeding edge Linux 5.15.5-rockchip64
  23. Hi, I was thinking of something else...(I thought you were taking the Board probe values as a reference value but which is not the case) But I highly recommend MAXTEMP = / dev / fan-p6 / pwm1 = 85 / dev / fan-p7 / pwm1 = 85 and MAXPWD=140 with the original thermal pad. Personally my helios has a powerful thermal pad, this allows it to be fanless (which is not the case because I always have a MAXPWM = 50 for ventilation in my helios64 with SSD), but the original thermal pad is of very poor quality (it insulates more than it dissipates). If you have high enough usage I would recommend changing the thermal pad or having the more severe fan control variables for safety or only not to use your helios64 without safety net (without thermal control it is hardware suicide with original thermal pad). Thank BipBip1981
  24. Hi! seems the udev rule needs to be rewritten too. I will look at that later... EDIT: @BipBip1981 do you really run kernel 5.15 or is your workaround for 5.10?