NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Original Infrant ReadyNAS NV powers up but not responding
After a recent power outage, our original Infrant NV seems to turn on but will not respond. It was populated with 3 WD 3 TB drives and has been that way for 6 or 7 years working perfectly. So prefe...
Well I've been rooting around the rabbit hole for a while now and I'm finally up for air. I was trying to use System Rescue CD but that was a dead end as it was too hard for me to add the necessary software without apt-get. I switched and set up a live persistent USB with Mint 18 and was able to access the files. As we speak they are being transfered to another drive. The USB was very easy to setup using Windows software here: https://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/
As many here know, the key was to use "fuseext2". Not "fuse-ext2" and not "mount". For those who are reading this without seeing alot of other info the SPARC versions of the ReadyNAS NV with version 4.x firmware use a non-standard 16k block size so fuseext2 is the only one that will play nice-ish. I still could not access the mounting with any GUI applications on Mint and it would lock up the LV if I tried. With my level of knowledge the only way out at that point was a reboot.The following instructions posted elsewhere will work. Just use the right mounter fuseext2 and do not add a dash. That was a huge time waster for me.
(1) sudo su (2) apt-get install fuseext2 (3) apt-get install lvm2 (4) modprobe fuse (5) vgscan (6) vgchange -ay c (7) fuseext2 -o ro /dev/c/c /mnt (7) fuseext2 -o ro -o sync_read /dev/c/c /mnt That’s it!!! You can now see the mounted files in the /mnt directory
While the clues were there, it took a long time for me to put them together. On an unsuccessful mount, Mint gives some advice to check the dmesg using
Code: dmesg | tail where I found this:
Code: EXT3-fs (dm-3): error: bad blocksize 16384
Googling the message found someone with the same issue and that fuseext2 must be used to accommodate the nonstandard block size. With that change, it was off to the races and plodding through authoring the proper rsync and find commands to get what I wanted.
I still like the tool set on the SytemRescueCD and while it can be done, I don't think I am at the level to add the software required to this live CD. It is a shame that it is not easier as there are always new (or old) tools that come along a person might need or want when troubleshooting.
Thank you very much for the time you spent considering my challenge. Just knowing there are knowledgeable people like you willing to help lowered the anxiety greatly.
Hombibi wrote:
Hi Stephen, not sure if you are arguing against me but please note that I never suggested or even discussed restoring an HD image to a new harddisk and putting that one back. I have no idea if that works
LongTimer listed it as his first option earlier in the thread, and I was just trying to take that off the table. I wasn't disagreeing with you, just amplifying the intended use of the clone - which I think we agree is on.
On disk stress - These posts often get read much later on, so I do sometimes make clarifying statements for future readers. The idea that cloning is somehow easier on the failing disk than a RAID resync is just your opinion (and your link speaks to data recovery, not to RAID resync - which is quite different).
But we agree that making a clone to maximize success with data recovery is a good idea. As your link says, attempts at data recovery will often increase the failed sectors on the disk, and the clone does minimize that (because data recovery can make multiple passes over the disk, and the cloning process doesn't).
Ugggh. After hours of waiting, WD Diagnostics on Drive 1 came up with "Test Result: Fail" "Test Error Code: 08-Too many bad sectors detected" and the Smart report from WD Diagnostics doesn't give raw numbers. Not much to go on.
so used smartctl to have a closer look. See below. Not alot more detail but at least there are raw numbers shown. I assume bad sectors show up in the reallocated sector count. Weird that the reallocated sector count is 0 but the attribute says shows signs of failure. "currrent pending sector" now at 3.
I guess I had better get clones made of all. Can the clones be put on one big drive per my question above?
C:\Users\Saul>smartctl -x sdc
smartctl 6.6 2017-11-05 r4594 [x86_64-w64-mingw32-win7-sp1] (sf-6.6-1)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
Warning: Limited functionality due to missing admin rights
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF)
Device Model: WDC WD20EARS-00MVWB0
Serial Number: WD-WMAZ20115523
Firmware Version: 50.0
Device is: In smartctl database [for details use: -P show]
ATA Version is: [No Information Found]
Local Time is: Thu Mar 29 01:15:20 2018 PDT
SMART support is: Available - device has SMART capability.
Enabled status cached by OS, trying SMART RETURN STATUS cmd.
SMART support is: Enabled
AAM feature is: Unavailable
APM feature is: Unavailable
Rd look-ahead is: Unavailable
Write cache is: Unavailable
DSN feature is: Unavailable
ATA Security is: Unavailable
Wt Cache Reorder: Unavailable
Read SMART Thresholds failed: Function not implemented
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (37200) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
No General Purpose Logging support.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 424) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate POSR-K 200 200 --- - 17
3 Spin_Up_Time POS--K 164 164 --- - 6783
4 Start_Stop_Count -O--CK 100 100 --- - 100
5 Reallocated_Sector_Ct PO--CK 200 200 --- - 0
7 Seek_Error_Rate -OSR-K 200 200 --- - 0
9 Power_On_Hours -O--CK 014 014 --- - 63020
10 Spin_Retry_Count -O--CK 100 253 --- - 0
11 Calibration_Retry_Count -O--CK 100 253 --- - 0
12 Power_Cycle_Count -O--CK 100 100 --- - 65
192 Power-Off_Retract_Count -O--CK 200 200 --- - 53
193 Load_Cycle_Count -O--CK 106 106 --- - 283001
194 Temperature_Celsius -O---K 115 104 --- - 35
196 Reallocated_Event_Count -O--CK 200 200 --- - 0
197 Current_Pending_Sector -O--CK 200 200 --- - 3
198 Offline_Uncorrectable ----CK 200 200 --- - 0
199 UDMA_CRC_Error_Count -O--CK 200 200 --- - 0
200 Multi_Zone_Error_Rate ---R-- 200 200 --- - 3
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning
Read SMART Log Directory failed: Function requires admin rights
General Purpose Log Directory not supported
SMART Extended Comprehensive Error Log (GP Log 0x03) not supported
Read SMART Error Log failed: Function requires admin rights
SMART Extended Self-test Log (GP Log 0x07) not supported
Read SMART Self-test Log failed: Function requires admin rights
Read SMART Selective Self-test Log failed: Function requires admin rights
SCT Commands not supported
Device Statistics (GP/SMART Log 0x04) not supported
Pending Defects log (GP Log 0x0c) not supported
SATA Phy Event Counters (GP Log 0x11) not supported
C:\Users\Saul>
LongTimer wrote:
Ugggh. After hours of waiting, WD Diagnostics on Drive 1 came up with "Test Result: Fail" "Test Error Code: 08-Too many bad sectors detected" and the Smart report from WD Diagnostics doesn't give raw numbers. Not much to go on.
so used smartctl to have a closer look.
Lifeguard does an an icon on the main page that will show you the smart stats. Did you capture smartctl after you ran the diag? Normally you would see much higher reallocated sectors (or off-line recorrectable, etc) than you are seeing. But it could be simply that you didn't run smartctl as admin/root.
LongTimer wrote:
I guess I had better get clones made of all. Can the clones be put on one big drive per my question above?
The usual tools do a sector-by-sector copy to another drive - they don't create an image of some sort, instead they do an exact copy. FWIW, these can be put in the NAS as a substitute for the original drive (powered down), but as noted above that can create filesystem corruption. Going directly to data recovery is safer.
Anyway, I think you should test the remaining drives, and get replacements to clone the ones that fail. I'd get WD20EFRX (2 TB reds), since they are intended for NAS use, and you can use them in the NAS later on.
I don't think you need to clone drives that are healthy, but you should capture the smart stats after each one is tested - lifeguard's thresholds for failure are higher than mine (it will pass drives I won't use).
Well I've been rooting around the rabbit hole for a while now and I'm finally up for air. I was trying to use System Rescue CD but that was a dead end as it was too hard for me to add the necessary software without apt-get. I switched and set up a live persistent USB with Mint 18 and was able to access the files. As we speak they are being transfered to another drive. The USB was very easy to setup using Windows software here: https://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/
As many here know, the key was to use "fuseext2". Not "fuse-ext2" and not "mount". For those who are reading this without seeing alot of other info the SPARC versions of the ReadyNAS NV with version 4.x firmware use a non-standard 16k block size so fuseext2 is the only one that will play nice-ish. I still could not access the mounting with any GUI applications on Mint and it would lock up the LV if I tried. With my level of knowledge the only way out at that point was a reboot.The following instructions posted elsewhere will work. Just use the right mounter fuseext2 and do not add a dash. That was a huge time waster for me.
(1) sudo su (2) apt-get install fuseext2 (3) apt-get install lvm2 (4) modprobe fuse (5) vgscan (6) vgchange -ay c (7) fuseext2 -o ro /dev/c/c /mnt (7) fuseext2 -o ro -o sync_read /dev/c/c /mnt That’s it!!! You can now see the mounted files in the /mnt directory
While the clues were there, it took a long time for me to put them together. On an unsuccessful mount, Mint gives some advice to check the dmesg using
Code: dmesg | tail where I found this:
Code: EXT3-fs (dm-3): error: bad blocksize 16384
Googling the message found someone with the same issue and that fuseext2 must be used to accommodate the nonstandard block size. With that change, it was off to the races and plodding through authoring the proper rsync and find commands to get what I wanted.
I still like the tool set on the SytemRescueCD and while it can be done, I don't think I am at the level to add the software required to this live CD. It is a shame that it is not easier as there are always new (or old) tools that come along a person might need or want when troubleshooting.
Thank you very much for the time you spent considering my challenge. Just knowing there are knowledgeable people like you willing to help lowered the anxiety greatly.Just to summarize. Without the mis-steps, recovering the data could have been relatively easy and I can highly recommend using a persistent linux Mint USB stick. You will need to use a terminal session for everything so the Mint GUI is more of a warm fuzzy:
-make a persistent live Mint USB (https://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/) in Windows
-pull all the drives, label and clone them one at a time using ddrescue (thanks Hombibi) in Mint
-connect the drives and mount using the recipe above (make sure you mount using fuseext2) in Mint
-copy the data of with rsync (this could be easy or take some time to figure out depending on what you want) in Mint
Here is the link to the forum post that made it all make sense:
https://askubuntu.com/questions/379154/attempting-to-read-lvm-disk-in-ubuntu
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
