Can't get to Admin page after firmware update.

---

StephenB wrote:

---

CatDaddy60 wrote:

Is there some sort of limit to how many posts can be made in a question? I keep replying to your latest post and the system appears to keep eating it. I'll try again...

There is an automatic spam filter that sometimes misbehaves.  It is catching your  disappearing replies.

 

---

CatDaddy60 wrote:

 

I'm presuming that to access the options you suggest, I'll need to be in front of it with a keyboard/monitor attached? Reason I ask is that I work remotely via VPN to the office and I'm guessing that not much can be done via remote connection? 

---

You can connect over the VPN.  But someone in the office would need to boot the NAS into tech support mode (since as far as we know, ssh is not enabled).

 

The way I work is to connect via VPN then RDP to my office workstation and that has PuTTY installed on it. Is there a default port to use when connecting to such a NAS using PuTTY?

 

So someone would need to be able/willing to do that for you (and perhaps reboot it later on).

 

---

CatDaddy60 wrote:

Can the OS be reinstalled without losing the data? 

---

It can, but if the OS partition is full, then attempting that would make things worse.

 

What you'd need to do to diagnose this is to

• boot up in tech support mode (the hardware manual has instructions)
• connect with telnet - I recommend using the free putty client for this
• log into the NAS using a backdoor password (which only works in tech support mode).
• Check for a full OS, and perhaps some other things

If the OS partition is not full, then it would be reasonable to try an OS reinstall.  That is another boot-menu option in the hardware manual.  The reinstall only does a partial reinstall of the OS, and it also 

• resets the admin password back to password
• resets the network config to use DHCP with no bonding
• disables volume quota (which can be re-enabled on the volume settings wheel).

The hardware manual is found here:

• https://www.downloads.netgear.com/files/GDC/RN2120/ReadyNAS_OS6_Rackmount_HWM_EN.pdf

Boot menu options are on pages 17-18

 

Have you much experience with the linux command line?

 

Not much. The only time I see Linux is when VMware ask me to create a PuTTY session direct to a host and then they take over. If I do get connected I wouldn't know how to check if the OS is full, for example. Is there a tolerance on the OS partition i.e. must have X Mb free in order to function?

 

Thank you for the assist thus far - you've been very helpful. I'll probably leave it now until I'm back at work on Monday and get back to painting the living room 😊. Some holiday!

---

---

CatDaddy60 wrote:

The way I work is to connect via VPN then RDP to my office workstation and that has PuTTY installed on it. Is there a default port to use when connecting to such a NAS using PuTTY?

 

---

You need to select telnet, which will change the port to 23.  

Thank you.

What Linux commands do I need to use in order to check whether the OS partition is full?

---

CatDaddy60 wrote:

 

What Linux commands do I need to use in order to check whether the OS partition is full?

---

First you need to boot the NAS in tech support mode, and connect with telnet.

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

Once in, you start the RAID, mount the OS partition and chroot using this command

rnutil chroot

 Your NAS uses the ext file system for the OS.

You can start with

cd //
du -d1 -h .

When I run this on one of my own NAS, I see this:

6.4M    ./bin
0       ./boot
24K     ./dev
12M     ./etc
0       ./home
33M     ./lib
4.0K    ./lib64
0       ./media
4.7M    ./opt
0       ./proc
40K     ./root
0       ./run
11M     ./sbin
0       ./srv
0       ./sys
0       ./tmp
331M    ./usr
542M    ./var
0       ./
0       ./data
0       ./apps
30M     ./frontview
968M    /

This will be somewhat different than yours, but it should help in seeing if there is a folder that has a lot more data than it should.

If you see a folder like that, you can descend into it with cd and then repeat the du command.  Once you've isolated the folder, you can use ls -als to look at the files in it.

---

StephenB wrote:

---

CatDaddy60 wrote:

 

What Linux commands do I need to use in order to check whether the OS partition is full?

---

First you need to boot the NAS in tech support mode, and connect with telnet.

 

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

 

Once in, you start the RAID, mount the OS partition and chroot using this command

rnutil chroot

 Your NAS uses the ext file system for the OS.

You can start with

cd //
du -d1 -h .

When I run this on one of my own NAS, I see this:

6.4M    ./bin
0       ./boot
24K     ./dev
12M     ./etc
0       ./home
33M     ./lib
4.0K    ./lib64
0       ./media
4.7M    ./opt
0       ./proc
40K     ./root
0       ./run
11M     ./sbin
0       ./srv
0       ./sys
0       ./tmp
331M    ./usr
542M    ./var
0       ./
0       ./data
0       ./apps
30M     ./frontview
968M    /

This will be somewhat different than yours, but it should help in seeing if there is a folder that has a lot more data than it should.

If you see a folder like that, you can descend into it with cd and then repeat the du command.  Once you've isolated the folder, you can use ls -als to look at the files in it.

Many thanks for that detailed reply. I'm sure it will be useful as Linux is a black art to me.

Assuming there was some kind of problem when it upgraded its firmware last week, are there any 'problem' files I should be looking for to delete i.e. the equivalent to Windows' dump files or similar? How do I delete them?

Thanks again.

---

CatDaddy60 wrote:

---

Assuming there was some kind of problem when it upgraded its firmware last week, are there any 'problem' files I should be looking for to delete i.e. the equivalent to Windows' dump files or similar? How do I delete them?

 

---

Let's first see if the OS partition is full (and if it is, what files are filling it).

---

StephenB wrote:

---

CatDaddy60 wrote:

---

Assuming there was some kind of problem when it upgraded its firmware last week, are there any 'problem' files I should be looking for to delete i.e. the equivalent to Windows' dump files or similar? How do I delete them?

 

---

Let's first see if the OS partition is full (and if it is, what files are filling it).

---

I've now got someone at the office pushing the buttons and the NAS appears to be in a very strange state. 

Following the instructions to put it into the boot menu gets as far as step #4 but my colleague doesn't see the LEDs blinking as described so they can't get into the boot menu and its options.

He also can't power it down gracefully as per the manual's instruction to hold down the power button until an LED flashes and then press Power again. Pressing the Power button for various periods of time does nothing.

As I'm writing this he's removing the drives and will power it up/down again to see if that clears the dodgy state and lets him get at the boot menu.

Any suggestions welcome.

---

CatDaddy60 wrote:

---

As I'm writing this he's removing the drives and will power it up/down again to see if that clears the dodgy state and lets him get at the boot menu.

 

---

You can't do anything useful without the drives, as the system normally boots from the drives.  This will give you some information on whether the chassis has failed, but that is about it.

While the drives are removed, you could test them in a PC with vendor tools (Seatools for Seagate, Dashboard for Western Digital).

Another path is to just try powering down, putting the drives back, and then attempting to boot into tech support mode.  Once in, you can look at the OS fullness.  The drives can potentially be tested using smartctl.

---

StephenB wrote:

---

CatDaddy60 wrote:

---

As I'm writing this he's removing the drives and will power it up/down again to see if that clears the dodgy state and lets him get at the boot menu.

 

---

You can't do anything useful without the drives, as the system normally boots from the drives.  This will give you some information on whether the chassis has failed, but that is about it.

 

While the drives are removed, you could test them in a PC with vendor tools (Seatools for Seagate, Dashboard for Western Digital).

 

Another path is to just try powering down, putting the drives back, and then attempting to boot into tech support mode.  Once in, you can look at the OS fullness.  The drives can potentially be tested using smartctl.

 

 

Thanks - I'll pass that on.

---

Nope. Powering down, putting the disks back and powering up made no difference. We still can't get into the boot menu.

I've seen mention of a USB Recovery process? Is that the next option? Does that recover the OS or nuke everything inc. existing data?

---

CatDaddy60 wrote:

Nope. Powering down, putting the disks back and powering up made no difference. We still can't get into the boot menu.

 

I've seen mention of a USB Recovery process? Is that the next option? 

---

I'd first test the disks in a Windows PC as suggested above. 

You can also try removing all the disks and doing a fresh install on a single test disk.  If the test disk is unformatted, the system should automatically do the factory install.  If that works, then double-check that the NAS boots with the disk in every slot (powering down, moving the disk, powering it up, ...)

---

StephenB wrote:

---

CatDaddy60 wrote:

Nope. Powering down, putting the disks back and powering up made no difference. We still can't get into the boot menu.

 

I've seen mention of a USB Recovery process? Is that the next option? 

---

I'd first test the disks in a Windows PC as suggested above. 

 

You can also try removing all the disks and doing a fresh install on a single test disk.  If the test disk is unformatted, the system should automatically do the factory install.  If that works, then double-check that the NAS boots with the disk in every slot (powering down, moving the disk, powering it up, ...)

 

 

---

Thanks for that. It's what I would do if I were in the office but it's my Manager who is pushing the buttons and he has less patience than I. I think he may have reached the point of un-racking the thing (for me to investigate next time I'm up there) and just buying a new one! I've forwarded your advice and am awaiting his reply.....

Cheers for now.

Just a quick and possibly dumb question.....

The OS partition you spoke of - is that on some kind of internal flash storage or does the NAS grab a bit of the disks' and create it there?

The reason I ask is that I have another working 2120 (not a 2120 v2) 1U NAS sitting on a table in my own office that I use for testing/temp storage. I was wondering about shutting that unit down gracefully, popping the disks out for safe keeping and seeing if that box will boot from the 4 disks belonging to the problem NAS?

Thoughts? Any dangers in doing that?

PS. My NAS is running OS 6.10.10 quite happily and that is the OS version reported in RAIDar and when trying to attach to the problem NAS in a browser before it goes on the unsuccessful hunt for the admin page.

---

CatDaddy60 wrote:

The OS partition you spoke of - is that on some kind of internal flash storage or does the NAS grab a bit of the disks' and create it there?

 

---

It's a small (4 GB) partition on each of the disks.  The NAS creates a RAID-1 array that mirrors the OS on every disk.  That allows the NAS to boot if the first disk fails.

FWIW, there is also a small swap partition that the NAS creates on every disk.

---

CatDaddy60 wrote:

 

The reason I ask is that I have another working 2120 (not a 2120 v2) 1U NAS sitting on a table in my own office that I use for testing/temp storage. I was wondering about shutting that unit down gracefully, popping the disks out for safe keeping and seeing if that box will boot from the 4 disks belonging to the problem NAS?

 

---

That would work.  You could also swap the disks, and see if the problem moves with the disks or not.

All the config is on the disks, so if you were to move the test system disks to the operational NAS, then it should boot up the same way as the test system (same hostname, etc).  Similarly if you put the operational disks in the test NAS.

Note that if the two NAS are running different firmware, then the newest firmware wins.  For example, if the install in the NAS flash is newer than what is on the disks, then the disks are updated from the flash.  Similarly, if the version of the disks is newer, then the NAS flash is updated from the disks.

---

StephenB wrote:

---

CatDaddy60 wrote:

The OS partition you spoke of - is that on some kind of internal flash storage or does the NAS grab a bit of the disks' and create it there?

 

---

It's a small (4 GB) partition on each of the disks.  The NAS creates a RAID-1 array that mirrors the OS on every disk.  That allows the NAS to boot if the first disk fails.

 

FWIW, there is also a small swap partition that the NAS creates on every disk.

 

---

CatDaddy60 wrote:

 

The reason I ask is that I have another working 2120 (not a 2120 v2) 1U NAS sitting on a table in my own office that I use for testing/temp storage. I was wondering about shutting that unit down gracefully, popping the disks out for safe keeping and seeing if that box will boot from the 4 disks belonging to the problem NAS?

 

---

That would work.  You could also swap the disks, and see if the problem moves with the disks or not.

 

All the config is on the disks, so if you were to move the test system disks to the operational NAS, then it should boot up the same way as the test system (same hostname, etc).  Similarly if you put the operational disks in the test NAS.

 

Note that if the two NAS are running different firmware, then the newest firmware wins.  For example, if the install in the NAS flash is newer than what is on the disks, then the disks are updated from the flash.  Similarly, if the version of the disks is newer, then the NAS flash is updated from the disks.

 

---

The disks were taken from the rogue NAS and put in my working NAS - same issue is shown in RAIDar re management service not running. I guess this suggests one or more disk problems, problems with OS partition?

My colleague also put a single new disk in the rogue NAS and RAIDar is showing the message 'Corrupt root' - I wasn't expecting that one. Any idea what that indicates? Maybe he used a disk that wasn't as clean as he thought it was?

Enough for today - thanks again for all the advice.

---

CatDaddy60 wrote:

---

My colleague also put a single new disk in the rogue NAS and RAIDar is showing the message 'Corrupt root' - I wasn't expecting that one. Any idea what that indicates? Maybe he used a disk that wasn't as clean as he thought it was?

 

---

Sounds like he put in a formatted disk, and not a blank (unformatted) one.

Options are to

1. delete the partitions using the Windows disk manager
2. zero the disk with Seatools
3. do a factory default using the NAS boot menu.

---

CatDaddy60 wrote:
The disks were taken from the rogue NAS and put in my working NAS - same issue is shown in RAIDar re management service not running. I guess this suggests one or more disk problems, problems with OS partition?

 

---

Certainly disk-related, but might not be the OS partition.  The NAS will normally boot from disk 1, and if that is generating a lot of errors you can get some odd symptoms.

You could try powering down, and swapping disk 1 and disk 2 - just to see if that changes the behavior.

Or connect the disks to a PC for testing.

My colleague also put a single new disk in the rogue NAS and RAIDar is showing the message 'Corrupt root' - I wasn't expecting that one. Any idea what that indicates? Maybe he used a disk that wasn't as clean as he thought it was?

 

Sounds like he put in a formatted disk, and not a blank (unformatted) one.

I'm told it was brand new - still in its sealed bag so unlikely to have had anything on it. What might cause it to baulk at such a disk?

My Manager has finally lost patience with it and is ordering a new unit for me to play with. The disks will get put on my desk to be checked out in a caddy next time I'm at HQ. At least we might get some usable spares out of them.

Thanks again for all your advice and patience with this issue. It's very much appreciated.

Have a good weekend.

Cheers.

---

CatDaddy60 wrote:

 

I'm told it was brand new - still in its sealed bag so unlikely to have had anything on it. What might cause it to baulk at such a disk?

---

Did he test it before he inserted it?

---

StephenB wrote:

---

CatDaddy60 wrote:

 

I'm told it was brand new - still in its sealed bag so unlikely to have had anything on it. What might cause it to baulk at such a disk?

---

Did he test it before he inserted it?

---

Don't think so. To be fair to him, I don't think I've ever had a duff disk straight out of the bag in 35+ years. That's not to say it wasn't iffy but I would be very surprised if it was. It'll go on my desk for testing with the other 4 from that NAS.

---

CatDaddy60 wrote:
I don't think I've ever had a duff disk straight out of the bag in 35+ years. 

---

I've had several, so I always test them before using them.  Generally I run the full non-destructive test, followed by a full write zeros test.  That is because I've had some out-of-the-box disks pass one of these tests but fail the other.

I suspect out-of-the-box failures are more likely to be caused by mishandling during shipment than manufacturing problems.

That said, I'm not saying this particular disk has failed, just raising the possibility.  For whatever reason, the NAS is thinking that it isn't blank.

---

CatDaddy60 wrote:

The disks were taken from the rogue NAS and put in my working NAS - same issue is shown in RAIDar re management service not running. I guess this suggests one or more disk problems, problems with OS partition?

  

---

AFAIK, the non-V2  2120 isn't capable of running OS6, so I think you put OS6 drives in an OS4.2.x unit, which isn't going to work.

---

CatDaddy60 wrote:

  

My colleague also put a single new disk in the rogue NAS and RAIDar is showing the message 'Corrupt root' - I wasn't expecting that one. Any idea what that indicates? Maybe he used a disk that wasn't as clean as he thought it was?

  That can happen if the drive is already formatted.