A system boot is the process by which a machine powers on, tests the hardware, loads and executes the operating system after configuring the devices on the machine. To boot, AIX machines require the following resources:
In AIX 3.2, there are three types of system boots:
Chip Sequencer checks if there are any problems in the system mother board. If there is problem, appropriate LED codes are displayed and the machine will stop. This check is also referred to as built-in self-test (BIST). During testing the LED displays values in the range of 100 to 199.
After BIST the control is passed on to the Read Only Storage (ROS) which performs power-on self-test (POST). During the POST, the LED displays values in the range of 200 and above. Please refer to Common Diagnostics and Service Guide. under section "Three-Digit Display Numbers", for a listing of the BIST indicators and their meanings. The same section also contains the meanings of POST indicators.
If the POST passes successfully, then the ROS starts to search for the boot device. The ROS first checks the bootlist contained in the nvram. The nvram keeps two separate bootlists, one for normal mode and one for service mode. Under normal mode, usually the hard disk is the first boot device. Under service mode, usually the floppy drive is the first boot device.
If there is a valid list in the nvram, the ROS will start booting from the
device pointed to by the bootlist. If the bootlist is not valid or absent, then
the ROS will begin searching for a bootable device from slot8 to slot0 and from
SCSI ID 0 thru SCSI ID 6. The nvram contents can be invalidated by unplugging
the battery or by the bootlist command as in the examples in section
Procedure to View and Change Service Mode
Bootlist. and section Procedure to View
and Change Normal Mode Bootlist. Please note that the bootlist is
referenced as the ipl list in some documentation.
Figure: ROS Kernel Init Phase
Once ROS has identified a boot device, it reads the boot block from the disk. It uses the disk offset and length from the boot block to load the boot image into memory. Control is then passed on to the boot image and the kernel begins executing. Once the kernel is in control, it relocates to address 0 and executes init.
# bootlist -m service -r
------------------- SERVICE IPLIST at address 0xa00278 --------------
57 52 2 47 46 2 47 54 2 47 W R - G F - G T - G
43 19 56 0 0 1 87 31 ac 62 C - V - - - - 1 - b
5f 0 0 0 0 0 0 0 0 53 - - - - - - - - - S
20 49 7 7 1 0 0 2 47 4b - I - - - - - - G K
2 47 49 0 0 0 0 0 0 0 - G I - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 - - - -
# bootlist -m service -i
# bootlist -m service rmt
# bootlist -m service fd rmt cd badisk scdisk
# bootlist -m normal -r
------------------- NORMAL IPLIST at address 0xa00224 ---------------
4a 4d 19 56 0 0 1 87 31 ac J M - V - - - - 1 -
62 5f 0 0 0 0 0 0 0 0 b - - - - - - - - -
53 20 49 7 7 1 0 0 0 0 S - I - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 0 0 0 0 0 0 - - - - - - - - - -
0 0 0 0 - - - -
# bootlist -m normal -i
# bootlist -m normal scdisk
Diagnostic programs provide an easier way to view and alter the normal and service mode bootlist. Three ways to invoke diagnostic programs in AIX V3.2 is given below:
In all the cases, after loading the diagnostic programs follow the procedure given below to view or alter the bootlist.
fd Generic Diskette Drive rmt Generic Magnetic Tape Drive cd Generic CD-ROM Drive hdisk0 400 MB SCSI Disk Drive badisk Generic Bus-Attached Disk scdisk Generic SCSI Disk
The reader is cautioned that the bootlist must not be changed if not necessary. When the system is installed the bootlist is properly set to boot from the correct hard disk. While the system administrator may view and record the bootlist values, changing the bootlist indiscriminately either for normal or service mode could cripple the system.
AIX diskless clients require a boot image and access to the AIX file systems, similar to a standalone machine. The network boot consists of three major parts, which are:
See Figure - ROS Kernel Init Phase for an outline of the kernel boot process. In a network boot, the bootlist will indicate that the boot device is a network device. The client machine ROS code broadcasts a boot request packet through a network boot device (network interface) to a boot server. The boot server uses the bootpd daemon to accept the request packet and find the client's boot code in the bootptab file. The server bootpd daemon sends a reply packet back to the client that contains the location of the client's boot file. The client ROS code then reads and loads the boot file from the server. Control is passed on to the kernel similar to a standalone boot.
In all modes ROS passes control on to the kernel. In IPL phase 1 and phase 2 the ssh program (simple shell) is executed. This simple shell is designed to operate in the RAM file system. It has no shared libraries. A copy of the /sbin/rc.boot script file is copied into the boot logical volume during the bosboot command.
The first command in rc.boot is the restbase command. During restbase, the base customize configuration information is read from the boot image. ODM database gets populated with the base customize information and the configuration manager is invoked in phase 1. This will locate the system bus and determine the type of adapters present on the machine. Any adapters that have ODM database entries in the predefined configuration database will be configured into the system. In the case of a disk boot, all disks in` the system are now configured. The bootinfo command is executed to get the ipldevice location from the IPL control block and a link is made to /dev/ipldevice.
The ipl_varyon routine is executed after varyon of the root volume group. Once the rootvg is varied on, paging is started. The fsck command is run on /dev/hd4 (root file system). Running fsck will cause logredo to execute and replay the jfslog on the volume group. The root file system from the hard disk is then mounted over /mnt and the PATH variable is changed to include the executables on the hard disk as well. Using /etc/filesystems information from the hard disk, /usr file system is mounted. Logical Volume Manager (LVM) information is copied to the hard disk. The directory /dev is recovered from any maintenance work.
Then mergedev is run which insures that the major/minor number of the devices configured to this point matches the devices in the /dev directory on the hard disk. This enables us to continue using the devices after moving the root to the hard disk. The final merge step is to merge the current ODM database entries into the hard disk. Now the temporary mounts are undone and / and /usr are mounted properly. Phase 2 is now complete.
At the end of phase 2 on rc.boot, the simple shell which was working as init will exit. Anytime init dies, the kernel will attempt to respawn init since init is the parent of all processes in an AIX system. In the meantime, however the root file system from the hard disk has been mounted over the / mount point. When the kernel respawns init, it will run init from the root file system. The first time init executes it will perform the newroot functions. The following events will occur:
When init begins executing, it will run /etc/inittab file.
The stanza brc starts execution at the beginning of /etc/inittab. If /etc/inittab is missing on AIX V3.2 then init will run brc directly. This causes /sbin/rc.boot 3 to be executed and the following tasks are performed:
The next step is to run configuration manager (cfgmgr) phase 2. At this time the full configuration database is available and cfgmgr will complete the system configuration. This will configure all attached devices and customize all user specified devices. The command cfgmon is executed to configure the system console. All system configuration is complete at this time and savebase is executed to save the base customize information to the boot image. The message Saving Base Customize Data to boot disk appears on the system console.
The stanza brc will perform the following steps and exit:
For further details of the service boot or the network boot please refer to the information in the /sbin/rc.boot script file.
At the end of brc, stanza rc runs /etc/rc. This performs the following functions:
At the end of the stanza rc, the message Multi-user Initialization completed is displayed on the console.
The srcmstr daemon is the System Resource Controller, which is also called the source master. The srcmstr daemon starts and controls subsystems such as qdaemon, tcpip, nfs, sna and others. The stanza for srcmstr must precede any other stanzas using scrmstr in inittab.
See Chapter 13, "System Resource Controller & Subsystems" in System Management Guide for AIX Version 3.2 for further details on srcmstr.
The subsystems tcpip and nfs are started with startsrc resource controller in the inittab file. The stanzas rctcpip and rcnfs run /etc/rc.tcpip and /etc/rc.nfs scripts to start the corresponding subsystems. A separate stanza to start sna subsystem uses the scripts in the file /etc/rc.sna. Each of these script files can be modified to suit the users requirements.
# lscons
/dev/tty0
# lsattr -E -l tty0 -a login
login enable Enable LOGIN True
# chdev -l tty0 -a login=disable
tty0 changed
# lsattr -E -l tty0 -a login
login disable Enable LOGIN True
These commands allow you to check the console device name, to show the current login attribute value for this device, to change it to the correct value, and to display it again.
The output of this lsattr command shows the ODM attribute name (login), its value (enable or disable in the example), its description, which you can see in the menu you get with the smit chgtty command, and the user-settable string.
If the console tty is set to enable, then /etc/inittab will run two different getty on it. One will be run from the console stanza, another one from the tty stanza. What may occur if the attribute of the tty is enable is some garbage on the screen, or some trouble when you loggin into the system. It may look like a cable wiring problem. Once again, this problem only occurs on the console tty.
The process init will follow inittab until all processes as defined in each stanza are started and then the control is passed to the user. The login prompt is displayed and the users can start using the system.
You can start whatever program, application or script shell you want to be run at boot time in file /etc/inittab.
You can refer to InfoExplorer to see further details about /etc/inittab file format.
In the following sections, the most common modes of failure during the boot process and possible recovery steps are discussed. Most boot failures on a previously working system are symptoms of some other problem. For example let us assume that rootvg is installed across multiple hard disks. When the system is rebooted, if one of the hard disks is not turned on, the varyon of rootvg will result in a 552 LED displayed. While applying PTFs, the command bosboot is run for some PTFs. If bosboot failed to complete and the warning message is ignored, then the system may not reboot. This problem may show up only when a reboot is attempted. Similarly if some changes are made in the /sbin/rc.boot file, that will be reflected only in a later bosboot and reboot.
To recover from a system that hangs at boot time, you can try to add some commands in file /sbin/rc.boot in maintenance mode, after having run getrootfs command. It will help you to determine the exact step in this shell that fails in normal mode. For example, you can use command /usr/lib/methods/showled, which displays the number you specified on the LED codes. An example of a showled argument is 0x777, in order to display 777 on the LED codes. If you insert your test command inside the Phase 2 boot - disk paragraph, you will have to run bosboot -a -d/dev/hdiskn command after your change, in order to take it into account at next boot. Replace the word hdiskn with the name of the bootable hard disk. If you change the paragraph Phase 3 boot - disk, you don't need to run bosboot command.
Given below is a procedure to boot the system in service mode and run getrootfs. This procedure will have to run before attempting most of the recovery procedures, which follow this section. This procedure when completed succesfully will attach / and /usr file systems and enable the commands to be executed from these directories, from the maintenance shell.
The maintenance boot may result in disks having different numbers as compared to those during normal boot, especially if you have external hard disks. During service boot, no base customized data is available and all devices are configured as they are encountered. The correct disk name must be used in the maintenance procedures for the suggested commands to function properly.
You may boot the system in maintenance mode from any one of the following:
# lqueryvg -p hdiskn -At | grep hd5for each hdiskn (hdisk0, hdisk1, and so on) until you get output that looks like:
00005264feb3631c.2 hd5 1
The exact output you get will be different. The logical volume identifier will correspond to that of your system in this output.
You may find more than one disk has this output. These will be the disks in the rootvg volume group. If you get hdisk0 and hdisk1 then use hdisk0. This step is to identify the hard disk on which the boot logical volume is located.
# getrootfs hdisknThe command getrootfs is a shell script in the file /usr/sbin/getrootfs.
The command syntax is as follows:
# getrootfs hdisk<n> <command>
Two examples of invoking the command are given below. The command
getrootfs hdiskn exit will stop getrootfs before mounting any
file system.
The command getrootfs hdiskn sh opens another shell before the
root file system is mounted. You can perform commands like fsck to
check and repair the file systems before mounting them. When you exit
the shell, the command getrootfs continues with the process of
mounting the file systems.
See the chapter on Recovery Procedures in AIX Installation Guide for additional information.
The following sections discuss the recovery procedures to try when your system can't boot in normal boot mode. This explains the usual causes of the usual LED codes, and describes how to repair the system in order to boot it in normal boot mode properly in such circumstances.
The known causes of LED 201 during IPL on a RISC System/6000 are:
The boot logical volume can become corrupted if the / (root) or /tmp file system is full when the command bosboot is run. When you install PTFs, the command bosboot is run by the installation process.
To recover from LED 201, you need to boot into maintenance mode, check the /dev/hd3 and /dev/hd4 file systems for space, erase files if necessary and rebuild the boot image. Then you need to check the error log for check stop errors. Follow the steps given below:
# df /dev/hd4 # df /dev/hd3
# lslv -m hd5The boot disk will be shown in the PV1 column in the output.
# bosboot -a -d /dev/hdiskn
# errpt -a | pg
Look for the words check stop. If you find them, contact the IBM Support Center for assistance.
# shutdown -Fr
An alternating LED 223/229, alternating LED 225/229, alternating LED 233/235, alternating LED 221/229, or solid LED 221 occurs in AIX V3.2 on the RISC System/6000 when the system cannot locate the boot image.
To recover from this problem, rebuild the bootlist with the following steps:
# bootlist -m normal scdisk badisk
# shutdown -Fr
The known causes of LED 551 during IPL on a RISC System/6000 are:
To recover from LED 551, you will need to boot the system in the maintenance mode and run logform on /dev/hd8. Then run fsck to check and correct the file systems. Follow the steps given below:
# logform /dev/hd8Answer yes when asked if you want to destroy the log.
# fsck -y /dev/hd1 # fsck -y /dev/hd2 # fsck -y /dev/hd3 # fsck -y /dev/hd4 # fsck -y /dev/hd9varThe -y option in the above commands gives the permission to the command to repair file systems when necessary. Note that you have to use the command getrootfs hdiskn sh in the getrootfs procedure to run fsck before mounting the file systems. You cannot run fsck on mounted file systems.
# cd /sbin/helpers # copy v3fshelper v3fshelper.afs # copy v3fshelper.orig v3fshelper
# lslv -m hd5
The boot disk will be shown in the PV1 column of the output.
# bosboot -a -d /dev/hdiskn
# copy v3fshelper.afs v3fshelper
# shutdown -Fr
If you followed all of the above steps and the system still stops at an LED 551 during a reboot in Normal mode, please contact the IBM Support Center for further assistance.
The known causes of LED 552 during IPL on a RISC System/6000 are:
To recover from LED 552, you will need to boot the system in the maintenance mode. Then run fsck to check and correct the file systems. Follow the steps given below.
# fsck -y /dev/hd1 # fsck -y /dev/hd2 # fsck -y /dev/hd3 # fsck -y /dev/hd4 # fsck -y /dev/hd9varThe -y option gives the permission to the command to repair file systems when necessary. Note that you have to use the command getrootfs hdiskn sh in the getrootfs procedure to run fsck before mounting the file systems. You cannot run fsck on mounted file systems.
Examine the output of fsck. Check the error condition and take the following actions.
If the fsck was successful on all file systems, go to Step 2 for rebooting the system.
The file system is unrecoverable. The only way to fix an unrecoverable file system is to recreate it. This involves deleting it from the system and restoring it from a backup. Note that hd2 (/usr) and hd4 (/) cannot be recreated. If either of these file systems are unrecoverable, you must reinstall AIX. For assistance with unrecoverable file systems, contact the IBM Support Center. You have completed the procedure.
Block 8 could be read, but you get an error that the file system is not a recognized AIX file system. Attempt to repair the file system with these commands:
# dd count=1 bs=4k skip=31 seek=1 if=/dev/hd# of=/dev/hd# # fsck /dev/hf# 2>&1 | tee /tmp/fsck.errors
In this command, /dev/hd# is the name of your bad logical volume. You may look at the file /tmp/fsck.errors to see what corrections fsck states need to be made.
A file system with an unknown log record type or fsck fails in the logredo process. A corruption of the jfslog logical volume has been detected. Use the following command to reformat it:
# logform /dev/hd8
# exit # sync;sync;sync # shutdown -Fr
Did the system reboot normally ?
# mount /dev/hd4 /mnt # mount /dev/hd2 /usr # mkdir /mnt/etc/objrepos/bak # cp /mnt/etc/objrepos/Cu* /mnt/etc/objrepos/bak # cp /etc/objrepos/Cu* /mnt/etc/objrepos # /etc/umount all # exit
Determine the boot disk with the following command:
# lslv -m hd5The boot disk will be shown in the PV1 column of the output.
Save the clean ODM database to the boot logical volume with the command:
# savebase -d /dev/hdisk0In the above command substitute hdisk0 with your boot disk number if different. If you are running AFS, go to Step 2. Otherwise, go to Step 3.
# cd /sbin/helpers # cp v3fshelper v3fshelper.afs # cp v3fshelper.orig v3fshelper # bosboot -a -d /dev/ipldevice # cp v3fshelper.afs v3fshelper
# shutdown -Fr
If you followed all of the above steps and the system still stops at an LED 552 during a reboot in the Normal mode, please contact the IBM Support Center.
For reasons of time and the integrity of your AIX operating system, the best alternative at this point may be to reinstall AIX.
The known causes for LED 553 during IPL on RISC System/6000 are:
To recover from LED 553, you will need to boot the system in the maintenance mode. Then check /dev/hd3 and /dev/hd4 for space problems. Check /etc/inittab file for corruption. Then check the shell profiles, the /bin/bsh file, and some other files. Follow the steps given below.
# df /dev/hd4 # df /dev/hd3
# TERM=xxx # export TERMIn the above command xxx is a terminal type, such as hft, ibm3151, or vt100. Now use an editor to create the /etc/inittab file. You may refer to Figure - Example of /etc/inittab for this purpose.
# ls -al /.profile /etc/environment /etc/profile -rw-r--r-- 1 root system ... /.profile -rw-rw-r-- 1 root system ... /etc/environment -rw-r--r-- 1 root system ... /etc/profile
One of these files may contain a command that is valid only in the Korn shell. Change the command to something that is also valid in the Bourne shell. For example, change:
# export PATH=/bin:/usr/bin/:/etc:/usr/ucb:.to:
# PATH=/bin:/usr/bin/:/etc:/usr/ucb:. # export PATH
# ln -s /usr/bin /bin
# ls -al /etc/fsck /usr/sbin/fsck /sbin/rc.boot lrwxrwxrwx 1 root system ... /etc/fsck -> /usr/sbin/fsck -r-xr-xr-x 1 root system ... /usr/sbin/fsck -rwxrwxr-- 1 root system ... /sbin/rc.boot
Use the following command to check the integrity of bos.obj:
# lppchk -f bos.obj
# cp /bin/bsh /bin/bsh.orig # cp /bin/ksh /bin/bsh
If you can then reboot successfully, you know that one of the profiles was causing problems for bsh. Check the profiles again by running the following:
# /bin/bsh.orig /.profile # /bin/bsh.orig /etc/profile # /bin/bsh.orig /etc/environment
If you receive errors with any of the above commands, you know there is a command in that profile that bsh cannot handle.
If you followed all of the above steps and the system still stops at LED 553
during a reboot in the Normal mode, please contact the IBM Support Center. For
reasons of time and the integrity of your AIX operating system, the best
alternative at this point may be to reinstall AIX.
In AIX V3 on the RISC System/6000, the system may hang
on LED 727 during a boot in Normal mode if the devices are defined on a
concentrator but are not attached. This problem is seen to occur on the 64-port
async adaptor card only. Normally LED 727 may occur when the system is
rebooted. Sometime during the operation, administrator could have disconnected
a concentrator from the async adaptor. Or the whole async adaptor may have been
removed or changed to another location. In such case, the tty and serial
printer devices become unavailable. This is a known problem. Refer to the IBM
Support Center for more information on APAR ix23405.
To recover from LED 727, list all the ttys and printers with the command
lsdev after booting the system in the maintenance mode. Then, for each
device listed as defined, remove the definition or attach the device.
An example is given in the following screen:
In the above example, you don't need to do anything for tty0
because it is on the native serial port 1, or for tty3, because it is
available. For tty4, you need to either remove the
definition or attach a terminal device to concentrator port
00-07-04-15.
Consider the following example for a serial printer:
You do not have to do anything for lp0, because it is on the
parallel port, or for lp3, because it is available. For
lp1 and lp4, you need to either remove the definitions or
attach printers to concentrator ports 00-07-04-15 and
00-07-02-11.
If you have successfully attached the devices and rebooted properly in the
normal mode, then you have completed the procedure.
If the system still hangs on LED 727, or if you do not have the devices to
attach to the defined ports, then you must remove these device
definitions from the system.
Note: Replace # with the appropriate number in the above
commands.
If you have successfully removed the devices, go to Step
10
You may receive the following error when you try to remove the devices:
Save the file and exit the editor.
The known causes of LED C31 during IPL on a RISC
System/6000 are:
To recover from LED C31 you need to check up the cable connections for the
console. If that is not the problem, then you need to boot the system in the
maintenance mode and change the console definition. Follow the steps given
below.
If your console is an hft (6091), run the command:
If the system still stops at LED C31 during reboot, please repeat Step
2. Note that the syntax of the command to be used is
getrootfs hdiskn sh to allow for a shell to fork before the file
systems are mounted. Then proceed with the step 6.
Determine which disk is the boot disk with the lslv command. The
boot disk will be shown in the PV1 column of the lslv output.
If you still get LED C31, contact the IBM Support Center for assistance.
The known cause for LED C99 during IPL is as follows:
To recover from LED C99, you need to boot the system in the maintenance
mode. Then you have to check the /usr file system and directories /usr/bin.
Follow the steps given below.
Did you find the /usr file system ?
Was this command successful ?
Look at the stderr output of the above command to check if any files are
missing from the /usr/bin directory.
: @(#)49 1.28 com/cfg/etc/inittab, bos, bos320 10/3/91 10:46:51
: COMPONENT_NAME: CFGETC
:
: ORIGINS: 3, 27
:
: (C) COPYRIGHT International Business Machines Corp. 1989, 1990
: All Rights Reserved
: Licensed Materials - Property of IBM
:
: US Government Users Restricted Rights - Use, duplication or
: disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
:
: Note - initdefault and sysinit should be the first and second entry.
:
init:2:initdefault:
brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 # Phase 3 of system boot
powerfail::powerfail:/etc/rc.powerfail >/dev/console 2>&1 # d51225
rc:2:wait:/etc/rc > /dev/console 2>&1 # Multi-User checks
fbcheck:2:wait:/usr/lib/dwm/fbcheck >/dev/console 2>&1 # run /etc/firstboot
srcmstr:2:respawn:/etc/srcmstr # System Resource Controller
rctcpip:2:wait:/etc/rc.tcpip > /dev/console 2>&1 # Start TCP/IP daemons
rcnfs:2:wait:/etc/rc.nfs > /dev/console 2>&1 # Start NFS Daemons
cons:0123456789:respawn:/etc/getty /dev/console
piobe:2:wait:/bin/rm -f /usr/lpd/pio/flags/* # Clean up printer flags files
cron:2:respawn:/etc/cron
qdaemon:2:wait:/bin/startsrc -sqdaemon
writesrv:2:wait:/bin/startsrc -swritesrv
uprintfd:2:respawn:/etc/uprintfd
rcncs:2:wait:sh /etc/rc.ncs
infod:2:once:startsrc -s infod
afs:2:wait:/etc/rc.afs > /dev/console 2>&1 # Start afs
tty0:2:off:/etc/getty /dev/tty0
Figure: Example of /etc/inittab
Recovery from LED 727
Recovery Procedure for LED 727
# ODMDIR=/etc/objrepos
# TERM=xxx
# export ODMDIR
# export TERM
# lsdev -Cc tty
# lsdev -Cc printer
# lsdev -Cc tty
tty0 available 00-00-S1-00 Asynchronous Terminal
tty3 available 00-07-01-13 Asynchronous Terminal
tty4 defined 00-07-04-15 Asynchronous Terminal
# lsdev -Cc printer
lp0 available 00-00-0P-00
lp3 available 00-07-01-13
lp4 defined 00-07-04-15
lp1 defined 00-07-02-11
# rmdev -l lp# -d
or
# rmdev -l tty# -d
0514-039 error unloading kernel extension
Method error: /etc/methods/ucftty
# odmdelete -q "name=${1}" -o CuAt
# odmdelete -q "name=${1}" -o CuDv
# odmdelete -q "value3=${1}" -o CuDvDr
# chmod +x del_dev
# shutdown -Fr
**** NOTE: ****
If all else fails, and you need to get your system running, you can turn the
system off and remove the 64-port adapter card. Then reboot. For assistance
with removing the card contact the IBM Support Center.
Recovery from LED C31
Recovery Procedure for LED C31
# chcons -a login=enable /dev/hft/0
If your console is a tty (ibm3151), run the command:
# chcons -a login=enable /dev/tty/0
# shutdown -Fr
# getrootfs hdiskn sh
# mount /dev/hd4 /mnt
# mount /dev/hd2 /usr
# mkdir /mnt/etc/objrepos/bak
# cp /mnt/etc/objrepos/Cu* /mnt/etc/objrepos/bak
# cp /etc/objrepos/Cu* /mnt/etc/objrepos
# /etc/umount all
# exit
# lslv -m hd5
Save the clean ODM database to the boot logical volume (n is the
number of the fixed disk, determined with the previous command):
# savebase -d /dev/hdiskn
# shutdown -Fr
Recovery from LED C99
Recovery Procedure for LED C99
/usr:
dev = /dev/hd2
vfs = jfs
log = /dev/hd8
mount = automatic
check = false
type = bootfs
vol = /usr
free = false
Figure: Example of /usr Stanza in /etc/filesystems
# df /usr
to make sure that /usr is mounted.
# cd /usr/bin
# ls -l /usr/bin/odmget
# lppchk -f bos.obj