NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Duo v2 will not boot after firmware upgrade
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 ...
hello
if you want to do USB recovery for your DUO V2 device,please download the tools from below URL link
Hi Deniro,
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.
Is your backup button stuck pressed in? If the backup button is pressed in it'll always try to boot off USB every boot.
Hi mdgm,
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 NumberI 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 2000000What 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...sdaErasing 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 directorydone
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
