Pccontacts.blogspot.com

AIX Booting Concepts

Glossary

Term
Definition
Advanced Interactive Executive (AIX)
RS/6000 Unix Operating System
Authorized Program Analysis Report (APAR)
Used to identify a fix for a PMR.
Base Operating System (BOS)

Fileset

Fragments
Allows disk space to be divided into units that are smaller than the size of a logical block
High Availability Cluster Multiprocessor  ?? (HACMP)
AIX Clustering
I-Node
128 bit structure that contains information about the file or directory such  as ownership, permissions, file type, number of links to the file, etc.
Logical Block
Disk block that contains file or directory data
Maintenance Level (ML)
Service updates necessary to upgrade the BOS to the current release level
ODN

Page
4KB unit of virtual memory than can be transferred between physical ram and disk paging space
Paging Space
Special logical volume used for holding inactive data that has been temporarily transferred out of physical ram.
Phsysical Volume ID (PVID)
Unique id that consists of a hash of the CPUID and the date.
Problem Management Record (PMR)
Tracking record used for customer problems.
Program Temporary Fix (PTF)
Temporary fix that will be incorporated into the next release of the product.  May be a single fix or multiple fixes associated with a single fileset.
Service Boot
Server is started with the key in the service position (as opposed to the key being in the normal position).
Superblock
Disk block that contains information about the entire file system.  It starts at byte offset 4096 and is 4096 bytes in size.
Swap Space
See Paging Space above.
System Management Interface Tool (SMIT)
Menu driven system administration interface for AIX
Vpath
Similar to HP LUN?


Boot Process

Phases of the Boot Process:
Read Only Storage Kernel Init Phase
Motherboard is Checked
Bootlist is found
Boot image is read into memory
Initialization starts
Base Device Configuration Phase
All devices are configured with cfgmgr command
System Boot Phase
Logical volumes are varied on
Paging is started
/etc/inittab is processed
Commands

alog - allows the administrator to view logs
alog -L  <-- displays log files that alog can view
alog -o -t boot   <-- displays the boot log file
cfgmgr
last
bootlist
uptime
mpcfg
shutdown

How to boot the system if the Service Processor Firmware Menu is displayed:

Service Processor Firmware
         Main Menu

1.  Service Processor Setup Menu
2.  System Power Control Menu
3.  System Information Menu
4.  Language Selection
5.  Call In/Call Out
6.  Set System Name
99.  Exit Menu

Choose Option 2:  System Power Control menu, then select option to Power On

How to boot to the SMS Menu (to apply firmware updates)
Boot normally
Interrupt the boot when the systems displays memory and cpu information
<1> on Ascii terminals
<F1> on Graphics terminals
If you want to update firmware then you need to choose option 3, then put software in diskette drive and choose:
Option 6 for Update System Software
Option 7 for Update Service Processor
Startup Scripts
/etc/inittab
Indentifier:RunLevel:Action:Command
Inittab Commands
lsitab  --> lists records in /etc/inittab
mkitab  --> makes a new entry in /etc/inittab
chitab  --> changes an existing entry in /etc/inittab
rmitab  -->  removes an entry from /etc/inittab
Disks


lsdev -C -c disk  - shows available disks on the server

lsfs    <-- show the filesystems on the server and their characteristics

lspv  - shows disks and their LVM information or "none" if not part of LVM

dumpfs <disk> - shows superblock, i-node map and disk map information for the file system specified.

df -v - shows the number of i-nodes used and free.

istat - shows the last updated, last modified and last accessed times of a file.

ls -i - shows the i-node number assigned to a file

bosboot -a  --> creates a new bootimage

bootlist -m normal -o hdisk0 hdisk1  --> puts hdisk0 and hdisk1 on the bootlist

bootlist -m normal -o  --> displays the current bootlist

How to mount a cdrom
Make sure the cdrom is inserted
Make sure the cdrom drive is properly identified
lsdev -Cc cdrom
Mount the cdrom
mount -v cdrfs -r /dev/cd0 /cdrom

Dump Space

The system dump facility copies critical information to the dump device when a system crash occurs.  This information is critical for determing the cause of the crash.

sysdumpdev -l  <-- shows where the system dump location currently is located.

sysdumpdev -P -p /dev/hd9   <-- changes the primary dump device to hd9

sysdumpdev -e   <-- estimates the size of the current dump

smitty dump   <-- access dump configuration through smit

Procedure for manually peforming a system dump
Using Commands
sysdumpstart
smit dump
Using special key sequence
Key in SERVICE mode
<CTRL><ALT><NUMPAD1> or K<CTRL><ALT><NUMPAD2>
Using the reset button
Key in SERVICE mode
Press the reset button once
Procedure to verify a system dump
Find out the name of the dump file
sysdumpdev -L
Run the crash command
crash <Dump copy filename>  or crash <Dump Device Name>
crash will provide a ">" prompt, stat and quit are commands of crash
>stat
If the dump is successful, then you will see statistics of the dump
>quit
Procedure to generate a system dump using snap
snap -gfkDNcd <directory to store snap file>
-g  <--  gets output of the lslpp -hBc command
-f   <--  gets system information
-k  <--  gets kernel information
-D  <--  gets dump and /unix information
-N  <--  does  not check for free space
-c  <--  creates a compressed pax image of all the files in the directory
-d  <--  allows the destination directory to specified, rather than the default of  /tmp/ibmsupt

Filesystems

Additional information in the file aix-lvm.html.

 mount -t <type>  --> mounts all filesystems in /etc/filesystems containing the t=type attribute

Copying files
cp
tar - limited to files smaller than 2 GB
cpio - limited to files smaller than 2 GB
pax

Argument list too long error
lsattr -E -l sys0 -a ncargs - List value of ARG/ENV
chdev -l sys0 -a ncargs=NewValue (range 6-128) - Modifies value of ARG/ENV.

Kernel

Changing from 32 bit kernel to 64 bit kernel
Change the link in the root directory
Existing link:  lrwxrwxrwx   1 root     system           21 Jun 12 09:59 unix -> /usr/lib/boot/unix_mp
Link to:  /usr/lib/boot/unix_64
Change the link in the /usr/lib/boot directory
Existing link:  lrwxrwxrwx   1 root     system           21 Jun 12 10:01 unix -> /usr/lib/boot/unix_mp
Link to:  /usr/lib/boot/unix_64


Networking

entstat -d en0   <-- this will display configuration and statistics for the network card "en0" - useful for displaying speed/duplex configuration

Paging and Swap Space

Utilities to monitor paging space:
vmstat
topas
lsps -a  <- Lists paging space by disk
chps -s 16 hd6   <- Changes the paging space by adding 16 logical partitions to the hd6 logical volume (default swap space device)
chps -d 16 hd6  <- Changes the paging space by deleting 16 logical partitions from the hd6 logical volume
mkps  <--  Makes additional paging space
rmps  <--  Deletes paging space  (paging space must be deactivated by chps and then system must be rebooted to remove the paging space)
swapon  <-- Turns on a paging space
swapoff  <-- Turns off a paging space

Total Paging Space = 512MB + (Physical Memory Size - 256MB) * 1.25


Processes and Services

/etc/inetd.conf - inetd configuration file
/etc/services - information about services, such as port number

Starting and stopping a process:
refresh -p <pid>
refresh -s <subsystem name>

Changing the inetd configuration
Files
/etc/inetd.conf
/etc/services
Using smit - daemon is recycled automatically upon exit
Using vi
restart the inetd daemon so that the new configuration is read:
refresh -s inetd
Using chservices to edit /etc/services
chservices -c  --> changes entries
chservices -a  --> adds entries
chservices -d  --> deactivates entries
Software Installation and Patches

lslpp -l "<fileset>"   <--  Shows information about filesets

rebuild .toc file - "inutoc"  <-- This rebuilds the toc where the bff's are located.  Needed if something is added to an existing fileset or new file will not be found.

root.oncwhst5:/# instfix -ciqk 5100-04_AIX_ML | grep ":-:"

root.oncwhst5:/# lslpp -l bos.iconv.ucs.com


Displaying the maintenance level and fixes that are installed
oslevel
oslevel -q
oslevel -r   <-- Shows the maintenance release that you are running
instfix -i | grep ML  <-- Shows what filesets are found for maintenance releases on your system and whether they are complete
instfix -ik <FIX_IX>   <-- Shows whether a particular fix has been installed on your system
lppchk -v   <-- Shows filesets that are incompletely installed or need to be corrected
lscfg -vp | grep alterable   <-- shows firmware level

Procedure to upgrade the maintenance level of the os


System Information

prtconf|more  <-- prints system information (aix 5.x)
amount of ram - bootinfo -r or lsattr -El sys0 -a realmem
number of  processors - lscfg | grep proc or bindprocessor -q

oslevel  --> returns the major level of the OS (such as 5.0)
oslevel -r  -->  returns the detailed level of the OS, with sub level and patch level info (such as 5.1)
uname -a
uname -uM  --> type of machine and serial number
System Monitoring

topas = top on hp-ux

Tapeutil

To run the menu version type "tapeutil"
Open the correct device
/dev/rmt0 = tape drive
/dev/smc0 = tape library
"lsdev -Cc tape" will list the devices
Use the commands listed
14 =Element Inventory
17 = Load/Unload Medium

To manually use tapeutil
"tapeutil -f /dev/smc0 move 5 82"  --> will move tape from slot 5 to the tape drive
To manually remove a tape from the drive using tapeutil:
tapeutil -f /dev/rmt0 unload  -->
tapeutil -f /dev/smc0 move 82 5


Terminal Configuration

Autocompletion:  <esc>\

Troubleshooting

See aix-troubleshooting.html

Users

Commands:
mkuser  -->  utility the creates a new user
passwd  -->  change the user's password
chuser  -->  change the user's attributes
chuser minother=# <user>  --> changes minother atttribute for a user
luser <user>    -->  lists the attributes for a specific user account
lsuser -f <user>  --> lists each attribute on it's own line
rmuser  -->  utility that removes a user
chsec  -->  change the user's security attributes
login
who  -->  lists who is currently logged into the system
whoami (who am i)  --> displays information about yourself
dtconfig

Files:
/etc/security/environ  --> lists environment attributes for each user
/etc/security/lastlog  --> lists last login attributes for each user
/etc/security/limits   -->  lists process resource limits for each user
/etc/security/user  --> lists extended user attributes for  each user
/usr/lib/security/mkuser.default  --> lists default attributes for new users
/usr/lib/security/mkuser.sys  --> script that sets up the user's environment
/etc/passwd  --> lists basic user attributes for each user
/etc/security/passwd  -->  contains password information for each user
/etc/security/login.cfg  -->  lists login security information for each user
/etc/utmp  --> contains users that are logged into the system, used by the "who" command
/var/adm/wtmp  -->  contains connect time information for users
/etc/security/failedlogin  --> contains unsuccessful login attempts
/etc/motd  -->  message of the day that is displayed when the user logs in.
/etc/environment  --> lists the default environment that new processes will use.
/etc/profile  -->  environment settings for all  users
$HOME/.profile  -->  environment settings for a specific user
/etc/group  -->  lists attributes for each group
/etc/security/group  -->  lists extended attributes for each group

Important /etc/security/user attributes to know about:

account_locked   -->  true or false
expires -->  Expiration time for a user account.  MMDDHHMMYY,  a value of 0 indicates no expiration
loginretires  -->  Number of invalid login attempts before a users is not allowed to login.  A value of 0 indicates this attribute is disabled.
maxage  --> Maximum number of weeks a password is valid, a value of 0 indicates unlimited
minage  -->  Minimum nuimber of weeks between password changes.

Procedure to add a new user
mkuser <user_id> or
smitty mkuser

Procedure to change the password on a server

passwd <User>

Note:  The account needs to be reset if when trying to log in the following message is received:

3004-303 There have been too many unsuccessful login attempts; please see
        the system administrator.

Procedure to reset the account:

1.  chsec -f /etc/security/lastlog -a "unsuccessful_login_count=0" -s N500620

2.  chuser "account_locked=false" N500620
Procedure to change the shell prompt:
Prompts
PS1 - normal system prompt
PS2 - prompt when system expects more input
PS3 - super-user prompt
export PS1="newprompt>"

AIX booting Process

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 hdisk0 cd0 rmt0

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 Level>:<Action>:<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:
Reserved for future operating system expansion
2: Default run level
3 through 9: User-definable
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.)
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:
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.
wait: Start the process, and wait for its termination.
once: Start the process, and do not wait for its termination. If the process is terminated, do not restart it.
boot: Process the entry only during system boot.
bootwait: Process the entry the first time the server goes from single-user to multi-user mode.
powerfail: Only execute the command if init receives a power fail signal.
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.
off: If the process is currently running, send the signal SIGTERM, then SIGKILL in 20 seconds.
ondemand: This value is the same as respawn but applies only to run levels a, b, and c.
initdefault: Only scan the entry when init is initially executed.
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_BIN:2:respawn:/usr/bin/rc.atc_bin


To disable the same script for run level 0, 1, 3, 6, and 9, use:
CORMANY_BIN:245780:respawn:/usr/bin/rc.atc_bin


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.
mkitab “CORMANY_BIN:2:respawn:/usr/bin/rc.atc_bin”


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:
chitab "CORMANY_BIN:3:respawn:/usr/bin/rc.atc_bin"


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:
lsitab -a


This example views only the record identified as CORMANY_BIN:
lsitab CORMANY_BIN


rmitab: Remove records from the inittab file.
The following example removes the record identified by CORMANY_BIN from the inittab file:
rmitab CORMANY_BIN

Hot Migrate Root Volumes in AIX?

AIX is one of the few OSes that, out of the 'box', can replace boot disks while the OS is running without an outage.  Of course, the standard disclaimers apply... namely, test this on a non-production LPAR and make sure you have backups.  This is extremely helpful for storage array migrations (bringing an LPAR under a SVC, for example) and general maintenance.

If you’re running under VIO Servers, it even allows complete cleanup to occur online.  I recommend a reboot at the end to be safe, but it really isn't necessary.

Assumptions:  All the target disks are currently configured on the LPAR and are not in any volume groups.

Step 0: MAKE SURE TO HAVE A CURRENT MKSYSB AND BACKUP.

Step 1: Replace an old root hdisk with the new one. If this fails due to the destination disk being smaller, go to the alternate instructions below

$ replacepv OLDDISK1 NEWDISK1

0516-1011 replacepv: Logical volume hd5 is labeled as a boot logical volume.

0516-1232 replacepv:

NOTE: If this program is terminated before the completion due to

a system crash or ctrl-C, and you want to continue afterwards

execute the following command

replacepv -R /tmp/replacepv385038

0516-1011 replacepv: Logical volume hd5 is labeled as a boot logical

volume.

Step 2: Verify that the old disk is not defined to any volumegroups:

$ lspv

OLDDISK1 00007690a14xxxxx None

NEWDISK1 00007690a14xxxxx rootvg  active

OLDDISK2 00007690913xxxxx rootvg  active

Step 3: Add the boot image to the new disk:

$ bosboot -ad NEWDISK1

bosboot: Boot image is 30441 512 byte blocks.

Step 4: Repeat steps 1-3 for the second root disk (if replacing both

root disks)

Step 5: Adjust the bootlist

$ bootlist -om normal  NEWDISK1 NEWDISK2

$ bootlist -om service NEWDISK1 NEWDISK2

Step 6: Remove the old hdisks.

$ rmdev -dl OLDHDISK

Step 7: Remove the old disk mappings from the VIO Server if applicable.

$ rmdev -dev OLDMAPPING

Step 9: Run savebase

$ savebase

Alternate Instructions

Step A1: Place the replacement hdisks into the volumegroup:

extendvg rootvg NEWDISK

Step A2: Migrate the disks (you must have PPs sufficient to migrate the

disk):

migratepv OLDDISK NEWDISK

Step A3: Validate that there is no data on the old disk

lspv -l OLDDISK

Step A4: Remove the OLDDISK from the Volumegroup

reducevg rootvg OLDDISK

Step A5: Add the boot image to the new disk:

$ bosboot -ad NEWDISK1

Step A6: Repeat steps A1-A5 for the second root disk.

Linux Web B_Logs

http://www.thelinuxblog.com/tags/kernel/

Aix BLogs

http://justaix.blogspot.com/

http://blog.boreas.ro/search/label/Oracle

http://www.techmute.com/2010/01/hot-migrate-root-volumes-in-aix.html

what bosboot -a

bosboot Command

Purpose

Creates boot image.

Syntax

For General Use:

bosboot -Action [ -d Device ] [ -Options ... ]

To Create a Device Boot Image:

bosboot {-a -v} [ -d Device ] [ -p Proto ] [ -k Kernel ] [ -I | -D ] [ -l LVdev ] [ -L] [ -M { Norm | Serv | Both } ] [ -T Type ] [ -b FileName ] [ -q ]

Description

The bosboot command creates the boot image that interfaces with the machine boot ROS (Read-Only Storage) EPROM (Erasable Programmable Read-Only Memory).

The bosboot command creates a boot file (boot image) from a RAM (Random Access Memory) disk file system and a kernel. This boot image is transferred to a particular media that the ROS boot code recognizes. When the machine is powered on or rebooted, the ROS boot code loads the boot image from the media into memory. ROS then transfers control to the loaded images kernel.

The associated RAM disk file system contains device configuration routines that make the machine's devices and file systems available. The RAM disk file system contains differing configuration files depending upon the boot device. A mkfs prototype file is supplied for each type of device. (See note 6 below.) Currently supported devices are:

• CD-ROM
• Disk
• Tape
• Network

A network device may be a token ring, Ethernet, or Fiber-Distributed Data Interface (FDDI) used to boot from a network boot server over a local area network (LAN).

The boot image varies for each type of device booted and is compressed to fit on certain media and to lessen real memory requirements. The boot logical volume must be large enough for the boot image.

In addition to creating a boot image, the bosboot command always saves device configuration data for disk. It does not update the list of boot devices in the NVRAM (nonvolatile random access memory). You can modify the list with the bootlist command.

The bosboot command is usually called during the Base Operating System installation and by the updatep command when the operating system is upgraded.

Notes:

1. You must have root user authority to use the bosboot command.
2. Do not reboot the machine if the bosboot command is unsuccessful with a message not to do so while creating a boot disk. The problem should be resolved and the bosboot command run to successful completion.
3. The bosboot command requires some space in the /tmp file system and the file system where the target image is to reside, if there is such an image.
4. The bosboot command requires that the specified physical disk contain the boot logical volume. To determine which disk device to specify, issue the following command:

   lsvg    -M    rootvg

   This command displays a map of all logical volumes. The default boot logical volume is hd5. Use the disk device that contains the boot logical volume.
5. When the device is not specified with the -d flag, the bosboot command assumes the default device is the disk the system is booted from. However, if the prototype file is specified with a -p flag, the device must also be specified with a -d flag.
6. The prototype file used by the bosboot command to build the RAM disk file system depends on the boot device and the hardware platform (sys0) type of the machine the boot image will run on.
   The hardware platform type is an abstraction which allows machines to be grouped according to fundamental configuration characteristics such as number of processors or I/O bus structure or both. Machines with different hardware platform types will have basic differences in the way their devices are dynamically configured at boot time. The hardware platform type rs6k in AIX® 5.1 and earlier applies to all Micro Channel-based uni-processor models through AIX® 5.1 only. The type rs6ksmp applies to all Micro Channel-based symmetric multi-processor models through AIX® 5.1 only. The type rspc in AIX® 5.1 and earlier applies to all ISA-bus models. As new models are developed, their hardware platform types will either be one of the aforementioned types or, if fundamental configuration differences exist, new types will be defined. Boot images for a given boot device type will generally be different for machines with different hardware platform types.
   "The prototype file used by bosboot is constructed by starting with a copy of the base prototype file for the platform type and boot device (for example, /usr/lib/boot/chrp.disk.proto). Next the bosboot command looks at the pcfg file for the platform type being used (for example, /usr/lib/boot/chrp.pcfg). The pcfg file contains entries which bosboot uses in a template to search for proto extension files. These files, located in the directory /usr/lib/boot/protoext, provide extensions to the prototype file under construction. For example, if the platform type is chrp and the boot device is disk, and the file /usr/lib/boot/protoext/chrp.pcfg contains the following:

   scsi.
   chrp.
   chrp_lpar.
   fcp.
   graphics.
   ide.
   isa_sio.
   pci.
   ssa.
   sys.pci.
   tty.
   usbif.

   The bosboot command will start with the base prototype file /usr/lib/boot/chrp.disk.proto, and search the directory /usr/lib/boot/protoext for any files that match the template disk.proto.ext.scsi.*. The contents of these files are added to the prototype file under construction. Next, the contents of files matching the template /usr/lib/boot/protoext/disk.proto.ext.scsi.* are added to the prototype file under construction. This continues until all lines in the pcfg file have been processed. At this point the prototype file under construction is complete. The bosboot command passes this prototype file to the mkfs command which builds the RAM disk file system.
7. The prototype files used by the BOSBOOT command to build boot images are dependent on the boot device. In addition, the prototype files are dependent on the system device type (sys0) of the machine for which the boot image is built.
   This is reflected in the names of these prototype files:
   /usr/lib/boot/chrp.disk.proto
   /usr/lib/boot/chrp.cd.proto
   /usr/lib/boot/chrp.tape.proto
   /usr/lib/boot/network/chrp.ent.proto
   /usr/lib/boot/network/chrp.tok.proto
   /usr/lib/boot/network/chrp.atm.proto
   /usr/lib/boot/network/chrp.fddi.proto
   The system device type is an abstraction that allows machines to be grouped according to fundamental configuration characteristics, such as number of processors and I/O bus structure. The system device is the highest-level device in the system node, which consists of all physical devices in the system.
   Machines with different system device types have basic differences in the way their devices are dynamically configured at boot time.
   The bosboot command, by default, uses the prototype file that matches the system device type of the machine executing the command. The -p option allows you to specify the system device type of the prototype file.
8. If the boot disk is removed from a running system, thus leaving the system operating from a replacement copy of that disk, you may experience an error message when you run the bosboot command. The error message states that the boot logical volume does not exist on the disk. This happens because the bosboot command, when called without the -d argument, defaults to the disk that the system most recently booted from. In this scenario, since that disk is no longer available, you will need to call the bosboot command with the -d argument, and the name of the disk on which the boot logical volume now resides. This provides the bosboot command with the information that is needed for identifying the new location of the boot image.

Flags

-d device

Specifies the boot device. This flag is optional for hard disk.

The following flags are action flags. One and only one flag must be specified.

-a	Creates complete boot image and device.
-v	Verify, but do not build boot image.

The following flags are option flags:

-b FileName	Uses specified file name as the boot image name. This flag is optional.
-D	Loads the low level debugger. This flag is optional.
-I (upper case i)	Loads and invokes the low-level debugger. This flag is optional.
-k Kernel	Uses the specified kernel file for the boot image. This flag is optional, and if not specified, /unix is the default.
-L	Enables lock instrumentation for MP systems. This flag has no effect on systems that are not using the MP kernel.
-l (lower case L) LVDev	Uses target boot logical volume for boot image. This flag is optional.
-M Norm|Serv|Both	Specifies the boot mode. The options are: norm Indicates normal mode. serv Indicates service mode. both Indicates both modes.
-p Proto	Uses the specified prototype file for the RAM disk file system. This flag is optional.
-q	Determines how much disk space is required in which file system to create the boot image. Boot image is not created. This flag is optional.
-T Type	Specifies the hardware platform type (see note 6). This causes the bosboot command to create a boot image for the hardware platform type specified. If the type is not specified, the bosboot command creates a boot image whose hardware platform type matches that of the currently running machine. This flag is optional.

Security

Access Control: Only the root user can read and execute this command.

Examples

1. To create a boot image on the default boot logical volume on the fixed disk from which the system is booted, type:

   bosboot -a

2. To create a bootable image called /tmp/tape.bootimage for a tape device, type:

   bosboot -ad /dev/rmt0 -b /tmp/tape.bootimage

3. To create a boot image file for an Ethernet boot, type:

   bosboot -ad /dev/ent0

4. To create a token ring boot image for a machine whose hardware platform type is chrp while you are running on a machine whose hardware platform type is chrp, type:

   bosboot -ad /dev/tok -T chrp

Files

/usr/sbin/mkboot	Specifies boot creation routine.
/usr/lib/boot/chrp.disk.proto	Specifies the disk RAM file system template.
/usr/lib/boot/chrp.cd.proto	Specifies the CD-ROM RAM file system template.
/usr/lib/boot/chrp.tape.proto	Specifies the tape RAM file system template.
/usr/lib/boot/network/chrp.ent.proto	Specifies the Ethernet RAM file system template.
/usr/lib/boot/network/chrp.tok.proto	Specifies the token-ring RAM file system template.
/usr/lib/boot/network/chrp.atm.proto	Specifies the ATM file system template.
/usr/lib/boot/network/chrp.fddi.proto	Specifies the FDDI RAM file system template.