NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
AMRivlin
Mar 21, 2013Apprentice
OS6 now works on x86 Legacy WARNING: NO NTGR SUPPORT!
Update: It is now unofficially possible using NTGR images to update legacy hardware to os6.X
See Post #3, for directions to install 6.2.1 on x86 Ultra and Pro Models. (ARM NOT SUPPORTED by this OS)
Be forewarned, this requires a SYSTEM WIPE and likely voids any warranty support from NTGR
Supported so far: pro 2/4/6, ultra 2/4/6, old pro / Pioneer Pro, 2100v2
Not Supported: NVX and 2100v1
Thanks go out to "HomeBrew Anonymous" for making this possible.
Update 2: A firmware image to downgrade back to 4.2.26 is now available. See this thread. While this downgrade should get you a working system again on the supported firmware, be forewarned this requires a SYSTEM WIPE and NetGear also does not provide support for this downgrade. If you have issues seek help on these forums.
Original Post/Gripes
I have been reading these forums since Monday's announcement and there has been a resounding "ooof" regarding the fact the Ultras and Pros are unsupported for future OS improvements.
To clear the air: it would appear Netgear will never support os6 on past hardware. I have almost come to grips with this, and at least they have been open and honest with their forward direction and aren't stringing us along. viewtopic.php?f=138&t=70131
The upside is our devices still work and are mostly stable and eventually we can upgrade to a new shell that has os6 support, but in the meantime our $500-1000 investment is unable to take advantage of modern features we all desire.
I don't think I can add a poll here at RN forums, but I would like to garner support for a 100% unsupported home brew of the os6 on Pro6 units.
If we get enough support perhaps a talented member(s) here would help release a homebrew of sorts.
The 3 main caveats are:
1. Netgear will never be held responsible/your warranty is void
2. A format is required (new FS and OS)
3. Data loss is highly possible
If you are still interested please post a reply to this thread.
mdgm and I have decided that its time to lock this thread. So please do post any new OS6 on Legacy issues on their own threads.
1,274 Replies
Replies have been turned off for this discussion
- chirpaLuminaryThe USB Boot Recovery process on Dave's page should restore it to 4.2. You'll then have to trigger a factory default.
Also, if you want to run this as a VM instead; viewtopic.php?f=35&t=70699 - mdgm-ntgrNETGEAR Employee Retiredchristerj77's symptoms when updating to R6 are consistent with not doing the required factory default (wipes all data, settings, everything) as part of the procedure to update to ReadyNAS OS 6.
This is not a case where USB Boot Recovery should have been attempted.
The Prep add-on if installed before the firmware update should force a factory default as part of the upgrade. If it doesn't you can still do a factory default via the boot menu. - christerj77AspirantI feel so stupid after reading about clearing the cache for the webbrowser, that did work.
I did try the factory default with the boot menu also yesterday but since firefox was using the cached page that did not help, ty for your help :)
It seams like i cant find the nas with the raidar tool anymore, is this normal with OS6? - mdgm-ntgrNETGEAR Employee RetiredCan you access the Dashboard?
RAIDar isn't as reliable at detecting devices running the new OS as it was at detecting devices running the old OS. - christerj77AspirantYes the dashboard works just fine now.
I have read about high fan speed, my is running at 5355 rpm, is that to high? - mdgm-ntgrNETGEAR Employee RetiredIt's not running at 5355 RPM (that's faster than your fan will go). The UI for the new OS reports 5355 RPM for the old devices all the time regardless of the fan speed.
- chirpaLuminaryUpdated my R6 in VM thread with an OVA appliance to easily test it out: viewtopic.php?f=35&t=70699
- durham70AspirantAfter trying it in a VM (and then backing up my data) took the plunge and upgraded my readynas ultra 4 to 6.0.4
Can't believe how much better the interface is !
Only drawback is my wife complaining about the noise of the fans :)
(Readynas lives in her home office....) - sventunusAspirantI've been held back on obtaining a time slot to perform the upgrade from 4.2 to OS6 on my Ultra6 guys, sorry for the delay...
The Ultra was in PRD until last night. It's free now for me to perform the upgrade. Aiming to do that this week. Week is booked pretty full though, will see if I can make the time for it.
Anyway, if it's not this week, then for sure next week or the forthcoming weekend! I'll keep you posted on my experiences.
Sven - RoyanAspirantHi.
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 the sensors 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.
The script is as follows:
ernst:~/bin# cat fan-monitor
#!/bin/bash
# files
lock="/tmp/.fan-monitor.lock" # lock file (needed?)
log="/root/log/fan-monitor.log" # log file
pwm_file="/sys/devices/platform/it87.2576/pwm<X>" # pwm file
# 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
# get values from array
cpu0=$(echo ${list[2]} | cut -f3 -d' ' | grep -P -o "[0-9.]+" | cut -f1 -d'.') # sensors cpu0 temperature
cpu1=$(echo ${list[3]} | cut -f3 -d' ' | grep -P -o "[0-9.]+" | cut -f1 -d'.') # sensors cpu1 temperature
fan=$(echo ${list[15]} | cut -f2 -d' ') # sensors fan speed
fan_min=$(echo ${list[15]} | 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=""
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!
brgds
Royan
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!