Ultra2 stops working after boot

[Shawinkle]

Hello.

My RNDU2220 works fine since.... a lot of years

Last month, after a long global power outage (UPS out of battery), the NAS runs strangely. It hangs just after the boot.

Here's a sample of the "/var/log/messages" copied quickly by SSH :

Mar 10 05:30:52 nas-C1-4E-C8 kernel: ata1.00: configured for UDMA/133
Mar 10 05:30:52 nas-C1-4E-C8 kernel: ata1: EH complete
Mar 10 05:30:52 nas-C1-4E-C8 kernel: ata2.00: configured for UDMA/133
Mar 10 05:30:52 nas-C1-4E-C8 kernel: ata2: EH complete
Mar 10 05:30:52 nas-C1-4E-C8 kernel: Adding 524272k swap on /dev/md1. Priority:-1 extents:1 across:524272k
Mar 10 05:30:52 nas-C1-4E-C8 kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1
Mar 10 05:31:00 nas-C1-4E-C8 RAIDiator: System is up.
Mar 10 06:16:21 nas-C1-4E-C8 RAIDiator: Veuillez redémarrer votre NAS pour poursuivre le processus de mise à jour.
Mar 10 06:17:06 nas-C1-4E-C8 RAIDiator: Veuillez fermer cette fenêtre de navigateur et utilisez RAIDar pour vous reconnecter au périphérique. Redémarrage du système ...
Mar 10 06:17:06 nas-C1-4E-C8 RAIDiator: Redémarrage du système
Mar 10 06:17:11 nas-C1-4E-C8 shutdown[10298]: shutting down for system reboot
Mar 10 06:17:12 nas-C1-4E-C8 kernel: ata1.00: configured for UDMA/133
Mar 10 06:17:12 nas-C1-4E-C8 kernel: ata1: EH complete
Mar 10 06:17:12 nas-C1-4E-C8 kernel: sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Mar 10 06:17:12 nas-C1-4E-C8 kernel: ata2.00: configured for UDMA/133
Mar 10 06:17:12 nas-C1-4E-C8 kernel: ata2: EH complete
Mar 10 06:17:12 nas-C1-4E-C8 kernel: sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Mar 10 06:17:14 nas-C1-4E-C8 exiting on signal 15

 This (translated) passage is strange :

RAIDiator: System is up.
RAIDiator: Please restart your NAS to continue the update process.
RAIDiator: Please close this browser window and use RAIDar to reconnect to the device. System restart ...
RAIDiator: System restarting

The system hasn't been updated for a long time. So...why this and now ?

I don't know if there's a hidden flag/parameter somewhere, like a "/.update" or "/.readynas_update".

I'll try to search how to intercept the call who creates a shutdown request, to investigate longer.

Julien.

[StephenB]

What firmware was the system running?

Do you have a backup for the files on the NAS?

[Shawinkle]

I don't really remember... 4.2.26 or 4.2.29.

I tried to "reinstall the OS" via the boot menu, but nothing happen. 

And I don't plan to lose data.

[StephenB]

The NAS says it is shutting down, but you are still getting information via ssh?

Does that mean that the NAS is still running, but that the shares (and frontview) are not available?

If so, is the data volume still mounted?

[Shawinkle]

I just have the time to connect during the boot through a SSH connection (with private key), and to copy (with scp command) some log files.
The volumes seems to be mounted. All the shares are available.

[StephenB]

---

@Shawinkle wrote:

The volumes seems to be mounted. All the shares are available.

---

Ok.

You could boot up the NAS in tech support mode and then get to the linux command line with telnet.  From there you can mount the OS partition and the data volume manually, and then back up the files to USB disks.  

Not sure if you can block the firmware update process, it depends on what is triggering it.  You could look for /.cf_update_in_progress, and delete it if you find it.  Similarly for /.os_update

If those aren't there (or if deleting them doesn't help), then you'd need to do a factory default (and maybe a USB recovery).

Have you ever used tech support mode?

[Shawinkle]

Nope. Never tried the system in Tech Mode. I'll give a try. 😊

[StephenB]

---

@Shawinkle wrote:

Nope. Never tried the system in Tech Mode. I'll give a try. 😊

---

Start by booting the NAS into tech support mode using the boot menu.

Instructions are on pages 14-15 here:

• https://www.downloads.netgear.com/files/GDC/RNDU2000/ReadyNAS_Ultra_UltraPlus_NVX_Pro_HW_en_8July11....

Next you will need to access the NAS using Telnet.  If you are using a Windows PC, I suggest you use the Putty client for that.

• https://www.chiark.greenend.org.uk/~sgtatham/putty/

When you connect to the NAS, log in as root.  The password is infr8ntdebug.

Then enter

start_raid.sh
mount /dev/md0 /sysroot

The OS partition is now mounted.  If you want to chroot (likely you will) then follow this with

mount --bind /proc /sysroot/proc
mount --bind /dev /sysroot/dev
mount --bind /dev/pts /sysroot/dev/pts
mount --bind /sys /sysroot/sys
chroot /sysroot /bin/bash

If you want to proceed with mounting the data volume:

vgscan
vgchange -a y
mount /dev/c/c /c

[Shawinkle]

Hello.

I tried different solutions :

• Activate the Tech Mode like you described
• Reinstall the firmware via USB

In these cases, nothing happens. 

Il also tried to disassemble the "little monster" to see if the hidden port (rear, bottom, left) was usable (referenced ?). But nope. At his moment, I noticed that there's a CR2032 battery. I thought I could remove it to reset the possible recorded informations. But before, I test through a quick SSH connection to check the "ntpdate" command. And it reveals tat the offset was huge... so, I decided to replace the CR2032 battery.

The RNDU2 booted and... TADAAAAAM !!!

Many thx @StephenB for the time spent on this case.

It was just this [censored] and inaccessible CR2032 battery...

Julien.

[Shawinkle]

One more thing...

On Win10, the USB recovery tool cannot run without the "Microsoft Visual C++ 2005 Service Pack 1 Redistributable".

"The application has failed to start because the side by side configuration is incorrect please see the application event log or use the command line sxstrace.exe tool for more detail."

Julien.

[Sandshark]

The battery's sole purpose is to back up the real-time clock.  So something else "fixed" it.  Could be just cleaning it out to get to the battery, or could be luck that it booted this time.  I recommend you create an updated backup just in case the "fix" doesn't stick.