12.1. Understanding the AIX standard packaging
This section provides you with a basic understanding of the AIX standard packaging. For further information about AIX standard packaging, please refer to the AIX 5L Version 5.2 Installation Guide and Reference.
12.1.1. Filesets and package files
In AIX, the smallest installable unit is a fileset. A fileset logically groups files and directories to be installed. A fileset also includes required control files and optional installation customization files.
Several filesets can be packaged in a package file. A package file is an AIX backup-format file; therefore, it is sometimes referred to as a bff-file.
Figure 12-1 illustrates the relationship among filesets, packages, and bundles.
Figure 12-1. Relationship among filesets, packages, and bundles
12.1.2. Bundles
In AIX, you have hundreds of filesets in the base operating system (BOS). Therefore, to easily select many filesets, AIX offers simple facilities, called bundles. In Figure 12-1, if you select bundle 1, then you specify installing the filesets A1, B1, and C1. Please note that multiple bundles can include the same filesets. For example, in Figure 12-1, both bundle 1 and 2 include the fileset B1.
A bundle is defined by a file installed in either the /usr/sys/inst.data/sys_bundles or /usr/sys/inst.data/user_bundles directories. In the /usr/sys/inst.data/sys_bundles directory, you can see the system defined[1] bundles are already installed by default (see Example 12-1 on page 407).
[1] You can also create user defined bundles under the /usr/sys/inst.data/user_bundles directory.
Example 12-1. System defined bundles on AIX 5L Version 5.2
# cd /usr/sys/inst.data/sys_bundles; ls -l *.bnd -rw-r--r-- 1 bin bin 896 Sep 13 09:53 AllDevicesKernels.bnd -rw-r--r-- 1 bin bin 879 Sep 13 09:53 Alt_Disk_Install.bnd -rw-r--r-- 1 bin bin 1391 Sep 13 09:53 App-Dev.bnd -rw-r--r-- 1 bin bin 1051 Sep 13 09:53 CC_EVAL.DocServices.bnd -rw-r--r-- 1 bin bin 1155 Sep 13 09:53 CC_EVAL.Graphics.bnd -rw-r--r-- 1 bin bin 1176 Sep 13 11:03 CDE.bnd -rw-r--r-- 1 bin bin 1026 Sep 13 09:53 DocServices.bnd -rw-r--r-- 1 bin bin 1292 Sep 13 09:53 GNOME.bnd -rw-r--r-- 1 bin bin 1517 Sep 13 09:53 Graphics.bnd -rw-r--r-- 1 bin bin 879 Sep 13 09:53 HTTP_Server.bnd -rw-r--r-- 1 bin bin 972 Sep 13 09:53 KDE.bnd -rw-r--r-- 1 bin bin 829 Sep 13 09:53 Kerberos_5.bnd -rw-r--r-- 1 bin bin 1201 Sep 13 09:53 Media-Defined.bnd -rw-r--r-- 1 bin bin 1363 Sep 13 09:53 Netscape.bnd -rw-r--r-- 1 bin bin 1214 Sep 13 11:03 Server.bnd -rw-rw-r-- 1 root system 409 Jun 06 2002 devices.bnd -rw-r--r-- 1 bin bin 2030 Sep 13 09:53 openssh_client.bnd -rw-r--r-- 1 bin bin 2030 Sep 13 09:53 openssh_server.bnd -rw-r--r-- 1 bin bin 1373 Sep 13 11:03 wsm_remote.bnd |
In order to install filesets using a bundle, do the following:
1. | Select the following SMIT menus (you can access it using the SMIT fast path smit easy_install): # smit
Software Installation and Maintenance
Install and Update Software
Install Software Bundle
|
2. | Specify the installation device (typically /dev/cd0): INPUT device / directory for software [ ] |
3. | Select a bundle name on the panel, then press the Enter key; all the filesets defined in the selected bundle file, shown in Example 12-1, will be installed. |
Please note that you can only use bundles for installation purposes. AIX does not offer simple methods to uninstall bundles or to confirm whether bundles are correctly installed.
12.1.3. Managing filesets
The installed filesets can be classified under several states, as shown in Table 12-1. The successfully installed filesets should be in either an applied or committed state.
| Status | Description |
|---|---|
| APPLIED | The specified fileset update is installed on the system. The APPLIED state means that the fileset update can be rejected with the installp command and the previous level of the fileset restored. This state is only valid for fileset updates. |
| APPLYING* | An attempt was made to apply the specified fileset, but it did not complete successfully, and cleanup was not performed. |
| BROKEN | The specified fileset or fileset update is broken and should be reinstalled before being used. |
| COMMITTED | The specified fileset is installed on the system. The COMMITTED state means that a commitment has been made to this level of the software. A committed fileset update cannot be rejected, but a committed fileset base level and its updates (regardless of state) can be removed or deinstalled by the installp command. |
| OBSOLETE | The specified fileset was installed with an earlier version of the operating system but has been replaced by a repackaged (renamed) newer version. Some of the files that belonged to this fileset have been replaced by versions from the repackaged fileset. |
| COMMITTING* | An attempt was made to commit the specified fileset, but it did not complete successfully, and cleanup was not performed. |
| REJECTING* | An attempt was made to reject the specified fileset, but it did not complete successfully, and cleanup was not performed. |
[2] Filesets with the state specified with an asterisk (*) are not shown on the lslpp -L command output, since they are considered to be in a transient state.
In order to confirm the fileset status, you can use the lslpp -L command, as shown in Example 12-2 on page 409. In this case, the fileset bos.rte.install is in committed status (C).
Example 12-2. Listing a fileset status
# lslpp -L bos.rte.install Fileset Level State Type Description (Uninstaller) ---------------------------------------------------------------------------- bos.rte.install 5.2.0.0 C F LPP Install Commands State codes: A -- Applied. B -- Broken. C -- Committed. O -- Obsolete. (partially migrated to newer version) ? -- Inconsistent State...Run lppchk -v. |
If a fileset status is broken, then you should deinstall and reinstall the fileset.[3] If a fileset status is obsolete, then the fileset may or may not be supported on your system. If a fileset status is inconsistent, you should check it using the lppchk -v command.
[3] If you install filesets over the network, you should verify the size and the checksum of the installing package file on the target system.
Figure 12-2 on page 410 illustrates the state diagram of the applied and committed states. Once a base level fileset (fileset level 1.0.0.0) is installed, it is always in the committed status. If you apply an update fileset (fileset level 1.0.1.0)[4], the status is changed to the applied status.
[4] An update fileset is sometimes referred to as a PTF (Program Temporary Fix).
Figure 12-2. State diagram between applied and committed state
If you commit the applied update fileset, then the updated fileset level is persistent. In order to revert to the previous fileset level, you have to uninstall the fileset and reinstall it. If you reject the applied update fileset, then the fileset level is reverted to the last committed level.
This mechanism is used to precisely control the software levels on the running system. When you encounter a software problem, you should investigate to solve the problem. If the problem is caused by some defects, software vendors supporting the software products might provide some software fixes.
APARs and fileset updates
In the IBM terminology, a software defect is uniquely identified by an identifier called an APAR (authorized program analysis reports). An APAR can be, but does not have to be, addressed by more than one fileset updates. If an APAR is addressed by multiple fileset updates, then the software defect affects many files included in multiple filesets. In Figure 12-3 on page 411,[5] the APAR IZ98765 includes the fileset update of foo.rte with an update level 1.0.1.0. Therefore, in order to fix the software defect identified by the APAR IZ98765, you have to apply this single fileset update only. In order to fix the software defect identified by the APAR IZ56789, you have to apply both fileset updates, for foo.rte and gnat.rte, as shown in Figure 12-3 on page 411.
[5] We use these two identifies, IZ98765 and IZ56789, for illustrative purposes only. They do not exist.
Figure 12-3. Relationship between APARs and update fileset
You can confirm whether the specific APARs are applied or not using the instfix command. In the following example, the APAR IY35444 is applied on the system:
# instfix -ivk IY35444
IY35444 Abstract: Add snapshot backup support to JFS2
Fileset bos.mp:5.2.0.1 is applied on the system.
Fileset bos.mp64:5.2.0.1 is applied on the system.
Fileset bos.up:5.2.0.1 is applied on the system.
All filesets for IY35444 were found.
If an APAR is not applied[6] on the system, the instfix -ik APAR_ID command shows the error message similar to either of the following examples:
[6] An APAR classified as a packaging APAR also shows this message. A packaging APAR is provided to specify multiple APARs using one identifier, mainly for ordering and distribution purposes.
All filesets for IZ98765 were not found.
or
There was no data for IZ56789 in the fix database.
Therefore, you do not have to remember which fileset update would fix the specific software defect, as long as you know the corresponding APAR.
To find APARs for AIX, visit the following URL:
http://techsupport.services.ibm.com/server/support?view=pSeries
Recommended maintenance level
Sometimes IBM ships a recommended maintenance level (also referred to as RML), which includes a series of fileset updates. By using recommended maintenance levels, you can easily track the latest level of all the filesets included in AIX. The latest AIX installation media set usually includes the latest recommended maintenance level in the Update CD.
To simply determine the latest recommended maintenance level applied on the system, you can use the oslevel -r command as follows:
# oslevel -r 5200-01
The command output 5200-01 shows that RML 5200-01 is applied on that system.
In order to determine what recommended maintenance levels are applied, you can use the instfix command as follows:
# instfix -i | grep ML
All filesets for 5.0.0.0_AIX_ML were found.
All filesets for 5200-01_AIX_ML were found.
If some lines show the message All filesets for XXXX-YY_AIX_ML were not found, then you can confirm which of the fileset updates included in the recommended maintenance level are not applied on the system by running the following command:
# instfix -ivk XXXX-YY_AIX_ML | grep not | grep:
To download the recommended maintenance level, visit the following URL:
http://techsupport.services.ibm.com/server/support?view=pSeries
Note
We strongly recommend that you purchase a software program support contract for each AIX system, even if you understand the AIX software packaging mechanism and can easily download the required fileset updates. To purchase software program support, please contact your IBM sales representative or the IBM Business Partner from which you purchased your systems.
12.1.4. Viewing the TOC file (.toc)
Each AIX standard package file contains a table of contents (TOC). Before installation, this information has to be retrieved from package files and placed in the directory as a TOC file named .toc.
If you download some APARs or copy some packages from the install media to a file system, you have to issue the inutoc command to create the .toc file. If you copy additional packages into the /usr/sys/inst.images directory, you have to manually rebuild the .toc file using the inutoc command. The following example shows you how to create or update the .toc file in the /usr/sys/inst.images directory:
# inutoc /usr/sys/inst.images # cd /usr/sys/inst.images; ls -l total 800 -rw-r--r-- 1 root system 552 Apr 10 15:55 .toc -rw-r--r-- 1 root system 403456 Apr 10 15:55 U476599.bff
The created .toc file is a text file, so you can view the contents using a viewer command, such as pg or more. Figure 12-4 shows an example entry of the .toc file. A package has a block shown as A in Figure 12-4. A fileset has a block shown as B in Figure 12-4. If a package contains multiple filesets, then you will see multiple blocks of B in the package block.
Figure 12-4. Sample .toc file
Table 12-2 on page 414 explains entries shown in Figure 12-4.
| Field name | Description |
|---|---|
| Package file name | The file name of the package. |
| Package type | Indicates package type:
|
| Fileset name | The name of the fileset. |
| Fileset level | The fileset level represented by (V.R.M.F):
|
| Bosboot flag | Indicates whether a bosboot is needed after installation:
|
| Content | Indicates the parts included in the fileset or the fileset update:
|
| Fileset description | The description of the fileset. |
| Required disk space | Size required for each install target directory. |
| APAR descriptions | Information regarding the APARs contained in the fileset update. |
For further information about the format of the .toc file, please refer to AIX 5L Version 5.2 General Programming Concepts: Writing and Debugging Programs.
Once a .toc file is created, you can list the table of contents using the installp command, as shown in Example 12-3 on page 415.
Example 12-3. Listing the table of contents
# installp -ld /usr/sys/inst.images Fileset Name Level I/U Q Content ==================================================================== bos.mp64 5.2.0.1 S b usr # Base Operating System 64-bit Multiprocessor Runtime bos.mp64 5.2.0.2 S sb usr # Base Operating System 64-bit Multiprocessor Runtime |
12.1.5. Viewing package files
The AIX standard packaging uses the backup command to archive package files. Therefore, you can un-archive it using the restore command. Example 12-4 shows how to view the contents of a package file.
Example 12-4. Viewing the contents of a package file
# restore -qTf bos.mp64.5.2.0.2.U New volume on bos.mp64.5.2.0.2.U: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Mon Nov 18 11:24:17 CST 2002 Files are backed up by name. The user is BUILD. ./ ./lpp_name ./usr ./usr/lpp ./usr/lpp/bos.mp64/bos.mp64/5.2.0.2 ./usr/lpp/bos.mp64/bos.mp64/5.2.0.2/liblpp.a ./usr/lib/boot/unix_64 The number of archived files is 7. |
TOC information file (lpp_name)
A package always contains a file, named lpp_name, as its first archived file. This file is the table of contents of this package file, as shown in Example 12-5 on page 416.
Example 12-5. Extracting the lpp_name file
# mp64.5.2.0.2.U ./lpp_name
x ./lpp_name
# ls -ld ./lpp_name
-r-xr-xr-x 1 root system 1823 Nov 18 11:24 ./lpp_name
# cat ./lpp_name
4 R S bos.mp64 {
bos.mp64 5.2.0.2 01 b U en_US Base Operating System 64-bit Multiprocessor
Runtime
[
%
/usr/lib/boot 19776
/usr/lpp/SAVESPACE 19776
/usr/lib/objrepos 8
/tmp 0 14656
INSTWORK 64 32
%
%
%
IY35438 3 dio read to an unpinned page
IY35432 3 Fixes for JFS2 on filesystems larger than 2TB
... many lines are skipped ...
]
}
|
Upon invoking the inutoc command, it parses the specified directory and extracts the lpp_name file from each package file, then concatenates the extracted information to the .toc file.
Installation control library file (liblpp.a)
A package also has to contain an installation control library file, named liblpp.a, under the appropriate sub-directory. This file is an ar format archive file, which contains the files, as shown in Example 12-6.
Example 12-6. Extracting the liblpp.a file
# restore -qxf bos.mp64.5.2.0.2.U ./usr/lpp/bos.mp64/bos.mp64/5.2.0.2/liblpp.a x ./usr/lpp/bos.mp64/bos.mp64/5.2.0.2/liblpp.a # cd ./usr/lpp/bos.mp64/bos.mp64/5.2.0.2 # ls -l liblpp.a -r-xr-xr-x 1 root system 11382 Nov 18 11:24 liblpp.a # file liblpp.a liblpp.a: archive # ar -t liblpp.a productid bos.mp64.copyright bos.mp64.inventory bos.mp64.size bos.mp64.al bos.mp64.fixdata |
The <fileset_name>.al file contains the list of files in the fileset. Example 12-7 shows you the contents of the bos.mp64.al file, which contains one file that is specified using the relative path name starting from the root directory.
Example 12-7. Contents of the bos.mp64.al file
./usr/lib/boot/unix_64 |
The <fileset_name>.inventory file contains the required information about files within the fileset (see Example 12-8). Each file has entries explained in Table 12-3.
| Entry name | Description |
|---|---|
| owner | Specifies the file owner. |
| group | Specifies the file group. |
| mode | Specifies the permission bit of the file. |
| type | Specifies the file type. |
| links | Specifies a hard-link of the file (if available). |
| class | The logical group of the file. |
| size | Specifies the size of the file. |
| checksum | Specifies the result of the cksum command to the file. |
These values are used to verify the contents of restored files from the package file if those files are restored correctly.
Example 12-8. Contents of the bos.mp64.inventory file
/usr/lib/boot/unix_64:
owner = root
group = system
mode = 555
type = FILE
class = apply,inventory,bos.mp64
size = 10122374
checksum = "07429 9886 "
|
For further information about the format of these files contained in the liblpp.a file, please refer to AIX 5L Version 5.2 General Programming Concepts: Writing and Debugging Programs.