AIX BOOT PROCESS
This
document gives you details of booting procedure in pseris aix based
servers , the procedure is provided by examining the rc.boot file
A TYPICAL BOOTING PROCEDURE
Seems to be very old question ,
Booting can be summarize in following points
i) Initializing (activate and make alive) system hardware
ii) Verify that the system hardware is working fine
iii) Initialize
the firmware (A small software stored in the system board contained in a
cmos or any eeprom or any nvram ) , this is referred to IPL (initial
program loader)
iv) IPL selects the boot device already mentioned in the firmware utility , of course set by us
v) Loads the bootstrap from the device
vi) Bootstrap loads the boot image (for example kernel)
vii) And IPL transfers the control over to the kernel
viii) After this the booting process is much specific to the os
UNDERSTANDING AIX BOOTING PROCEDURE
Aix booting procedure can be summaries with following points
i) System starts and it checks and verify the functionality of devices (POST)
ii) Firmware program (stored in Read only storage ) checks for valid boot list (this firmware program is referred as IPL)
Note: The
system maintains a default boot list located in ROS and a user boot
list stored in NVRAM, for a normal boot. Separate default and user boot
lists are also maintained for booting from the Service key position
iv) The
first device in the valid boot list is checked for the first record or
program sector number (PSN). If it is a valid boot record, it is load into memory and is added to the initial program load (IPL) control block in memory. The key boot record data contains the starting
location of the boot image on the boot device, the length of the boot
image, and instructions on where to load the boot image in memory.
vi) based
on the information provided by key boot data , the boot image or blv is
loaded into the memory (decompressed into the memory ) , Boot image
contains Kernel , a Ram file system , compressed odm and basic commands
vii) kernel loads and the control is passed from ipl to kernel , kernel loads the Ram file system into memory (it creates ram
drives into existing ram and mounts the file system in ram this
facilitates the kernel to load initial prerequisites from a file system
before the rootvg is varied on
viii) From the ram file system init process is started which loads rc.boot file phase 1
The
rc.bootfile sets few functions regarding network boot , iscsi boot ,
nim and others before going to the phase 1 , for example it runs the
command bootinfo –c to get all network boot parameters
It sets home environment after setting the functions and then goes to the boot phase
rc.boot phase1
In
phase 1 rc.boot first restores odm information from boot image using
command restbase , then it configures base devices , it also checks if
system booted from iscsi and loads the drivers related to iscsi , error
in boot phase 1 shows led codes 0x510 ,0x511 and 0x554 , in the last it
links the boot device with ipldevice for that it runs bootinfo –b
After completion of phase 1 init starts rc.boot with option 2 or rc.boot phase 2
rc.boot phase2
It firsts call iplvaryon with –v and checks the output and shows led codes based on the output
ipl_varyon -v
rc=$?
case $rc in
0 ) ;; # do nothing
7 | 8 ) loopled 0x554 "BOOTDEV ACC FAIL";;
4 | 9 ) loopled 0x556 "LVM_QUERY ERROR";;
* ) loopled 0x552 "IPLVARYON ERROR";;
esac
Then it checks and mounts root
Then it Copies /dev
special files from RAM filesystem to disk based filesystem, including
/dev/ipldevice. The mounted root filesystem contains a symlink /usr/lib that points to /../usr/lib, and that is how it finds mergedev with the root fs mounted
/usr/lib/boot/mergedev 2>&1 | \
/../usr/bin/tee -a /../tmp/boot_log
It then checks and mounts /usr
The date command is available after /usr is mounted
Then it checks and mounts /var , runs copycore command
And un mounts /var
It checks for paging device using command lsps –t lv and if the lv name is not null it starts paging space
It starts savebase procedure that is merging the compressed odm with the odm in disk
It also checks if tcb is installed and invokes it if it is enabled
It then mounts /var and copies all the log from ramfs to /var
The init process starts rc.boot with option three or rc.boot phase 3
Then the init process executes the processes defined by records in the
/etc/inittab file. One of the instructions in the
/etc/inittab file executes phase 3 of the
rc.boot script
rc.boot phase3
It
starts with checking the existence of /etc/filesystems and if it is
present it starts mounting of /tmp and if it fails to mount it shows an
error
it checks for primary boot logical volume
it checks for space in /tmp
it then sets dump devices
it then sets and configures console and if required loads graphical boot
starts the errdemon
run diagnostics if system supports
complets end of boot
it also checks for any pending power event
After completion of rc.boot file from inittab
Rest of the daemons are run through /etc/inittab for example rc.tcpip
Detailed boot process in AIX
As a system administrator you should have a general understanding of the boot process. This knowledge is useful to solve problems that can prevent a system from booting properly. These problems can be both software or hardware.We also recommend that you be familiar with the hardware configuration of your system.
Booting involves the following steps:
The initial step in booting a system is named Power On Self Test (POST). Its purpose is to verify that basic hardware is in functional state.The memory, keyboard, communication and audio devices are also initialized. You can see an image for each of these devices displayed on the screen. It is during this step that you can press a function key to choose a different boot list. The LED values displayed during this phase are model specific. Both hardware and software problems can prevent the system from booting.
System Read Only Storage (ROS) is specific to each system type. It is necessary for AIX 5L Version 5.3 to boot, but it does not build the data structures required for booting. It will locate and load bootstrap code. System ROS contains generic boot information and is operating system independent. Software ROS (also named bootstrap) forms an IPL control block which is compatible with AIX 5L Version 5.3, takes control and builds AIX 5L
specific boot information. A special file system located in memory and named RAMFS file system is created. Software ROS then locates, loads, and turns control over to AIX 5L Boot Logical Volume (BLV). Software ROS is AIX 5L information created based on machine type and is responsible for completing machine preparation to enable it to start AIX 5L kernel. A complete list of files that are part of the BLV can be obtained from directory /usr/lib/boot.
The most important components are the following:
- The AIX 5L kernel
- Boot commands called during the boot process such as bootinfo, cfgmgr
- A reduced version of the ODM. Many devices need to be configured hd4 (/) made available, so their corresponding methods have to be stored in the BLV. These devices are marked as base in PdDv.
- The rc.boot script
Note: Old systems based on MCI architecture execute an additional step before this, the so called Built In Self Test (BIST). This step is no longer required for systems based on PCI architecture.
The AIX 5L kernel is loaded and takes control. The system will display 0299 on the LED panel. All previous codes are hardware-related. The kernel will complete the boot process by configuring devices and starting the init process. LED codes displayed during this stage will be generic AIX 5L codes. So far, the system has tested the hardware, found a BLV, created the RAMFS, and started the init process from the BLV. The rootvg has not yet been activated. From now on the rc.boot script will be called three times, each timebeing passed a different parameter.
1.Boot phase 1
During this phase, the following steps are taken:
The init process started from RAMFS executes the boot script rc.boot
If init process fails for some reason, code c06 is shown on LED display. At this stage, the restbase command is called to copy a partial image of ODM from the BLV into the RAMFS. If this operation is successful LED display shows 510, otherwise LED code 548 is shown.
After this, the cfgmgr -f command reads the Config_Rules class from the reduced ODM. In this class, devices with the attribute phase=1 are considered base devices. Base devices are all devices that are necessary to access rootvg.
For example, if the rootvg
is located on a hard disk all devices starting from motherboard up to
the disk will have to be initialized.The corresponding methods are
called so that rootvg can be activated in the nextboot phase 2. At the
end of boot phase 1, the bootinfo -b command is called to determine the last boot device. At this stage, the LED shows 511.
2.Boot phase 2
In this phase , the rc.boot script is passed to the parameter 2. During this phase the following steps are taken.
a) The rootvg volume group is varied on with the special version of the varyonvg command ipl_varyon. If this command is successful the system displays 517. otherwise one of the following LED will appear 552,554,556 and the boot process is halted.
b) Root file system hd4 is checked using the fsck -f
command. This will verify only whether the filesystem was unmounted
cleanly before the last shutdown. If this command fails, the system will
display code 555.
c) The root file system ( /dev/hd4 ) is mounted on a temporary mount point /mnt in RAMFS. If this fails 557 will appear in LED.
d) The /usr file system is verified using fsck -f command and then mounted. the copycore command checks if a dump occured. if it did, it is copied from default dump devices, /dev/hd6 to the default copy directory /var/adm/ras. After this /var is unmounted.
e) The primary pagingspace from rootvg, /dev/hd6 will be activated.
f) The mergedev process is called and /dev files from RAMFS are copied to disk.
g) All customized ODM files from the RAMFS are copied to disk.Both ODM versions from hd4 and hd5 are synchronized.
h) Finaly, the root file system from rootvg (disk) is mounted over the root file system from the RAMFS. The mount points for the root filesystems become available. now the /var and /usr file systems from the rootvg are mounted again on their ordinary mount points. There is no console available at this stage; so all boot messages will be copied to alog. The alog command maintains and manages logs.
3.Boot Phase 3
After phase 2 is completed rootvg is activated and the following steps are taken,
a. /etc/init process is started. It reads /etc/inittab file and calls rc.boot with argument 3
b. The /tmp filesystem is mounted.
c. The rootvg is synchronized by calling the synchvg command and launching it as background process. As a result all stale partitions from rootvg are updated.At this stage LED code 553 is shown.
d. At this stage the cfgmgr command is called.if the system is booted in normal mode the cfgmgr command is called with option -p2; in service mode, option -p3. The cfgmgr command reads the Config_rules files from ODM and calls all methods corresponding to either phase 2 or 3. All other devices that are not base devices are configured at this time.
e. Next the console is configured by calling the cfgcon command. After the configuration of the console , boot messages are send to the console if no STDOUT redirection is made. However all missed messages can be found in /var/adm/ras/conslog. LED codes that can be displayed at this time are :
c31 = console not yet configured.
c32 = console is an LFT terminal.
c33 = console is a TTY.
c34 = console is a file on the disk.
f. finally the synchronization of the ODM in the BLV with the ODM from the / (root) filesyatem is done by the savebase command.
g. The syncd daemon and errdaemon are started.
h. LED display is turned off.
i. if the /etc/nologin exists, it will be removed.
j. If there are devices marked as missing in CuDv a message is displayed on the console.
i. the message system initialization completed is send to the console. the execution of the rc.boot has completed. init process will continue processing the next command from /etc/inittab.
II. system initialization
During system startup,
after the root file system has been mounted in the pre-initialization
process, the following sequence of events occurs:
1. The init command is run as the last step of the startup process.
2. The init command attempts to read the /etc/inittab file.
3. If the /etc/inittab file exists, the init command attempts to locate an initdefauult entry in the /etc/inittab file.
a. If the initdefault entry exists, the init command uses the specified runlevel as the initial system run level.
b. If the initdefault entry does not exist, the init command requests that the user enter a run level from the system console (/dev/console).
c. If the user enters an S, s, M, or m run level, the init command enters the maintenance run level. These are the only runlevels that do not require a properly formatted /etc/inittab file.
4. If the /etc/inittab file does not exist, the init command places the system in the maintenance run level by default.
5. The init command rereads the
/etc/inittab file every 60 seconds. If the /etc/inittab file has changed
since the last time the init command read it, the new commands in the
/etc/inittab file are executed.
III. The /etc/inittab file
The /etc/inittab file controls the initialization process.
The /etc/inittab file supplies the script to the init command's
role as a general process dispatcher. The process that constitutes the
majority of the init command's process dispatching activities is the /etc/getty
line process, which initiates individual terminal lines. Other
processes typically dispatched by the init command are daemons and the
shell.
The /etc/inittab file is composed of entries that are position-dependent and have the following format,
/etc/inittab format = Identifier:RunLevel:Action:Command
Each entry is delimited by a newline character. A backslash (\) preceding a new line character indicated the continuation of an entry. There are no limits (other than maximum entry size) on the number of entries in the /etc/inittab file.
The maximum entry size is 1024 characters.
The entry fields are :
Identifier
A one to fourteen character field that uniquely identifies an object.
RunLevel
The run level at which this entry can be processed. The run level has the following attributes:
-Run levels effectively correspond to a configuration of processes in the system.
-Each process started by the init command is assigned one or more run levels in which it can exist.
-Run levels are represented by the numbers 0 through 9.
Eg: if the system is in run level 1, only those entries with a 1 in the run-level field are started.
-When you request the init command
to change run levels, all processes without a matching entry in the
run-level field for the target run level receive a warning signal
(SIGTERM). There is a 20-second grace period before processes are forcibly terminated by the kill signal (SIGKILL).
-The run-level field can define multiple run levels for a process by selecting more than one run level in any combination from 0 through 9. If no run level is specified, the process is assumed to be valid at all run levels.
-There are four other values that appear in the run-level field, even though they are not true run levels: a, b, c and h. Entries that have these characters in the run level field are processed only when the telinit command requests them to be run (regardless of the current run level of the system). They differ from run levels in that the init command can never enter run level a, b, c or h. Also, a request for the execution of any of these processes does not change the current run level. Furthermore, a process started by an a, b, or c command is not killed when the init command changes levels. They are only killed if their line in the /etc/inittab file is marked off in the action field, their line is deleted entirely from /etc/inittab, or the init command goes into single-user mode.
Action
It tells the init command how to treat the process specified in the process field. The following actions are recognized by the init command:
respawn If the process does not exist, start the process. Do not wait for its termination (continue scanning the /etc/inittab file). Restart the process when it dies. If the process exists, do nothing and continue scanning the /etc/inittab file.
wait When the init command enters the run level that matches the entry's run level, start the process and wait for its termination.
All subsequent reads of the /etc/inittab file, while the init command
is in the same run level, will cause the init command to ignore this
entry.
once When the init command enters a run level that matches the entry's run level, start the process, and do not wait for termination. When it dies, do not restart the
process. When the system enters a new run level, and the process is
still running from a previous run level change, the program will not be
restarted.
boot Process the entry only during system boot, which is when the init command reads the /etc/inittab file during system startup. Start the process, do not wait for its termination, and when it dies, do not restart
the process. In order for the instruction to be meaningful, the run
level should be the default or it must match the init command's run
level at boot time. This action is useful for an initialization function
following a hardware reboot of the system.
bootwait Process the entry the first time that the init command goes from single-user to multi-user state after the system is booted. Start the process, wait for its termination, and when it dies, do not restart the process. If the initdefault is 2, run the process right after boot.
powerfail Execute the process associated with this entry only when the init command receives a power fail signal ( SIGPWR).
powerwait Execute the process associated with this entry only when the init command receives a power fail signal (SIGPWR), and wait until it terminates before continuing to process the /etc/inittab file.
off If the process associated with this entry is currently running, send the warning signal (SIGTERM), and wait 20 seconds before terminating the process with the kill signal (SIGKILL). If the process is not running, ignore this entry.
ondemand Functionally identical to respawn, except this action applies to the a, b, or c values, not to run levels.
initdefault An entry with this action is only scanned when the init command is initially invoked. The init command uses this entry, if it exists, to determine which run level
to enter initially. It does this by taking the highest run level
specified in the run-level field and using that as its initial state. If
the run level field is empty, this is interpreted as 0123456789.
therefore, the init command enters run level 9. Additionally, if the
init command does not find an initdefault entry in the /etc/inittab
file, it requests an initial run level from the user at boot time.
sysinit Entries of this type are executed before the init command tries to access the console before login.
It is expected that this entry will only be used to initialize devices
on which the init command might try to ask the run level question. These
entries are executed and waited for before continuing.
Command
A shell command to execute. The
entire command field is prefixed with exec and passed to a forked sh as
sh -c exec command. Any legal sh command syntax can appear in this
field. Comments can be inserted with the # comment syntax.
The getty command writes over the output of any commands that appear before it it in the /etc/inittab file. To record the output of these commands to the boot log, pipe their output to the alog -tboot command. The stdin, stdout, and stderr
file descriptors may not be available while the init command is
processing inittab entries. Any entries writing to stdout or stderr may
not work predictably unless they redirect their output to a file or to
/dev/console.
The following commands are the only supported methods for modifying the records in the /etc/inittab file.
lsitab Lists records in the /etc/inittab file.
mkitab Adds records to the /etc/inittab file.
chitab Changes records in the /etc/inittab file.
rmitab Removes records from the /etc/inittab file.
Eg:
If you want to add a record on the /etc/inittab file to run the find command on the run level 2 and start it again once it has finished:
1. Run the ps command and display only those processes that contain the word find:
# ps -ef | grep find
root 19750 13964 0 10:47:23 pts/0 0:00 grep find
#
2. Add a record named xcmd on the /etc/inittab using the mkitab command:
# mkitab "xcmd:2:respawn:find / -type f > /dev/null 2>&1"
3. Show the new record with the lsitab command:
# lsitab xcmd
xcmd:2:respawn:find / -type f > /dev/null 2>&1
#
4. Display the processes:
# ps -ef | grep find
root 25462 1 6 10:56:58 - 0:00 find / -type f
root 28002 13964 0 10:57:00 pts/0 0:00 grep find
#
5. Cancel the find command process:
# kill 25462
6. Display the processes:
# ps -ef | grep find
root 23538 13964 0 10:58:24 pts/0 0:00 grep find
root 28966 1 4 10:58:21 - 0:00 find / -type f
#
Since the action field is configured
as respawn, a new process (28966 in this example) is started each time
its predecessor finishes. The process will continue re-spawning, unless
you change the action field,
Eg:
1. Change the action field on the record xcmd from respawn to once:
# chitab "xcmd:2:once:find / -type f > /dev/null 2>&1"
2. Display the processes:
# ps -ef | grep find
root 20378 13964 0 11:07:20 pts/0 0:00 grep find
root 28970 1 4 11:05:46 - 0:03 find / -type f
3. Cancel the find command process:
# kill 28970
4. Display the processes:
# ps -ef | grep find
root 28972 13964 0 11:07:33 pts/0 0:00 grep find
#
To delete this record from the /etc/inittab file, you use the rmitab command.
Eg:
# rmitab xcmd
# lsitab xcmd
#
Order of the /etc/inittab entries
The base process entries in the /etc/inittab file is ordered as follows:
1. initdefault
2. sysinit
3. Powerfailure Detection (powerfail)
4. Multiuser check (rc)
5. /etc/firstboot (fbcheck)
6. System Resource Controller (srcmstr)
7. Start TCP/IP daemons (rctcpip)
8. Start NFS daemons (rcnfs)
9. cron
10.pb cleanup (piobe)
11.getty for the console (cons)
The System Resource Controller (SRC)
has to be started near the begining of the etc/inittab file since the
SRC daemon is needed to start other processes. Since NFS requires TCP/IP
daemons to run correctly, TCP/IP daemons are started ahead of the NFS
daemons. The entries in the /etc/inittab file are ordered according to dependencies,
meaning that if a process (process2) requires that another process
(process1) be present for it to operate normally, then an entry for
process1 comes before an entry for process2 in the /etc/inittab file.
* Source Article from : Internet
