Can't get into the web GUI on a 4500

[LarryInCa]

Hi All,

I'm new the this forum, and looking for some help to bring a 4500 back online. I know just enough to be dangerous, and that it's easier to break it than it is to fix it. After doing quite a bit of searching on this forum, and it looks like I came to the right place.

I have a 4500 that won't come back up after a power outage. I've been able to get into the console, so something is up and running.

When the unit first powers on, it looks like it's trying to come up. It will answer a ping, but the GUI is still inaccessible. During that time I'm able to connect to it using Server Manager and get some information.

But after about 5 minutes or so, the unit goes unresponsive to anything other than the console. Lights flash, nic port flashes, but no longer answers a ping.

I've seen quite a few references to "recovery mode," but that doesn't seem to be an option that I'm presented with. These are the three options that come up as boot options, with the first one as the default:

1. Opus
2. Opus-alt
3. tserver

I just let it pick the default, and watched it reboot itself. Hangs after that with just the console active.

I'm new to digging around in the guts of a Snap Server, and would appreciate any pointers. The box was configured as a RAID 5 (pretty sure), and the OS is version 4.0.228.


Thanks

[Phoenix32]

This is directed to LarryInCa and anyone else who wants it, EXCEPT BitO
And no worries, I dont feel the need to double post either, like some idiots do on forums.


If the system light is blinking back and forth between amber and green, then the unit is in Recovery mode. If not, then it isn't...

If it is in Recovery mode, then use your browser to log in directly with the known IP address of the unit to get to the Recovery Console.

Hope it helps...

[blue68f100]

Connect a Null modem cable to the com port and watch the boot process using terminal. This will tell you exactly what is going on and where the problem is at. I think the com is set to 115.2 kbs N, 8, 1.

[LarryInCa]

Thanks for the quick responses Phoenix32 and blue68f100!

I'm not at the machine currently, but from memory the front panel lights looked "normal." Drive lights were green, system light was green, and the hearbeat light pulsed every 5 or 10 seconds.

On the rear of the box, the NIC card was green with occasional traffic being shown. The switch it was connected to also showed green. One of the IT guys looked into the switch, and it reported that the network was up.

I do have a console port connected -- your setting suggestions seem correct (will verify and post back). That's how I was able to get the list of three choices.

But as I said, I know just enough to be dangerous, so any pointers on where / what to look at next to help identify what's the problem would be greatly appreciated.

Thanks again,

Larry

[LarryInCa]

I've looked at the box and the serial connection, and here's what I found.

Com settings:

• Speed: 115200
• Data Bits: 8
• Parity: None
• Stop Bits: 1
• Flow control: Xon/Xoff

LED status lights:

• Green on all four drive lights
• Green on system LED (first light on the left)
• Green flash about every two seconds on second LED (heartbeat?)
• Green on third LED (NIC #1)
• Fourth LED is off

[blue68f100]

Do a cold boot on the server with terminal running to collect the data needed to diag the problem.

[bitor]

Hello LarryInCa,

I do remember reading that this can cause OS file corruption. Somebody posted something about this and how to fix it. I'll look at my notes to see if I can find it.

bitor

Originally Posted by LarryInCa

I have a 4500 that won't come back up after a power outage.

[bitor]

LarryInCa,

I could not find it in my notes , but I remembered it was a recent post. So, I looked for the post and found the link for you. This might help you to understand what happens with an abrupt power outage.

http://forums.procooling.com/vbb/sho...t=file+corrupt

Anyway, I hope it helps you,

bitor

[LarryInCa]

Before I start, I'd like to first thank all of you that jumped in and tried to help me. Spending your own time trying to unwind somebody else's mess is often a thankless chore, and I want you to know that I do appreciate it.

Bitor -- The thread that you pointed out was one that I had seen, and it was probably the main reason why I decided to ask for help in this forum. I could tell that there were some skilled individuals with a depth of knowledge that could help.

And I do believe that http://forums.procooling.com/vbb/showthread.php?t=15481 is most likely the root cause of the problem. Unfortunately, the thread died before it was answered -- sorta like the last few pages missing from a book.

Rather than continue to beat myself over the head, I decided to drop back 10 and punt. I took the easy way out, pulled the front cover, crossed my fingers, and pushed that little white button.

As far as I can tell, the box is almost back to normal. I was able to get into the GUI, change the default IP address, and put it back onto the network. I haven't added it back into the domain, as I'll need IT to do that part for me. So I can't verify if all of the ACL's were restored, but it does look like the quotas were preserved. (any hints on how to verify this?)

The only thing I saw that has me a bit concerned is this line in the Event Log flle:

EXT2-fs warning: maximal mount count reached, running e2fsck is recommended

Not sure what to do about that. Should I do anything, or can I ignore it? If I should do something, what would that be?

Back to the root cause -- I do have a capture. Unfortunately its full of garbage unprintable characters, as I used HYPERTERMINAL to connect to the SNAP. If somebody wants to spend some time to help me sift through it, let me know what sections you'd like to see and I'll post them.

Again, thanks for all of the help, and I'm sure I'll be back. I have a 4100 with a bad drive that probably could use upgrading.

[willPower]

.

[LarryInCa]

Now the question is, if the button was red, would you still have pressed it?

I probably would have pressed it if it was covered by yellow caution tape, with a big label that read "Initiate Self Destruct."


A nice side effect was that the box was forced into some sort of recovery mode, something that I was unable to make happen using the command line. Hopefully the file / directory permissions are still intact, because they don't appear to be at the UNIX level. Everything in the share seems to have owner:group pairing of admin:AllLocal.

Don't know if that's good or bad. It seems to imply that there is something sitting on top of the file system that controls access to the files. Again, another learning opportunity for me (sigh).

[Phoenix32]

Originally Posted by bitor

Hello LarryInCa,
I do remember reading that this can cause OS file corruption. Somebody posted something about this and how to fix it. I'll look at my notes to see if I can find it.

Larry, just so you are aware, that "Somebody" was me, and his "notes" are what he can pick up off this forum. You need to know he has very little knowledge of his own on this stuff (or at least how it always appears). He also conveniently "forgets" where he gets his information when I am involved, which is most of the time. Are you familar with the phrase, "knows just enough to be dangerous", or in his case, to send you off on 50 wrong directions. So be cautious when listening to him. Nuff said.

Now, your problem in this case is most likely a crashed OS. The OS is striped and cloned in various hidden partitions on the drives. Sadly, the methods I know to get it back up and running always end with the data gone.

David (blue68f100) and WillPower are more of the software guys than I am, so they may know how to save the data. Wish I coud help more.

[LarryInCa]

Phoenix32,

Thanks for the advice, both technical and otherwise -- it does help.

I'm pretty sure that I dodged the bullet, as I was able to access all off the data after the reset. The RAID reported that it had rebuilt itself, and I could browse the directory structure ... that is when I could still power the box up .

Although the "reset to factory" appeared to work in this instance, I hesitate to use that as an operational procedure in the future if I find the box in some strange state. I was hoping for some pointers that could help me unravel what state the box thought it was in, so I might be in a better position to deal with it in the future. Perhaps one of the two SW guys you mention might want to help me do some CSI work to figure that one out?

Larry