http://www.ibm.

com/developerworks/aix/library/au-
speakingunix_unixboot/index.html#main

Introduction
The AIX operating system is the particular IBM flavor of UNIX. IBM first released AIX in 1986 as AIX
version 1.0 and, through several iterations over the past 22 years (AIX version 6.1 was the latest
version at the time of writing), AIX has matured into a solid UNIX system.
While many interchange the terms AIX and RS/6000, they are not the same thing. AIX is the UNIX
operating system; IBM RS/6000® is the reduced instruction set computer (RISC) server hardware
that AIX can run on. IBM initially launched AIX on the IBM 6150 RT workstation; through the years,
AIX has progressed through IBM PS/2 Intel® 386 computers, IBM mainframes, and the POWER
architecture. AIX now runs on IBM System p™ (formerly known as RS/6000) and System i™
(formerly known as IBM iSeries® and AS/400®) computers.

The AIX boot method

There are three ways to boot the AIX operating system: normal, stand-alone, and network boot.
Normal boot
The typical AIX boot method is the normal boot option. The normal boot option boots AIX from local
disks to the server. When complete, the operating system will be in multi-user mode.
Stand-alone boot
The next type of boot on an AIX system is called the stand-alone boot, or maintenance mode
option. The stand-alone boot option is similar to the normal boot option, but instead of being
brought up in multi-user mode, the system is brought up in single-user maintenance mode. You can
stand-alone boot an AIX system in several ways, such as booting the server from removable media
(tape or CD), clicking F5 (or F6, depending on the hardware) after the keyboard has been initialized
during the initial hardware peripheral checks, or a possible issue has been found (corrupt file
system) and the system must be repaired prior to entering normal boot. Some systems may have a
key that you can turn to maintenance mode, as well. Stand-along booting the server allows you to
install software, correct issues, run diagnostics, and configure hardware without the presence of
other users and reducing the risk of locked resources.
Network boot
The last type of boot is the network boot option. Again, similar to the normal boot option, the AIX
system is booted into a multi-user mode. However, with this option, AIX receives its boot
information from another server on the network.

The bootlist and how to manage it

Because you can boot AIX from several different types of media, you must have a way to manage
the different types. This is where the bootlist comes into play. The bootlist maintains a list of all boot
devices available to the system for each boot method.
To view a bootlist for a specific boot method, simply add the switch ­o. In the following example, the
normal boot method is displayed. The order the server will try to boot from is the first local disk
(hdisk0), then by CD (cd0), and finally by tape (rmt0).
# bootlist -m normal -o
hd i sk0
cd0
rmt0

To set the bootlist for a specific boot method, type the switch ­m and the appropriate boot method
followed by the desired boot devices. In the following example, the bootlist for a normal boot is
altered to attempt to boot the server in the order of hdisk0, cd0, or cd1:
 bootlist -m normal hdisk0 cd0 cd1

As you can see from the previous examples, the ­m switch has been used each time to discern which
boot method to modify or display. This option allows modification to normal, service (single-user
maintenance mode), both (normal and service), and prevboot (the previous bootlist).

The AIX boot sequence

Now that you've selected the boot method, it's time to move to the actual sequence of events that
occurs after the server is powered on.
Note: Throughout the rest of this article, you'll boot the server using normal boot mode.
POST
After you've turned on the power and the server is starting, the server's hardware is verified and
checked for possible issues. This step is called power-on self-test (POST). While the server is
running through its process, POST is checking the memory, keyboard, sound card, and network
devices. During this time, if you wanted to enter stand-alone mode (single-user maintenance), you
would click F5 or F6 after the keyboard has been initialized. However, in this article, no keystrokes
are entered, and the server boots into its normal boot mode.
Bootstrap
After the POST process has finished, the bootstrap —or a smaller program used to load a larger
program—is loaded into memory. The bootstrap then loads the Boot Logical Volume (BLV) into
memory. After the BLV is loaded, the kernel takes over the boot process.
Boot Logical Volume and the bosboot command
The BLV is the location that contains AIX's bootable images. Typically, the BLV can be found on the
local disk of the server. The BLV contains the AIX kernel, the rc.boot file, commands required during
the boot process, and a trimmed-down version of the Object Data Manager (ODM).
To create bootable images, you use the bosboot command. Using bosboot, you create a boot file
(that is, a bootable image) from a RAM disk, a file system, and a kernel. The bootable image is
created along with interfaces with the server's boot Read-Only Storage (ROS) and Erasable
Programmable Read-Only Memory (EPROM).
The following example shows how to create a bootable image on the default BLV on the local fixed
disk from which the system boots:
bosboot -a

The AIX kernel

The AIX kernel stored in the BLV creates the / (root), /usr, and /var file systems in RAM. Keep in
mind that these file systems as well as the kernel are stored in RAM initially during the operating
system boot process. Because they are in RAM, they are not accessible to anything outside the BLV.
After the file systems have been loaded into RAM, the kernel executes the init process, which now
takes over the boot process.
The init process
The AIX kernel loads the process init as process identifier (PID) 1. This process is the parent, or
root, process to all other processes running on AIX. After the init process has been loaded and is
running the boot process, init calls rc.boot.
The rc.boot file
The rc.boot file has three important cases of execution during the AIX boot-up process. The first
section of rc.boot initializes the system's hardware to prepare it for the operating system to boot. A
limited amount of devices needed to start the system are configured at this time with the
Configuration Manager command cfgmgr.
During the second section of rc.boot, the file systems /, /usr, and /var as well as the paging space
are mounted. After these file systems have been mounted, init is replaced with init on the disk as
PID 1, and the RAM is cleared.
In the third and final section of rc.boot, the actual init process is executed from disk. When init is
executed, the /etc/inittab file is read, and each item is executed. During this time, the /tmp file
system is now being mounted to disk. Now that the system is in the last leg of the boot process, the
cfgmgr command is run again on the remaining devices that were not configured in the first section
of rc.boot.

The /etc/inittab file

After the init process has been executed, the next step is for init to open /etc/inittab and read
each entry. The purpose of the /etc/inittab file is to deliver to the init process those processes that
are started at boot-up and during normal operations.
The format of the /etc/inittab file is very specific, and each field is colon delimited. The format of the
/etc/inittab is as follows:
<ID>:<Run Leve l> :<Act i on>:<Command>

The descriptions for the fields defined in the /etc/inittab file are:

• ID: A unique string that identifies the object.

• Run Level: Execute <Command> when the system has entered the init level. For
example, if an entry in /etc/inittab is set to have a run level of 2, when the operating
system enters init level 2, the command will be executed.

The init or run levels are different on AIX from other UNIX- or Linux®based systems. The
following run levels are defined in AIX:

o Reserved for future operating system expansion

o 2: Default run level
o 3 through 9: User-definable
o a through c: Unique levels (When init is executed to a run level a, b, or c,
processes are not killed. Processes in these run levels that are not running will be
executed, but processes from the previous run level are not touched.)
o Q, q: A quick way to tell init to rescan the /etc/inittab file
• Action: The action field tells the init process how to treat the process in each respective
entry in the inittab file. The following are values to the action field that AIX uses:
o respawn: If the process doesn't exist, start the process. Do not wait for its
termination, and continue to scan the inittab file. If the process is terminated,
restart it.
o wait: Start the process, and wait for its termination.
o once: Start the process, and do not wait for its termination. If the process is
terminated, do not restart it.
o boot: Process the entry only during system boot.
o bootwait: Process the entry the first time the server goes from single-user to
multi-user mode.
o powerfail: Only execute the command if init receives a power fail signal.
o powerwait: Only execute the command if init receives a power fail signal, and
wait until the process terminates before continuing to scan the inittab file.
o off: If the process is currently running, send the signal SIGTERM, then SIGKILL
in 20 seconds.
o ondemand: This value is the same as respawn but applies only to run levels a, b,
and c.
o initdefault: Only scan the entry when init is initially executed.
 o sysinit: Execute the entry before init accesses the console before login.
• Command: The final entry's field in the /etc/inittab is the command field. This is the
actual command to execute if <action> deems it necessary when <run level> has been
initiated. When the command is ready to be executed, AIX will fork the process as sh ­c 
exec <command>.

The following example shows running a shell script named /usr/bin/rc.atc_bin when run level 2 has
been initiated and respawn every other time run level 2 is called:
CORMANY_B IN :2 : respawn: /us r /b in / rc .a tc _b in

To disable the same script for run level 0, 1, 3, 6, and 9, use:

CORMANY_B IN :245780 : respawn: /us r /b in / rc .a tc _b in

Viewing and modifying the inittab

AIX has commands to make your life easier rather than manually changing the /etc/inittab file. The
commands follow the same naming convention as other AIX commands:

• mkitab: Add records to the inittab file.

The following example adds the /usr/bin/rc.atc_bin script in the inittab with a run level 2.
mki tab
“CORMANY_B IN :2 : respawn: /us r /b in / rc .a tc _b i n”

• chitab: Changes records in the inittab file. The syntax is identical to the actual record in the
inittab file.

The following example changes the previous example's /usr/bin/rc.atc_bin script in the
inittab file to run level 3:
ch i tab
"CORMANY_B IN :3 : respawn: /us r /b in / rc .a tc _b in "

• lsitab: List records in the inittab file. Using lsitab is a safe means of viewing the inittab
records individually or all together.

The following example views all records in the inittab file:

l s i t ab - a
This example views only the record identified as CORMANY_BIN:
l s i t ab CORMANY_B IN

• rmitab: Remove records from the inittab file.

The following example removes the record identified by CORMANY_BIN from the inittab file:
rm i tab CORMANY_B IN

Conclusion
Now that the inittab file has been read and all the proper processes have been executed, the system
is at a login waiting for you! You may now log in to and enjoy your AIX system.
It may not seem like a lot when you press the power button on a server and it magically starts up,
but as you can see, there's a lot to the AIX system when it is starting. Hopefully, by reading this
article you have gained a new appreciation of what AIX has to go through to provide the base of a
solid operating system.