This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Hi.
I have made a basic bash script for fan-control based on cpu temperatures. It's running via crontab and it needs root user.
This requires some tweaking to get it to work in each individual case, and is supplied here as a template. This is based on my PRO2 and my environment. The temperature/fan speeds used here may not be suitable to your environment It is not a cut/paste job if you want to use it. I will not be held responsible in any way if it cooks your nas! Your box, your responsibility!
Prerequisites: 1. SSH root access 2. Working setup of lm-sensors
You need to have lm-sensors installed, and an output through thesensors program similar to this:
ernst:~/bin$ sensors line 0: coretemp-isa-0000 line 1: Adapter: ISA adapter line 2: Core 0: +51.0°C (high = +80.0°C, crit = +100.0°C) line 3: Core 1: +43.0°C (high = +80.0°C, crit = +100.0°C) line 4: it8721-isa-0a10 line 5: Adapter: ISA adapter line 6: NC: +0.00 V (min = +0.00 V, max = +0.00 V) ALARM line 7: V5_0: +4.91 V (min = +5.47 V, max = +5.47 V) ALARM line 8: NC: +0.00 V (min = +0.00 V, max = +0.00 V) ALARM line 9: NC: +0.00 V (min = +0.00 V, max = +0.00 V) ALARM line 10: V3_3: +3.30 V (min = +2.76 V, max = +3.18 V) ALARM line 11: VCOR: +1.16 V (min = +0.00 V, max = +0.00 V) ALARM line 12: V+12: +11.87 V (min = +13.33 V, max = +13.33 V) ALARM line 13: 3VSB: +3.31 V (min = +4.61 V, max = +5.30 V) ALARM line 14: VBat: +3.26 V line 15: SYSFAN: 1490 RPM (min = 799 RPM) line 16: fan2: 0 RPM (min = 35 RPM) ALARM line 17: temp1: +0.1°C (low = -55.0°C, high = -122.0°C) ALARM sensor = thermal diode line 18: temp2: +0.0°C (low = +29.0°C, high = +51.0°C) sensor = thermal diode line 19: temp3: -0.1°C (low = +31.0°C, high = +75.0°C) sensor = disabled line 20: cpu0_vid: +2.050 V
("line xx:" are added by me) The critical lines are: Line 2,3 and 15 since I'm piping the output from sensors to an array, In each line the relevent values must be at word 3,3 and 2 respectively since I'm using the cut program on each array item to get the values.
In effect I'm reading line 2, word 3; line 3, word 3 and line 15, word 2 from the output, and then strip away unwanted characters.
# misc dt=$(date +"%F %R") # get timestamp for logging email_address="<your email address>"
# superuser check if [[ $EUID -ne 0 ]]; then # check if process is running as superuser echo $dt "This script must be run as root" >> $log # need su to write pwm file exit 10 fi
# check for lock [ -f "$lock" ] && exit # exit if another instance of this script >$lock # is writing to pwm file (not nessesary?)
# get output from sensors into an array OLDIFS="$IFS" # store current IFS IFS=$'\n' # set IFS to newline list=(`sensors`) # populate array from sensors output IFS="$OLDIFS" # restore original IFS
# read pwm values pwm=$(cat $pwm_file) # pwm value from pwm file pwm_min=50 # known minimum value pwm_max=255 # known maximum value
# determine cpu with highest temperature cpu=0 cpu_name="" if ((cpu0 >= cpu1)) then cpu=$cpu0 cpu_name="CPU0" else cpu=$cpu1 cpu_name="CPU1" fi
# verify cpu test has returned a value if ((cpu == 0)) then # log and send mail message="$dt: CPU test failed, cpu0: $cpu0, cpu1: $cpu1" echo $message >> $log echo -e "Subject:temp-monitor error\n$message" | /usr/sbin/sendmail $email_address rm -f $lock # cleanup lock exit 11 # exit error code fi
# determine new pwm value # new pwm is based on current pwm and temperature. # if we base first level test on current pwm, and then increase/decrease value # based on temperature, we will get a gradual stepping effect on fan speed. # below we split fan speed in 7 steps. minimum - 5 steps - maximum # a 5C increase in temperature will step the fan up # once you're in a step, there's a 10C window for that step # and once you're stepping down, a decrease of 5C will step down # the steps are: # pwm 50 - temp below 50. over 50, step up - nice and cool # pwm 60 - temp 45 - 55. over 55, step up; under 45, step down - this is all right, then # pwm 70 - temp 50 - 60. over 60, step up; under 50, step down - warm summer breeze # pwm 80 - temp 55 - 65. over 65, step up; under 55, step down - need some shade # pwm 100 - temp 60 - 70. over 70, step up; under 60, step down - getting hot in here # pwm 200 - temp 65 - 75. over 75 ,step up; under 65, step down - uncomfortable, fan me! # pwm 255 - temp over 70. keep fan max until temp drops below 70 - fan me now, damnit!
new_pwm=0 if (( pwm <= 50)); then if (( cpu >= 50)); then new_pwm=60 fi elif ((pwm <= 60)); then if ((cpu >= 55)); then new_pwm=70 elif ((cpu <= 45)); then new_pwm=50 fi elif ((pwm <= 70)); then if ((cpu >= 60)); then new_pwm=80 elif ((cpu <= 50)); then new_pwm=60 fi elif ((pwm <= 80)); then if ((cpu >= 65)); then new_pwm=100 elif ((cpu <= 55)); then new_pwm=70 fi elif ((pwm >= 80 && pwm < 200)); then #pwm == 100 if ((cpu >= 70)); then new_pwm=200 elif ((cpu <= 60)); then new_pwm=80 fi elif ((pwm >= 200 && pwm < 255)); then #pwm == 200 if ((cpu >= 75)); then new_pwm=255 elif ((cpu <= 65)); then new_pwm=100 fi elif ((pwm == 255)); then if ((cpu <= 70)); then new_pwm=200 fi fi
# check new pwm value if ((new_pwm == 0)); then # no new pwm value = no need to do anything echo "$dt: OK: $cpu_name: $cpu, pwm: $pwm" >> $log # log ok status if you want to keep track of what's happening rm -f $lock # cleanup locks exit 0 # exit with ok status fi
# ok, now we have a new pwm value and need to set it # # --> uncomment the next 2 lines to actually update fan speed <-- # #command_out=$( `echo $new_pwm > $pwm_file` 2>&1 ) # write new pwm value to pwm file, and catch any output #command_rc=$? # get error codes
# # --> comment the next line when you uncomment the two lines above <-- # command_rc=0 # <- will log ok status and send ok mail
uptime=$(echo `uptime`) # get extra data for email
if(( command_rc == 0)); then # no errors setting pwm. # log and send mail message="$dt: pwm changed: $pwm -> $new_pwm, $cpu_name temp: $cpu" echo $message >> $log echo -e "Subject:temp-monitor\n$message\nfan: $fan \nuptime: $uptime" | /usr/sbin/sendmail $email_address else # oops, we got an error setting new pwm. # log and send mail message="$dt: ERROR setting pwm: $pwm -> $new_pwm, $cpu_name temp: $cpu - ERRROR rc: $command_rc, stdout and stderr: $command_out" echo $message >> $log echo -e "Subject:temp-monitor error\n$message\nfan: $fan\nuptime: $uptime" | /usr/sbin/sendmail $email_address fi
#cleanup locks rm -f $lock
Important lines here are: - email_address="<your email address>" - pretty self explanatory 🙂 - pwm_file="/sys/devices/platform/it87.2576/pwm<X>" - <X> must be replaced with the pwm file number that corresponds to the fan you want to control. Afaik there are 3 pwm files in /sys/devices/platform/it87.2576/, named pwm1, pwm2 and pwm3. Look at the files named pwmX_enable to see which are active. In my case the values are: pwm1_enable: 1, pwm1:60 pwm2_enable: 0, pwm1:255 pwm3_enable: 0, pwm1:255 which indicates to me that pwm1 is the file I want.
I have commented out the lines that do the actual updating in this script. Look at this section when you want to do the actual updating:
# # --> uncomment the next 2 lines to actually update fan speed <-- # #command_out=$( `echo $new_pwm > $pwm_file` 2>&1 ) # write new pwm value to pwm file, and catch any output #command_rc=$? # get error codes
# # --> comment the next line when you uncomment the two lines above <-- # command_rc=0 # <- will log ok status and send ok mail
Finally there's the root users crontab:
ernst:~/bin# crontab -l # Edit this file to introduce tasks to be run by cron. #... #... MAILTO=<your email address> # m h dom mon dow command * * * * * /root/bin/fan-monitor > /dev/null
This makes the script run once every minute. A side effect of running this as a cron job is that it spams the system log. Every time a cron job runs, it is registered in the system log.
As it is, it logs every run to a log file. If it finds an error, or it changes the fan speed, it will email me with the changes. My PRO2 is located in my living room, mainly running with a CPU temperature at about 48 to 52C , with a fan speed of about 1500RPM. I have been running this for about a week now, and it seems to do the job. But I can't guarantee that it is bug free!
As I said: this is a basic script made by a script noob! I have no doubt that someone can make a better, more efficient and more robust version easily. Maybe even a daemon 🙂 I anyone wants to step up: please do!
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Hi I installed 6.0.4 firmware on my ultra4. All work good exept fan. I use manual command to decrease fan speed. I succeed to install crashplan on my ultra 4 with 6.0.4 firmware. Now i ll try Royan script to automatically manage fan speed.
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
I've also installed it on my brand new Ultra 4 that I got at a clearance price... At first, I had some problems adding a second drive to create a mirror (2x 2TB WD Red). It was trying to use it as a second volume with no name. I couldn't delete it because of that. I've resolved this by doing a factory reset and copying my stuff back. Now, everything is working fine. I'd really like to have the temp and the fan speed in the GUI but I can live with that for now.
In the meantime, I've adapted Royan's script to run on the Ultra 4 (single CPU, some optimizations, etc.). All credits go to him.
As usual, here is the disclaimer : I'm not responsible of any damages caused by this script...
So, here it is :
#!/bin/bash
# log and send mail function sendmail { ( echo "To:$email_address" echo "From:$email_address" echo "Subject:$host: temp-monitor: $1" echo echo "$2" ) | /usr/sbin/sendmail -t --read-envelope-from echo $message >> $log }
# misc dt=$(date +"%F %R") # get timestamp for logging email_address="<your_email_address>" host=`hostname`
# superuser check if [[ $EUID -ne 0 ]]; then # check if process is running as superuser echo $dt "This script must be run as root" >> $log # need su to write pwm file exit 10 fi
# check for lock [ -f "$lock" ] && exit # exit if another instance of this script >$lock # is writing to pwm file (not nessesary?)
# get output from sensors into an array OLDIFS="$IFS" # store current IFS IFS=$'\n' # set IFS to newline list=(`sensors`) # populate array from sensors output IFS="$OLDIFS" # restore original IFS
# get values from array cpu0=$(echo ${list[2]} | cut -f3 -d' ' | grep -P -o "[0-9.]+" | cut -f1 -d'.') # sensors cpu0 temperature fan=$(echo ${list[14]} | cut -f2 -d' ') # sensors fan speed fan_min=$(echo ${list[14]} | cut -f7 -d' ') # sensors minimum fan speed
# read pwm values pwm=$(cat $pwm_file) # pwm value from pwm file pwm_min=50 # known minimum value pwm_max=255 # known maximum value
# determine cpu with highest temperature cpu=0
cpu_name="" cpu=$cpu0 cpu_name="CPU0"
# verify cpu test has returned a value if ((cpu == 0)); then message="$dt: CPU test failed, cpu0: $cpu0, cpu1: $cpu1" sendmail "ERROR" "$message" rm -f $lock # cleanup lock exit 11 # exit error code fi
# set the new pwm value for the fan speed. if ((cpu < 50)); then new_pwm=$pwm_min elif ((cpu > 70)); then new_pwm=$pwm_max else let new_pwm=($cpu-50)*10+50 fi
# check new pwm value if ((new_pwm == 0)); then # no new pwm value = no need to do anything echo "$dt: OK: $cpu_name: $cpu, pwm: $pwm" >> $log # log ok status if you want to keep track of what's happening rm -f $lock # cleanup locks exit 0 # exit with ok status fi
# don't resend emails if there is no change from previous run if ((new_pwm != pwm)); then # ok, now we have a new pwm value and need to set it command_out=$( `echo $new_pwm > $pwm_file` 2>&1 ) # write new pwm value to pwm file, and catch any output command_rc=$? # get error codes
uptime=$(echo `uptime`) # get extra data for email
if (( command_rc == 0)); then # no errors setting pwm. message="$dt: pwm changed: $pwm -> $new_pwm, $cpu_name temp: $cpu, fan: $fan uptime: $uptime" sendmail "Fan speed changed" "$message" else # oops, we got an error setting new pwm. message="$dt: ERROR setting pwm: $pwm -> $new_pwm, $cpu_name temp: $cpu, fan: $fan uptime: $uptime - ERRROR rc: $command_rc, stdout and stderr: $command_out" sendmail "ERROR" "$message" fi fi
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Anyone got any ideas regarding lm-sensors and Ultra 6?
i get the correct rpm for the fans, but i get N/A for the temp of the cpu (atom d510)
anyone knows how to fix the temp reading ?
(Ran 4.2.22 on it, but it was unstable because of bad termal paste, since i dont have any handy, i opted to install 6.0.4 on it with the fans at full speed and that is working flawlessly)
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Heh, exactly the same stuff from arctic cooling that ive used 😛 (just dont let any fish near it) 😉
- but anyway, it didnt fix the "suddenly the box doesnt respond" problem it keeps freezing, it did so on 4.2.22 as well, so its not a termal problem, maybe its a memory problem... ill have to run a mem test on the unit and see if that helps... or if anyone else has some ideas, im all ears 🙂
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Hi to all,
Here is how to fix fan and temperature issues with OS 6.0 on legacy systems : Fan and temperature controls are operational, but reports to GUI are false as well
NO WARRANTY / NO SUPPORT !!!
..with root access, execute the following commands: apt-get update && apt-get upgrade apt-get install lm-sensors fancontrol yes "" | sensors-detect sensors .......(to see your sensors values)
..give values to fan control echo "#fancontrol" > /etc/fancontrol pwmconfig ....... give answers to following tests / questions and give values to fan control ....... set interval to 5 seconds ....... save config file
..and now start fancontrol daemon (it will start automaticaly after reboot) /etc/init.d/fancontrol stop /etc/init.d/fancontrol start ...... enjoy your new silence !!!!
..use >> sensors << command to validate your values and fan RPM
..if you want to change pwmconfig values, you have to stop fancontrol daemon pwmconfig ............or update values directly in file /etc/fancontrol ....... and so on /etc/init.d/fancontrol stop /etc/init.d/fancontrol start
Tested on Ultra6 model.
For example, values for Ultra6 model are ( /etc/fancontrol file 😞
# Configuration file generated by pwmconfig, changes will be lost INTERVAL=5 DEVPATH=hwmon0=devices/platform/coretemp.0 hwmon1=devices/platform/it87.2576 DEVNAME=hwmon0=coretemp hwmon1=it8721 FCTEMPS= hwmon1/device/pwm3=hwmon0/device/temp2_input FCFANS= hwmon1/device/pwm3=hwmon1/device/fan3_input MINTEMP= hwmon1/device/pwm3=51 MAXTEMP= hwmon1/device/pwm3=58 MINSTART= hwmon1/device/pwm3=40 MINSTOP= hwmon1/device/pwm3=40 MINPWM= hwmon1/device/pwm3=40 MAXPWM= hwmon1/device/pwm3=255
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
glem wrote:
Hi to all,
Here is how to fix the fan issue with OS 6.0 on legacy systems : Fan control is operational, but reports to GUI are false as well
WITH NO WARANTY !!!
with root access, execute the following commands: echo "#fancontrol" > /etc/fancontrol apt-get install lm-sensors fancontrol yes "" | sensors-detect sensors (to see your sensors values) pwmconfig ....... ask to following answers & tests & give values to fan control ....... set interval to 5 seconds ....... save config file
and now start fancontrol daemon (it will start automaticaly after reboot) /etc/init.d/fancontrol start ...... enjoy your new silence !!!!
use sensors command to validate your values and fan RPM
if you want to change pwmconfig values, you have to stop fancontrol daemon /etc/init.d/fancontrol stop pwmconfig ....... and so on
Tested on Ultra6 model.
For example, values for Ultra6 model are (fancontrol file):
# Configuration file generated by pwmconfig, changes will be lost INTERVAL=5 DEVPATH=hwmon0=devices/platform/coretemp.0 hwmon1=devices/platform/it87.2576 DEVNAME=hwmon0=coretemp hwmon1=it8721 FCTEMPS= hwmon1/device/pwm3=hwmon0/device/temp3_input FCFANS= hwmon1/device/pwm3=hwmon1/device/fan3_input MINTEMP= hwmon1/device/pwm3=51 MAXTEMP= hwmon1/device/pwm3=58 MINSTART= hwmon1/device/pwm3=40 MINSTOP= hwmon1/device/pwm3=40 MINPWM= hwmon1/device/pwm3=40 MAXPWM= hwmon1/device/pwm3=150
Does this control both the CPU and System fan? Does the LCD screen turn off once raid initialization is complete?
Also has anyone figured out how to do dual redundancy with X-RAID2?
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
All fans controled by pwmconfig are monitored by fancontrol. For me, on Ultra6 model, LCD works fine, it turns off/on and displays infos as on 4.2.xx version if it's wrong for you, you can try >> apt-get install lcdproc
I've just tested with two disks in XRAID2, I have no experience about dual redondancy on OS 6.0
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
I know that RAID-6 is dual redundancy but RAID-6 is not expandable compared to the dual redundancy in X-RAID2 on 4.2.22. If it's possible to use dual redundancy in X-RAID2 on OS 6 that would be great.
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
So I decided to flash this and this is my second time. At first I thought there was something wrong so I restored with the usb flash option.
Here is the question: Is it normal for the nas to rebuild the file system after I flash this. I have 2 x 2TB hard drives in there and it has been accessing them for a while and the blue light is flashing. Or should I just give up and go back to the OS 4.2.X.
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
mdgm wrote:
Updating to ReadyNAS OS requires a factory default. The disks have to be synced sector-by-sector to setup the RAID.
So in other words what your saying is let it do its thing, since this is normal? LoL, thanks for your response.
I never really got to setup the raid or anything. I performed the update and upon reboot it seems to be syncing with the drives. So I will just let it perform whatever its doing.
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
With all the whining on the forum (and I've done my fair share) I have to give credit to Netgear for one thing. It seems like they now have a very tight development schedule, keeping ReadyNAS OS close to upstream patches. 6.0.5 is shipping with kernel 3.0.74 released April 16. Lets hope they can keep updating so that the new OS will not suffer the "rot" as the older versions have done. For a quick recap:
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
bajorgensen wrote:
With all the whining on the forum (and I've done my fair share) I have to give credit to Netgear for one thing. It seems like they now have a very tight development schedule, keeping ReadyNAS OS close to upstream patches. 6.0.5 is shipping with kernel 3.0.74 released April 16. Lets hope they can keep updating so that the new OS will not suffer the "rot" as the older versions have done.
The advantage of using a longterm kernel for the new OS is that minor kernel patches can relatively easily added. https://www.kernel.org/category/releases.html suggests that 3.0 will continue to receive patches till October this year. Hopefully around then they will be ready to update to a newer longterm kernel e.g. 3.2 which will receive updates for some years yet.
bajorgensen wrote:
Samba has also been updated to 4.0.5 released April 9.
The way the new OS is designed is also helpful for being able to update things like samba. An advantage of starting afresh on e.g. Samba 4.x and Netatalk 3.x means that NetGear can easily incorporate minor patches for those without having to test upgrades from e.g. very old versions of samba.
Re: OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Hi to all,
spiderman wrote: I was wondering if anyone on the forum has installed the new OS on a Pro not Pro 6 and what they have noticed in terms of performance, etc.
spiderman, may be this post can help you. I'm interested by performance comparison between OS 6.0.5 and 4.2.22 on legacy Ultra 6 , and I ran some very basic tests:
Here are results of throughput transfer test on Ultra 6 model running OS 6.0.5 and 4.2.22. with 2x disks in XRAID2 mode (like RAID1)
Configuration for this test was : 1x PC DELL E4200 CPU U9600 RAM 5GB SSD Samsung 256GB, 1xNIC, running Windows 7 2x ReadyNAS Ultra 6 CPU Atom D510 RAM 2GB 2xDD WD Red 3TB XRAID2, 2xNIC bonding ALB, (one NAS running RAIDiator 4.2.22 and one NAS running ReadyNAS OS 6.0.5) Gigabit network
Test : robocopy running on PC with 10 parallel threads to transfer files from PC to NAS and after from NAS to PC (example : robocopy \PC \\NAS /E /MT:10) Test with big files : 6 x divx, total 4056 MB Test with small files : 66 directories, 686 files (word, excel, pdf, jpg,...) , total 1293 MB
robocopy time reports are translated to MB/s, it's easier to compare.
Here are results, Higher is better
big files : 6 x divx, total 4056 MB PC -> NAS - 4.2.22 : 65.49 MB/s - OS 6.0.5 : 90.13 MB/s NAS -> PC - 4.2.22 : 70.62 MB/s - OS 6.0.5 : 75.85 MB/s
small files : 66 directories, 686 files (word, excel, pdf, jpg,...) , total 1293 MB PC -> NAS - 4.2.22 : 34.94 MB/s - OS 6.0.5 : 22.93 MB/s NAS -> PC - 4.2.22 : 35.91 MB/s - OS 6.0.5 : 35,91 MB/s
