Operating System - HP-UX
1748136 Members
3642 Online
108758 Solutions
New Discussion

Re: Console lines during boot

 

Console lines during boot


I have a strange console issue on one of the HP servers I manage. Specifically, when the server boots and I watch the console messages, this particular server must print 200 periods between the each boot script identifier and the [ ok ] message. It's an A500 with a GSP console and I have both LAN and serial connectivity enabled.

It's aggravating because I'll miss things that happen during boot instead of clearly seeing a [ FAIL ] status. I've dug around online and I can't seem to google the right set of keywords to find a solution.

Thanks in advance for any help you can provide!
7 REPLIES 7
Univer_1
Valued Contributor

Re: Console lines during boot

It seems that you have a wrong setting of the console type. Try to change your console type to VT100 or HP.

And have you try the LAN Console yet?

Regards
SANTOSH S. MHASKAR
Trusted Contributor

Re: Console lines during boot

Set console emulation to 'hp'


-Santosh
Matti_Kurkela
Honored Contributor

Re: Console lines during boot

This is not necessarily a console terminal type issue.

HP-UX boot & shutdown scripts are rather complex: when creating the boot checklist, the scripts will first collect all the boot script identifiers by calling all the relevant boot scripts with the "start_msg" argument. The longest of all these messages will determine the width of the listing.

You should examine all the non-standard scripts in /sbin/init.d or /sbin/rc?.d directories. If there is a script that outputs anything more than a single description line when invoked with the "start_msg" or "stop_msg" option, that script is causing the problem or contributing to it.

You could even invoke each of those scripts with a "start_msg" or "stop_msg" option to see what they will display. Something like this might help:

for script in /sbin/init.d/*
do
echo "Start message of script $script is:"
sh "$script" start_msg
echo "Stop message of script $script is:"
sh "$script" stop_msg
done

I had this problem with the standard (cross-platform) startup script of Patrol monitoring agent. I eventually created a modified version of the script, then used "diff -c" to create a patch file of my changes. Now I use the "patch" command to apply my edits automatically each time I install the Patrol agent.
MK
Marcel Burggraeve
Trusted Contributor

Re: Console lines during boot

If I remember correctly there's a patch available which solves this.
It had something to do with a hex number for 'printing' periods to fill the gap between identifier and the message which should have been a decimal number.
However, I have no clue what the right set of keywords would be on ITRC to find the patch which corrects this behaviour.
Bill Hassell
Honored Contributor

Re: Console lines during boot

Here's the patch description:

1. sh-posix now (PHCO_26789 or newer patch) adheres
to ISOC standards by recognizing the octal and
hexadecimal numbers (i.e., numbers starting with
0 should be recognized as octal and starting with
0x or 0X should be recognized as hexadecimal) in
arithmetic expressions involving let, $((..))
or ((..)).
This exposed a problem in rc.utils script containing
the following lines:
let ROWS="$rows"
let COLS="$cols"
where "rows" and "cols" contain 3 digit decimal values
of number of rows and columns of the HP terminal device.
If the $rows or $cols starts with a leading zero,
sh-posix(1) recognizes these numbers as octal numbers
instead of recognizing them as decimal numbers.

For example, if the value of "rows" is set to "079",
then sh-posix(1) will recognize the value of "rows"
as octal number while processing the let statement
"let ROWS="$rows"".Since "079" isn't a valid octal
number,the following error message is displayed during
bootup:
"/sbin/rc[41]: 079: The specified number is not
valid for this command."
Resolution:
The fix is to change the lines:
let ROWS="$rows"
let COLS="$cols"
to
let ROWS="${rows##*(0)}"
let COLS="${cols##*(0)}"
which removes the leading zeroes.

====================

Here is another possibility:

You probably don't have an HP terminal connected to the console port. The script that sets the terminal startup options is /etc/rc.config.d/list_mode and it is used by /sbin/rc.utils. When the system first boots, the /sbin/rc.utils script is run and the command ttytype is run to figure out what type of terminal you have connected.

Unfortunately, there are dozens of somewhat dubious quality emulators out there, many written by programmers that have never seen a DEC VT100 or HP terminal. Some of these emulators are web programs or firmware on a terminal server. And because they are not compliant with the standard, the ttytype code may not be able to identify the actual terminal.

If you are using a PC as the console (no terminal servers or other concentrators between the console port and the PC) then get a copy of Reflection for HP from WRQ (it comes as an option for new HP 9000 computers, known as the HP Console CD) or oerhaps download QCTerm. Otherwise, use a 'real' HP console. They run $30-$80 on eBay and are dirt cheap when compared to the complex mods you'll have to make to rc.utils to handle some other console. And note that rc.utils may be patched in the future and the problem will return.


Bill Hassell, sysadmin

Re: Console lines during boot

Hi Matti

Greetings from Denmark !!

Old post, but it saved me a lot of time !!.

Just started working for a new customer and everybody was complaining about lack over overview of the boot process seen on lan console.

I was going crazy with TERm settings etc. etc. until I finally (duuh) found the right search combo and found your post.

Sure enough: 1 oracle agent script and HP ISEE scripts returned more than 1 line from start_msg

No problems with stop_msg

 

Thank you so much for sharing your expirience and knowledge to us all !!

 Cheers, Per

Bill Hassell
Honored Contributor

Re: Console lines during boot

This is a common problem, especially when rc start/stop script don't follow the rules. In order to check hundreds of servers, I wrote the attached script: rcmsgck.sh  It flags any script that has no message, a multi-line message, or a long line message.

 

It checks every rc script automatically.

 

# rcmsgck -?

  Usage: rcmsgck [ -v | -q ] [ -l # ] [ -s # ]
  where:    -l # sets the maximum message length to allow
                 (default=74)
            -s # sets the smallest message length to allow
                 (default=5)
            -q = quiet, show errors only
            -v = verbose, adds actual msg

   Flags any start_msg/stop_msg text from start/stop scripts that are more
   than screen-width chars long. Screen width is the current screen or
   optionally, -s ## can be used to specify the width.

   Also flags scripts that do not have any message or have multi-line messages.

  -v option will show msg-length and script-name plus actual message

 Here's the standard output (no options):

 # rcmsgck

Start scripts:

/sbin/rc0.d:
          K-scripts = 7
   len=16 - K400utmpd
   len=18 - K480syncer
   len=28 - K650kl
   len=22 - K800killall
   len=45 - K850kcshutdown
   len=20 - K900localmount
   len=61 - K930vxvm-daemon-kill

/sbin/rc1.d:
          S-scripts = 16
   len=28 - S080crashconf
   len=23 - S090sw_clean_vxvm
   len=44 - S091vxvm-nodes-check
   len=42 - S092vxvm-startup
   len=51 - S093vxvm-reconfig
   len=18 - S100localmount
   len=16 - S320hostname
   len=29 - S350kl
   len=19 - S400set_prvgrp
   len=12 - S420set_date
   len=38 - S430pdcinfo
   len=32 - S440savecrash
   len=09 - S450evp.init
   len=27 - S500swap_start
   len=19 - S520syncer
   len=52 - S600utmpd
          K-scripts = 87
   len=14 - K013hostagent
   len=13 - K014opendial
   len=17 - K015hostwatchdog
   len=25 - K100cifsclient
   len=33 - K100ems
   len=29 - K100intrbald_init
   len=32 - K100samba
   len=41 - K100xf86
   len=23 - K105gwlmagt
   len=32 - K162omni
   len=35 - K165w_registry
   len=31 - K178wlm
   len=35 - K180prm
   len=51 - K182hpsmhd
   len=39 - K190ovpa
   len=26 - K190pctl
   len=23 - K215hub

...etc...

 



Bill Hassell, sysadmin