RNDU2000 NAND recovery

[firerain]

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 that with USB attached drive while performing reformat.

What I did exactly, was deleting the whole partition with fdisk and creating a primary ext4 partition. Upon ending I have relised what I did and I have created vfat partition back.

Anyway, now here I am with a chasis not able to boot into system.

Keeping it short:

• The unit was running RNOS 6.10.1
• I hooked the unit up with USB-TTL and I am able to communicate with it via serial console
• Booting without HDDs shows "MBR Missing operating system"
• Booting from Recovery USB (created using this method, with RNOS 6.10.3 image) shows "Missing operating system Reboot and Select proper Boot device"
• Booting from Linux USB succeeds
• I have second RNDU2000 (also running RNOS 6.10.1) that is functional

My idea was to dd NAND content from my second unit and then recover it to the first one but that doesn't seem to work. Still getting "MBR Missing operating system".

Any thoughts on how should I proceed with the recovery?

I know that this procedure is totally unsupported and so on but I'd appreciate any help.

[firerain · Accepted solution]

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]

---

@firerain wrote:

• Booting from Recovery USB (created using this method, with RNOS 6.10.3 image) shows "Missing operating system Reboot and Select proper Boot device"

What "this method" are you referring to?  You need to create an OS4.x style USB recovery and use a modified OS6 image (same as used to convert OS4 to OS6) on a legacy NAS.  A native OS6 recovery won't recognize your hardware configuration.  That or USB restore to 4.x and then re-convert.  I believe the recovery will completely re-format the flash and put on the OS.  But, you have also wiped out the model and serial number information that's contained there.  The model number isn't really important under OS6 because the ProBE, Pro Pioneer, Pro6, and Ultra6Plus (which all have the same motherboard) all behave the same under OS6 and the OS seems to be able to figure out on its own that it's one of those.  But lack of a valid serial number will keep you from using ReadyCloud.  The mods may be willing to help you restore that information, but you'll have to PM them a photo of the serial number label and ask them nicely to help un-do the mess you made, then put the unit in remote support mode for them to gain access.

If you DD the image from another NAS, you'll have two with the same serial number, and I don't know what the consequence of that would be with Netgear network services.

[firerain]

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]

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]

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 · Accepted solution]

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]

---

@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.