No console or remote access

[Don Moody]

I have a d class system which I cannot access.
The telnet window pops up for a second, then goes away. When I go to the console, all I see is a blinking cursor.

I hit "Return" but nothing happens. The is a 70096 on the system configured for (Serial2/Serial1) It is set for Remote Mode* and the display is set the "HP" I have power cycled the monitor with and without pressing the "d" button. I have done a hard and soft rest of the terminal. Nothing works. The cables are connected and the monitor is powered on. Any ideas?

[Robert A. Pierce]

Have you tried booting from tape?

Rob

[Paula J Frazer-Campbell]

Hi

Can you reboot this machine?

Have you tried another monitor?

Is the machine in use?

What was being done on the console to lock it?
Console is your last resort and as such should not be used for general use.

Paula

[Don Moody]

Thanks for the quick response.

This is a system I have just "inherited" with shared root access. The other "root" user is on the other side of the world and they say they have done nothing.


- There have been no backups on this system as
far as I can tell. (Something I will remedy
very quickly)

- I have just received authorization to reboot
the system.

- I have tried another monitor with no success.

- It has processes running as I can see disk
activity.

- If I could access the system any other way,
I would be using telnet or login but
neither of those work.

[Paula J Frazer-Campbell]

Don

Get other root user to login

then

Who -u | grep console

kill console pid

you may have to use kill -9 on the pid.

This should release the system console.


Paula

[Steven E. Protter]

Your easiest path for correction is as follows:

Power off the console, then the sytem.

Power on the console then the system.

Interupt at the 10 second prompt, if it shows up, take the system into single user mode:

bo
Y interact

hpux -ix

Reset the root password.

If the console is dead, connect a laptop to the console cable with a nine pin straight through connector(I assume here you can't just replace the cable or console or you would have).

Start up hyper terminal set it up for the com port on the laptop 9600 baud n 1, connect.
Restart the box,if you did it right, you will see console messages in the hyper-terminal session.

I can not be more precise,I'm 1000 miles from my hardware right now.

SEP
Sundance,WY

[GK_5]

For telnet
Can you ping the machines IP address?
Try using another lan cable.
For console
Use another working console or compare the configuration of the console with other working console.
Try switching console cable with other working console cable.

[Don Moody]

Thanks again for the quick responses.

Paula, no one can access the system, root or otherwise, that's how this sitch became noticed in the first place. They called me asking what happened and I'm in a reaction mode right now.

As I have no other recourse at this point, I will have to try and follow Steven's suggestion.

Thanks again.

[Hunan_1]

Ask the other root user if He can access the system through rlogin, or maybe if you can execute remote commands over the server from other machine it could help you to solve the problem, If not Try with other console, It could have some problems.

good luck

[Don Moody]

GK,

- I can ping the system with no problems.

- I have used another KB, monitor, and serial cable just in case there was a problem with any of them.

[Kent Ostby]

Instead of power cycling the system, you want to make sure that the service/normal switch (on the back of a D-class if present) is in "service".

Then do:

cntl-b

and from the CM> prompt type:

TC

The reason to do this rather then power cycle the machine is that it will generate a crash file that can be read by HP to see why the box was hanging.

If you power cycle the box, you lose all of this data.

[doug mielke]

If you're not on the same IP segment as the server, can you get to one, even through telnet, first. Themn try to telent from that box to the server. This would eliminate routeing problems.

Not having a route back to the source of the telent can cause no access symtoms, ( except for that 1st flicker of telnet screen)

Out of spce can also prevent new sessions. If so, and if permitted, rcp guesses may help.
ie. rcp some_small_file dlass:/var/adm/mail.log

I'm always afraid to reboot once a problem exists until I know the scope of the issue, but it looks like you've tried nearly everything.