2.3 Power On Sequence
LEDs and Audio Signals
2.3 Power On Sequence
LEDs and Audio Signals
The commands that are used to manage system startup, shutdown, and the related tasks are discussed in the following sections.
There may be instances when the system administrator must trace the boot process and find out whether something did go wrong with the system. AIX provides the system administrator with an excellent tool to monitor these problems with the help of the alog command.
The alog command can maintain and manage logs. It reads standard input, writes to standard output, and copies the output into a fixed-size file. This file is treated as a circular log. If the file is full, new entries are written over the oldest existing entries.
The rc.boot script explicitly redirects boot information through the alog command to a file /var/adm/ras/bootlog. If something goes wrong with the system, the system administrator can boot the system in single-user mode (maintenance mode) and access these logs through the alog command to see at what stage the system is failing. A part of the rc.boot script is shown below to illustrate how the logging mechanism has been incorporated.
# Error Recovery if customized data is zero
[ -f /no_sbase ] && {
echo "rc.boot: executing savebase recovery procedures" \
>>/tmp/boot_log
X=`ODMDIR=/mnt/etc/objrepos odmshow CuDv |\
fgrep population`
count=`echo $X | cut -f2 -d' '`
[ $count -ne 0 ] && {
/usr/sbin/savebase -o /mnt/etc/objrepos
[ $? -ne 0 ] && loopled 0x546
mount /var # so that reboot can log
echo "savebase recovery reboot" \
>>/tmp/boot_log
cat /tmp/boot_log | alog -q -t boot
reboot
}
}
The alog command works with log files that are specified on the command line or with logs that are defined in the alog configuration database.
The most common flags used with the alog command and their
description are given in Table 1.
Table 1: alog Command Flags
These logs can be maintained by using either SMIT or by using the alog command directly. The general use of the alog command is as follows:
In order to list the contents of a log file, use the command:
alog -f LogFile [ -o ]
You can change the default file that is used to log the activities by using the following command:
alog -f LogFile | [ [ -q ] [ -s Size ] ]
The verbosity value specifies the depth of information that is written to a log. In order to display the verbosity value of a log, use the following command:
alog -t LogType -V
You can use the different attributes of a log type by using the following command:
alog -C -t LogType [ -f LogFile ] [ -s Size ] [ -w Verbosity ]
Before you can change the attributes of a log it is recommended to view what the current attributes are. Use the following command to display the current attributes of a log type:
alog -L [ -t LogType ]
In order to view the boot log, you can either use SMIT or use the alog command directly. Follow the sequence in 2.4.1.6 Viewing the Boot Log to view the contents of the boot log.
You can view the boot log by either using the SMIT fastpath smitty alog_show and giving the name of the log you want to view, or you can use the command. In order to view a log using the alog command, determine what predefined logs are available to you.
Use the alog -L command to view the logs defined in the alog database. On the command line enter:
# alog -L boot bosinst nim dumpsymp
In order to view the boot log (the log that holds boot information) enter:
# alog -o -t boot --------- attempting to configure device 'fda0' invoking /usr/lib/methods/cfgfda_isa -2 -l fda0 return code = 0 ****************** stdout *********** fd0 ****************** no stderr *********** ----------------------------------------------------------------------- invoking top level program -- "/etc/methods/starttty" return code = 0 ****************** no stdout *********** ****************** no stderr *********** ----------------------------------------------------------------------- invoking top level program -- "/etc/methods/startsmt" return code = 0 ****************** no stdout *********** ****************** no stderr *********** ----------------------------------------------------------------------- invoking top level program -- "/etc/methods/load_blockset_ext" return code = 0 ****************** no stdout *********** ****************** no stderr *********** ----------------------------------------------------------------------- invoking top level program -- "/usr/lib/methods/defaio" return code = 0 ****************** no stdout *********** ****************** no stderr *********** ----------------------------------------------------------------------- calling savebase return code = 0 ****************** no stdout *********** ****************** no stderr *********** Starting AIX Windows Desktop..... Saving Base Customize Data to boot disk Starting the sync daemon Starting the error daemon System initialization completed. Starting Multi-user Initialization Performing auto-varyon of Volume Groups Activating all paging spaces swapon: Paging device /dev/hd6 activated. /dev/rhd1 (/home): ** Unmounted cleanly - Check suppressed Performing all automatic mounts Multi-user initialization completed
Any errors that are encountered will be logged into this file. However, the alog file has no concurrency control; therefore, if multiple processes try to write to the same file at the same time, the contents of the log file might not be as anticipated. Additionally, it is a cyclic file; so, when its size gets to the maximum, it is overwritten.
During the boot process, the system has to determine what resources are available to it. For example, the system has to determine what kind of bus the system is using, what type of devices are attached to the system, where the rootvg resides, and so on. The configuration of these devices is handled by the BOS command cfgmgr. The cfgmgr command configures devices and optionally installs device software into the system.
The general syntax of the cfgmgr command is as follows:
cfgmgr [ -f | -s | -p Phase ] [ -i Device ] [ -l Name ] [ -v ]
The most commonly used flags and their description are given in
Table 2:
Table 2: cfgmgr Command Flags
The devices to be configured are controlled by the Configuration Rules object class, which is part of the Device Configuration database. Each configuration rule specifies three items:
During system boot, the cfgmgr command configures all the devices that are necessary to use the system. System boot is a two-step process.
Phase 1 begins when the kernel is brought into the system, and the boot file system is initialized. During this phase, the cfgmgr command is invoked specifying this as phase 1 by using the -f flag. The cfgmgr command runs all of the phase 1 configuration rules, which results in the base devices being configured.
In this phase, the cfgmgr command is called with the -s flag.
The cfgmgr command recognizes three phases of configuration rules:
Normally, the cfgmgr command runs all the rules for the phase specified during invocation (for example, phase 1 rules for the -f flag). However, if the -l flag is issued, the cfgmgr command configures only the named device and its children.
If the cfgmgr command is invoked without a phase option (for example, without the -f,-s, or -p flags), then the command runs the phase 2 rules. The only way to run the phase 3 rules is with the -p flag.
If you invoke the cfgmgr command with the -i flag, the command attempts to install device software automatically for each new detected device. The device variable of the -i flag specifies where to find the installation medium. The installation medium can be a hardware device (such as a tape or diskette drive), a directory that contains installation images, or the installation image file itself.
| Note |
|---|
|
To protect the Configuration database, the cfgmgr command is not interruptible. Stopping this command before execution is complete could result in a corrupted database. |
The cfgmgr command configures only those devices at the system startup that are powered on and are self configurable, such as SCSI drives, or ttys that have been defined in the inittab file. If you have some devices that were not powered on when the system started, the system will not make them available until you explicitly tell it to configure them. The syntax of the command is:
cfgmgr -v
It will produce an output similar to the alog -o -t boot command. See Section 3.2 Configuring System Devices.
The last command is generally used to display, in reverse chronological order, all previous logins and logoffs recorded in the /var/adm/wtmp file. The /var/adm/wtmp file collects login and logout records as these events occur and retains them until the records are processed by the acctcon1 and acctcon2 commands as part of the daily reporting procedures. When the time daemon, timed, changes the system time, it logs entries in wtmp under the pseudo-user date. An entry starting with date | is logged before the change, and one starting with date { is logged after the change. This allows for accurate accounting of logins that span a time change. The general syntax of the command is as follows:
last [ -f FileName ] [ -Number ] [ Name ... ] [ Terminal ... ]
The common flags used with last command are
provided in Table 3.
Table 3: last Command Flags
For example, if you want to find out when root logged on and off from the console, enter the command:
# last root console root pts/3 dummy Oct 23 12:27 still logged in. root lft0 Oct 22 11:45 still logged in. root lft0 Oct 22 09:46 - 11:27 (01:40) root pts/0 dummy Oct 21 11:36 - System is halted by system administrator. (00:24) root pts/1 dummy.xyz.abc Aug 08 13:05 - System is halted by system administrator. (02:17) root pts/0 dummy.xyz.abc Aug 08 12:43 - System is halted by system administrator. (02:39) root lft0 Sep 18 15:41 - System halted abnormally. (14203+20:56) root pts/1 dummy.xyz.abc Sep 18 15:00 - System halted abnormally. (00:31) root pts/3 dummy.xyz.abc Sep 18 12:05 - System halted abnormally. (14245+02:51) root pts/3 dummy.xyz.abc Sep 18 12:04 - 12:05 (00:00) root pts/1 dummy.xyz.abc Sep 18 11:50 - 12:04 (00:14) root pts/1 dummy.xyz.abc Sep 16 13:32 - 11:11 (1+21:38) root pts/2 dummy.xyz.abc Sep 16 11:35 - System is halted by system administrator. (00:04) root pts/0 dummy.xyz.abc Sep 04 15:27 - System is halted by system administrator. (00:15) root lft0 Sep 04 15:27 - 15:40 (00:13) wtmp begins Sep 04 15:11
The last command can also be used to determine when the system was last shutdown. The syntax of the command follows:
# last | grep shutdown shutdown pts/0 Oct 22 09:23 shutdown lft0 Oct 21 16:39 shutdown pts/0 Oct 21 13:41 shutdown lft0 Sep 25 14:43 shutdown pts/1 Aug 08 15:22 shutdown lft0 Sep 16 11:40 shutdown ~ Sep 08 14:47
The bootlist command allows you to display and alter the list of boot devices from which the system may be booted. When the system is booted, it will scan the devices in the list and attempt to boot from the first device it finds containing a boot image. This command supports updating of the following:
Support of these boot lists varies from platform to platform. Some platforms do not have bootlists. When searching for a boot device, the system selects the first device in the list and determines if it is bootable. If no boot file system is detected on the first device, the system moves on to the next device in the list. As a result, the ordering of devices in the device list is extremely important.
The general syntax of the command is as follows:
bootlist [ { -m Mode } [ -r ] [ -o ] [ [ -i ] | [ [ -f File ] [ Device [ Attr=Value ... ] ... ] ] ]
The most common flags used with bootlist command are provided in
Table 4.
Table 4: bootlist Command Flags
In order to display a boot list (Version 4.2 or later) use the command:
# bootlist -m normal -o fd0 cd0 hdisk0
If you want to make changes to your normal boot list, use the command:
bootlist -m normal hdisk0 cd0
This will change the normal bootlist to indicate that when the system is booted, it will first attempt to boot from the floppy disk. If it cannot find a boot image in fd0, it will then look for hdisk0 to find the boot code, then it will search the CD-ROM. Otherwise, it will instruct the system to provide an LED error code and wait for user intervention.
The naming conventions that can be used in your boot list are provided in Table 5. Each device that you add to your bootlist must be in the AVAILABLE state. Otherwise, the bootlist command will fail, and you will encounter an error similar to:
0514-210 bootlist: Device xxxxx is not in the AVAILABLE state
If you suspect that your system was shutdown and restarted, you can use the uptime command to find this out. The uptime command shows how long the system has been up. The general syntax of the command is as follows:
# uptime 05:10PM up 6 days, 21:45, 13 users, load average 4.00, 3.00, 0.00
The uptime command prints the current time, the length of time the system has been up, the number of users online, and the load average. The load average is the number of runnable processes over the preceding 5, 10, or 15 minute intervals. The output of the uptime command is, essentially, the heading line provided by the w command.
The mpcfg command enables a user with root authority to manage service information consisting of the service support and diagnostic flags (-S and -f flags), the modem and site configuration (-m flag), and the remote support phone numbers (-p flag).
The mpcfg command works only on multiprocessor systems with Micro Channel I/O. For IBM systems, this includes the IBM 7012 Model G Series, the IBM 7013 Model J Series, and the IBM 7015 Model R Series.
The general syntax of the command and the meaning of the flags are as follows:
In order to display service information, you can use:
mpcfg -d { -f -m -p -S}
For example, in order to find out what the status is of your diagnostic
flags, use the mpcfg command as shown in
Figure 1.
Figure 1: Displaying Diagnostic Flags
In order to change the service information, use the mpcfg command with the following combination of flags:
mpcfg -c { -f | -m | -p -S -w} Index Value...
For example, if you want to Fast IPL the system, you can change the value of the diagnostic flag as follows:
mpcfg -cf 11 1
This command will look up in the index (see Figure 1) and will change the value of the eleventh item (that is Fast IPL) to 1. The next time the system is booted, the system will skip extensive hardware testing and will take less time to boot than normal.
In order to store information about the flags, use the mpcfg command with the following syntax:
mpcfg { -r | -s }
The most commonly used command flags for the mpcfg command are
listed in Table 6.
Table 6: mpcfg Command Flags
A system shutdown is controlled by a shell script that properly prepares a system with multiple users to be turned off or rebooted. An improper shutdown can have undesirable results on the system's integrity.
The general syntax of the shutdown command is as follows:
shutdown [ -d ] [ -F ] [ -h ] [ -i ] [ -k ] [ -m ] [ -p ] [ -r ] [ -t mmddHHMM [ yy ] ] [ -v ] [ +Time [ Message ] ]
The common flags used with the shutdown command are provided in
Table 7.
Table 7: shutdown Command Flags
In order to perform a fast shutdown and restart the system, enter:
shutdown -Fr
You will see the message shutdown completed. at the end of this process before the reboot.
At times, it may be necessary to properly close down all the applications and other user processes without issuing a kill command to end the processes. You can achieve this by adding your desired commands and actions to a file named /etc/rc.shutdown. The /etc/rc.shutdown file is checked each time a shutdown command is issued. If the file exists, it will be run; otherwise, the system will perform a regular shutdown depending on the flags that are used to bring the system down.
| Note |
|---|
|
/etc/rc.shutdown must be set as executable before it can called by the /usr/sbin/shutdown script. |
Beginning with AIX 4.2.0, the /usr/sbin/shutdown script is changed to incorporate this file. A part of the /usr/sbin/shutdown script executing the rc.shutdown file is shown below:
if [ $nohalt = off ]
then
# /etc/rc.shutdown is for adminstrators to create for their
# own local needs. If it is not successful, shutdown will
# abort.
if [ -x /etc/rc.shutdown ]
then
sh /etc/rc.shutdown
if [ $? -ne 0 ] ; then
dspmsg -s 1 shutdown.cat 60 \
"/etc/rc.shutdown failed. Shutdown aborting.\n"
exit 1
fi
fi
2.5 Troubleshooting Boot
Problems