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 (on old systems) or it is written on the screen on new systems. 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 before hd4 is 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
The AIX 5L kernel is loaded and takes control. The system will display 0299 on the LED panel. All previous codes are hardwarerelated. 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 time being passed a different parameter.
Boot phase 1
During this phase, the following steps are taken: – The init process started from RAMFS executes the boot script rc.boot 1. 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 next boot 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.
Boot phase 2
In boot phase 2, the rc.boot script is passed to the parameter 2. During this phase, the following steps are taken. – The rootvg volume group is varied on with the special version of the varyonvg command named the ipl_varyon command. If this command is successful the system displays 517, otherwise one of the following LED codes will appear: 552, 554, 556 and the boot process is halted. – Root file system hd4 is checked using the fsck -f command. This will verify only whether the file system was unmounted cleanly before the last shutdown. If this command fails, the system will display code 555. The root file system (/dev/hd4) is mounted on a temporary mount point (/mnt) in RAMFS. If this fails, 557 will appear in the LED display. – The /usr file system is verified using the fsck -f command and then mounted. If this operation fails, the LED 518 appears. – he /var file system is verified using the fsck -f command and then mounted. The copycore command checks if a dump occurred. 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.
– The primary paging space from rootvg, /dev/hd6, will be activated. – The mergedev process is called and all /dev files from the RAM file system are copied onto disk. – All customized ODM files from the RAM file system are copied to disk. Both ODM versions from hd4 and hd5 are now synchronized. – Finally, the root file system from rootvg (disk) is mounted over the root file system from the RAMFS. The mount points for the rootvg file systems 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.
Boot phase 3
After phase 2 is completed rootvg is activated and the following steps are taken: – /etc/init process is started. It reads /etc/inittab file and calls rc.boot with argument 3 – The /tmp file system is mounted. – The rootvg is synchronized by calling the syncvg command and launching it as background process. As a result all stale partitions from rootvg are updated. At this stage, the LED code 553 is shown. – At this stage, the cfgmgr command is called: if the system is booted in normal mode the cfgmgr command is called with option -p2; if the system is booted in service mode the cfgmgr command is called with option -p3. The cfgmgr command reads the Config_rules file from ODM and calls all methods corresponding to either phase=2 or phase=3. All other devices that are not base devices are configured at this time. – Next, the console is configured by calling the cfgcon command. After the configuration of the console, boot messages are sent 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. Provides instructions to select console. c32: Console is an LFT terminal c33: Console is a TTY c34: Console is a file on the disk
– Finally, the synchronization of the ODM in the BLV with the ODM from the /(root) file system is done by the savebase command.
– – – –
The syncd daemon and errdemon are started. LED display is turned off. If the file /etc/nologin exists, it will be removed. If there are devices marked as missing in CuDv a message is displayed on the console – The message System initialization completed is sent to the console. The execution of rc.boot is has completed. Process init will continue processing the next command from /etc/inittab.
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 initdefault entry in the /etc/inittab file. a. If the initdefault entry exists, the init command uses the specified run level 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 run levels 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.
The /etc/inittab file is composed of entries that are position-dependent and have the following format: Identifier:RunLevel:Action:Command Each entry is delimited by a newline character. A backslash (\) preceding a newline character indicates 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. 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. For example, 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 ommand 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 ode.
Alog -> to see the logs. Smitty alog Doc.next -> page no 124 , run level page 140