Forum Discussion

Tutor

Oct 18, 2020

Solved

RNDU2000 NAND recovery

Hello guys! So this is it. I finally managed to wipe out the internal NAND of one of my old RNDU2000. Of course, I did that by mistake. I was having a very bad day, been quite reckless and mistaken ...

firerain
Nov 02, 2020
Hi guys,
just letting you know (and for sake of others) that everything went fine. I just needed some free time to report back to you.

mdgm wrote:
The USB Boot Recovery key does need to be set up correctly to boot. It needs to use the MBR partitioning scheme with a single FAT32 partition and the MBR needs to be set to be bootable, with the syslinux bootloader installed as well. Not all USB keys are compatible.
That's true, I needed to find a proper key to make it work. Suprisingly, an old, 1G key wasn't working at all, although I've used it to boot on other, even older devices.
Another problem was, that internal NAND also needs a proper partitioning scheme. Mine was screwed up earlier by deleting the partition and creating a new Linux partition using fdisk, so I needed to recreate it. Actually, the values for heads, cylinders and sectors were wrong.
I had:
And the proper configuration looks like this:

One note at this point: you need a proper linux distro that would run in a console environment, has fdisk included and supports raid configurations (has proper drivers/kernel modules included).

My next mistake was that I was trying to create and restore separate images for MBR and sda1 but it turned out that simple dd of whole block device is enough.

I'm a bit surprised that actually none of the recovery images did their work:
The one for RNOS6 couldn't find proper hardware configuration, which is totally understood
The legacy one (RNOS4) couldn't locate ANY flash drives

For the record, I haven't found anything in the NAND content that would suggest that the serial number is stored there.
For instance, the Device ID for the ReadyCLOUD is MAC based:

Anyway, thanks for supporting me! :-)

mdgm

Virtuoso

Oct 25, 2020

The boot menu options depend on the internal flash contents.

dd'ing an image of the internal flash on the working Ultra 2 and restoring it onto the working one should have worked well enough to get the system to boot even though not a recommended way to fix.

The USB Boot Recovery key does need to be set up correctly to boot. It needs to use the MBR partitioning scheme with a single FAT32 partition and the MBR needs to be set to be bootable, with the syslinux bootloader installed as well. Not all USB keys are compatible.

Seeing you can boot off a Linux USB it should be possible to try some things using that, that could fix the system.

firerain

Tutor

Nov 02, 2020

Hi guys,

just letting you know (and for sake of others) that everything went fine. I just needed some free time to report back to you.

mdgm wrote:
The USB Boot Recovery key does need to be set up correctly to boot. It needs to use the MBR partitioning scheme with a single FAT32 partition and the MBR needs to be set to be bootable, with the syslinux bootloader installed as well. Not all USB keys are compatible.

That's true, I needed to find a proper key to make it work. Suprisingly, an old, 1G key wasn't working at all, although I've used it to boot on other, even older devices.
Another problem was, that internal NAND also needs a proper partitioning scheme. Mine was screwed up earlier by deleting the partition and creating a new Linux partition using fdisk, so I needed to recreate it. Actually, the values for heads, cylinders and sectors were wrong.

I had:

And the proper configuration looks like this:

One note at this point: you need a proper linux distro that would run in a console environment, has fdisk included and supports raid configurations (has proper drivers/kernel modules included).

My next mistake was that I was trying to create and restore separate images for MBR and sda1 but it turned out that simple dd of whole block device is enough.

I'm a bit surprised that actually none of the recovery images did their work:

The one for RNOS6 couldn't find proper hardware configuration, which is totally understood
The legacy one (RNOS4) couldn't locate ANY flash drives

For the record, I haven't found anything in the NAND content that would suggest that the serial number is stored there.
For instance, the Device ID for the ReadyCLOUD is MAC based:

Anyway, thanks for supporting me! :-)

Sandshark
Sensei - Experienced User
Nov 02, 2020
firerain wrote:

For the record, I haven't found anything in the NAND content that would suggest that the serial number is stored there.
For instance, the Device ID for the ReadyCLOUD is MAC based:
It's not supposed to be. It defaults to the MAC when it can't find the proper serial number in the vpd file. Apparently, there were also some units that shipped without the proper serial number in the file. I had one of those. Other users have been unable to use ReadyCloud with a MAC based serial number because it has too few characters. Maybe Netgear changed that.