My ReadyNAS Duo v2 (RND2000-200NAS) was working fine prior to the most recent firmware upgrade (5.3.13). I was able to back up files via rsync from PC and laptop. I could browse media files on the home network. The web interface was totally functional. Everything was working perfectly on firmware 5.3.12.
Then I received an email from NETGEAR stating that they found a security vulnerability in 5.3.12, and they recommended upgrading to 5.3.13. So I went into my web interface and navigated to the upgrade option. Sure enough, the ReadyNAS reported that a new firmware version (5.3.13) was found, and it proceeded to download and install it.
My Duo v2 never came back online after that. When it rebooted, the USB/Backup LED was flashing quickly. Every time I reboot, that's all that happens. The Backup LED comes on solid for one second, then starts flashing forever. In the meantime, the fan turns on and the drives spin up, but nothing more ever happens.
I read many NETGEAR KB articles online about USB recovery drives, and that's what NETGEAR Support recommended as well. NETGEAR Support unfortunately referred me (via a link in an email) to the USB recovery information for x86-based devices, where you run usbrecovery.exe and it creates the recovery drive. My Duo v2 is ARM-based, and the process for creating the USB recovery drive is manual (as far as I know - I haven't seen a similar usbrecovery.exe for ARM-based devices).
For the manual creation of the USB recovery drive, I found the files "uImage-recovery" and "initrd-recovery.gz" from a KB article, and I also copied a recent "uboot.bin" that was also referenced in the KB article. I then copied the 5.3.13 firmware to the drive. When I rebooted with the drive, I could see the USB drive being read in chunks. After the 3rd or 4th read (maybe 2 minutes into the process), the ReadyNAS would power down on its own. However, rebooting without the USB drive would yield the same blinking Backup LED.
I purchased a USB to TTL cable, and now I have the pleasure of viewing the serial console output and interacting with U-Boot. I can see that, when I have the USB recovery drive inserted, the ReadyNAS loads the kernel (uImage-recovery) and a ramdisk (initrd-recovery.gz). It then boots the kernel, and then it seems to flash the firmware, and finally it performs a clean shutdown.
However, when I boot without the USB drive inserted, it errors out fairly quickly. The USB device scan fails to find a storage device (which is correct, since I don't have it inserted), so the bootcmd (which is basically "usb start", "fatload kernel" (fails, no usb), "fatload ramdisk" (fails, no usb), "bootm 0x1200000 0x2000000". The final messages are "## Booting image at 01200000 ..." and "Bad Magic Number". Again, this makes sense, since I'm trying to boot without the USB drive. It's as if the firmware upgrade succeeded, but the bootcmd was never changed - so it's always trying to boot from the USB drive.
That's basically a summary of where I'm at right now. I cannot get the ReadyNAS to boot from anything other than the USB drive, and since the USB drive has a recovery kernel and recovery initrd on it, it just upgrades the firmware each time, and then restarts.
I would love to get my Duo v2 running properly again.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
Thank you for sending along the Duo V2 USB recovery tool. Even before I ran the tool, I took a look at the files associated with the Duo V2 within the archive. The uImage-recovery and initrd-recovery.gz files were both identical to the files that I already had on my USB drive.
Still, I decided to run the recovery tool. I re-formatted the drive and selected my device. Sure enough, the recovery tool copied the exact uImage-recovery and initrd-recovery.gz files that I already had. It then copied the 5.3.13 firmware file (RAIDiator-arm-5.3.13) that I already had on the drive. So, I believe I already had the correct files on my USB drive, after reading many other KB articles.
The recovery tool confirms that I had the correct files.
I will try booting with the USB drive once I'm back at my ReadyNAS device, but I can guarantee that it will do the same thing as before: It will boot from the USB drive, load the kernel, load the ramdisk, update the firmware, and shut down. I'll remove the USB drive and attempt to boot up again, and the boot will fail because it is always trying to boot from the USB drive.
I'll relay the results to you once I try the USB drive again, but since the recovery files are identical to before, I expect no change in results.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
The Backup button is definitely not pressed in. I checked several times. The device continues to attempt to boot from USB on every reboot. Here is the last segment of the console output:
Net: egiga0 [PRIME] Hit any key to stop autoboot: 0 (Re)start USB... USB: scanning bus for devices... 1 USB Device(s) found Waiting for storage device(s) to settle before scanning... 0 Storage Device(s) found ** Can't read from device 0 **
** Unable to use usb 0:1 for fatload ** ** Can't read from device 0 **
** Unable to use usb 0:1 for fatload ** ## Booting image at 01200000 ... Bad Magic Number
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
I tried the USB recovery drive that I created from the link that Deniro posted. Same exact result, as expected. The 3 files (uImage-recovery, initrd-recovery.gz, RAIDiator-arm-5.3.13) were all identical to the ones that I had already downloaded and copied to the USB drive.
The Backup button is not stuck. I can clearly feel it moving when I press it, and I can feel the push back from the button.
I will note that the bootcmd environment variable is set to:
bootcmd=usb start;fatload usb 0:1 0x1200000 /uImage-recovery;fatload usb 0:1 0x2 000000 /initrd-recovery.gz;bootm 1200000 2000000
What would the bootcmd be if a device is booting normally? I could try entering that command directly to see if the device boots properly. Then I could work backwards to figuring out why it's always trying to boot from USB.
If someone could send me the environment variables as they would exist for a normal bootup, I can try setting and saving those variables.
The device is definitely not bricked, and it does seem to be able to load a kernel and initrd from either USB or TFTP (I set up a TFTP server on my Linux box to see if that would work... it does!)
However, when I boot using TFTP, I get dropped into a shell (/bin/ash), because the search for an external flash device fails. The message is:
Unlocking flash... Done Erasing old environment... Done Writing environment to /dev/mtd1... Done Locking ... Done Searching for internal boot flash device...mtdblock4 Searching for external boot flash device...Could not find external boot flash! ERROR: Could not find external flash device!! /bin/ash: can't access tty; job control turned off
/ #
(at this point, I'm in a Linux shell with busybox commands available to me)
Compare that to the stage when booting from USB:
Unlocking flash... Done Erasing old environment... Done Writing environment to /dev/mtd1... Done Locking ... Done Searching for internal boot flash device...mtdblock4 Searching for external boot flash device...sda
Erasing 128 Kibyte @ 180000 -- 100 % complete. Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Erasing 128 Kibyte @ 600000 -- 100 % complete. Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Writing data to block 4 at offset 0x80000 Writing data to block 5 at offset 0xa0000 Writing data to block 6 at offset 0xc0000 Writing data to block 7 at offset 0xe0000 Writing data to block 8 at offset 0x100000 Writing data to block 9 at offset 0x120000 Writing data to block 10 at offset 0x140000 Writing data to block 11 at offset 0x160000 Writing data to block 12 at offset 0x180000 Writing data to block 13 at offset 0x1a0000 Writing data to block 14 at offset 0x1c0000 Writing data to block 15 at offset 0x1e0000 Writing data to block 16 at offset 0x200000 Writing data to block 17 at offset 0x220000 Writing data to block 18 at offset 0x240000 Writing data to block 19 at offset 0x260000 Writing data to block 20 at offset 0x280000 Writing data to block 21 at offset 0x2a0000 Writing data to block 22 at offset 0x2c0000 Writing data to block 23 at offset 0x2e0000 Writing data to block 24 at offset 0x300000 Writing data to block 25 at offset 0x320000 Writing data to block 26 at offset 0x340000 Erasing 128 Kibyte @ 1000000 -- 100 % complete. Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Writing data to block 4 at offset 0x80000 Writing data to block 5 at offset 0xa0000 Writing data to block 6 at offset 0xc0000 Writing data to block 7 at offset 0xe0000 Writing data to block 8 at offset 0x100000 Writing data to block 9 at offset 0x120000 Writing data to block 10 at offset 0x140000 Writing data to block 11 at offset 0x160000 Writing data to block 12 at offset 0x180000 Writing data to block 13 at offset 0x1a0000 Writing data to block 14 at offset 0x1c0000 Writing data to block 15 at offset 0x1e0000 Writing data to block 16 at offset 0x200000 Writing data to block 17 at offset 0x220000 Writing data to block 18 at offset 0x240000 Writing data to block 19 at offset 0x260000 Writing data to block 20 at offset 0x280000 Writing data to block 21 at offset 0x2a0000 Writing data to block 22 at offset 0x2c0000 Writing data to block 23 at offset 0x2e0000 Writing data to block 24 at offset 0x300000 Writing data to block 25 at offset 0x320000 Writing data to block 26 at offset 0x340000 Writing data to block 27 at offset 0x360000 Writing data to block 28 at offset 0x380000 Writing data to block 29 at offset 0x3a0000 Writing data to block 30 at offset 0x3c0000 Writing data to block 31 at offset 0x3e0000 Writing data to block 32 at offset 0x400000 Writing data to block 33 at offset 0x420000 ls: /sysroot/vpd*: No such file or directory
done The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system poweroff System halted.
The big difference is that "sda" is found as an "external boot flash device" when booting from USB, while nothing is found when booting via TFTP.
Either way, I still have not been able to get the unit to start up normally.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
As you know, I have already tried booting from the USB drive (recovery), which does seem to properly boot the kernel and ramdisk, and then flash the firmware. The device shuts down, but when booting without the USB drive, it just fails.
I tried using TFTP by interrupting the bootup and loading the kernel and initrd via TFTP. The load works fine, but when I use "bootm", I end up at a shell prompt, after the "external boot flash device" is not found.
I then saw a KB article where someone booted from the NAND (instead of USB or TFTP). So I once again interrupted the bootup process, and entered the following commands:
This time, the bootup process made it past the "USB 3.0 Port Power On, Waiting for 3 seconds" message. The continued bootup looks more promising:
USB 3.0 Port Power On, Waiting for 3 seconds HDD_pwrctl_init MPP26 High. MPP28 High. Request the irq HDDpwrctrl success. Todo: mknod /dev/buttons c 253 0 scsi 0:0:0:0: Direct-Access WDC WD20EARX-00PASB0 51.0 PQ: 0 ANSI: 5 scsi 1:0:0:0: Direct-Access WDC WD20EARX-00PASB0 51.0 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512. sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) sd 0:0:0:0: [sda] 0-byte physical blocks sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FU A sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512. sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512. sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) sd 1:0:0:0: [sdb] 0-byte physical blocks sda: sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FU A sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512. mice: PS/2 mouse device common for all mice i2c /dev entries driver sdb: md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: raid10 personality registered for level 10 md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com sdb1 sdb2 sdb3 sd 1:0:0:0: [sdb] Sector size 0 reported, assuming 512. Registered led device: backup sd 1:0:0:0: [sdb] Attached SCSI disk Registered led device: sys Registered led device: sys_fail Registered led device: SATA1_act Registered led device: SATA2_act Registered led device: power sda1 sda2 sda3 sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512. sd 0:0:0:0: [sda] Attached SCSI disk usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver IPv4 over IPv4 tunneling driver ip_tables: (C) 2000-2006 Netfilter Core Team TCP bic registered NET: Registered protocol family 10 lo: Disabled Privacy Extensions tunl0: Disabled Privacy Extensions NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by David S. Miller <davem@redhat.com> TWSI: twsiDataTransmit ERROR - status 30 in write trans rtc mv_rtc: setting system clock to 2017-10-18 01:24:48 UTC (1508289888) Freeing init memory: 128K
Starting the boot process... systype=12 Loading kernel modules...armvpd: module license 'Proprietary' taints kernel. Disabling lock debugging due to kernel taint ReadyNAS Pro VPD device driver init... Tuxera NTFS driver 3011.10.19 [Flags: R/W MODULE]. eth0: link down eth0: started ADDRCONF(NETDEV_UP): eth0: link is not ready done Kernel panic - not syncing: Attempted to kill init!
So booting from the NAND definitely produced different results, but I'm still stuck. I'm guessing that if I use correct bootargs, I might be able to get this thing to start all the way.
Looking forward to your continued insights......
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
OK, now I think I'm really close to having this resolved..... I am able to manually boot my ReadyNAS Duo v2 all the way to bringing it online.
I followed the "boot from NAND" steps that I outlined above. However, as I mentioned earlier, booting from NAND eventually yielded a kernel panic, even though it got much further along in the bootup process.
So I decided to overwrite the bootargs environment variable with:
bootargs = console=ttyS0,115200 init=/bin/sh
Apparently, the "init=/bin/sh" portion helped the bootup process to continue. The bootup moved along, and the device appeared in RAIDar. It then began updating the rootdisk on its own (probably a continuation of the upgrade process), and the RAIDar status changed from "BOOT" to "UPDATE". After that, it went into "QUOTA_CHECK", then back to "BOOT", and then finally, the status changed to "5.3.13", which is the new firmware version.
I was able to access the ReadyNAS from my web browser, as well as via an SSH connection. The serial console displayed a login prompt. I ran some backups using rsync from my PC, and it all worked perfectly. The ReadyNAS was functioning exactly as it used to.
I then decided to try a reboot, to see if it would boot up all the way without any manual intervention, but once again, rebooting yields an error message about being unable to boot from USB.
So the device is still stuck trying to boot from USB. I'm guessing if I replace the "bootcmd" variable with something else, I could force it to boot in a different (non-USB) manner.
At least for now, I can consistenly boot up my ReadyNAS using the serial console and booting from the NAND. I'm guessing that I'm not that far away from resolving this completely.
Please let me know how I should proceed. Thanks.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
I actually have used "saveenv" to save away the new "bootcmd" variable that works. However, when I reboot, the "bootcmd" variable is back to the USB boot. My setting is not sticking.
I created a "bootcmd_nand" variable to make it easy for me to change bootcmd by using:
> setenv bootcmd $(bootcmd_nand)
> setenv bootargs $(console)
When I print the environment using "printenv", I can see that "bootcmd" is set correctly. I type "saveenv" to save the environment, and then "printenv" again, and the "bootcmd" is still fine. If I type "boot", which basically executes "run bootcmd", the ReadyNAS boots up fine. (I can also boot using "run bootcmd_nand", which is the variable I mentioned above that I created just to make sure that I have the NAND boot sequence saved.)
However, once I reboot, the "bootcmd" has reset back to the USB boot command. Something is forcing the bootcmd to always be set to the USB boot command. I have checked to confirm that my Backup button is not physically stuck. Is it possible that the Backup button is doing something strange that I cannot perceive?
More likely, the logic that the Backup button executes (probably something that sets "bootcmd" to the USB boot sequence) is somehow executing, even though the Backup button is not pressed.
Any advice? I really need to ability to reboot the device automatically, without connecting a serial cable to it constantly.
Can someone send me a full dump of their default environment, so I can confirm that my environment matches? What else can I check?
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
Nothing new to report today. I cannot get the "bootcmd" variable to stick. Every time I reboot (whether by using "reset" in u-boot, or a standard reboot), the "bootcmd" variable is always set to the USB boot. Same applies to the "bootargs". If I set "bootargs" to a simple "console=ttyS0,115200" and use "saveenv", it ends up being set to a much longer value upon reboot.
Can anyone help me get this working? Do I need to install a different U-Boot? Should I clear out the entire NAND? Please provide me specific commands that I would need to execute in order to fix this. I'm pretty much at the limits of my knowledge.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
Maybe you can try to run CMD "buttond" when box bootup successfully , then press backup and power button to check if you can see the message ? The following is mine:
# buttond
backup button is pressed. power button is pressed.
When I run buttond, I see the Power button and the Reset button (using a paper clip in the back of the unit) showing up. If I hold either the Power or Reset buttons in for more than 3 seconds, I get a "power_hold" or "reset_hold" message, respectively.
However, pressing the Backup button yields no output, no matter how quickly or how long I press, it and no matter how many times I press it.
So, there is definitely something wrong with the Backup button. It is definitely not stuck, because I can feel it moving, and it definitely pushes itself back into the unpressed position when I let go. But it is not generating any output in "buttond". I'm guessing that this is related to the bootup problem that I'm having.
What do I do now?
Do I have to trash the unit just because the Backup button is either not working or is stuck in the "On" position always? If necessary, I would be willing to sacrifice the button entirely (I have never used it anyway) in order to have a running unit that reboots properly.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
If there is no way to tell the firmware to ignore the button (somebody from NetGear will have to tell you if there is), you'll have to test the button itself to see if it's the button or something else in the circuit that's causing the problem..
Unfortunately, the backup button is soldered directly to the main board, not connectorized. If you take off the side panel of the NAS adjacent to the button, you will see four solder joints in a trapazoidal pattern at the top front. The two closest to the front of the unit are the electrical contacts. The other two just hold it in place. You can test the button there with an ohm meter. It's a normally closed switch. If the button works, then something else in the circuitry is the problem. If there is a lot of dust (and especially if there is residue from smoking), a good cleaning mght do the job. But other than that, without a schematic and with all the parts being small surface-mount ones, I would recommend you stop and say your NAS is done. Since the switch is normally closed, you can't disable it by jumpering it, either. You'll have to remove it or cut the really fine trace leading away from it. If you get to the point of wanting to remove the button and need some more help, just ask. I have a mostly disassembled DuoV2 I can use as a reference. If you choose to cut the trace, you are on your own, but it is obvious which one it is once you remove the board.
NOTE: I take no responsibility if your attempt to fix it makes things worse -- but really, how can it get worse than an unusable NAS?
I'm not sure what I was thinking, but you could jumper the button. The switch is normally closed, but your broken one (assuming the button is to blame) would be permanently open, so jumpering it would make it look unpushed. The solder joints aren't big enough to clip something on for a quick test and are pretty close to the case to solder a jumper without removing the board. You could just inspect the solder joints, too. I suppose it's possible they are cracked.
Thank you for the detailed reply. I have had the unit open several times during this process, and I've pulled the entire mainboard (plus the SATA and RJ45/USB3/TTL daughterboards). So I'm comfortable working inside the chassis, but I've never worked with soldered-on parts before.
To be clear, my ReadyNAS Duo v2 is quite usable once I manually boot it. In other words, if I interrupt the normal bootup (the 3-second delay), or if I let the boot fail (because no USB drive is detected), then I'm dumped into the U-Boot prompt. I can then boot from the NAND by setting bootargs to "console=ttyS0,115200" and by using the "run bootargs_nand" command to utilize my "bootargs_nand" variable that I defined (listed in a previous comment on this thread).
The device will start up fine and function fine. It's just the damn reboot that is a problem. I suppose I could try to create a USB drive that contains the exact same code as the NAND, and just leave the USB drive in the front USB port all the time. However, I have never successfully had a full start-to-finish boot when using the USB drive... only recovery. It's the NAND boot that goes start-to-finish.
I mention all of this to make it clear that the device itself seems to be fine, but the "bootcmd" variable is always set to the USB boot on startup, probably because of this Backup button problem.
So I'd like to try some non-destructive tests to see if it's truly the button. The ohm meter test sounds feasible to me. However, I'm not really great at using ohm meters... as in, I'm not sure what level of sensitivity to use. I've used a meter to detect wall voltage before when installing my Nest thermostat, but this is different.
Could you explain specifically how I can test the button and its connections to determine where the failure is occurring?
I must say, these forums are amazing. The detailed help I'm getting here is leagues beyond the help that I received on the phone with NETGEAR customer support. They gave up on me by the third time I corresponded with them.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
Yeah, I've already tried removing the mainboard battery. I even replaced it with a fresh battery, just to be sure. I think the battery only maintains the internal clock, and nothing more, but I could be wrong.
As for building a new U-Boot, I would be open to that, but mdgm warned me that installing a bad U-Boot will brick the unit. I wouldn't know where to start in order to build the exact same U-Boot that was built for the Duo V2, minus the USB bootup logic. I think it's beyond my expertise.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
So, to "jumper" the switch, would I simply touch a wire to both solder points of the Backup button?
Yup, but that's easier said than done becase of the location. With a helper, you could probably hold the wires in place and turn the NAS on, but I don't know how long you's have to hold it there. If it works, you'll want to solder the jumper in place. There is wire glue that would probably do the trick if you are not skilled at or have the equipment for electronic soldering.
OK, here's where I stand on this. I used my multimeter to measure voltage. I first measured it across the Power button contacts, for a reference. When the Power button is unpressed, the voltage reads 3.3V. When I press the Power button in, the voltage changes to 0V, as expected.
So, on to the Backup button. The multimeter is reading anywhere between 0.01V and 0.04V when the Backup button is unpressed. When I press the Backup button in, the voltage changes to 0V, as expected. The question is, does such a low "unpressed" voltage make sense?
At one point, the Backup button voltage got as high as 0.11V on one particular power-on, but it generally stayed around 0.03V.
I used a paper clip to jumper the two contacts of the Backup button, but that did not seem to affect the bootup sequence in any manner.
I'm guessing that the voltage going across the Backup button (unpressed = closed circuit = 0.03V) is too low for the mainboard to detect the pressing of the button as the voltage drops to 0V.
Do you know what the expected voltage is for the Backup button? Is it 3.3V?
I've tried wiping down the mainboard and blowing on the button itself. I don't know what else to do.
Model: ReadyNAS RND2000v2|ReadyNAS Duo v2 Chassis only
I just measured it, and 3.3V is normal. So, the button itself is working but it's not being sensed by whatever receives it. I think you're at the end of the line hardware wise. Even with a schematic, the surface mount parts would be nearly impossible to purchase in single quantities and require the proper equipment and skill to replace.
Unless somebody can tell you how to tell the software to ignore the button, then it looks like time for a new NAS.
