NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
(Case Solved) Nightmarish Ultra 6 4.2.18 update aftermath
CASE CLOSED : Apparently a user folder ended up in the OS folder and filled it up, probably a case of PEBCAK on my part which coincided with the update.
Owner of a ReadyNAS Ultra 6 for 9 months without trouble, I've encountered my first problem with the upgrade to RAIDiator 4.2.18.
Hardware : Stock ReadyNAS Ultra 6
Firmware : RAIDiator 4.2.18, SSH enabled (from 4.2.17)
Hard drives : 6x 1.5TB Samsung HD154UI in X-RAID2, 6448GB of 6931GB used
Clients : Mac OS X Snow Leopard, Windows 7 Pro 64, both using Chrome, IE9 or Safari to access the web interface
After the update things went absolutely FUBAR, here are the symptoms so far :
- At first shares are visible but any attempt to access them through CIFS ends up with a permission warning, a check on the web interface shows the permissions haven't changed.
- Later on (around 10 to 20mn after boot) the shares disappear altogether, a quick check on the web interface shows CIFS and FTP sharing are suddenly offline, attempts to reactivate them fail (you check them, apply, they are still unchecked, most other settings fail to "stick" in the same manner).
- Then the fan "LED" blinks yellow, a check on component status shows 5 entries for fans, the first one OK but empty, the second one named SYS1 reporting 0rpm, the third one named SYS2 reporting the proper rpm and two more empty ones; Likewise, the CPU reported temp is abnormal at this stage, instead of being around 20°C, it is around 10°C which is barely probable, also, there is a third, empty temperature report in addition to CPU and SYS.
- Worse, after some time (around 20 to 40mn after boot) the web interface stops reporting the shares, the list of shares indicates there are no share at all.
- Attempts to rollback to 4.2.17 are fruitless, the image check finding the file (RAIDiator-x86-4.2.17) not valid for this architecture.
- Attempts to use SSH (it was enabled under 4.2.17 to ease the migration of large folders from share to share) fail (connection refused).
- Any attempt to reboot or shutdown from the web interface doesn't work, at all.
- Logs are empty.
At the moment I'm stuck and worse, Ican't afford to do anything that might lose the data on the NAS as it is the backup for a main machine that already lost some of these data, so losing them on the NAS at this stage means losing them entirely (yeah, I know, I should have fixed the main earlier).
Any suggestion ?
Thanks in advance for your help.
Owner of a ReadyNAS Ultra 6 for 9 months without trouble, I've encountered my first problem with the upgrade to RAIDiator 4.2.18.
Hardware : Stock ReadyNAS Ultra 6
Firmware : RAIDiator 4.2.18, SSH enabled (from 4.2.17)
Hard drives : 6x 1.5TB Samsung HD154UI in X-RAID2, 6448GB of 6931GB used
Clients : Mac OS X Snow Leopard, Windows 7 Pro 64, both using Chrome, IE9 or Safari to access the web interface
After the update things went absolutely FUBAR, here are the symptoms so far :
- At first shares are visible but any attempt to access them through CIFS ends up with a permission warning, a check on the web interface shows the permissions haven't changed.
- Later on (around 10 to 20mn after boot) the shares disappear altogether, a quick check on the web interface shows CIFS and FTP sharing are suddenly offline, attempts to reactivate them fail (you check them, apply, they are still unchecked, most other settings fail to "stick" in the same manner).
- Then the fan "LED" blinks yellow, a check on component status shows 5 entries for fans, the first one OK but empty, the second one named SYS1 reporting 0rpm, the third one named SYS2 reporting the proper rpm and two more empty ones; Likewise, the CPU reported temp is abnormal at this stage, instead of being around 20°C, it is around 10°C which is barely probable, also, there is a third, empty temperature report in addition to CPU and SYS.
- Worse, after some time (around 20 to 40mn after boot) the web interface stops reporting the shares, the list of shares indicates there are no share at all.
- Attempts to rollback to 4.2.17 are fruitless, the image check finding the file (RAIDiator-x86-4.2.17) not valid for this architecture.
- Attempts to use SSH (it was enabled under 4.2.17 to ease the migration of large folders from share to share) fail (connection refused).
- Any attempt to reboot or shutdown from the web interface doesn't work, at all.
- Logs are empty.
At the moment I'm stuck and worse, Ican't afford to do anything that might lose the data on the NAS as it is the backup for a main machine that already lost some of these data, so losing them on the NAS at this stage means losing them entirely (yeah, I know, I should have fixed the main earlier).
Any suggestion ?
Thanks in advance for your help.
10 Replies
Replies have been turned off for this discussion
- You other problem is that the HD154UI is not an approved drive on any ReadyNAS.
You could try to download 4.2.18 onto a PC and then try a local upgrade if you can get to Frontview. - Thanks for the suggestion, I completely forgot to start by that; concerning the drives, when I chose them, while they were not approved at the time, there was no indication of incompatibility, since they worked flawlessly for 9 month I doubt they chose to raise hell at the same time I updated the firmware.
Turns out the result of trying to load the 4.2.18 image is the same as with 4.2.17, "not valid for this architecture"...
So no luck... - My advice would be to contact support and see what they can do for you.
Of course, if you're like me, you like to try to figure things out for yourself. It's possible that one of your drives is flaky and is what's causing the trouble. You may want to do the following to help isolate and/or eliminate the source of the trouble:
1. Download the logs from Frontview and take a look to see if there's anything of consequence.
2. Test your disks using vendor tools: http://home.bott.ca/webserver/?p=388
3. Test your RAM using the Boot Menu: http://home.bott.ca/webserver/?p=252 - Yep, I'd rather do it myself, especially with non-HCL drives and SSH enabled (even though I know Netgear support is very friendly).
1) RAM already checked, no trouble.
2) Drives checked 3 days ago, but I launched a new test just in case anyway.
3) Since the update the logs are clean, nothing there at all to download.
4) Since the last drive check the only 2 noticeable events were a disk scrubbing that went without a hitch last night (and no trouble since) and the 4.2.18 upgrade, after which troubles started.
However, since I see a lot of problems with the upgrade even finishing, I suspect mine was botched in some way.
Once the disk check are complete I'll try a firmware reinstall from the boot menu.
Thanks for your suggestions. - So...
RAM checked out fine again...
Disks checked out fine again...
Some symptoms start appearing only after trying to change parameters in Frontview, those conditionnal symptoms include the FUBARd fan and temp monitoring and the share disappearance, other symptoms are from boot or delayed without user interaction.
Now to the OS reinstall... - And, it's exactly the same after an OS reinstall...
P.S. :
Using a whole new array of disk gets me a working system, so far.
Getting back to factory default with the new array then trying to use the problematic one doesn't solve the problems.
All hardware, FS and root system checks on the drives are OK, yet it appears the trouble is related to this particular array of drives since 4.2.18.
Guess I'll have to see with support what can be done. - Sounds like the upgrade went FUBAR. I'm reasonably certain that support can remote in and fix things up for you. You'll need to open a ticket and ask for L3 support and put your unit in Tech Support (Telnet-mode) when requested.
You may also want to post your support ticket number here in the event that a Jedi feels a disturbance in the force. - Case closed thanks to L3 support, according to L2, it was due to a user folder ending up in the OS folder and filling it up, which seems rather strange and may be more a case of PEBCAK during a mv through SSH than anything else, the simultaneity with the upgrade would then just be coincidence; anyway, two thumbs up for L3 support, all seems fine so far.
- Thanks for the update. Glad everything got resolved. 8)
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
