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! :-)

firerain

Tutor

Oct 19, 2020

Thanks for your input.

I had to copy&paste the message so the link got lost. I was reffering to this method, so the offical one for OS6 units.

Runing it from the RAIDiator USB recovery has came to my mind but I got so surprised by the fact that dd method didn't work that I 've decided to get some second thoughts from the community.

I am aware of the SN issue but I need to get this unit up and running first and then I will try to take care of that.

I don't know if I'll have enough time to test it before the weekend but for sure I will give it a try and report back here.

firerain

Tutor

Oct 24, 2020

Unfortunately, the USB recovery (for legacy OS) throws this arror at me:

Same goes for default boot options and for OSReinstall.

Any new ideas?

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.