NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Unable to Boot or Factory Reset ReadyNAS NVX Pioneer (RNDX400E)
Hi everyone, I ran into this forum thread while searching for answers to a very similar if not exactly the same problem. I have a Readynas NVX Pioneer edition and would really appreciate your adv...
If it is "could not properly extract..." that would suggest corrupt firmware on the internal flash as a possibility. This problem generally isn't observed until a factory reset is done so it seems likely. USB Boot Recovery might fix it but that can lead to the EEPROM getting corrupted.
Don't need to use the serial console to troubleshoot that, though it is an option.
As the NVX is 32-bit care has to be taken to ensure the 32-bit kernel is in the right place if manually extracting a copy of the firmware onto the internal flash, I think. If you go down the manual route you can either put a copy of the firmware image (don't put a zip file on, put the image) on a USB key or copy the firmware on some other way e.g. download it from a http (not https) website.
StephenB wrote:
Do you mean tech support mode? Or something else?
What commands have you entered (other than uname -a and cat /etc/os_version)
Yes, tech support mode sorry. I looked around the filesystem to see whether the disks showed up in /dev/ (they do).
Aside from that, like I said I'm not sure what I should look for without a service manual. I looked through the directories and read some files to try and find any logs that might indicate a faulty shutdown or a firmware update, but couldn't find anything. Didn't want to risk starting the raid script or mounting any of the drives to have a look.
Is there anything I could run to get useful information?
frankie0p wrote:
StephenB wrote:
Do you mean tech support mode? Or something else?
What commands have you entered (other than uname -a and cat /etc/os_version)Yes, tech support mode sorry. I looked around the filesystem to see whether the disks showed up in /dev/ (they do).
Is there anything I could run to get useful information?
You can gather some information on disk health with this:
# for i in a b c d e f g h i j k l m n; do smartctl -a /dev/sd${i} | egrep -i "Device Model|Serial Number|Reallocated_sec|ATA Er|offline_uncorrect|current_pending_sector|Power_on"; done
You could attempt to mount the OS partition (I don't think this would cause harm).
# start_raid.sh
# mount /dev/md0 /sysroot
It that works, you chould chroot, which would give you the full range of commands:
# mount --bind /proc /sysroot/proc
# mount --bind /dev /sysroot/dev
# mount --bind /dev/pts /sysroot/dev/pts
# mount --bind /sys /sysroot/sys
# chroot /sysroot /bin/bash
It is possible to look at the internal flash (though this is not something I've ever needed to do). This would be the smallest disk with a single partition (which you can find via cat /proc/partitions). Once you know the disk, you can mount the flash
# mount /dev/sdg1 /mnt
You will see the flash image as root.tlz (a compressed tar file). If you have mounted the OS partition, you could try extracting this to sysroot - that could be risky if the OS partition already contains linux. I suggest waiting for mdgm or one of the mods to comment before trying that.
# tar -avx -f root.tlz -C /sysroot/
Alternatively, you could copy it to a USB flash drive (assuming you know how to mount it), and examine it on another system. That should let you know if there was an attempt to convert the NAS to OS-6.
Good morning and happy Friday all.
Thanks so much to StephenB for that detailed walkthrough, it's been very illuminating. Kudos on its way.
Disk Health:
I ran the oneliner with a small adjustment and got the following output
# for i in a b c d e f g h i j k l m n; do smartctl -a /dev/sd${i} | egrep -i "Device Model|Serial Numbe r|ID#|Reallocated_sec|ATA Er|offline_uncorrect|current_pending_sector|Power_on"; done Device Model: ST32000542AS Serial Number: 5XW22XCR ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 2301 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 Device Model: ST32000542AS Serial Number: 5XW0MLTB ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 3698 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 Device Model: ST32000542AS Serial Number: 5XW1P5A1 ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 3579 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 Device Model: SAMSUNG HD204UI Serial Number: S2H7JD2B402601 ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 252 252 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 625 197 Current_Pending_Sector 0x0032 252 252 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 252 252 000 Old_age Offline - 0As far as I can gather from this and the smartctl man page, all the disks are in acceptable health and don't look like failing any time soon. Following this conclusion, I tried out mounting the OS partition and was pleasently surprised to find that worked also.
I then started to go through the process of mounting the flash, which was successful and allowed me to copy the entire contents of flash to a USB. I did have to have the USB plugged in on boot as it didn't register otherwise.
root@22N294RA00187:/# ls -la /mnt/flash/ total 52398 drwxr-xr-x 2 root 0 16384 Jan 1 1970 . drwxr-xr-x 3 root 0 4096 Sep 23 04:38 .. -rwxr-xr-x 1 root 0 354 Aug 18 2017 CSUMS.MD5 -rwxr-xr-x 1 root 0 1718218 Aug 18 2017 INITRD.GZ -rwxr-xr-x 1 root 0 3040368 Aug 18 2017 KERNEL -r-xr-xr-x 1 root 0 12424 Oct 1 2009 LDLINUX.SYS -rwxr-xr-x 1 root 0 169600 Aug 18 2017 MEMTEST -rwxr-xr-x 1 root 0 48031517 Aug 18 2017 ROOT.TLZ -rwxr-xr-x 1 root 0 650860 Aug 18 2017 SUPPLMNT.TLZ -rwxr-xr-x 1 root 0 532 Aug 18 2017 SYSLINUX.CFG -rwxr-xr-x 1 root 0 42 Aug 18 2017 VERSION.TXT -rwxr-xr-x 1 root 0 512 Feb 27 2011 VPDI tried using 7zip to open the file but this got to about 29% before giving "Data error: ROOT". However, the ROOT file it generated could be opened in notepad++ and was mostly human readable. Had an interesting moment of confusion when I saw listings for airport flights but I then realised it was a sample table in the files for SQL.
So I then took the USB to my linux machine. This took a few tries to get decompressing started. tar then decompresses what looks like an entire root directory, but exits with an error:
$> tar -vx -f root.tlz -C ./root ./bin/bash ... ./usr/share/mysql/sql-bench/Data/ATIS/fconnection.txt tar: Skipping to next header xz (stdin): Compressed data is corrupt tar: Child returned status 1 tar:Error is not recoverable: exiting now $>The file it stops on starts with a normal-looking list of rows from an sql table, but then gets confused and out of order, with random unrecognised characters appearing and the formatting dissapears. I haven't yet managed to get lziprecover to work on the data, though I will keep trying in the background.
Based on the information available, my current guess is that someone did do a firmware upgrade, but that it was the faulty RAM chip I replaced caused the errors; seeing as I can only find 4.3.21 version numbers anywhere.
I am not sure how to proceed with recovery and have a few questions in my mind:
- Is the root file in flash a copy of the OS partition on the disk? or vice versa? or neither?
- If the root file is corrupt, are any of the other contents of flash damaged?
- If I replace the contents of flash, can I get factory restore to work?
EDIT:
I forgot to add that in the /etc/sudoers file that was inside the TLZ archive, I found that both root and admin are users with passwords, though I can't find a passwd or shadow file. I can find these inside the OS partition on the NAS, and also shadow seems to have a copy called "shadow.1" that I can't find any mention of in the docs.
# cat /sysroot/etc/passwd root:x:0:0:root:/root:/bin/bash admin:x:98:98::/c/home/admin:/bin/false # cat /sysroot/etc/shadow root:$1$/3nocmnO$Odaqgd5zzR4oleBHEQ46T.:18892:0:99999:7::: admin:$1$HwBrp9DK$jXrwgOofbIHx3dMG/mAqD0:13959:0:99999:7::: # cat /sysroot/etc/sudoers # sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL) ALL admin ALL = NOPASSWD : /frontview/bin/empty_spool, /sbin/tune2fs, /usr/bin/net, /sbin/mdconfig, /sbin/mdadm, /frontview/bin/share_snapshot, /sbin/lvdisplay, /usr/sbin/repquota, /sbin/iwconfig, /usr/sbin/ethtool, /usr/sbin/smartctl, /bin/cat, /sbin/dumpe2fs, /bin/mount, /bin/umount, /usr/bin/killall, /frontview/bin/check_dir_compatibility.pl, /usr/bin/stat, /sbin/hdparm, /usr/bin/pdbeditSorry all for such a long post, if it makes anyone feel any better I'm finding this journey absolutely fascinating.
frankie0p wrote:I tried using 7zip to open the file but this got to about 29% before giving "Data error: ROOT". However, the ROOT file it generated could be opened in notepad++ and was mostly human readable.
If 7zip wrote a file to the flash memory then you should delete it.
frankie0p wrote:
So I then took the USB to my linux machine. This took a few tries to get decompressing started. tar then decompresses what looks like an entire root directory, but exits with an error:
I am not sure how to proceed with recovery and have a few questions in my mind:
- Is the root file in flash a copy of the OS partition on the disk? or vice versa? or neither?
- If the root file is corrupt, are any of the other contents of flash damaged?
- If I replace the contents of flash, can I get factory restore to work?
The root file is used for
- factory installs to empty disks
- OS reinstalls from the boot menu
The boot process also checks the firmware version in the flash, and compares that with what is on the OS. If there is a mismatch, then the system will use the root file to update (or downgrade) the OS.
There could of course be more damage in the flash - unfortunately checking or repairing damaged files in it isn't something I've never needed to do. There are other who have - mdgm or perhaps one of the mods ( Marc_V or JeraldM ) might have some guidance. Not sure if Sandshark has dealt with this before.
StephenB wrote:If 7zip wrote a file to the flash memory then you should delete it.
7Zip was running on my windows machine, working on a copy of the flash contents, I've been very careful to leave things as I found them so no worries there.
StephenB wrote:The root file is used for
- factory installs to empty disks
- OS reinstalls from the boot menu
The boot process also checks the firmware version in the flash, and compares that with what is on the OS. If there is a mismatch, then the system will use the root file to update (or downgrade) the OS.
There could of course be more damage in the flash - unfortunately checking or repairing damaged files in it isn't something I've never needed to do. There are other who have - mdgm or perhaps one of the mods ( Marc_V or JeraldM ) might have some guidance. Not sure if Sandshark has dealt with this before.
In that case it definitely sounds like once I have checked for more damage, I can have a go at manually replacing the contents with un-damaged firmware. This takes me back to a tangent from earlier - How do I find the firmware files from the firmware image downloaded from netgear? Is the "RAIDiator-x86-4.2.31" file a type of archive with the extension removed?
frankie0p wrote:
In that case it definitely sounds like once I have checked for more damage, I can have a go at manually replacing the contents with un-damaged firmware. This takes me back to a tangent from earlier - How do I find the firmware files from the firmware image downloaded from netgear? Is the "RAIDiator-x86-4.2.31" file a type of archive with the extension removed?
The 4.2.31 can be found here: https://kb.netgear.com/000038793/RAIDiator-x86-Version-4-2-31
7zip can open the binary inside:
Most of these appear to be identical to the flash files (same size anyway), and you could try verifying the flash files using the md5 checksums.
Not sure about kernel.up, though it appears match kernel in the flash (both size and checksum). So that could be ok.
You could of course try copying root.tlz onto the flash. But there might be a way to check (and spare) bad sectors, which might make sense to do first. Maybe wait for others to chime in, as they might have advice on that.
According to mdgm in PM, the kernel.up is for 32 bit architecture and needs to be renamed to kernel in case of manual extraction. This would explain why it matches a different hash to the one listed. Same-same but different.
I've noticed while doing some more looking around, there's a /lib64/ folder on the first raid partition, making me think that an update to the x64 version of 4.3.21 was attempted, if not to OS 6, unless it's meant to be there just because.
I can't get badblocks to run when chroot'd into the raid partition, output below. I believe it's because of the file being for x64 architecture.
root@22N294RA00187:/# ls -la lib64 total 2176 drwxr-xr-x 2 root 0 4096 Sep 16 03:31 . drwxr-xr-x 22 root 0 4096 Sep 23 04:27 .. -rwxr-xr-x 1 root 0 131576 Jan 29 2015 ld-2.7.so lrwxrwxrwx 1 root 0 9 Sep 16 03:31 ld-linux-x86-64.so.2 -> ld-2.7.so lrwxrwxrwx 1 root 0 15 Sep 16 03:31 libblkid.so.1 -> libblkid.so.1.0 -rw-r--r-- 1 root 0 48848 Sep 19 2014 libblkid.so.1.0 -rwxr-xr-x 1 root 0 1498416 Jan 29 2015 libc-2.7.so lrwxrwxrwx 1 root 0 11 Sep 16 03:31 libc.so.6 -> libc-2.7.so lrwxrwxrwx 1 root 0 17 Sep 16 03:31 libcom_err.so.2 -> libcom_err.so.2.1 -rw-r--r-- 1 root 0 12352 Sep 19 2014 libcom_err.so.2.1 lrwxrwxrwx 1 root 0 13 Sep 16 03:31 libe2p.so.2 -> libe2p.so.2.3 -rw-r--r-- 1 root 0 28816 Sep 19 2014 libe2p.so.2.3 lrwxrwxrwx 1 root 0 16 Sep 16 03:31 libext2fs.so.2 -> libext2fs.so.2.4 -rw-r--r-- 1 root 0 283168 Sep 19 2014 libext2fs.so.2.4 -rwxr-xr-x 1 root 0 130197 Jan 29 2015 libpthread-2.7.so lrwxrwxrwx 1 root 0 17 Sep 16 03:31 libpthread.so.0 -> libpthread-2.7.so lrwxrwxrwx 1 root 0 25 Sep 16 03:31 libreadynas_lgpl.so.0 -> libreadynas_lgpl.so.0.1.1 -rwxr-xr-x 1 root 0 11896 Mar 2 2010 libreadynas_lgpl.so.0.1.1 lrwxrwxrwx 1 root 0 12 Sep 16 03:31 libss.so.2 -> libss.so.2.0 -rw-r--r-- 1 root 0 24432 Sep 19 2014 libss.so.2.0 lrwxrwxrwx 1 root 0 14 Sep 16 03:31 libuuid.so.1 -> libuuid.so.1.2 -rw-r--r-- 1 root 0 16112 Sep 19 2014 libuuid.so.1.2 root@22N294RA00187:/# badblocks -v /dev/sde1 badblocks: error while loading shared libraries: libreadynas_lgpl.so.0: cannot open shared object file: No such file or directory root@22N294RA00187:/#
frankie0p wrote:
According to mdgm in PM, the kernel.up is for 32 bit architecture and needs to be renamed to kernel in case of manual extraction.
FWIW, I was thinking that might be the case - but definitely something that needed to be confirmed before touching that file in the flash.
frankie0p wrote:
I've noticed while doing some more looking around, there's a /lib64/ folder on the first raid partition, making me think that an update to the x64 version of 4.3.21 was attempted, if not to OS 6, unless it's meant to be there just because.
You must mean 4.2.31 (there is no 4.3.x firmware). But I don't see how the 4.2.31 x64 firmware would have been applied, since the install should autodetect that the NVX is a 32 bit machine.
I haven't seen details of exactly what happens to the OS partition if you attempt to upgrade an NVX to OS-6. But I'd think there would be far more stuff wrong if OS-6 binaries put in the root folder.
So I'm thinking it's "meant to be there just because" it was just easier to populate some folders that weren't used on 32-bit machines.
I guess you could try seeing if badblocks is available w/o the chroot. Or just try to replace root.tlz, and see if it works.
StephenB wrote:I guess you could try seeing if badblocks is available w/o the chroot. Or just try to replace root.tlz, and see if it work.
I did look for it in the tech support root but I dont think it's included in busybox. I tried smartctl but the flash module doesn't support selftest logging either. At this point I think the best thing I can do is indeed attempt to copy the new root.tlz over, as the flash itself being bad is pretty much a terminal illness.
Can anyone help reflash my Readynas NVX
after an atttempt to move to OS6 found out the Readynas NVX is a 32 bit machine that is not supported
(1) From the firmware file RAIDiator-x86-4.2.31 i get the checksums are
% cat csums.md5
3b149aa715d8c09491439f9240285ca2 initrd.gz
d3af676e47ee06ed1c3bcf9b22f35341 kernel
8cf6bab4b104fc5b869aeb8585849b24 kernel.up
26acb3351b52a61f3480533a1fd89b9c memtest
2f6e4d8775717a54ac3d074e527c3209 root.tlz
9de4bac1de70732b8f7bb4e8fe0397c9 supplmnt.tlz
aea8b2361c563250478a687d16f38b6a syslinux.cfg
fac783aa9c70094c2c63850ac6286983 version.txt
with dates
-rw-r--r--@ 1 aldospadaccini staff 57370624 24 May 2017 RAIDiator-x86-4.2.31
-rw-r--r-- 1 aldospadaccini staff 354 23 May 2017 csums.md5
-rw-r--r-- 1 aldospadaccini staff 1718218 23 May 2017 initrd.gz
-rw-r--r-- 1 aldospadaccini staff 3731456 23 May 2017 kernel
-rw-r--r-- 1 aldospadaccini staff 3040368 23 May 2017 kernel.up
-rwxr-xr-x 1 aldospadaccini staff 169600 23 May 2017 memtest
-rw-r--r-- 1 aldospadaccini staff 48031517 23 May 2017 root.tlz
-rw-r--r-- 1 aldospadaccini staff 650860 23 May 2017 supplmnt.tlz
-rwxr-xr-x 1 aldospadaccini staff 532 23 May 2017 syslinux.cfg
-rw-r--r-- 1 aldospadaccini staff 42 23 May 2017 version.txt
% cat version.txt
RAIDiator!!version=4.2.31,time=1495520166
(2) on the Readynas NVX after a USB recovery boot I get on the Flash
# mkdir /mnt
# mount /dev/sde1 /mnt
# cd mnt
# ls -al
drwxr-xr-x 2 0 0 16384 Jan 1 1970 .
drwxr-xr-x 17 0 0 0 May 8 23:16 ..
-rwxr-xr-x 1 0 0 128 Apr 30 01:51 CSUMS.MD5
-rwxr-xr-x 1 0 0 4454994 Apr 30 01:51 INITRD.GZ
-rwxr-xr-x 1 0 0 3040368 Aug 4 2017 KERNEL
-r-xr-xr-x 1 0 0 12424 Jun 22 2010 LDLINUX.SYS
-rwxr-xr-x 1 0 0 169600 Aug 4 2017 MEMTEST
-rwxr-xr-x 1 0 0 61039715 Apr 30 01:51 ROOT.TLZ
-rwxr-xr-x 1 0 0 650860 Aug 4 2017 SUPPLMNT.TLZ
-rwxr-xr-x 1 0 0 532 Aug 4 2017 SYSLINUX.CFG
-rwxr-xr-x 1 0 0 42 Aug 4 2017 VERSION.TXT
-rwxr-xr-x 1 0 0 512 Aug 3 2011 VPD
with checksum
# cat CSUMS.MD5
f3990a6e51a4af81861c5d6adca19ef9 initrd.gz
0fb4d3019e0e77ce578694dea23df8d7 kernel
82059e5c1ec6307fa8cc660761644ac8 root.tlz
# cat VERSION.TXT
RAIDiator!!version=4.2.31,time=1495520166
it seems the files on the ReadyNAS Flash need to be updated to the ones in the RAIDiator-x86-4.2.31 firmware archive.
Is it just a straight copy onto the flash drive via another usb?
I'm thinking to mount the Usb Recovery to get a command prompt and mount as follows:
# mkdir /mnt_internal_flash
# mount /dev/sde1 /mnt_internal_flash
Then insert another USB into the Readynas with a copy of the 7zz extract contents from the firmware file RAIDiator-x86-4.2.31. Then mount and copy as follows
# mkdir /mnt_anotherusb
# mount /dev/sdf1 /mnt_anotherusb
Finally copy the files across
# cp /mnt_anotherusb/* /mnt_internal_flash/
Is this the right way to go to refresh the ReadyNas NVX?
Thanks in advance
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
