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.
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!
