Console Baud keeps changing and I am unable to boot

[Jay LaBonte]

OK! Here the situation! This is an older D220/1 system.

"/dev/vg00/lvol6 /usr" has been commented out in fstab.

The System was rebooted, an I attempted to enter single user mode from ISL by entering hpux -is. So far so good.

Everything starts booting fine then the screen gets scrambled. It looks like the console baud rate has changed. I have spent 3 hours trying every baud rate combination possable, and I can not hit the correct baud.

I need to get the system back up and running.

Unfortunatly I do not have an ignite of the system or a recent backup, so reigniting is out of the question. I would lose to much work!

Is there any way to bring the system up in single user mode, with the NIC set for a specific IP, so I can telnet into the system.

[T G Manikandan]

What console you have connected.
If that is a 700/96 type.

reset the terminal by powering off and then
pressing the "d" key and powering it on.
That should reset it to the defaults

[Mark Grant]

It might not be your baud rate. It could be parity or data/stop bits. Try combinations of the stop bits and parity. Also, make sure the cable is in nice and tight :) Either way though, it sounds a bit odd, particularly if this doesn't happen when you go multi-user.

There could well be something in your startup scripts with a terminal drawing capabilites (like SAM) and your terminal personality isn't set correctly.

[Steven E. Protter]

You may just have a broken console. May want to try another or connect a laptop with hyper-terminal and see what happens there.


Do start making Ignite backups after you get this fixed.

single user mode means no networking, so I don't think telnet is going to help.

If its a bad serial port you can get that repaired and then have your console and do single user mode.

SEP

[Shaikh Imran]

Hi,
You can use a pc serial port and hyperterm to get the console.
You need a serial cross cable which is 9-9 pin normally used in routers.Your networking guy will be able to help you with this.
connect the one end of this cable to the console port and other to the pc's serial port and try some combination such as 7bit/odd parity,8/bit odd parity,etc..,
You will definately get the console.

Regards,

[Jay LaBonte]

Thanks for all the suggestions, but I have already tryed every baud, parity, and stop bit combination. As stated I spent 3 hours doing that.

The console I am using is fine. I have also used Hyperterminal.

Any other ideas would be appreciated.

[Shaikh Imran]

Hi,
You have said that Console baud changes.
This means that your console is not able to save the changes which you make or you are forgetting to save it.If the console is not saving the baud settings then your console is having problem in the memory-Pls try to get it rectified.

In the situation Now you can only just try different TTY,BIT and PARITY settings.
It may also be like Since you have removed the mount point of /usr you are facing this problem as per you statement.

Try to boot from recovery CD and somehow mount the root filesystem and save and reboot.Normally root filesystem will be
/dev/vg00/lvol3 (Most Cases )

Regards,

[Bill Hassell]

There is no way to get the immense amount of software needed for networking to run in single user mode. Since everything works OK in single user mode, then the changes are occurring in the rc startup scripts. The simples way to track this down is to go into single user mode and list the rc scripts by date/time. ll -t /sbin and ll -t /sbin/init.d will do the trick. The most recently modified script or link is the likely culprit. NOTE: don't allow test or experimental files to reside in /sbin/init.d or in /sbin/rc?.d as they may executed during startup. Single user mode bypasses all these.

You can also isolate the problem by booting into a lower init level such as 1 and 2. Use interactive mode and instead of typing: hpux -is for single user mode, type: hpux -i1 and if all works OK, use hp-ux -i2. The differences between these two init states will be found in the /sbin/rc1.d and /sbin/rc2.d directories.

[Floyd Curtis]

Jay,
As a wild guess while booted and getting garbage try blind typing
sttysane

IF this does not work, try booting into lvm maintenance mode:
hpux -lm
If you get the same thing, then try booting from the a recovery cd.

Once up, see if you can look at the inittab file - especially the console line.

Or try to get a clean copy of the /etc/inittab file in place.
If you can get usr mounted, there is a fresh/clean copy in /usr/newconfig/etc/inittab.

Also try renaming (move it out of the way) the file /etc/ioctl.syscon and rebooting. I believe this is where the last known console defs are stored (if someone did a shutdown at a none standard baudrate..) The system will recreate it on startup... hopefully.

good luck,
fwc

[Floyd Curtis]

One more thought...Have you tried booting from a previous kernel to see if it behaves the same way?
[Power] power on the system
[ESC] hit this to interrupt the boot sequence
BOOT ADMIN> boot pri isl boot from the primary boot disk
Interact with the IPL? y Do interact with the IPL/ISL
ISL> hpux /stand/vmunix.prev Boot from the previous kernel - optionally include -is for single user or -lm for lvm maintenance mode.

good luck,
fwc

[Jay LaBonte]

OK! I now have the baud problem resolved. I dont know how, it just works now!

I can get it to boot into single user mode and can get to the # prompt. Then the console locks up, or serial port!

I have reset the terminal, tried hyper terminal, and several other serial terminal products. It looks like the serial port is locking up.

Any suggestions Please?

[Shaikh Imran]

Hi,
I suppose you have remarked /dev/vg00/lvol6 for some reason or maintainance.
Have you finished your work with /dev/vg00/lvol6 then please remount it
and start the server in normal mode.
If you are facing the same problem then try booting in LVM Mode and finish your work.
ISL>hpux -lm

Regards,

[Jay LaBonte]

Yes, it was remarked for a maintenance procedure, and I would love to un-remark it. I have entered LVM mode and the console is sitting at the # prompt now.

Normally I would have no problem getting the system up and running at this point.

However, the serial port hangs at the prompt and I am unable to entry anything.

I am open to suggestions if someone can tell me how to uncomment /dev/vg00/lvol6 without the use of the console, or any other access to the fstab.

[Bill Hassell]

It sounds like the console entry in /etc/gettydefs has been corrupted. Normally, you could just run getty -c and it would report any errors. Or you could rename /etc/gettydefs and replace it with the original version by copying it from /usr/newconfig/etc/gettydefs. However, since console is dead and there is no other way to get to a shell prompt that works, your only choice is to move the vg00 disk(s) to another system and import the / filesystem so you can fix gettydefs.

Another possibility is that you have a hardware problem with the console port. Since you said that it started working without any changes made to the system, this could be an electronic failure. Moving the root disk(s) to another D-class machine could verify this possibility. If you don't have one, eBay is a good source for an extra one, certainly cheaper than all the time you've spent trying to recover this box.

[Jay LaBonte]

OK! Here what I know so far!

I installed two new 4.2 gb drives in the D220 and have decided to ignite the system and then try to recover my other drive after the system is back up.

I have tried several times now to boot from the CD-ROM to install HP_UX 11.11i and each time the boot process get to the question that states it needs to know what type of terminal I have, HP, vt100, or wyse 60.

and each time it stops at the prompt and will not accept input.

Normally I would think its a bad serial port, but the serial port works fine at the boot menu, and in IPL.

Any new suggestion on how to get the serial port to accept input, or why it is not accepting input, and what can I do about it?

[Bill Hassell · Accepted solution]

This is sounding very much like a hardware problem. The console path is actually quite complicated. The boot menu and IPL is handled by a special path via code in the processor ROMs. Once the system begins to bootup, the processor ROMs relinauish control of the port and now executable code in HP-UX will talk to the port. Apparently, the receive portion of this path is broken. This is verified by the request for the terminal type--HP-UX uses ttytype (or tset) to discover the terminal but this requires a query and response. The query goes out but the response (just like the keyboard) is disabled. Time to get a new service processor board or possibly the processor board itself.

[Jay LaBonte]

Well Thank you everyone!

I finally got the console working. It looks like it was a hardware issue.

I opened the unit, and removed all boards, cleaned all the contact points and reassembled the system.

And now it works. For how long..... We will see!

Regards,
Jay LaBonte