K20
Re: RN104 bricked
September 20, 2020 06:27PM
Thanks bodhi for your reply.

Quote
since you can log in stock OS with the HDD rootfs, why not let stock OS reinstall the FW for you? there must be a way to do that.

I have tried many ways to write the OS to flash via GUI, for example:

Restore to default= NAS reboots and give error "Error: could not mount the boot flash" and removes the OS from the HDD
Firmware update= NAS reboots and give error "Error: could not mount the boot flash" OS stays on the HDD
USB recovery= Error recovery USB failed.
Downgrade FW= GUI doesn't let me downgrade the firmware and as per netgear documentation can be done via USB recovery but when tried, it fails right away.

Quote
./nanddump --help
./nandwrite --help


root@nas-36-66-02:/media/tools/tools# ./nanddump --help
Usage: nanddump [OPTIONS] MTD-device
Dumps the contents of a nand mtd partition.

-h         --help               Display this help and exit
           --version            Output version information and exit
           --bb=METHOD          Choose bad block handling method (see below).
-a         --forcebinary        Force printing of binary data to tty
-c         --canonicalprint     Print canonical Hex+ASCII dump
-f file    --file=file          Dump to file
-l length  --length=length      Length
-n         --noecc              Read without error correction
           --omitoob            Omit OOB data (default)
-o         --oob                Dump OOB data
-p         --prettyprint        Print nice (hexdump)
-q         --quiet              Don't display progress and status messages
-s addr    --startaddress=addr  Start address

--bb=METHOD, where METHOD can be `padbad', `dumpbad', or `skipbad':
    padbad:  dump flash data, substituting 0xFF for any bad blocks
    dumpbad: dump flash data, including any bad blocks
    skipbad: dump good data, completely skipping any bad blocks (default)
root@nas-36-66-02:/media/tools/tools# ./nandwrite --help
Usage: nandwrite [OPTION] MTD_DEVICE [INPUTFILE|-]
Writes to the specified MTD device.

  -a, --autoplace         Use auto OOB layout
  -m, --markbad           Mark blocks bad if write fails
  -n, --noecc             Write without ecc
  -N, --noskipbad         Write without bad block skipping
  -o, --oob               Input contains oob data
  -O, --onlyoob           Input contains oob data and only write the oob part
  -s addr, --start=addr   Set output start address (default is 0)
  -p, --pad               Pad writes to page size
  -b, --blockalign=1|2|4  Set multiple of eraseblocks to align to
      --input-skip=length Skip |length| bytes of the input file
      --input-size=length Only read |length| bytes of the input file
  -q, --quiet             Don't display progress messages
  -h, --help              Display this help and exit
      --version           Output version information and exit



Edited 2 time(s). Last edit at 09/20/2020 06:28PM by K20.
tme
Re: RN104 bricked
September 20, 2020 07:35PM
Hi K10,

Quote

Removed OS HDD

The stock firmware needs an unpacked root file system on disk to run. It expects to find this root file system on the first of 3 RAID partitions on an array in the Slots. It uses the second RAID partition as swap media, i.e. to offload the 512 MiB of internal RAM when it runs full. The third RAID partition on the array is by far the largest one and is where your payload data is stored.

When you did "OS reinstall" to the spare disk on the working box, all 3 RAID partitions where created on the single disk as degraded arrays with one disk available and 3 disks missing. As more disks are added they will be included in the array, but you probably don't want that since you have valuable data that most likely will be wiped out if you do.

Starting the boot process...
Detected system type: RN104
Loading kernel modules...done
Boot mode: Normal
[    4.382673] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes
[    4.394049] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1:0, read 64 bytes
...
[    5.744448] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 122:0, read 64 bytes
[   22.023591] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 917:0, read 64 bytes
UBI device number 0, total 919 LEBs (116690944 bytes, 111.3 MiB), available 11 LEBs (1396736 bytes, 1.3 MiB), LEB size 126976 bytes (124.0 KiB
I don't know what happened here, but it may be failing to open the last mtd partition. After boot completes, you may issue the command
dmesg
on both boxes to figure out what happened and what should happen 4.4 seconds into kernel boot. Maybe it failed to open the last of the 5 mtd-partitions.

Bringing up network...eth0.done
ERROR: Resolving timed out after 10008 milliseconds
command failed: /usr/bin/rnutil firmware_update
eth1 is the prime Ethernet connection, so the time out may be because it tries to connect on this connector first, but only succeeds wen it falls back to eth0. Also, since you have cloned the U-Boot environment from your good box, you must only power up one at a time for now since they will have the same mac address. All kinds of issues may be observed when there are two boxes with equal mac addresses on the same network.

'/usr/bin/rnutil firmware_update' may be failing because Netgear has terminated or moved their update service for your product. I checked and get no response from 'update.readynas.com':
ping update.readynas.com
PING update.readynas.com (206.16.42.180) 56(84) bytes of data.
mdadm: array /dev/md0 started.
mke2fs 1.42.13 (17-May-2015)
Discarding device blocks: done                            
Creating filesystem with 1047552 4k blocks and 1048576 inodes
Filesystem UUID: f47add44-1aef-48ae-8b95-ba14d8873a22
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This looks to me that the box successfully creates an empty ext3 file system (ext2 + journaling) on the first RAID partition, but maybe it is created on the USB-stick in stead since you removed all disks?
Extracting root image...ERROR: Could not mount boot flash [/dev/ubi0_0] (Invalid argument)
command failed: mdev -s
I may be wrong, but this might be where the newly created file system should have been populated with files extracted and uncompressed from the last mtd partition.

Regards,
Trond Melen
Re: RN104 bricked
September 20, 2020 08:57PM
K20,

Ah. I see. These binaries are old so I forgot that the options have changed. Here is the revised commands.

nandump commands are the same

./nanddump --noecc --omitoob -f mtd0.u-boot.rn104 /dev/mtd0
./nanddump --noecc --omitoob -f mtd1.u-boot-env.rn104 /dev/mtd1
./nanddump --noecc --omitoob -f mtd2.uImage.rn104 /dev/mtd2
./nanddump --noecc --omitoob -f mtd3.minirootfs.rn104 /dev/mtd3
./nanddump --noecc --omitoob -f mtd4.ubifs.rn104 /dev/mtd4


nandwrite must specify --noecc :

./nandwrite --noecc /dev/mtd0 mtd0.u-boot.rn104
./nandwrite --noecc /dev/mtd1 mtd1.u-boot-env.rn104
./nandwrite --noecc /dev/mtd2 mtd2.uImage.rn104
./nandwrite --noecc /dev/mtd3 mtd3.minirootfs.rn104
./nandwrite --noecc /dev/mtd4 mtd4.ubifs.rn104

So reflash the bricked box again.

The issue with permission during nandwrite can be fixed by using bootargs. So if there is permission error, then just reboot. Interrupt serial console and:

printenv
I expect the bootargs need to be revised here, so you can post the output, boot into HDD OS again, and wait for my next post.

-bodhi
===========================
Forum Wiki
bodhi's corner
K20
Re: RN104 bricked
September 22, 2020 09:38PM
Thanks for your message bodhi.

I have tried ./nandwrite --noecc on last 2 partitions but I still got ubi_io_read errors.

Then I also tired 1st partitions "mtd0" from the backup but NAS failed to boot uboot and now there is no point checking permission issue for mtd1 as flashing method not working.

I am totally lost now, I dont know what to do,



Edited 4 time(s). Last edit at 09/22/2020 11:43PM by K20.
Re: RN104 bricked
September 22, 2020 11:35PM
K20,

Run kwboot on serial console to recover. Similar to this:

https://forum.doozan.com/read.php?2,106589,107374#msg-107374


Quote


The Wiki thread:
Quote
https://forum.doozan.com/read.php?2,23630
Unbricking with Serial Console & JTAG console

Repair Pogo E02 with Raspberry PI (JTAG) and OpenOCD
Serial Port connector - what are people using to make it work
Serial Console hookup - GoFlex Net (external link)
Serial Console hookup - Pogoplug E02 and Pogoplug Pro V3 (external link)
OSX Serial/Net Console
Use Phone Jack - Phone Jack Serial Console Pics
Adding serial connector to Pogoplug Mobile (external link)
WD Mycloud EX2100/4100 Serial Console pic1, also pic2, pic3
Dreamplug Serial Console
How to unbrick your box using serial console with kwboot
kwboot on Mac OSX 10
Unbrick a Pogoplug Pro v3 OXNAS by flashing u-boot in serial console
Unbricking Synology Diskstation DS414 - See also the working thread for this unbricking session

You would start kwboot from where you run serial console (use the kwboot command in that distribution would suffice)

If the mtd0 nanddump file is mtd0_backup_file:
kwboot -t -B 115200 /dev/ttyUSB0 -b mtd0_backup_file -p
And then power up the RN102 box. If kwboot handshakes with the RN102 BootROM successfully, it will start sending the mtd0_backup_file binary. When it completed, the RN102 BootROM will run this u-boot. And the rest is similar to a typicall serial console session.

Once you can get u-boot to start over serial like above, you can restore your mtd0.

-bodhi
===========================
Forum Wiki
bodhi's corner
K20
Re: RN104 bricked
September 22, 2020 11:43PM
Is there anyway I can manually create UBIFS as I have manage to extract root.tlz file from FW

Quote
Did you try reflashing stock mtd3 and mtd4? and how did you do that? i.e. usually ubifs need to be flashed with different command, not nand write.

If root.tlz is an mtd4 nanddump, then flash with nand write. But if it is a rootfs backup, you would need to create UBIFS volume, write it ,.... in UBIFS way (look at documentation how Netgear flash this).

-bodhi
===========================
alxvt:

yep,
i did it with nand write but it is a rootfs backup
from what i understand (tarred with lzma),
so i am going to try recreating the UBIFS


https://forum.doozan.com/read.php?3,95249
K20
Re: RN104 bricked
September 22, 2020 11:52PM
Also is there anyway I can write the root.tlz file to the UBIFS partition

root@nas-36-66-02:~# lsblk
NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda         8:0    0   149G  0 disk
├─sda1      8:1    0     4G  0 part
│ └─md0     9:0    0     4G  0 raid1 /
├─sda2      8:2    0   512M  0 part
│ └─md1     9:1    0 511.4M  0 raid1 [SWAP]
└─sda3      8:3    0 144.5G  0 part
  └─md127   9:127  0 144.4G  0 raid1 /data
mtdblock0  31:0    0   1.5M  1 disk
mtdblock1  31:1    0   512K  1 disk
mtdblock2  31:2    0     6M  1 disk
mtdblock3  31:3    0     4M  1 disk
mtdblock4  31:4    0   116M  1 disk

root@nas-36-66-02:/dev# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00180000 00020000 "u-boot"
mtd1: 00080000 00020000 "u-boot-env"
mtd2: 00600000 00020000 "uImage"
mtd3: 00400000 00020000 "minirootfs"
mtd4: 07400000 00020000 "ubifs"

This is the error when NAS tries to load the FW form flash
Extracting root image...ERROR: Could not mount boot flash [/dev/ubi0_0] (Invalid argument)
Re: RN104 bricked
September 23, 2020 12:15AM
Quote

Extracting root image...ERROR: Could not mount boot flash [/dev/ubi0_0] (Invalid argument)

This looks like an error because of u-boot envs. Not about the UBIFS system on that mtd itself.

So even though you have reflashed mtds 0,1,2,3, somehow the boot command and bootargs envs were not correct.

Do you have a log when you did the flashing and a boot log you can post here? please post the entire 2 logs (as much as you can). A snipet of the log will not provide enough info.

-bodhi
===========================
Forum Wiki
bodhi's corner
K20
Re: RN104 bricked
September 23, 2020 12:42AM
printenv

Marvell>> printenv
AC_Power_fail_detect=open
CASset=min
HW_version=MVT
MALLOC_len=5
Manufacturer=NETGEAR
NANDboot=nand read.e 0x2000000 0x200000 0x400000;nand read.e 0x1000000  0x7e00000 0x20000;nand read.e  0x3000000 0x800000 0x400000;bootz 0x2000000 0x3000000 0x1000000
Product=ReadyNAS 104
SKUNum=RN104
Startup=Normal
USBboot=fatload usb 0:1 0x2000000 /zImage-recovery;fatload usb 0:1 0x1000000 /RN104-recovery.dtb;fatload usb 0:1 0x3000000 /initrd-recovery.gz;bootz 0x2000000 0x3000000 0x1000000
Version=V1.0
autoload=no
baudrate=115200
bootargs=console=ttyS0,115200
bootargs_end=:10.4.50.254:255.255.255.0:KW40:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=nand read 0x2000000 0x200000 0x400000; nand read 0x3000000 0x800000 0x400000; bootm 0x2000000 0x3000000 0x1000000
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_ubi=ubi part ubifs; ubifsmount rootfs; ubifsload 0x2000000 kernel; ubifsload 0x3000000 initrd.gz; bootm 0x2000000 0x3000000 0x1000000
bootdelay=0
cacheShare=no
check_usb=usb start; fatload usb 0:1 0x2000000 /NTGR_USBBOOT_INFO.txt
console=console=ttyS0,115200
disL2Cache=yes
disaMvPnp=no
eeeEnable=no
enaAutoRecovery=yes
enaClockGating=yes
enaFPU=no
enaWrAllo=no
envver=3
eth1addr=00:50:43:02:00:00
eth1mtu=1500
ethact=egiga1
ethaddr=00:50:43:02:02:00
ethmtu=1500
ethprime=egiga1
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-370-db.dtb
image_name=uImage
initrd_high=0xFFFFFFFF
initrd_name=uInitrd
ipaddr=192.168.82.234
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs)
mvNetConfig=switch_config=none
mv_pon_addr=00:50:43:00:00:02
nandEcc=1bit
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=rc
pxe_files_load=:default.arm-armada370-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
rcvrip=169.254.100.100
rootpath=/srv/oneiric
sata_delay_reset=0
sata_dma_mode=yes
serverip=192.168.82.150
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
usb0Mode=host
usb1Mode=host
usb2Mode=device
usbActive=0
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81

Environment size: 2690/131068 bytes

|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_ 
        | | | |___|  _ \ / _ \ / _ \| __| 
        | |_| |___| |_) | (_) | (_) | |_ 
         \___/    |____/ \___/ \___/ \__| 
 ** LOADER **


U-Boot 2011.12-gec25d27-dirty (Oct 26 2015 - 16:56:14) Marvell version: v2011.12 2014_T2.0p1 
06/23/2015 ReadyNAS-104 V2.0

Board: DB-88F6710-BP
SoC:   MV6710 A1
CPU:   Marvell PJ4B v7 UP (Rev 1) LE
       CPU    @ 1200 [MHz]
       L2     @ 600 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 600 [MHz]
       DDR 16Bit Width, FastPath Memory Access
DRAM:  512 MiB

Map:   Code:		0x1feef000:0x1ff9f514
       BSS:		0x1ffef8a0
       Stack:		0x1f9eeef8
       Heap:		0x1f9ef000:0x1feef000

NAND:  (ID 0xf1ad)	128 MiB
MMC:   MRVL_MMC: 0
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000002120000
nand_read_bbt: Bad block at 0x000004580000
nand_read_bbt: Bad block at 0x000007640000

Initialize and scan all PCI interfaces
PEX unit.port(active IF[-first bus]):
------------------------------------------
PEX 0: Root Complex Interface, Detected Link X1, GEN 2.0
PEX 1: Root Complex Interface, Detected Link X1, GEN 2.0
FPU not initialized
USB 0: Host Mode
USB 1: Host Mode
Shutting down unused interfaces:
       SDIO
       AUDIO
       TDM
Modules/Interfaces Detected:
       RGMII0 Phy
       RGMII1 Phy
       PEX0 (Lane 0)
       PEX1 (Lane 1)
       SATA0 (Lane 2)
       SATA1 (Lane 3)
Net:   egiga0, egiga1 [PRIME]
Power On!

FDT loaded successfully
Hit any key to stop autoboot:  0 

NAND read: device 0 offset 0x200000, size 0x400000
 4194304 bytes read: OK

NAND read: device 0 offset 0x800000, size 0x400000
 4194304 bytes read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Marvell>>
Marvell>> setenv serverip 192.168.1.3
Marvell>> setenv ipaddr 192.168.1.2 
Marvell>> setenv gatewayip 192.168.1.1

Marvell>> tftpboot 0x000000000000 uboot.bin
Using egiga0 device
TFTP from server 192.168.1.3; our IP address is 192.168.1.2
Filename 'uboot.bin'.
Load address: 0x0
Loading: #############################################################
done
Bytes transferred = 894280 (da548 hex)
Marvell>> nand write 0x000000000000 0x000000020000 0x000000180000

NAND write: device 0 offset 0x20000, size 0x180000
 1572864 bytes written: OK
Marvell>> tftpboot 0x2000000 kernel.arm 
Using egiga0 device
TFTP from server 192.168.1.3; our IP address is 192.168.1.2
Filename 'kernel.arm'.
Load address: 0x2000000
Loading: #################################################################
	 #################################################################
	 #################################################################
	 ##########################################
done
Bytes transferred = 3474632 (3504c8 hex)
Marvell>> nand write 0x2000000 0x200000 0x400000 

NAND write: device 0 offset 0x200000, size 0x400000
 4194304 bytes written: OK
Marvell>> tftpboot 0x3000000 initrd.gz 
Using egiga0 device
TFTP from server 192.168.1.3; our IP address is 192.168.1.2
Filename 'initrd.gz'.
Load address: 0x3000000
Loading: #################################################################
	 #################################################################
	 #################################################################
	 #######################################
done
Bytes transferred = 3425169 (344391 hex)
Marvell>> nand write 0x3000000 0x800000 0x400000

NAND write: device 0 offset 0x800000, size 0x400000
 4194304 bytes written: OK
Marvell>> boot

## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   Linux-4.4.190.armada.1
   Created:      2019-10-28   2:07:50 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3474568 Bytes = 3.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 03000000 ...
   Image Name:   initramfs
   Created:      2020-02-12   1:13:27 UTC
   Image Type:   ARM Linux RAMDisk Image (lzma compressed)
   Data Size:    3425105 Bytes = 3.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x01000000
   Loading Kernel Image ... OK
   Loading Ramdisk to 1f6aa000, end 1f9ee351 ... OK
   Using Device Tree in place at 01000000, end 010068e5
Updating device tree successful

Starting kernel ...


Starting the boot process...
Detected system type: RN104
Loading kernel modules...done
Boot mode: Normal
UBI device number 0, total 919 LEBs (116690944 bytes, 111.3 MiB), available 915 LEBs (116183040 bytes, 110.8 MiB), LEB size 126976 bytes (124.0 KiB)
Searching for disks (5)...
Bringing up network...done
ERROR: Could not resolve host: update.readynas.com
command failed: /usr/bin/rnutil firmware_update
mdadm: array /dev/md0 started.
mke2fs 1.42.13 (17-May-2015)
Discarding device blocks: done                            
Creating filesystem with 1047552 4k blocks and 1048576 inodes
Filesystem UUID: 1ea9e77c-a133-4bd0-bb95-b6b9db536643
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 

Extracting root image...ERROR: Could not mount boot flash [/dev/ubi0_0] (Invalid argument)

Welcome to ReadyNASOS
nas-02-02-00 login: command failed: mdev -s
command failed: /usr/sbin/telnetd

Welcome to ReadyNASOS
nas-02-02-00 login:
tme
Re: RN104 bricked
September 23, 2020 01:25AM
Hi K20,

Quote

I have manage to create a recovery USB.

If I understand correctly, the recovery USB was partly successful a few days ago. Did it flash your mtd4/ubifs partition OK? If so, you may step back and use all the experience you've gained to recover from that point.

But wait for bodhi's advice and try his recommendation first.

Regards,
Trond Melen
Re: RN104 bricked
September 23, 2020 02:28AM
K20,

UBI device number 0, total 919 LEBs (116690944 bytes, 111.3 MiB), available 915 LEBs (116183040 bytes, 110.8 MiB), LEB size 126976 bytes (124.0 KiB)
Searching for disks (5)...
Bringing up network...done
ERROR: Could not resolve host: update.readynas.com
command failed: /usr/bin/rnutil firmware_update

That UBI device number 0 looks like the rootfs on mtd4.

At this point, either the network is not working properly, or the site "update.readynas.com" is no longer online. So the '/usr/bin/rnutil firmware_update" failed.

1. Check update.readynas.com. See if the website is still working and Netgear is still providing support.

2. In serial console, after you have set the IPs

Marvell>> setenv serverip 192.168.1.3
Marvell>> setenv ipaddr 192.168.1.2 
Marvell>> setenv gatewayip 192.168.1.1

Ping google.com

ping 8.8.8.8

See if the network is really OK. If you can ping google.com then internet is working in u-boot. If not, then that's the problem why update.readynas.com cannot be reached.

And then later, after you see

Welcome to ReadyNASOS
nas-02-02-00 login:

Go ahead and log in. And in ReadyNASOS, check the network again. Ping the router, and ping google.com.

ping 192.168.1.1
ping 8.8.8.8

If the netowrk is up OK with both pings. Then run

/usr/bin/rnutil firmware_update
See how it behaves, whether the stock FW can be upgraded this way,

-bodhi
===========================
Forum Wiki
bodhi's corner
tme
Re: RN104 bricked
September 23, 2020 04:01AM
Hi K20,

Some thoughts: UBIFS sits upon UBI which sits upon '/dev/mtd4'. UBIFS don't care about bad blocks, that's handled by UBI.

I imagine that if '/dev/mtd4' is cloned from another box, the status of the blocks from the other box will be applied to the receiving one. That some blocks are marked bad becuse they were bad on the other box is a minor issue, the main problem is that information about bad blocks on the receiving box is ignored.

So the right way to restore '/dev/mtd4' would be to first install UIB and let it detect and mark bad blocks, then copy the UBIFS from the other box to this one. I assume that both the recovery USB stick and "OS restore" from the Boot menu works this way, while 'nanwrite' don't.

Regards,
Trond Melen
Re: RN104 bricked
September 23, 2020 04:52AM
Trond,

> I imagine that if '/dev/mtd4' is cloned from
> another box, the status of the blocks from the
> other box will be applied to the receiving one.
> That some blocks are marked bad becuse they were
> bad on the other box is a minor issue, the main
> problem is that information about bad blocks on
> the receiving box is ignored.

That's a good observation. However, nandwrite do know about bad blocks at a low level regardless of what content it writes to NAND. So during the nandwrite, one needs to observe the result output to see if there is any error. And we also need take notice of bad blocks before the nanddump.

With that said, It is always a good idea to recreate the UBIFS volume (i.e. ubi initialize and format) . During that, the real bad blocks will be noted and ignored.

But all of the above is academic. From inside stock OS, an upgrade FW procedure will perform all that for you.

The issue here is

Quote

ERROR: Could not resolve host: update.readynas.com
command failed: /usr/bin/rnutil firmware_update

UPDATE:

Ping failed to connect to that site:
PING update.readynas.com (206.16.42.180): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6

So USB restore is more likely to succeed.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 3 time(s). Last edit at 09/23/2020 05:00AM by bodhi.
Re: RN104 bricked
September 24, 2020 09:30PM
bodhi Wrote:
> UPDATE:
>
> Ping failed to connect to that site:
>
> PING update.readynas.com (206.16.42.180): 56 data
> bytes
> Request timeout for icmp_seq 0
> Request timeout for icmp_seq 1
> Request timeout for icmp_seq 2
> Request timeout for icmp_seq 3
> Request timeout for icmp_seq 4
> Request timeout for icmp_seq 5
> Request timeout for icmp_seq 6
>
>
Except ping is not always a good indicator of whether or not a site is available as ping packets can be blocked or dropped.
Browsing to http://update.readynas.com/ results in the following:

Forbidden

You don't have permission to access this resource.
Apache/2.4.25 (Debian) Server at update.readynas.com Port 80

So there is an apache web server there but it likely needs a more specific url.

Ray
tme
Re: RN104 bricked
September 28, 2020 02:01PM
Quote
rayknight
Except ping is not always a good indicator of whether or not a site is available

Good point!
root@rn102:~# apt install -y binutils
root@rn102:~# strings /usr/bin/rnutil | grep netgear
https://my.netgear.com/ajax/Update/firmware/firmware?serial_number=%s&model=%s&firmware_version=%s

root@rn102:~# rnutil firmware_update
name:    ReadyNASOS
version: 6.10.3
verno:   6010003
time:    1581469513
arch:    arm
size:    77369344
md5sum:  fe0afd1f70df930a070482a2ddbcee19
descr:   ReadyNASOS

Not downgrading firmware.
So Netgear's firmware update service is active.

Regards,
Trond Melen
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: