NickS

Hi jotapesse, yes same for me ... but on closer inspection ... the flashing of the LAN activity light no longer seems to be tied to real network activity! 1/ It flashes a lot less than it used to do. 2/ If I download a large movie file from the Helios64 to my PC I occasionally see a brief flash, but not the sustained activity that I'd expect from a download that takes several minutes. 3/ Inspecting my network router, I can see constant low level activity on the Helios64 ip address (I only have one ethernet cable attached to the Helios64) but don't see any flashing LED. So in conclusion ... its still not working properly!

Hello liberodark, I'm not sure you have the same problem as me - although it is possible the two problems are related. My system boots fine and my eth0 adaptor and network are all running OK - for me its just the activity indicator on the front panel that no longer works. It sounds like your network is not working at all ... Nick

Hello again Groetjes, thanks for your reply. Yes "echo 'activity' | sudo tee '/sys/class/leds/helios64:blue:net/trigger'" has an effect. The LED is now flashing blue on and off. I presume "activity" is the module designed for the "System Activity LED" and that "netdev" was supposed to do a similar job for the the "LAN Activity LED" - but no longer does. Regards ... Nick

Hello again Groetjes. There is no difference after the echo command - the LED remains off. I rebooted - just in case - still no difference. Regards ... Nick

Hi Groetjes, thanks for the interest. Here's the info you asked for... root@Helios64:~# echo 'netdev' | sudo tee '/sys/class/leds/helios64:blue:net/trigger' netdev root@Helios64:~# Regards ... Nick

Hi I'm talking about the BLUE "LAN Activity LED" on the front panel. On release of the first batch of Helios64 this "LAN Activity LED" was always inactive as it wasn't yet supported by the software. At some point during development (I can't remember when) there was an update which enabled support and it worked fine until recently. Kind regards ... Nick

Helios64 network activity light no longer flashes (always off). I have one ethernet cable attached to eth0 and enabled. Otherwise eth0 is working fine Helios64 is rebooted each 24 hours. If I echo "1" to /sys/class/leds/helios64:blue:net/brightness then LED lights up OK. Contents of /sys/class/leds/helios64:blue:net/trigger [none] usb-gadget usb-host kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 activity default-on panic mmc1 mmc2 netdev stmmac-0:00:link stmmac-0:00:1Gbps stmmac-0:00:100Mbps stmmac-0:00:10Mbps rc-feedback tcpm-source-psy-4-0022-online gpio-charger-online rfkill-any rfkill-none phy0rx phy0tx phy0assoc phy0radio rfkill0 System level Linux Helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux PRETTY_NAME="Armbian 21.08.2 Buster" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"

Stable System: Absolutely I'm running with all latest maintenance & OMV5. Linux 5.10.21-rockchip64, OMV 5.6.2-1(Usul) ---- but I'm keeping things very simple... NO RAID 4 x HDD ALL THE SAME NO ZFS BOOT FROM SD AUTO SHUTDOWN & RESTART EACH 24 hours -- until I get to the apps 21 Docker containers running various apps & services. I've had one docker image fail to come up on a couple of occasions. So ... I'm a very happy customer. My Data resilience doesn't come from RAID (which I really don't like 'cos 8TB disks take forever to rebuild). I just backup critical data to my old trusty Helios4!

Hi gprovost, Yes I happened to find RTC in the doc yesterday! I'm still using auto power on in case of power failure. But, as you kindly suggest, I'm now using RTC - 2 tasks in OpenMediaVault5 job scheduling... 1/ sudo rtcwake -m disable (each reboot to reset any outstanding wake timers) 2/ sudo rtcwake -m off --date '+ 6 hour 15 minutes 0 seconds' (each morning at 01:00 to shutdown and set wake timer for 07:15) It worked fine this morning!

OK Thanks ebin-dev For others who are as dumb as me you need to edit "/lib/systemd/system-shutdown/disable_auto_poweron" and change line ... "echo 0 > /sys/class/gpio/gpio153/value" to "echo 1 > /sys/class/gpio/gpio153/value" and it works!!!

My NAS do very little overnight so my NAS4 shuts down in the evening and shortly afterwards a physical time switch cuts the power - reinstating power in the morning at which time the NAS4 automatically reboots. I want to do the same with the NAS64 - but even though I've read this (https://wiki.kobol.io/helios64/auto_poweron/) I'm not sure how to go about it. I can't understand if it only works if the UPS has died, or if I have to run a script before shutdown or both. Could you please clarify? Thx ... Nick

Just happened to be in my office when I heard a sharp crack from one of my 2 Helios4 servers which were both up and running at the time. Noticed that the LED display on one had frozen and could not get that server to respond. Recycled the power on it and although it came up with LED shining, on investigation no power to HDDs or fans. Suprising it booted at all, but it did! Swapped power supplies and issue moved with the PSU so looks like I have a deadish PSU. Pulled it apart and can see 2 of the 1000mf capacitors have blown. Would have replaced them but the massive heat sink is in the way and is soldered to too many components to bother. I'll buy a new one. Lesson 1: Immediately suspected the power supply as other users have been complaining about them nearing end-of-life - so thanks for those users writing on this forum. Lesson 2: These PSUs can partially fail and may at first appear to be OK. Lesson 3: My data base was backed up on the surviving server:} Good job because apart from that being corrupted everything else is OK. Restored db and server is back up - but I can only run one at a time until I source another PSU. Kind regards ... Nick

Unfortunately no. You'll want to transcode ahead of time and use direct play if you want to use helios as plex server I do, and although I try to rerender content manually, occasionally I just let the software carry the load. I use serviio as my DLNA server on the Helios4. It has the capacity to set up different render profiles for a plethora of target devices so you can present full quality and bitrate to say a TV but less so for a tablet. For remote viewing you'll have to pay the small subscription, but there is a 30day full free test. I'm not sure the Helios4 has the horespower to do more than one render at a time. A bit like someone flushing the toilet when their partner is in the shower! Installation instructions attached. serviio.txt

The following patch makes fans revert to slow on shutdown rather than top speed! ================================================================================ --- /usr/sbin/fancontrol 2018-02-17 13:54:50.065478090 +0800 +++ /usr/sbin/fancontrol 2018-02-17 13:58:56.910831481 +0800 @@ -334,7 +334,7 @@ # No enable file? Just set to max if [ ! -f $ENABLE ] then - echo $MAX > $1 + echo $MINPWM > $1 return 0 fi @@ -433,9 +433,9 @@ fi # If fanspeed-sensor output shall be used, do it + min_fanval=100000 if [[ -n ${fan} ]] then - min_fanval=100000 fanval= # A given PWM output can control several fans for one_fan in $(echo $fan | sed -e 's/+/ /')

Hi sirleon, I'm running OMV4 in my deployment, and a recent set of updates broke "psutil.disk_io_counters()". If you are using this routine in your OLED code to fetch disk information then this may be your problem. Anyway you should SSH into your NAS and run the OLED code directly from the SSH terminal and let us see all the nice error messages it throws up :}

OLED panel Here's my version of the sys-oled script with various panels for... System Logo; System Load, Fan & Temperature; HDD activity; Network activity; Temperature & Clock Anyone wishing to deploy it will need to change the location of their HDDs in status_hdd() Also change location of temperature sensor in cpu_temp() depending on your Kernel Apologies for the crude code - Python is not my favourite! oled.py

Hi gprovost Well more and more strange - I checked voltages across ground and all pins for both J10 & J17 at fan values of 255, 50 & 1 (always with fancontrol stopped). Of course with a meter I can only see the mean voltage and not the waveform and duty cycle length. The PWM voltages look a bit random. Does this help you? 12V SENSE PWM-255 PMW-50 PWM-1 J17 12.19 9.2 0.14 0.04 0.01 J10 12.19 9.1 1.19 1.18 1.18 Kind regards ... Nick

Hi Igor, Yes, this is a test system - fresh new latest Stretch image downloaded and installed yesterday.

Igor - that's how it should work I know! But if you read the thread you'll see that they just stay at low speed all the time now. Anyway ... moving on ... following on from gprovosts suggestion... I found a brand new Arctic F8 PWM rev.2 4 pin fan in my workshop and substituted that for one of the Helios4 kit fans. #> echo 255 > /dev/fan-j10/pwm1 #> echo 255 > /dev/fan-j17/pwm1 #> echo 50 > /dev/fan-j10/pwm1 #> echo 50 > /dev/fan-j17/pwm1 Above commands have no effect. Both fans (kit & new replacement) run exactly the same speed - unchanging. So I find it hard to believe that its a fan problem. I wish I had a scope to put across the fan pins - but sadly I don't. But PWM fans in general work at full power if no PWM signal is present - so I'm surmising that there is a signal on the PWM pin that is providing a short duty cycle keep the speed low. Very odd. Any idea how I might locate the driver and trace what its doing?

Hi gprovost, Yes - I am using the original fans supplied with the Helios4 kit. They were working fine after I applied the fan patch. ie they would go to full speed on boot then settle down to a slower speed and occasionally I would hear them change pitch. I noticed that the fans stopped going to full speed on boot about 6 weeks ago - and only just got around to trying to understand what's going on. I may have some old fans lying around that i could substitute one of them with. Will any 4-pin fan work? Kind regards ... Nick

Hello gprovost, thanks for the quick reply. I stopped fancontrol & tried all 3x2 direct updates to the pwm1 files. A cat of the 2 files showed they had both taken the new values. I saw/heard no change in physical fan speeds - they both just run at a constant low speed. test system used... Linux Helios4 4.14.70-mvebu #266 SMP Wed Sep 19 10:35:09 CEST 2018 armv7l GNU/Linux Kind regards ... Nick

OK yesterday I installed a brand new test system (well it was until you guys slipped 4.14.66 in overnight!) Armbian_Helios4_Debian_Stretch_4.14.20.img.xz Debian 9 Stretch (Kernel 4.14.20) Build date : 17/02/2018 Size : 229 MB I'm seeing exactly the same symptoms. I turned DEBUG=1 on in fancontrol and let it rip and pasted the output below. I then hacked fancontrol to report a temperature value of 99C (99000) and tested again. You will note that fancontrol sets the fan speeds to 255 (max allowed) so fancontrol seems to be working as designed However the actual fans don't spin any faster? ... here's the DEBUG output of regular fancontrol first followed by my hacked 99C version ===================================================== Loading configuration from /etc/fancontrol ... Common settings: INTERVAL=10 Settings for /dev/fan-j10/pwm1: Depends on /dev/thermal-cpu/temp1_input Controls MINTEMP=55 MAXTEMP=95 MINSTART=50 MINSTOP=50 MINPWM=50 MAXPWM=255 Settings for /dev/fan-j17/pwm1: Depends on /dev/thermal-cpu/temp1_input Controls MINTEMP=55 MAXTEMP=95 MINSTART=50 MINSTOP=50 MINPWM=50 MAXPWM=255 Enabling PWM on fans... Starting automatic fan control... pwmo=/dev/fan-j10/pwm1 tsens=/dev/thermal-cpu/temp1_input fan= mint=55000 maxt=95000 minsa=50 minso=50 minpwm=50 maxpwm=255 tval=74642 pwmpval=255 fanval= min_fanval=1 new pwmval=150 pwmo=/dev/fan-j17/pwm1 tsens=/dev/thermal-cpu/temp1_input fan= mint=55000 maxt=95000 minsa=50 minso=50 minpwm=50 maxpwm=255 tval=73690 pwmpval=255 fanval= min_fanval=1 new pwmval=145 ======================================================== Loading configuration from /etc/fancontrol ... Common settings: INTERVAL=10 Settings for /dev/fan-j10/pwm1: Depends on /dev/thermal-cpu/temp1_input Controls MINTEMP=55 MAXTEMP=95 MINSTART=50 MINSTOP=50 MINPWM=50 MAXPWM=255 Settings for /dev/fan-j17/pwm1: Depends on /dev/thermal-cpu/temp1_input Controls MINTEMP=55 MAXTEMP=95 MINSTART=50 MINSTOP=50 MINPWM=50 MAXPWM=255 Enabling PWM on fans... Starting automatic fan control... ***************** +99000 pwmo=/dev/fan-j10/pwm1 tsens=/dev/thermal-cpu/temp1_input fan= mint=55000 maxt=95000 minsa=50 minso=50 minpwm=50 maxpwm=255 tval=99000 pwmpval=255 fanval= min_fanval=1 new pwmval=255 ***************** +99000 pwmo=/dev/fan-j17/pwm1 tsens=/dev/thermal-cpu/temp1_input fan= mint=55000 maxt=95000 minsa=50 minso=50 minpwm=50 maxpwm=255 tval=99000 pwmpval=255 fanval= min_fanval=1 new pwmval=255 =================================================================

Helios4 Fan problems again! OK, I got hold of an OLED display and have it installed and set up - it works really well - thankyou. I significantly changed your script and included a panel for CPU load, system temperature and system fan speeds. This is where I noticed that fancontrol does indeed increase the fan speed values in /dev/fan-j10/pwm1 and /dev/fan-j17/pwm1 as the temperature value in /dev/thermal-board/temp1_input is seen to rise. However I never see or hear any change to the physical fans' speed. The fans' speed remain constant at boot, after boot, during shutdown and even after shutdown. I turned on DEBUG in fancontrol and it appears to be doing what it is supposed to do. Every 10 seconds or so it reads the temp and calculates a new fan speed value which it then writes to the two fan control files. I even modified fancontrol to write values 1 to 255 incremented every 10 seconds and saw absolutely no change to the physical fan speed. It looks as if either the fan driver is not using the values set in /dev/fan-j1x/pwm1 to control fan speeds or the physical fans are not responding to the driver. Can you suggest how I debug this please? Overall the continuous low fan speed appears to keep the temperature of the board & CPU at a reasonable level (below 50C) - but the HDDs do get a bit hot from time to time - so I would like to try and fix this. I am running Jessie 4.4.112-mvebu with OMV 3.0.99 (Erasmus)

OK I just found my notes on this and it was a little more complex than I led you to believe. I've added a text file with all my install and update notes. I guess you follow the install notes first and only the update if required. I now remember that I got a lot of this info from a web search, and it did get me up and running with ownCloud. But oC had several red flags that were annoying so I researched fixes for those and included in this text file. Good luck ... Nick owncloud.txt

I have ownCloud running under OpenMediaVault on the Helios4. You need some "NginX Extra Options" and ensure that you give it a "Pool" with user & group set to "www-data" Give pool "Extra Options" of env[PATH] = /usr/local/bin:/usr/bin:/bin Don't forget that whatever you set as your directory in NginX for this server, should be set up as a share with www-data having Read/Write access In your NginX server definition for oC have the following "Extra Options"... client_max_body_size 10G; # set max upload size fastcgi_buffers 64 4K; rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect; rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect; rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect; index index.php; error_page 403 /core/templates/403.php; error_page 404 /core/templates/404.php; location = /robots.txt { allow all; log_not_found off; access_log off; } location ~ ^/(data|config|\.ht|db_structure\.xml|README) { deny all; } location / { # The following 2 rules are only needed with webfinger rewrite ^/.well-known/host-meta /public.php?service=host-meta last; rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last; rewrite ^/.well-known/carddav /remote.php/carddav/ redirect; rewrite ^/.well-known/caldav /remote.php/caldav/ redirect; rewrite ^(/core/doc/[^\/]+/)$ $1/index.html; try_files $uri $uri/ index.php; } location ~ ^(.+?\.php)(/.*)?$ { try_files $1 = 404; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$1; fastcgi_param PATH_INFO $2; fastcgi_param HTTPS on; fastcgi_pass $socket; } # Optional: set long EXPIRES header on static assets location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ { expires 30d; # Optional: Don't log access to assets access_log off; } add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" ;