tuxd3v

Hello, I know that Kobol is out of Business.. But I am thinking...what if my helios4 motherboard die...? To mitigate that, I want to acquire new motherboard. Does any one knows how I could get one? Thanks in Advance

Hello Heisath, Thanks a lot! I will be a beta tester Regards,

Will be there a 5.4 LTS kernel for Helios4? Thanks in Advance, Best Regards, tux

hello, I run 'armbianmonitor -u' http://ix.io/28AC I rebooted the OS and maybe apparently everything is nice..I thing, It just hanged some days ago around 5AM, maybe a peak on power grid or something.. Fancontrol has MINTEMP like this: root@helios4:~# grep MINTEMP /etc/fancontrol MINTEMP=/dev/fan-j10/pwm1=60 /dev/fan-j17/pwm=70

Hello, Sumething nasty hapenned this night on my Helios4, that left the OS crippled.. I have been analysing the logs, and I find no reason for that, what I know is that ssh server received a SIGHUP( maybe a peak in the network grid.. ). In this process I am analysing logs, and checking the system.. I have lots of entries in '/var/log/syslog' related with fancontrol.. root@helios4:~# tail -n 2 /var/log/syslog Jan 24 21:48:25 localhost fancontrol[906]: /usr/sbin/fancontrol: line 477: let: mint=*1000: syntax error: operand expected (error token is "*1000") Jan 24 21:48:36 localhost fancontrol[906]: /usr/sbin/fancontrol: line 477: let: mint=*1000: syntax error: operand expected (error token is "*1000") Which means, by some reason, and in some situations '${AFCMINTEMP[$fcvcount]}' ir null : root@helios4:~# grep -ni "let mint" /usr/sbin/fancontrol 477: let mint="${AFCMINTEMP[$fcvcount]}*1000"

Hello Igor,Werner, Thanks a lot

Hello, At least for the tests done with 2 other colleagues, Seems that Armbian kernel is missing a .config option.. 'CONFIG_SENSORS_PWM_FAN=y' Which is present in 'ayufan' kernels work.. ATS needs sysfs to communicate with the kernel driver, and is not there the pwm ctl: '/sys/class/hwmon/hwmon0/pwm1'

I am starting to think in adding 1 more :)

Hello Guys, Happy Helios4, for some time, user here.. Mine is running 3 disks, iddle ~7 watts, working - 20 watts( with very very brief peaks of 50 watts initially.. when disks are in APM 0, and jump to APM 127..). Does any one is running Helios4, with 4 disks in the raid setup? thanks in advance, regards

Probably not a good suggestion.. It needs to be created has a 64bit Filesystem, from the beginning, I think.. If turned ON, in a 32 bits one, I think it will Damage the FileSystem..

I haven't checked it, But the limitation has to do with, the tools for partitioning, since they are using default C types.. I think that somewere it time was released a flag to so this problem -O 64bit Check this See the content of: cat /etc/mke2fs.conf in ext4 is there a -O 64bit option, but I think it only works if filesystem was created with 64 bits, from the beginning.. So a resize2fs -b /dev/sdx -b Turns on the 64bit feature, resizes the group descriptors as necessary, and moves other metadata out of the way. will only work in a previous 64 bits available fs.. But I have never tested it

Indeed, One other thing is yet to look if you are running NFS.. I had one problem with NFS , wen I mounted on the client, machine, just shutdown and start, the disks are always going down and start.. The disks power was cut abruptly when system went down every time.., and even with system up, they had that behaviour Solution until now... not mounting NFS, until I understand what is causing that problem( That was NOT happening in Helios4, but in another ARM based system.. ) To me, his problem its or related with one of: park/unpark heads aggressively( Which he needs to fix APM modes and timers on each disk.. ) NFS or any other think, munted and is creating kernel panics or so.. So to check, I would deactivate nfs,samba, and so on. Only OS running without application layers.. Then check if problem persists, if yes: Mesure power cycles and load/unload heads, and see if it happening with frequency.. for blockid in {a..c};do smartctl --attributes /dev/sd${blockid}|grep -E "^ 12|^193"; done I also Have Seagate disks, in APM mode 127, so they enter in mode 1( standby, after the timers defined period ), but they don't park and unpark like crazy, they work very nicely.. In the past I had WD REd, and that disks, were parking and unparking like crazy, I could only aliviate the problem encreasing the timmers to tnter in APM mode 1, but I couldn't do much more.. Does he, configured timers for APM modes?If you do that with small timers, heads will start parking/Unparking at that intervals defines, and need to be adjusted again.. Use OpenSeaChest Utilities to verify more information not present in SMART, since this tools are made for Seagate disks, and implement Seagate Technology..

You welcome Ok I was in the opinion that maybe we could but, your point 2., is the answer I needed ;) thanks

Humm, That sounds to me that your hdds are always parking/unparking heads like crazy...( which could limit its life cycle.. ) It could be a problem related with APM features.. Does you have OS in harddrives? Try to mesure the output of this command, in time(lets say within 15 minutes intervals), and see if load/unload increase a lot: for blockid in {a..c};do smartctl --attributes /dev/sd${blockid}|grep -E "^ 12|^193"; done Regards

Hello, Adjust your fancontrol settings, I use this ones: root@helios4:~# cat /etc/fancontrol # Helios4 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/dev/fan-j10/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-j17/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-j10/pwm1=60 /dev/fan-j17/pwm1=65 MAXTEMP=/dev/fan-j10/pwm1=65 /dev/fan-j17/pwm1=70 MINSTART=/dev/fan-j10/pwm1=20 /dev/fan-j17/pwm1=20 MINSTOP=/dev/fan-j10/pwm1=29 /dev/fan-j17/pwm1=29 #MINPWM=0 Yes, the CPU Scheduler.. The Option I found is putting into /etc/rc.local # Force CPU sheduler Ondemand cpufreq-set -g ondemand It is indeed ondemand, but freq seems to be at 1.6 Ghz.. so this will put it ondemand again, and it seems to work With both settings above, my disks ar at: root@helios4:~# hddtemp /dev/sd{a,b,c} /dev/sda: ST4000VN008: 21 C /dev/sdb: ST4000VN008: 22 C /dev/sdc: ST4000VN008: 22 C And CPU( which seems to support 100C ) are at: root@helios4:~# cat /sys/devices/virtual/hwmon/hwmon1/temp1_input 60359 reboot your Helios4 and check if everything is ok now