NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
kzalewski
Oct 17, 2017Aspirant
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 ...
kzalewski
Oct 17, 2017Aspirant
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.
mdgm-ntgr
Oct 17, 2017NETGEAR Employee Retired
Is your backup button stuck pressed in? If the backup button is pressed in it'll always try to boot off USB every boot.
- kzalewskiOct 18, 2017Aspirant
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 Number- kzalewskiOct 18, 2017Aspirant
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 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.
- kzalewskiOct 18, 2017Aspirant
Some additional information:
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:
nand read.e 0x1200000 0x200000 0x600000
nand read.e 0x2000000 0x800000 0x1000000
bootm 0x1200000 0x2000000This 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: 128KStarting 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......
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!