NV+ SODIMM failed after RAIDiator 4.1.13 [SOLVED]

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