Boot Up Messages

When your SCO machine boots, there are numerous messages output to the screen. Most of these messages come from drivers announcing their hardware configuration (address, interrupt, etc.). You also get information about memory found, and how much of it has been allocated for I/O buffers. These messages are not just displayed to the screen, however: they are also stored in a file.

The messages will be found in /usr/adm/messages. Unless something or somebody has been cleaning this out now and then, you will find that this file has messages starting back when the machine was booted for the very first time. If you've been running for a few years, and re-booting daily, the file could be of an impressive size by now, and you might want to truncate it ("> /usr/adm/messages" will do it) or edit it down to a more reasonable size ("tail -200 /usr/adm/messages > /tmp/ saveme; cp /tmp/saveme /usr/adm/messages" might be useful).


Hate these ads?

There are a couple of things you may want to consider before doing that, however. The startup messages are useful in that they show what drivers were present over time and what the supposed hardware configurations were. You can sometimes get an idea of what troubles the installer had by looking at the earliest messages in the file, and if you are changing hardware now, this file can tell you how your working hardware was addressed.

But beyond that, /usr/adm/messages also contains messages from your system, and some of them could be important. As a start toward determining that, I like to do :

egrep "CONFIG|NOTICE|WARN" /usr/adm/messages | sort -u

to see what has been. You may get some messages that indicate conditions that have long since been corrected (you'll need to go into the file to see WHEN these occurred), or that are unimportant (tape left out, no floppy in drive), but you may also find things that you were previously unaware of and should know about. In those cases, you might want to copy off the file for more extensive examination.

Booting also includes messages from the rc scripts. Every script that runs in rc2.d generates output to a log of the same name in /etc/rc2.d/messages. The same is true for rc0.d, which writes to /etc/rc0.d/messages on shutdown.

The "prc_sync" command also logs to this directory; examining that can identify and scripts that did not complete (and generated the "/etc/rc2: xxx Alarm Call" messages). By the way, a common reason for that is setting a default route that is not yet up and running.






And, of course, there is /var/adm/syslog, which gets the output from many of the daemons that get started by rc2.d scripts, and finally there are small logs in var.adm for rc0, rc1, rc2 and pmd (the power management daemon).

If you are just after the driver initialization messages, "hwconfig" will show those.


© 1998 Anthony Lawrence. All rights reserved.



cartoon
Need eyes on the ground at your customer's site?
Installation and light training Boston and New England
Reliable and experienced, punctual and professional.


Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Or use any RSS reader

Delivered by FeedBurner


Views for this page
Today This Week This Month This Year  Overall
5401602,512 15,972

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here

pavatar.jpg
More:
       - Kernel/Internals
       - Basics
       - OSR5




Unix/Linux Consultants

Your ad here - $48.00 yearly!

UBB Computer Services Support for Openserver, Unixware and Linux. Windows integration with Unix/Linux servers. Hardware, Backup and Networking issues. Located near Sacramento CA, we provide onsite support throughout Northern CA and Nationwide via remote access. We are a SCO Authorized Partner and a Microlite BackupEdge Certified Reseller.


http://www.breakthru.com.au SCO (Openserver and Unixware), Unix, Solaris and Linux Consulting services including: Secure Networking Solutions; Linux based Firewalls; Backup Solutions; Secure Home to Office Network Setup; Phone, Remote and On-Site Support available - Satisfaction Guaranteed!


larryi@ccamedical.com SCO OS5, Debian Linux, RedHat Linux, MySQL, Apache, AJAX development using dXport/dL4/Unibasic, Windows Connectivity, Sharing Resouces, Automation, Shell Scripting



Twitter
  • Nov 19 17:29
    Cold today.. walked from South Station to Back Bay and later returned. Fingers hurt.. head hurt.. nice walk though :-)
  • Nov 19 17:28
    My voice mail suddenly gave me a pile of deleted messages - causing me confusion and stress as I thought things I fixed were broken again.









Change Congress


Related Posts