RN104 bricked

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.

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

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 (buy bodhi a beer)

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.

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 (buy bodhi a beer)

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

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)

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 (buy bodhi a beer)

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:

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

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 (buy bodhi a beer)

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

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 (buy bodhi a beer)



Edited 3 time(s). Last edit at 09/23/2020 05:00AM by bodhi.

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

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

Hi K20,

I will try to do the same you have done to your box. I have the same box as you a RN104. But where do you find the files.: uboot.bin and kernel.arm and initro.gz
Is this files inside the Ready NasOs-6.10.3-arm.img file.? Because i can't find this 3 files.
When i unzip the Ready NasOs-6.10.3-arm.zip there is only 2 files the .img and a other on. can't see what name the other file is coz. in a win 10. computer right now. Not on the debian computer.

And also this will be the same if i use the last one.: Ready NasOs-6.10.4-arm.zip

Oki,

Thanks.

Regards.

AkkJaa...

********************************************************************************************************
IMPORTANT: There are updates to this instruction in the next posts below (Step 0, 1, and 2)

********************************************************************************************************


Alright, here's the procedure for anyone in the same situation.

I have an RN102 on which I ran Debian. I had to use the UBIFS partition for the initrd as it was too big to fit in the "minirootfs" mtdpart, so I hosed it. I wanted to restore the NAS to its original condition to sell it, but I found myself with the same issue as the OP: while restoring the kernel and initrd is easy, Netgear doesn't provide any easy way to fix the ubifs!

I had done a backup of the mtd4 partition, the "ubifs" one, from Debian after installing it, just before flashing the new kernel and initrd. But when I tried flashing it back I got endless errors and it couldn't be mounted; amongst other things all the CRCs were wrong apparently. So that backup couldn't be used to restore the system, but it was still useful: I studied it, listed the files in it, and therefore I knew exactly what I needed to put into a replacement ubifs.

I spent a long afternoon and evening poking around and I finally nailed it.

IMPORTANT: this is provided without any guarantee. You may kill your NAS, burn your house down, your dog may shit in your shoes, I don't care. You're on your own with that procedure.

That said, I replayed it from the start and I wrote down everything as I was validating it. It should work.

All the following commands were tested on a Debian 11 PC and on a Netgear RN102. You may need to adapt them to your own setup.

It should be reasonably safe on an RN104, too. I wouldn't try on an RN2xx without looking at an mtd dump first...

I did the whole procedure without any drive in my NAS. I don't know what can happen if drives are present, or when you'll reboot the NAS after fixing everything. Data may be lost.

I'm assuming that your kernel, initrd and ubifs partitions are hosed, but your u-boot and u-boot-env are good. Also, your environment contains the mtd partitioning info -- so we don't have to recreate that.


You will need:

• a Linux computer with 7zip (or 7z) and the mtd-utils packages;
• a working serial connection to your NAS;
• an empty USB stick, size <32GB, formatted in FAT32 / vfat.

STEP 1: extract the data

Download the ReadyNAS package for ARM from Netgear:
https://kb.netgear.com/20684/ReadyNAS-Downloads

Unzip the file:

$ unzip ReadyNASOS-6.10.5-arm.zip 
Archive:  ReadyNASOS-6.10.5-arm.zip
  inflating: ReadyNASOS-6.10.5-arm.img  
  inflating: ReadyNASOS-6.10.5_Release_Notes.html

All the data that we need is inside that .img file. I'm not sure what it is: "file" says data, "binwalk" says tar, "tar" gives an error. But 7zip works brilliantly as usual:

$ mkdir ReadyNASOS-6.10.5-arm

$ 7z x -oReadyNASOS-6.10.5-arm ReadyNASOS-6.10.5-arm.img
[ ... ]
Extracting archive: ReadyNASOS-6.10.5-arm.img
--
Path = ReadyNASOS-6.10.5-arm.img
Type = tar
Offset = 16384
Physical Size = 77291520
Headers Size = 13312
Code Page = UTF-8

Everything is Ok

Files: 12
Size:       77275568
Compressed: 77307904

Everything we need is there:

$ ls -ahlp ReadyNASOS-6.10.5-arm/
total 74M
drwxr-xr-x  2 XXX  XXX   280 Jul 23 23:13 ./
drwxrwxrwt 20 root root  620 Jul 23 23:13 ../
-rw-r--r--  1 XXX  XXX   551 Apr 22 07:16 csums.md5
-rw-r--r--  1 XXX  XXX  3.3M Apr 22 07:16 initrd.gz
-rw-r--r--  1 XXX  XXX  3.4M Apr 22 07:16 kernel
-rw-r--r--  1 XXX  XXX  3.3M Apr 22 07:16 kernel.alpine
-rw-r--r--  1 XXX  XXX     0 Apr 22 07:16 kernel.arm
-rw-r--r--  1 XXX  XXX   59M Apr 22 07:16 root.tlz
-rw-r--r--  1 XXX  XXX  872K Apr 22 07:16 u-boot-rn102-2.0.img
-rw-r--r--  1 XXX  XXX  874K Apr 22 07:16 u-boot-rn104-2.0.img
-rw-r--r--  1 XXX  XXX  1.1M Apr 22 07:16 u-boot-rn202-1.2.img
-rw-r--r--  1 XXX  XXX  1.1M Apr 22 07:16 u-boot-rn204-1.2.img
-rw-r--r--  1 XXX  XXX  972K Apr 22 07:16 u-boot-rn2120-2.0.img
-rw-r--r--  1 XXX  XXX  872K Apr 22 07:16 u-boot-rn25-2.0.img

And that is all that we need! We can restore the kernel, the initrd and we can recreate the ubifs filesystem. The contents of the original ubifs mtdpart are the same as the contents of that img file, just in a different format.

Looking at the files, we can see:

• a kernel for the RN10x generation ("kernel")
• a kernel for the RN2xx generation ("kernel.alpine")
• a common initrd
• u-boot images for each individual machine
• "root.tlz", which contains the files that will be written to the root partition on the hard drives.

STEP 2: create the new UBIFS image

For those not aware, UBI/UBIFS is a weird thing. UBI is the abstration over the flash device, and that takes care of bad blocks and wear. UBIFS sits on top of UBI and takes care of file presentation, while still being extremely low-level. So the creation of a complete UBI image containing an UBIFS image is a two-step process: create the UBIFS filesystem image, then create an UBI image including the UBIFS one.

We'll break that process down into multiple parts. We'll create the UBIFS on the computer, then we'll format the mtdpart and initialize the UBI layer directly on the NAS, then write the UBIFS image we created.

So let's create the UBIFS image:

$ /usr/sbin/mkfs.ubifs -v -r ReadyNASOS-6.10.5-arm -m 2048 -e 126976 -c 907 -o ReadyNASOS-6.10.5-arm.ubifs
mkfs.ubifs
	root:         ReadyNASOS-6.10.5-arm/
	min_io_size:  2048
	leb_size:     126976
	max_leb_cnt:  907
	output:       ReadyNASOS-6.10.5-arm.ubifs
	jrn_size:     8388608
	reserved:     0
	compr:        lzo
	keyhash:      r5
	fanout:       8
	orph_lebs:    1
	space_fixup:  0
	selinux file: (null)
	super lebs:   1
	master lebs:  2
	log_lebs:     5
	lpt_lebs:     2
	orph_lebs:    1
	main_lebs:    611
	gc lebs:      1
	index lebs:   5
	leb_cnt:      622
	UUID:         F9374152-8713-46B4-901C-DEA723F62167
Success!

I got the various parameters to mkfs.ubifs by looking at the original mtd4 dump that I had. I reused exactly the same values. They're all inherited from the NAND size and configuration. They should be the same on an RN104, but I don't know what they'd be on an RN20x/RN21x.

Right, we've got our UBIFS image.


STEP 3: prepare the USB stick

Make sure that your USB stick is mounted. In the following examples mine is mounted on /media/sdb1.

The files we need are:

• the UBIFS image we just created;
• the kernel for our machine;
• the initrd.

So:

$ cp -v ReadyNASOS-6.10.5-arm.ubifs ReadyNASOS-6.10.5-arm/kernel ReadyNASOS-6.10.5-arm/initrd.gz /media/sdb1/
'ReadyNASOS-6.10.5-arm.ubifs' -> '/media/sdb1/ReadyNASOS-6.10.5-arm.ubifs'
'ReadyNASOS-6.10.5-arm/kernel' -> '/media/sdb1/kernel'
'ReadyNASOS-6.10.5-arm/initrd.gz' -> '/media/sdb1/initrd.gz'

Unmount your USB drive, and stick in into the USB 2.0 of your NAS. It's the only one supported by uboot. On the RN102 it's in the front.


STEP 4: flash the kernel and initrd

Now on the NAS.

Have your serial console active. Power on your NAS and stop the autoboot. You'll get into the uBoot command line.

Mount the USB stick and check that everything is there:

Marvell>> usb start
(Re)start USB...
USB:   Active port:     0
Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found

Marvell>> usb tree

Device Tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller 
  |
  +-2  Mass Storage (480 Mb/s, 100mA)
                USB Flash Memory 0611132321190
     
Marvell>> fatls usb 0:1
 78979072   readynasos-6.10.5-arm.ubifs 
  3479896   kernel 
  3427623   initrd.gz 

3 file(s), 0 dir(s)

All good!

Now check your mtd partition table, and wipe the kernel, initrd and ubifs ones (do not touch the u-boot and u-boot-env ones!!!):

Marvell>> mtdparts 

device nand0 <armada-nand>, # parts = 5
 #: name                size            offset          mask_flags
 0: u-boot              0x000000180000          0x000000000000          0
 1: u-boot-env          0x000000020000          0x000000180000          0
 2: uImage              0x000000600000          0x000000200000          0
 3: minirootfs          0x000000400000          0x000000800000          0
 4: ubifs               0x000007400000          0x000000c00000          0

active partition: nand0,0 - (u-boot) 0x000000180000 @ 0x000000000000

defaults:
mtdids  : none
mtdparts: none

Marvell>> nand erase uImage 0x000000600000

NAND erase: device 0 offset 0x200000, size 0x600000
Erasing at 0x7e0000 -- 100% complete.
OK

Marvell>> nand erase minirootfs 0x000000400000

NAND erase: device 0 offset 0x800000, size 0x400000
Erasing at 0xbe0000 -- 100% complete.
OK

Marvell>> nand erase ubifs 0x000007400000

NAND erase: device 0 offset 0xc00000, size 0x7400000
Skipping bad block at  0x07f00000                                          
Skipping bad block at  0x07f20000                                          
Skipping bad block at  0x07f40000                                          
Skipping bad block at  0x07f60000                                          
Skipping bad block at  0x07f80000                                          
Skipping bad block at  0x07fa0000                                          
Skipping bad block at  0x07fc0000                                          
Skipping bad block at  0x07fe0000                                          

OK

I have some bad blocks in my flash. You probably have some too. (Side note: the original UBI image is smaller than the space on the mtd4 partition, on purpose, so that the flash dies can have some bad blocks without it being a problem.)

Now let's load the kernel and initrd from the USB stick into memory, and write them to the flash chip:

Marvell>> fatload usb 0:1 0x2000000 kernel    
reading kernel

3479896 bytes read

Marvell>> nand write.trimffs 0x2000000 uImage 0x000000600000

NAND write: device 0 offset 0x200000, size 0x600000
 6291456 bytes written: OK

Marvell>> fatload usb 0:1 0x2000000 initrd.gz               
reading initrd.gz

3427623 bytes read

Marvell>> nand write.trimffs 0x2000000 minirootfs 0x000000400000

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

We're writing more than we read, that's OK. There will be random memory contents in the mtd partitions after the useful data, and it doesn't matter.

If you're getting error messages or timeouts when loading from the USB stick, use a different one. UBoot is picky.


STEP 5: set up the ubifs partition

Initialize the UBI partition:

Marvell>> ubi part ubifs
Creating 1 MTD partitions on "nand0":
0x000000c00000-0x000008000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=4"
UBI: MTD device size:            116 MiB
UBI: number of good PEBs:        920
UBI: number of bad PEBs:         8
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             907
UBI: total number of reserved PEBs: 13
UBI: number of PEBs reserved for bad PEB handling: 9
UBI: max/mean erase counter: 1/1

Remember some of those values? We used "smallest flash I/O unit" and "logical eraseblock size" when creating the UBIFS image.

We also used the "available PEBs", which is 907 on my device. We created the UBIFS earlier image for 907 PEBs. Depending on your NAND, you may need to go back to that step and recreate a new UBIFS image with your number of available PEBS.

Now we need to create a volume to hold the data inside that partition, which must be called "rootfs":

Marvell>> ubi createvol rootfs          
No size specified -> Using max size (115167232)
Creating dynamic volume rootfs of size 115167232

Marvell>> ubi info l
UBI: volume information dump:
UBI: vol_id          0
UBI: reserved_pebs   907
UBI: alignment       1
UBI: data_pad        0
UBI: vol_type        3
UBI: name_len        6
UBI: usable_leb_size 126976
UBI: used_ebs        907
UBI: used_bytes      115167232
UBI: last_eb_bytes   126976
UBI: corrupted       0
UBI: upd_marker      0
UBI: name            rootfs

UBI: volume information dump:
UBI: vol_id          2147479551
UBI: reserved_pebs   2
UBI: alignment       1
UBI: data_pad        0
UBI: vol_type        3
UBI: name_len        13
UBI: usable_leb_size 126976
UBI: used_ebs        2
UBI: used_bytes      253952
UBI: last_eb_bytes   2
UBI: corrupted       0
UBI: upd_marker      0
UBI: name            layout volume

Now let's load the UBIFS image into RAM:

Marvell>> fatload usb 0:1 0x2000000 readynasos-6.10.5-arm.ubifs
reading readynasos-6.10.5-arm.ubifs

78979072 bytes read

The number of bytes read needs to be converted to hexadecimal. That number depends on your exact image and version of ReadyNAS, so you have to do that yourself.

For me, 78979072 = 0x4B52000.

With that information I can flash my UBIFS image:

Marvell>> ubi writevol 0x2000000 rootfs 0x4B52000
78979072 bytes written to volume rootfs

And finally check that we can mount the UBIFS and list its contents:

Marvell>> ubifsmount rootfs
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: mounted read-only
UBIFS: file system size:   113770496 bytes (111104 KiB, 108 MiB, 896 LEBs)
UBIFS: journal size:       9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root:  0 bytes (0 KiB)

Marvell>> ubifsls 
          3427623  Thu Apr 22 05:16:56 2021  initrd.gz
          3448616  Thu Apr 22 05:16:56 2021  kernel.alpine
          1147028  Thu Apr 22 05:16:56 2021  u-boot-rn202-1.2.img
          3479896  Thu Apr 22 05:16:56 2021  kernel
         60950986  Thu Apr 22 05:16:48 2021  root.tlz
                0  Thu Apr 22 05:16:56 2021  kernel.arm
              551  Thu Apr 22 05:16:56 2021  csums.md5
           995112  Thu Apr 22 05:16:56 2021  u-boot-rn2120-2.0.img
           894280  Thu Apr 22 05:16:56 2021  u-boot-rn104-2.0.img
           892032  Thu Apr 22 05:16:56 2021  u-boot-rn25-2.0.img
          1146748  Thu Apr 22 05:16:56 2021  u-boot-rn204-1.2.img
           892696  Thu Apr 22 05:16:56 2021  u-boot-rn102-2.0.img

Great!

Umount the UBIFS volume:

Marvell>> ubifsumount 
Unmounting UBIFS volume rootfs!

STEP 6: Reboot and enjoy

Check that your env is correct:

Marvell>> printenv bootargs
bootargs=console=ttyS0,115200

Marvell>> printenv bootcmd
bootcmd=nand read 0x2000000 0x200000 0x600000; nand read 0x3000000 0x800000 0x400000; bootm 0x2000000 0x3000000 0x1000000

Marvell>> printenv mtdparts 
mtdparts=mtdparts=armada-nand:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubif
s)

I guess that it should look the same on RN104 too.

If everything is alright, reboot:

Marvell>> reset
resetting ...

Then after that you're on your own. I put a blank disk in it to make sure that everything works, and it initialized it correctly. I don't know what would happen if you insert a drive that already has data on it. If ReadyNAS doesn't recognize the partitions it may overwrite them. I don't know either what would happen if you have an older ReadyNAS on the drives, and a newer one in flash. That all depends on ReadyNAS' behaviour.

As far as this procedure is concerned, this is mission accomplished: I restored the NAS to full original condition.

I hope that it will help the OP.



Edited 1 time(s). Last edit at 07/24/2021 05:14AM by bodhi.

JF,

Fantastic! Thanks for sharing.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Bodhi, you're welcome!

I thought about it some more overnight, and I think that I need to make a few corrections and addendum.

Also there is an important mistake in step 1! It didn't affect me, but it might affect someone else.


First, the .img file distributed by Netgear is a 16k header followed by a tarball. 7zip is smart enough to find the beginning of the tarball on its own, but not tar.

The header contains just this, followed by zeroes:

info::name=ReadyNASOS,version=6.10.5,time=1619067981,size=77307904,md5sum=0297d035d37792977d2f6b36dd53f31f,arch=arm,descr=ReadyNASOS

I now believe that the reason why Netgear distributes this .img file and not a ready-to-flash UBIFS or UBI image, is that each flash die has a different amount of bad blocks, therefore the exact size of each UBIFS is different! The flash chip details might also vary, affecting how UBIFS is created.

The likely workflow goes like this. During manufacturing, an UBI/UBIFS is created automatically on the mtd4 partition taking into account the pre-existing bad block (which allows them to use less-than-perfect dies). Then when the OS upgrades itself, the new files are written to the UBIFS volume without having to worry about the bad blocks. If new bad blocks appear, it's detected by the UBI layer. Hopefully the OS can see that, and rewrite the files to the UBIFS volume at the next boot -- skipping around the new bad blocks.

So that means that each UBIFS image is unique, and needs to be done specifically for each device!

Let's add a step zero.


STEP 0: Get your UBI details

Start your serial console, power on your NAS, interrupt the boot and get to the UBoot console.

Then wipe the "ubifs" partition and go through the UBI initialization:

Marvell>> nand erase ubifs 0x000007400000

NAND erase: device 0 offset 0xc00000, size 0x7400000
Skipping bad block at  0x07f00000                                          
Skipping bad block at  0x07f20000                                          
Skipping bad block at  0x07f40000                                          
Skipping bad block at  0x07f60000                                          
Skipping bad block at  0x07f80000                                          
Skipping bad block at  0x07fa0000                                          
Skipping bad block at  0x07fc0000                                          
Skipping bad block at  0x07fe0000                                          

OK

Marvell>> ubi part ubifs
Creating 1 MTD partitions on "nand0":
0x000000c00000-0x000008000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=4"
UBI: MTD device size:            116 MiB
UBI: number of good PEBs:        920
UBI: number of bad PEBs:         8
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             907
UBI: total number of reserved PEBs: 13
UBI: number of PEBs reserved for bad PEB handling: 9
UBI: max/mean erase counter: 1/1

We will need the following values to create the UBIFS image:

• logical eraseblock size: 126976 bytes
• smallest flash I/O unit: 2048
• available PEBs: 907

The two first ones may be different if you flash chip is completely different from mine. The last one is more likely to be different, and depends on how many bad blocks there are.


UPDATED STEP 1: extract the data

Here's the mistake I did in my previous post: "kernel" and "kernel.arm" are hardlinked in the tarball, but 7zip didn't extract them as such, and the size of "kernel.arm" is zero! I don't know why I didn't have any issue, but let's fix this.

First get the tarball out of the .img file:

$ dd if=ReadyNASOS-6.10.5-arm.img of=ReadyNASOS-6.10.5-arm.tar bs=1024 skip=16
75480+0 records in
75480+0 records out
77291520 bytes (77 MB, 74 MiB) copied, 0.152685 s, 506 MB/s

Create a directory to hold the data and extract it:

$ mkdir ReadyNASOS-6.10.5-arm

$ tar -C ReadyNASOS-6.10.5-arm -xvf ReadyNASOS-6.10.5-arm.tar 
csums.md5
initrd.gz
kernel
kernel.alpine
kernel.arm
root.tlz
u-boot-rn102-2.0.img
u-boot-rn104-2.0.img
u-boot-rn202-1.2.img
u-boot-rn204-1.2.img
u-boot-rn2120-2.0.img
u-boot-rn25-2.0.img

Check that everything is there, and look at the inode numbers on the left to make sure that "kernel" and "kernel.arm" have the same one, i.e. are hard links (your inode numbers will be different from mine):

$ ls -ahilp ReadyNASOS-6.10.5-arm
total 78M
502 drwxr-xr-x  2 XXX  XXX   280 Jul 24 10:36 ./
  1 drwxrwxrwt 18 root root  520 Jul 24 10:36 ../
503 -rw-r--r--  1 XXX  XXX   551 Apr 22 07:16 csums.md5
504 -rw-r--r--  1 XXX  XXX  3.3M Apr 22 07:16 initrd.gz
505 -rw-r--r--  2 XXX  XXX  3.4M Apr 22 07:16 kernel
506 -rw-r--r--  1 XXX  XXX  3.3M Apr 22 07:16 kernel.alpine
505 -rw-r--r--  2 XXX  XXX  3.4M Apr 22 07:16 kernel.arm
507 -rw-r--r--  1 XXX  XXX   59M Apr 22 07:16 root.tlz
508 -rw-r--r--  1 XXX  XXX  872K Apr 22 07:16 u-boot-rn102-2.0.img
509 -rw-r--r--  1 XXX  XXX  874K Apr 22 07:16 u-boot-rn104-2.0.img
510 -rw-r--r--  1 XXX  XXX  1.1M Apr 22 07:16 u-boot-rn202-1.2.img
511 -rw-r--r--  1 XXX  XXX  1.1M Apr 22 07:16 u-boot-rn204-1.2.img
512 -rw-r--r--  1 XXX  XXX  972K Apr 22 07:16 u-boot-rn2120-2.0.img
513 -rw-r--r--  1 XXX  XXX  872K Apr 22 07:16 u-boot-rn25-2.0.img

Now we have the right data. Phew.


UPDATED STEP 2: create the new UBIFS image

Now we can create the UBIFS image. Replace the values in the command below with the ones that you wrote down after initializing UBI:

$ /usr/sbin/mkfs.ubifs --verbose --space-fixup --squash-uids --min-io-size=2048 --leb-size=126976 --max-leb-cnt=907 --root=ReadyNASOS-6.10.5-arm --output=ReadyNASOS-6.10.5-arm.ubifs
mkfs.ubifs
	root:         ReadyNASOS-6.10.5-arm/
	min_io_size:  2048
	leb_size:     126976
	max_leb_cnt:  907
	output:       ReadyNASOS-6.10.5-arm.ubifs
	jrn_size:     8388608
	reserved:     0
	compr:        lzo
	keyhash:      r5
	fanout:       8
	orph_lebs:    1
	space_fixup:  1
	selinux file: (null)
	super lebs:   1
	master lebs:  2
	log_lebs:     5
	lpt_lebs:     2
	orph_lebs:    1
	main_lebs:    611
	gc lebs:      1
	index lebs:   5
	leb_cnt:      622
	UUID:         2A0E76EA-D40D-402D-B241-0EB8ABD15B9C
Success!

I have done a few important updates to the mkfs.ubifs options (apart from using their long names):

• "--space-fixup" is a workaround to avoid needless writes and wear to the flash chip when updating the image. It will make the very first UBIFS mount in Linux longer, taking maybe 10s.
• "--squash-uids" stores all files with UID and GID 0, thus belonging to root instead of our local user. That's how the original UBIFS is set up.

If you have ubidump installed you can check the contents of the .ubifs file:

$ ubidump -l ReadyNASOS-6.10.5-arm.ubifs 
==> ReadyNASOS-6.10.5-arm.ubifs <==
-rw-r--r--  1 0     0        3427623 2021-04-22 05:16:56 initrd.gz
-rw-r--r--  1 0     0        3448616 2021-04-22 05:16:56 kernel.alpine
-rw-r--r--  1 0     0        1147028 2021-04-22 05:16:56 u-boot-rn202-1.2.img
-rw-r--r--  2 0     0        3479896 2021-04-22 05:16:56 kernel
-rw-r--r--  1 0     0       60950986 2021-04-22 05:16:48 root.tlz
-rw-r--r--  2 0     0        3479896 2021-04-22 05:16:56 kernel.arm
-rw-r--r--  1 0     0            551 2021-04-22 05:16:56 csums.md5
-rw-r--r--  1 0     0         995112 2021-04-22 05:16:56 u-boot-rn2120-2.0.img
-rw-r--r--  1 0     0         894280 2021-04-22 05:16:56 u-boot-rn104-2.0.img
-rw-r--r--  1 0     0         892032 2021-04-22 05:16:56 u-boot-rn25-2.0.img
-rw-r--r--  1 0     0        1146748 2021-04-22 05:16:56 u-boot-rn204-1.2.img
-rw-r--r--  1 0     0         892696 2021-04-22 05:16:56 u-boot-rn102-2.0.img

2 instead of 1 for "kernel" and "kernel.arm", the two files are the same size, and "0 0" for the owner and group. Looks good.


After that it's all the same until step 4 and step 5. As you have already wiped mtd4 and reinitialized UBI, you don't need to do it again. So you can skip those two commands.

In step 4:

Marvell>> nand erase ubifs 0x000007400000

In step 5:

Marvell>> ubi part ubifs

It's no big drama if you run them again, though. Note that they go together, so if you run the first one again by mistake you'll have to run the second one again too.


Then after you reset your NAS and restart under Linux, you'll see something like this on the serial console:

Starting the boot process...
Detected system type: RN102
Loading kernel modules...done
Boot mode: Normal
UBI device number 0, total 920 LEBs (116817920 bytes, 111.4 MiB), available 9 LEBs (1142784 bytes, 1.1 MiB), LEB size 126976 bytes (124.0 KiB)

The boot process will hang there for a little bit as the free space is fixed on first boot, and then continue. Don't panic.

Bodhi, could you please edit my first post to add a big fat banner at the top saying that there are important updates in later messages in that thread?

Thank you very much!

JF,

> Bodhi, could you please edit my first post to add
> a big fat banner at the top saying that there are
> important updates in later messages in that
> thread?

I've put a notice on top.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Excellent! Thank you very much Bodhi.

JF,

I speed-read the instruction once. All looks good!

I do have one comment about UBIFS step(s).

I suspect that you don't have to worry too much about dupplicating exactly the parameters from the mtd backup that you have. Since you've extract the files on it and copy them over to the new volume. So you could create the UBIFS volume using default values, and it will work (I could be wrong, it's been a while since I played with this subject). Nevertheless, using the same parameters to replicate the mtd is probably better.

=======

Added to the Wiki thread.

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

Quote

Unbricking with Serial Console & JTAG console

How to unbrick your box using serial console with kwboot
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
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
Unbricking (Restore Factory Firmware) Netgear ReadyNAS RN102/104

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@Bodhi,

You don't have default values for the UBIFS image. Because of the way the UBI and UBIFS layers are tightly intertwined, you need to know the three values to be able to create an UBIFS image. "mkfs.ubifs" will print out an error message if you forget any of them. Those three values depend on the state of your NAND chip, and are likely to be different on different systems.

At first I simply copied the parameters from my backup, as a starting point. It worked, I didn't think any further about it (my bad) and I wrote the instructions. Then overnight it dawned on me that those parameters matched exactly my NAND chip, including its number of bad blocks! That meant it worked by accident because I copied the parameters from my own backup, but that it wasn't generic and would need to be tuned for each and every system.

Someone whose chip has 16 bad blocks for example (twice as much as on my chip), wouldn't be able to write the UBIFS image created with my number of available erase blocks. There just wouldn't be enough room on that chip.

Also, my original instructions kind of skipped over the whole topic of finding those values. It's easy enough if you have a backup, but what if you don't? I guess that most people in that situation won't have one at hand.

So the update to the instructions made the process completely generic, and removed the need to look at a backup to figure out the three parameters. Step 0 gives us those three critical values that can be used later to create a custom UBIFS for that system.

Did I explain myself clearly enough? :)

JF,

> You don't have default values for the UBIFS image.

Of course you're right! I did not remember correctly. I digged out my old notes to find example of this.

The command you used for this NAND

$ /usr/sbin/mkfs.ubifs --verbose --space-fixup --squash-uids --min-io-size=2048 --leb-size=126976 --max-leb-cnt=907 --root=ReadyNASOS-6.10.5-arm --output=ReadyNASOS-6.10.5-arm.ubifs

One I used for the Pogoplug V4 and then used squashfs to shrink it (I did not release a rescue system for this box).

mkfs.ubifs -q -r /media/rootfs -m 2048 -e 131072 -c 728  -o rescue-v3.img

The above is a good illustration how the LEB size is different.

> So the update to the instructions made the process
> completely generic, and removed the need to look
> at a backup to figure out the three parameters.
> Step 0 gives us those three critical values that
> can be used later to create a custom UBIFS for
> that system.
>

Good thought!

> Someone whose chip has 16 bad blocks for example
> (twice as much as on my chip), wouldn't be able to
> write the UBIFS image created with my number of
> available erase blocks. There just wouldn't be
> enough room on that chip.

How about provisioning a small chunk of NAND (i.e. creating the volume a bit smaller than the real mtd size)?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

JF,

BTW, your HowTo is a really good exampe for UBIFS when someone looking for this subject :)

You could combine the 1st and 2nd post and make a new post for the final instruction, too. And I'll update the old posts to point people to the instruction.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@Bodhi, thank you for your kind words. :)

I did think of having a smaller UBIFS volume that wouldn't fill up the whole UBI layout, yes. But in that specific case the goal was to restore the RN102 to its manufacturing state, and in the original mtd4 there's a single volume taking up the whole UBI layout. So that was the only option really.

Indeed I should merge the posts. It's complicated enough as it is without having to go back and forth on the page. Also, I might do multiple posts in a row in a new topic, with each post covering a specific piece of information or step.

I'll work on that when I'll have some time.

Here's the updated and cleaned-up procedure:

HOWTO: Restore a ReadyNAS 102/104 to original state

Thanks JF!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)