NV+ SODIMM failed after RAIDiator 4.1.13 [SOLVED]

Originally there were four 250GB drives as XRAID. For testing and attempts at USB Recovery, there is one 1TB drive.

The NV+ response is no different with one drive than with four, at least in terms of how the power button responds (it doesn't) or which LEDs light up.

Is data recovery the chief concern, or it is simply getting the NAS running again?

The answer is, "it depends".

I have asked the organization to confirm whether an external backup drive was up to date since I can't examine logs. If the backup is current, then getting the NAS running again is the #1 concern. That option means repair vs. replace costs and benefits.

Otherwise, I assume my option is borrowing/renting an NV+ from a friend and making a current backup. That's assuming the drives from a working NV+ can simply be removed and replaced with the four 240GB drives from the non-functioning NV+ temporarily -- long enough to copy the data.

Is it feasible to swap NV+ arrays like that?

You can put the drives into another NV+ v1 chassis with no problem. You'd want to make sure the borrowed system is also at 4.1.13 - as it will attempt to downgrade your disks if it is not.

You can upgrade it if needed by inserting a temporary scratch disk, doing the normal install, and then upgrading. Then (if desired) downgrade by reinstalling the scratch disk, and manually installing the original firmware when done.

Put in your drives with the NAS powered down, and keeping them in their original slots. (its a good idea to label them while they are still in the current chassis). Disks are wiped if they are hot-inserted.

If you have access to an x86 linux system with enough drive connections, you can also manually mount the disks and recover data. There's a link here: viewtopic.php?f=11&t=66479

The normal guide is here: http://home.bott.ca/webserver/?p=306 But that is unavailable at the moment. Here's a copy from google's cache:

Simple step by step guide to mounting Sparc-based ReadyNAS Drives in x86-based Linux: Tested on brand new install of Ubuntu 10.10 (32bit x86), no other dependencies- 23rd Jan 2011 In a terminal window: (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 -o sync_read /dev/c/c /mnt That’s it!!! You can now see the mounted files in the /mnt directory (NB: Without the “-o sync_read” option to fuseext2 I had problems with copying large files. It kept saying the source file wasn’t found. After adding this option everything worked fine). ************************************************ Original Post When the ReadyNAS developers changed the default block size in RAIDiator 4.x to 16 KB (from 4 KB in version 3.x), there was concern from the community that users would be unable to mount drives from a failed ReadyNAS into a Linux computer. The concern is that the ReadyNAS Duo, NV+, X6, 600 & 1100 use a Sparc-based processor and that an x86-based PC cannot read 16 KB blocks. One of the developers, Skywalker, has provided some details and I have taken the liberty of editing his posts into an easy-to-follow step-by-step set of instructions. Quoting Skywalker: There is no “proprietary” filesystem running on any ReadyNAS. It is “straight”, ordinary, unmodified EXT3. You can even run all the e2fsprogs (debugfs, e2fsck, etc) on a 16KB ReadyNAS filesystem on a standard Linux PC with no modifications. Mounting a 16KB ReadyNAS filesystem on an x86 PC requires about the same amount of work as mounting an NTFS filesystem read/write on Linux — using a FUSE driver to mount it. The ext2fuse driver won’t come on any LiveCDs, so you’d need a full distro running with the necessary build tools installed. Ubuntu, Fedora, Debian… it doesn’t really matter. Once you get those installed, you need to get the ext2fuse source code from sourceforge.net. Using Debian, you can install the build tools by issuing the following command as root: apt-get install build-essential Download the ext2fuse package and extract it: tar xvzf ext2fuse-src-0.8.1.tar.gz Change to the directory of the extracted program Run the following command: ./configure Before compiling, open src/Makefile in an editor. Remove the lines that look like this: ext2fuse_DEPENDENCIES = ../lib/et/libcom_err.a \ ../lib/ext2fs/libext2fs.a Change this line: ext2fuse_LDADD = ../lib/et/libcom_err.a ../lib/ext2fs/libext2fs.a To this: ext2fuse_LDADD = -lcom_err -lext2fs Then build the executable by running make: make Next, install the package by running make install: make install After compiling and installing the package, you’ll need to load the fuse module: modprobe fuse Next, run the following commands to recover the volume group information and then activate it: vgscan vgchange -ay c Create a directory to mount the array: mkdir /mnt/lvm Mount the array: ext2fuse /dev/c/c /mnt/lvm If successful, you should see: /dev/c/c is to be mounted at /mnt/lvm fuse-ext2 initialized for device: /dev/c/c block size is 16384 At this point, your ReadyNAS data volume should be mounted on /mnt/lvm and you should be able to access your data. I haven’t tried this myself (I gave my NV+ to my dad), but welcome any feedback on making it better. Update (May 22, 2010) – Have a look at this for additional information: http://greyproc.blogspot.com/2010/04/re ... buntu.html Alternative Method If you are trying to recover data from a Duo (or from a disk with only 1 or 2 disks in the array), then you may be able to recover the data using the following method: Connect your faulty disk to PC using a SATA to USB cable Download, install & run the free software R-Linux from www.r-tt.com Copy the recovered data from the faulty disk

Wow, thank you!! This is very, very helpful.

I labeled each drive with the slot number when I removed them, so I'm hoping the drives are ok. I friend has a working NV+, so I'll see if he will loan me his unit to use for extracting the data, just in case the nonprofit's NV+ is fried.

I will post results. Thanks again!

Good news!

I replaced the SODIMM with a Crucial Technology CT12864X335 (Amazon item B0002VAQR4, http://www.amazon.com/gp/product/B0002VAQR4/) and the ReadyNAS is alive again! The LCD panel lit up, the ReadyNAS booted from the single 1TB drive with firmware 4.1.13; I then rebooted it without error, shutdown, replaced the original drives in the original slots, and it's working.

Not sure what caused the first SODIMM to go bad, maybe dust? (I thoroughly cleaned it, but found big wads of dust on the first SODIMM.)

In any case, I am very grateful to the ReadyNAS community for advice and assistance. Thanks mdgm, vandermerwe and StephenB!!

kmm454 wrote:

Good news! I replaced the SODIMM with a Crucial Technology CT12864X335 (Amazon item B0002VAQR4, http://www.amazon.com/gp/product/B0002VAQR4/) and the ReadyNAS is alive again! The LCD panel lit up, the ReadyNAS booted from the single 1TB drive with firmware 4.1.13; I then rebooted it without error, shutdown, replaced the original drives in the original slots, and it's working. Not sure what caused the first SODIMM to go bad, maybe dust? (I thoroughly cleaned it, but found big wads of dust on the first SODIMM.) In any case, I am very grateful to the ReadyNAS community for advice and assistance. Thanks mdgm, vandermerwe and StephenB!!

The problems you describe are exactly the problem I just had today when resurrecting my original ReadyNAS NV with a new PSU. I re-installed my stock/OEM 256MB stick and the unit booted fine. I will give the part you link on Amazon.com a try, I suppose, under the assumption that I too had a stick of RAM "go bad" with 4.1.13. While Murphy might be proud of the situation, I suspect there is a firmware issue related to our former RAM upgrade parts.

My former 1GB part was: Crucial/Micron CT12864X335.16FFY 1GB 128Mx64 DDR (which appears to be the exact same part as your replacement? According to Amazon.com, I ordered this exact part in Feb of 2009.)

Short follow-up... went ahead and ordered the exact same SODIMM from Amazon to see if my original part had indeed gone dead... and in fact it had. Call it a weird coincidence, but if you have this error, try a new CT12864 part. No idea if something in the 4.1.13 RAIDiator update itself could have caused hardware failure, but the timing is impeccable.

I'll see if Crucial will lifetime warranty the old (presumably defective) part so I have a spare for future use.

Thanks for this thread. It saved me a lot of time and applied to me as well....

Situation / Status: I had my original ReadyNAS NV+ no longer boot after a power failure (my UPS went bad) with the same symptoms -- flashing blue LED in the power button followed by disk LEDs 1 and 3 steady and unable to turn off the unit using the power button. It was not clear what to do next as there were two paths -- the more likely one given the LED indication and based on the various web resources was to boot from a USB drive and restore the OS. However, like scootie -- my issue was resolved by replacing the DIMM which I assume failed. This unit came from Infrant with the 1GB upgrade installed and, other than the bad power supply early on and the sticky drive trays, has provided excellent service for nearly 10 years. Luckily I found the original 256MB DIMM from my second ReadyNAS that I had upgraded to 1GB years earlier and was able to reboot the older NAS using the old DIMM. To my relief, the unit did an FS check and resynch and seems to be working fine. I have since ordered a new 1GB DIMM which I will swap in when it arrives as I expect to keep using this NAS for many more years.

The whole thing seems a bit suspicious to me as I too am running 4.1.13. However, as mentioned, this happened with an Infrant (Netgear) installed 1GB DIMM and my other unit with an aftermarket Corsair has not (yet) exhibited the same problem. I sure hope it does not when I next reboot it.

Incidentally, I convinced myself having two ReadyNAS NV+ units provides me some additional redundancy in the event of a system failure. Presumably I can just move my drives (preserving their order) from one unit to the other to recover my data.

jsoto wrote:

Thanks for this thread. It saved me a lot of time and applied to me as well.... Situation / Status: I had my original ReadyNAS NV+ no longer boot after a power failure (my UPS went bad) with the same symptoms -- flashing blue LED in the power button followed by disk LEDs 1 and 3 steady and unable to turn off the unit using the power button. It was not clear what to do next as there were two paths -- the more likely one given the LED indication and based on the various web resources was to boot from a USB drive and restore the OS. However, like scootie -- my issue was resolved by replacing the DIMM which I assume failed. This unit came from Infrant with the 1GB upgrade installed and, other than the bad power supply early on and the sticky drive trays, has provided excellent service for nearly 10 years. Luckily I found the original 256MB DIMM from my second ReadyNAS that I had upgraded to 1GB years earlier and was able to reboot the older NAS using the old DIMM. To my relief, the unit did an FS check and resynch and seems to be working fine. I have since ordered a new 1GB DIMM which I will swap in when it arrives as I expect to keep using this NAS for many more years. The whole thing seems a bit suspicious to me as I too am running 4.1.13. However, as mentioned, this happened with an Infrant (Netgear) installed 1GB DIMM and my other unit with an aftermarket Corsair has not (yet) exhibited the same problem. I sure hope it does not when I next reboot it. Incidentally, I convinced myself having two ReadyNAS NV+ units provides me some additional redundancy in the event of a system failure. Presumably I can just move my drives (preserving their order) from one unit to the other to recover my data.

The only failure I have ever experienced with my NV+ involved a firmware upgrade [attempt] with a 1GB DIMM installed. The ugly problem that resulted required I exchange my chassis with Netgear. I restored the "refurb" replacement from Netgear with the original 256 DIMM, bought a 2nd chassis for backup, and have no need or interest to ever use that 1GB DIMM again.

It was silly of me to bother with a 1GB DIMM since I don't use my NV+ for anything but storage of PC backups which happen every day, but IMO unless there's a specific issue one is having with one's NV+ that is certain to be solved with 1GB RAM, I don't think it's worth attempting. My suspicion is that something about the chassis firmware or Linux software doesn't like a gig of memory. And yes my sig is correct--I haven't updated FW in my unit for years--gunshy now for sure.