Run level Description
0-1 Reserved for the future use of the operating system.
2 Contains all of the terminal process and daemons that are run in themultiuser environment. This is the default run level.
3-9 Can be defined according to the user’s preferences
a,b,c,h These are not true run levels; they differ from run levels in that the initcommand cannot request the entire system to enter these run levels.
Tuesday, 5 February 2008
THE /etc/inittab FILE
Order of the /etc/inittab entriesThe 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 beginning ofthe 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 arestarted ahead of the NFS daemons. The entries in the /etc/inittab file are ordered
according to dependencies, meaning that if a process (process2) requires thatanother process (process1) be present for it to operate normally, then an entryfor process1 comes before an entry for process2 in the /etc/inittab file.
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 beginning ofthe 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 arestarted ahead of the NFS daemons. The entries in the /etc/inittab file are ordered
according to dependencies, meaning that if a process (process2) requires thatanother process (process1) be present for it to operate normally, then an entryfor process1 comes before an entry for process2 in the /etc/inittab file.
LED 552, 554, and 556 SUPERBLOCK CORRUPTED
1. Repeat steps 1 through 2 for LEDs 551, 555, and 557.
2. If fsck indicates that block 8 is corrupted, the super block for the file system iscorrupted and needs to be repaired. Enter the command:dd count=1 bs=4k skip=31 seek=1 if=/dev/hdn of=/dev/hdnwhere n is the number of the file system.
3. Rebuild your JFS log by using the command:/usr/sbin/logform /dev/hd8
4. If this solves the problem, stop here; otherwise, continue with step 5.
5. Your ODM database is corrupted. Restart your system and follow the proceduregiven in 4.4.2, “Accessing a system that will not boot” on page 105 to access rootvgwith choice 2 on the Volume Group Information screen.
6. Mount the root and usr file systems as follows:mount /dev/hd4 /mntmount /usr
7. Copy the system configuration to a back up directory:mkdir /mnt/etc/objrepos/backupcp /mnt/etc/objrepos/Cu* /mnt/etc/objrepos/backup
8. Copy the configuration from the RAM file system as follows:cp /etc/objrepos/Cu* /mnt/etc/objrepos
9. Unmount all file systems by using the umount all command.
10. Determine the boot disk by using the lslv -m hd5 command.
11. Save the clean ODM to the boot logical volume by using the command:savebase -d/dev/hdisknwhere n is the disk number of the disk containing boot logical volume.
12. Reboot, if the system does not come up, and reinstall BOS.
2. If fsck indicates that block 8 is corrupted, the super block for the file system iscorrupted and needs to be repaired. Enter the command:dd count=1 bs=4k skip=31 seek=1 if=/dev/hdn of=/dev/hdnwhere n is the number of the file system.
3. Rebuild your JFS log by using the command:/usr/sbin/logform /dev/hd8
4. If this solves the problem, stop here; otherwise, continue with step 5.
5. Your ODM database is corrupted. Restart your system and follow the proceduregiven in 4.4.2, “Accessing a system that will not boot” on page 105 to access rootvgwith choice 2 on the Volume Group Information screen.
6. Mount the root and usr file systems as follows:mount /dev/hd4 /mntmount /usr
7. Copy the system configuration to a back up directory:mkdir /mnt/etc/objrepos/backupcp /mnt/etc/objrepos/Cu* /mnt/etc/objrepos/backup
8. Copy the configuration from the RAM file system as follows:cp /etc/objrepos/Cu* /mnt/etc/objrepos
9. Unmount all file systems by using the umount all command.
10. Determine the boot disk by using the lslv -m hd5 command.
11. Save the clean ODM to the boot logical volume by using the command:savebase -d/dev/hdisknwhere n is the disk number of the disk containing boot logical volume.
12. Reboot, if the system does not come up, and reinstall BOS.
LED 551, 555, and 557 - Corrupted file system, corrupted JFS log, and so on
LED 551, 555, and 557 - Corrupted file system, corrupted JFS log, and so on
1. Follow the procedure described in 4.4.2, “Accessing a system that will not boot” onpage 105 to access the rootvg before mounting any file systems (choice 2 on theVolume Group Information screen).
2. Verify and correct the file systems as follows:fsck -y /dev/hd1fsck -y /dev/hd2fsck -y /dev/hd3fsck -y /dev/hd4fsck -y /dev/hd9var
3. Format the JFS log again by using the command:/usr/sbin/logform /dev/hd8
4. Use lslv -m hd5 to obtain the boot disk.
5. Recreate the boot image using the command:bosboot -a -d /dev/hdiskn
Where n is the disk number of the disk containing the boot logical volume.
1. Follow the procedure described in 4.4.2, “Accessing a system that will not boot” onpage 105 to access the rootvg before mounting any file systems (choice 2 on theVolume Group Information screen).
2. Verify and correct the file systems as follows:fsck -y /dev/hd1fsck -y /dev/hd2fsck -y /dev/hd3fsck -y /dev/hd4fsck -y /dev/hd9var
3. Format the JFS log again by using the command:/usr/sbin/logform /dev/hd8
4. Use lslv -m hd5 to obtain the boot disk.
5. Recreate the boot image using the command:bosboot -a -d /dev/hdiskn
Where n is the disk number of the disk containing the boot logical volume.
LED 223-229 - INVALID BOOT LIST SOLUTIONS
1. Set the key mode switch to service (F5 for systems without keylock) and power up the machine.
2. If display continues normally, change the key mode switch to Normal and continuewith step 3. If you do not get the prompt, go to step 4.
3. When you get the login prompt, log in and follow the procedure described in 4.4.1,“The bootlist command” on page 103 to change your bootlist. Continue with step 7.
4. Follow the procedure in 4.4.2, “Accessing a system that will not boot” to access your rootvg and continue with step 5.
5. Determine the boot disk by using the lslv -m hd5 command.
6. Change the bootlist following the procedure given in 4.4.1, “The bootlist command”on page 103.
7. Shut down and restart your system.
2. If display continues normally, change the key mode switch to Normal and continuewith step 3. If you do not get the prompt, go to step 4.
3. When you get the login prompt, log in and follow the procedure described in 4.4.1,“The bootlist command” on page 103 to change your bootlist. Continue with step 7.
4. Follow the procedure in 4.4.2, “Accessing a system that will not boot” to access your rootvg and continue with step 5.
5. Determine the boot disk by using the lslv -m hd5 command.
6. Change the bootlist following the procedure given in 4.4.1, “The bootlist command”on page 103.
7. Shut down and restart your system.
COMMON BOOT LED CODES AND SOLUTIONS
LED 201 - Damaged boot image
1. Access your rootvg by following the procedure described “Accessing asystem that will not boot”
2. Check the / and /tmp file systems. If they are almost full, create more space.
3. Determine the boot disk by using the lslv -m hd5 command.
4. Recreate the boot image using bosboot -a -d /dev/hdiskn, where n is the disknumber of the disk containing the boot logical volume.
5. Check for CHECKSTOP errors in the error log. If such errors are found, it isprobably failing hardware.
6. Shut down and restart the system.
1. Access your rootvg by following the procedure described “Accessing asystem that will not boot”
2. Check the / and /tmp file systems. If they are almost full, create more space.
3. Determine the boot disk by using the lslv -m hd5 command.
4. Recreate the boot image using bosboot -a -d /dev/hdiskn, where n is the disknumber of the disk containing the boot logical volume.
5. Check for CHECKSTOP errors in the error log. If such errors are found, it isprobably failing hardware.
6. Shut down and restart the system.
Monday, 4 February 2008
BOOT PHASE 3
Boot phase 3
After phase 2 is completed, rootvg is activated and the following steps are taken:
/etc/init process is started. It reads the /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 itas a background process. As a result, all stale partitions from rootvg areupdated.
At this stage, the LED code 553 is shown.
At this stage, the cfgmgr command is called; if the system is booted in normalmode,
the cfgmgr command is called with option -p2; if the system is bootedin service mode, the cfgmgr command is called with option -p3. The cfgmgrcommand reads the Config_rules file from ODM and calls all methodscorresponding to either phase=2 or phase=3.
All other devices that are notbase devices are configured at this time.
Next, the console is configured by calling the cfgcon command. After theconfiguration of the console, boot messages are sent to the console if noSTDOUT 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.
_ The 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
After phase 2 is completed, rootvg is activated and the following steps are taken:
/etc/init process is started. It reads the /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 itas a background process. As a result, all stale partitions from rootvg areupdated.
At this stage, the LED code 553 is shown.
At this stage, the cfgmgr command is called; if the system is booted in normalmode,
the cfgmgr command is called with option -p2; if the system is bootedin service mode, the cfgmgr command is called with option -p3. The cfgmgrcommand reads the Config_rules file from ODM and calls all methodscorresponding to either phase=2 or phase=3.
All other devices that are notbase devices are configured at this time.
Next, the console is configured by calling the cfgcon command. After theconfiguration of the console, boot messages are sent to the console if noSTDOUT 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.
_ The 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
Subscribe to:
Posts (Atom)