AIX 4.1 and beyond have a new option for installing the base operating system. In most cases, if your system is at a previous version or release, migration is the default method of installation.
The migration has the following advantages:
This document describes the migration process, pre-migration checks and some post-migration tests to run to verify that your migration is consistent. Please note that a migration is a system-wide change, and sometimes it can be difficult to pinpoint problems. This document contains some precautionary steps for the most common problems customers encounter.
This document uses the following conventions:
[text] - information specific to your environment
should be filled in
# - the command prompt: the information after
this prompt should be entered exactly as
it appears (after filling in info that is
specific to your environment)
Also, you need to understand the IBM convention for labeling levels. Whenever you want to find the level of a fileset or the system, output is displayed in VRMF format:
V = Version
R = Release
M = Maintenance
F = Fix
For example, if you were to type oslevel and got back 4.2.1.0, you would know that you were at maintenance 1 of release 2 of version 4. System levels will always show fix levels of 0. If you were to run lslpp -l bos.net.tcp.client, output would be similar to the following:
bos.net.tcp.client 4.2.0.12 APPLIED TCP/IP Client Support
This would tell us that you were at fix 12 of maintenance 0 of release 2 of version 4.
After your console and languages are set, and after the system boots from the install media, one of the first things that happens is that the system drives are checked for the kernel level. If this level is a different release or version, a migration option is present and is the default.
After the migration begins, a pre-install script runs to prepare the system for the installation. This pre-installation script retrieves a list of installed filesets; creates a list of new filesets to install; determines if there is enough room to perform a migration installation, based on configuration files that must be saved and new filesets that must be installed; and saves configuration files to /tmp/bos and removes files that are no longer necessary, including old version 3.2 PTF directories for version 3.2 systems only.
Next, the bi_main script takes over. This is the guts of the installation. The bi_main script restores the bos.rte image, unmounts the temporary mount points and mounts real file systems, and then calls the post-install script.
The post-install script removes any unnecessary directories (any separate logical volumes are not touched), removes any obsolete messages and locales, removes packaging directories of filesets that will be migrated, cleans up the Vital Products Database by removing all PTF information for bos.obj and all AVAILABLE entries, increases root (/) by one partition to increase the number of available inodes, processes the bos.rte.cfgfiles file in order to merge the bos.obj config files, removes obsolete System Resource Controller entries with the rmsrc command, and determines what needs to be reinstalled at the latest level; everything that bi_main's bos.rte image did not include.
After the post-install script finishes, bi_main once again takes over calling installp with a list of filesets to be migrated, device filesets that need to be installed, and the contents of the appropriate autoi bundles (that is, server, client).
Then the system is rebooted and brought to a login prompt.
#lppchk -v
This command should not have any output. Any output returned is error output. You should correct these problems before proceeding.
| TO | FROM |
| 4.1 | 3.2.5.0 or higher |
| 4.2 | 3.2.5.0 or higher |
| 4.3 | 3.2.0.0 or higher |
In version 3.2.x, different commands give us different levels. Use the following commands to find your level:
#lslpp -l bos.obj
You should see output similar to:
Name State Description -------------------- ------------ ------------------------- Path: /usr/lib/objrepos bos.obj 03.02.00.00 COMMITTED The Base Operating System Path: /etc/objrepos bos.obj 03.02.00.00 COMMITTED The Base Operating System
This verifies that you are at least at 3.2.0. If the preceding chart shows that you need to be higher than 3.2.0 for migration to 4.1.x or 4.2.x, check your level with the following command:
#lslpp -m bos.obj
You should minimally have the following lines of output:
Description State Fix Id
---------------------------- ------ ------------
bos.obj 3.2.0.0
3250 bos Maintenance Level C U491123
root:!:0:0::/:/bin/ksh deamon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: uucp:!:5:5::/usr/lib/uucp: guest:!:100:100::/home/guest: nobody:!:4294967294:4294967294::/:
On version 3.2 systems, the adm group will appear as follows:
adm:!:4:4::/usr/adm:
It is important to verify that the preceding entries exist and match exactly. Also, verify that no other user has UIDs that duplicate the preceding. The UID is the third colon-separated entry, the first number.
Verify that your /etc/group file has entries matching the following:
system:!:0:root staff:!:1: bin:!:2:root,bin sys:!:3:root,bin,sys adm:!:4:bin,adm uucp:!:5:uucp mail:!:6: security:!:7:root cron:!:8:root printq:!:9: audit:!:10:root ecs:!:28: nobody:!:4294967294:nobody usr:!:100:guest
Check that the preceding entries exist. It is acceptable to have more users in the group, for instance, the system entry can look like system:!:0:root,james,eddie,rocky,david, but verify that the GIDs are unique and that the users are in the preceding groups. GIDs are the third colon-separated entry, the first number.
Make sure all of the user definitions are correct in the user database:
#usrck -n ALL
Do the same for the groups:
#grpck -n ALL
If you find errors, correct them by replacing the -n flag with the -t flag.
WARNING: AIX checks the users and groups based on standard UNIX user and group expectations. Your environment or application may require groups and users that deviate from standard UNIX users and groups. If you are not sure, it's best to leave it the same!
You can verify that no jobs are scheduled by running the following command:
#at -l
Save the following files if you have edited them:
/usr/adm/cron/at.allow /usr/adm/cron/at.deny /usr/adm/cron/cron.allow /usr/adm/cron/cron.deny
#tcbck -n ALL
You may not have the TCB installed on your system. If you get the following error message, it has not been activated:
3001-101 The Trusted Computing Base is not enabled on this machine.
To enable the TCB, reinstall and set the Install Trusted Computing Base option to YES. No checking is being performed.
If you get other errors from the command, do one of the following:
In order to fix the problems, correct the entries in the /etc/security/sysck.cfg file. Refer to the documentation on TCB in the Systems Management Guide.
You can circumvent the database by saving off the sysck.cfg file, removing it and touching a new file.
Disabling the TCB is not recommended. Unless you have some sort of TCB corruption, you should take the first or second method.
/tmp - 15MB free space / - 10MB free space 80MB of unallocated physical partitions in the rootvg
Check the free space in the file systems with the following command:
#df -kt
At version 3.2 the kt flags do not operate. Simply run df.
Check the amount of free physical partitions in the rootvg with the following command:
#lsvg rootvgLook for the line that says FREE PPs:. If you do not have the unallocated physical partitions, make sure you have at least 80MB free in /usr.
If you do not have the free partitions in the rootvg, you can circumvent by having the 80MB free in the /usr file system.
If your paging space is less than 32MB, the migration will increase it to 32MB.
| LEVEL | MEMORY/TAPE | MEMORY/CD | |-----------|-----------------|---------------| | 4.1.x | 16MB | 8MB | | 4.2.x | >16MB | >16MB | | 4.3.x | 32MB | 32MB |
#lslpp -l bos.rte.lvm
If you are between levels 4.1.5.9 and 4.1.5.13, update this fileset to 4.1.5.14 or later.
If you use HACMP, you could be using a clustered version of the logical volume manager. Check this level with the following command:
#lslpp -l prpq.clvm
If you are between levels 4.1.5.6 and 4.1.5.9, update this fileset to 4.1.5.10 or later.
Migration to Version 4.3.3 only
During migration to version 4.3.3, a system with Serial Storage Architecture
(SSA) drivers may receive a bosboot failure. The error message is
usually the following:
0301-154 bosboot: missing protofile: /usr/lib/drivers/ssapinOn an SP system, the LED may be U55, A55, or C61. On a standalone system, it is usually C61.
There is a build problem with the Serial Storage Architecture (SSA) device drivers on Version 4.3.3 install media. After you have encountered the problem, that is, a failed migration, recover by reinstalling devices.common.IBM.ssa.rte.
There is also an efix available. Before the migration, execute this script on the node by entering:
ssa_pre_i.efixAfter executing the efix script, verify that it worked. Enter:
7013 G40 - 4.2.0 7013 J40 - 4.2.0 7013 J50 - 4.1.5 7015 R40 - 4.2.0 7015 R50 - 4.1.5 7017 S70 - 4.3.0 7024 E20 - 4.2.0 7024 E30 - 4.2.0 7025 F30 - 4.2.0 7025 F40 - 4.1.5 7025 F50 - 4.2.1 7026 J50 - 4.2.1 7026 h50 - 4.2.1 7043 43p - 4.2.1 7317 F3L (604) - 4.2.0 7317 F3L (604e) - 4.2.1
Following is a list of the order in which the releases came out, the most recent listed first. The support is based on release dates. If you have one of the preceding systems, find the level on the following list. Everything including that level and what is above it will run. See the notes for hardware support.
4.3.2 4.3.1 4.3.0 4.2.1 4.1.5 4.2.0 4.1.4
To identify it:
hiprfmge0 Available 00-03 High Performance 3D Color Graphics Processor
Any machine requiring pcmcia drivers, which includes any laptop, is currently not supported.
POWER GTO (TM) Accelerator Adapter
POWER Gt1 (TM) Graphic Adapter 1-Bit
POWER Gt1b ISO Graphic Adapter 1-Bit
POWER Gt1x Graphic Adapter
2780 High-Performance 8-bit 3D Color Graphics Processor
2781 High-Performance 24-bit 3D Color Graphics Processor
2782 24-bit Z-Buffer Solid Rendering Option
2783 24-bit Color Graphics Frame Buffer Upgrade
#lsvg -l rootvg
You should see output similar to the following:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT hd6 paging 64 64 1 open/syncd N/A hd5 boot 1 2 2 closed/syncd N/A hd8 jfslog 1 1 1 open/syncd N/A hd4 jfs 9 9 1 open/syncd / hd2 jfs 36 36 1 open/syncd /usr hd9var jfs 4 4 1 open/syncd /var hd3 jfs 7 7 1 open/syncd /tmp hd1 jfs 4 4 1 open/syncd /home
The preceding output shows that /dev/hd5, the boot logical volume, or blv, is mirrored once (because PPs = (2 x LPs), so there are two copies). To reduce the mirrored copies, use the rmlvcopy command. See the man page for details.
Before removing any mirrors, verify the disk from which you booted by using the command lslv and checking the links in the /dev directory:
#lslv -m hd5
The command should output information as follows for the scenario where the hd5 is mirrored once:
LP PP1 PV1 PP2 PV2 PP3 PV3 0001 0001 hdisk0 0001 hdisk1
This shows that there are copies on hdisk0 and hdisk1. Next, check to see which one was booted from (the IPLDEVICE). This is done by comparing the major and minor numbers of the devices:
#ls -l /dev/ipldevice /dev/rhdisk<X> /dev/rhdisk<Y>
In this case, X would be 0 and Y would be 1. Here is the output:
crw------- 2 root system 12, 1 Mar 10 09:44 /dev/ipldevice crw------- 2 root system 12, 1 Mar 10 09:44 /dev/rhdisk0 crw------- 1 root system 12, 2 Mar 10 09:44 /dev/rhdisk1
The major and minor numbers appear in the fifth column. The /dev/ipldevice matches up with /dev/rhdisk0, indicating that you booted from hdisk0. With this knowledge, remove the mirror from hdisk1 with the following command:
#rmlvcopy hd5 1
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 0 . _ - +
AIX, and UNIX operating systems in general, may operate in unexpected ways if file names are used that contain characters special to UNIX.
Some examples of these special characters are:
<space or tab> = field separator for shell scripts and several UNIX utilities <?,*,$,@,\,/> = wildcard characters for command line and shellscript parsing, and also pathname parsing <^C, ^D, and so on> = tty control characters, which affect input for most OID UNIX utilities < <,>,",',`,&,> = characters special to command line parsing and shell
Some licensed IBM products and third party products have been known to create files that use these special characters. File names containing special characters in the /tmp directory will cause the migration to fail. If you have any, especially in /tmp, back them up and remove them from the system.
The following command checks to see if any poorly named files exist on the system. The syntax of the command takes the current directory and checks for unacceptable files.
#ls -ld !(+([a-zA-Z0-9._+-]))
/etc/objrepos /usr/lib/objrepos /usr/share/lib/objrepos
If there are 0-length files, please contact your support organization to verify that they are not necessary to the system. Lock files are supposed to be 0 length.
#lsvg
Use this output to run a sync:
WARNING : Before running a synclvodm, verify that you do not have raw logical volumes with an owner or group other than root or system in the rootvg. For example, ORACLE owns their own logical volumes. In AIX Versions 4.2 and later, run the synclvodm with the -P flag to preserve permissions. Do not run this command if programs are using the raw logical volume.
#synclvodm <volume_group>
If you get errors, use local problem reporting procedures to fix them before trying a migration.
hd1 /home hd2 /usr hd3 /tmp hd4 / hd5 blv (a raw lv, not a filesystem) hd9var /var
At AIX Version 4.2.1 only
If you are migrating to 4.2.1 and you have a GXT110P,
GXT120P, GXT800M, or any other newer graphics adapter that does
not have support on the media, use a circumvention
diskette to see the install menus. To identify
this problem, check the system hangs on c31 when booting
off of the install media.
If you are not presented a migration option, your pad string could be wrong. According to the preceding instructions, you should be presented with a migration option.
Sometimes the boot logical volume (blv) contains the wrong system information. This usually occurs when an install has been attempted in the past. Make sure the pad string reflects the version and release of the system.
For 4.x systems, run:
#lquerypv -h /dev/hd5 2A0 50
You should see something similar to:
000002A0 32393533 00000000 00000000 00000000 |2953............|
000002B0 00000000 00000000 00000000 0000342E |..............4.|
000002C0 33207061 64207374 72696E67 3A402524 |3 pad string:@%$|
000002D0 237E217E 7E217E23 24254000 00000000 |#~!~~!~#$%@.....|
000002E0 00000000 00000000 00000000 00000000 |................|
This output reflects a 4.3 pad string, or a 4.3.x system.
For 3.2 systems, run:
#dd if=/dev/hd5 bs=512 count=2 2>/dev/null|strings|tail -2
You should see:
3.2 pad string:~!~#$%@@%$#~!~
3.2 pad string:~!~#$%@@%$#~!~
This output reflects a 3.2 pad string, or a 3.2.x system.
If your level is incorrect, change the pad string contained in the blv. If it is correct, go to the next step.
For 4.x systems, run:
#/usr/lpp/bosinst/blvset -d /dev/hdisk<X> -plevel
4.<Y>
X denotes the disk where the blv (/dev/hd5) resides.
This can be determined by running lslv -m hd5.
Y denotes the release of AIX you are running, for example, 1
for version 4.1
For 3.x systems, run:
#/usr/lpp/bosinst/blvset -d /dev/hdisk<X> -p menu < /etc/settings
X denotes the disk where the blv (/dev/hd5) resides. This can
be determined by running lslv -m hd5.
In order to migrate a system, do the following:
Change / Show Installation Settings
Method of installation
Disks you want to install to Primary Language Trusted Computing BaseWhen you install the trusted computing base, the trusted path, the trusted shell, and system integrity checking are installed. The trusted path protects your system in case a program is masquerading as the program you want to use. It tries to ensure that the programs you run are trusted programs.
WARNING: TCB should only be installed with a New and Complete Overwrite unless it exists on the system being migrated. Do not select the Trusted Computing for migrations or preservations unless you are sure you had it installed at the previous level.
1 List the saved base system configuration files which will not
be merged into the system. These files are saved in /tmp/bos
2 list the filesets which will be removed and not replaced
3 list directories which will have all current contents removed
4 reboot without migrating
0 continue with the migration
This screen gives you information on files that will be affected by the migration. After viewing the information, select 0 to start the migration.
NOTE: During the installation, you see a screen that shows how long the installation has been going and the percentage thereof that is complete. If the key is in Normal, the system will automatically reboot.
After the migration, make some basic checks to ensure that the install occurred correctly. These checks cannot be complete but they provide a good starting point.
Make sure the installed Licensed Program Products are consistent:
#lppchk -v
There should be no output from the preceding command. Any output is error output and should be corrected.
Make sure the oslevel command shows the proper VRMF information. The fix information should always be zero. Enter:
#oslevel
For systems that are being migrated to 4.2.1, it is necessary to run an update_all on the second volume of 4.2.1 BOS CDs for the oslevel command to return 4.2.1.0. This may be true of other levels that are installed with multi-volume CDs, unless the system prompted you for other volumes of the CD during the install. By default, the prompting for other volumes is turned off so the system will migrate unhindered.
Make sure you do not have any previous level filesets committed:
#lslpp -l|grep <previous_version.previous_release>|grep COMMITTED
For example, if you had migrated from version 4.2.1 to version 4.3.0, run:
#lslpp -l|grep 4.2|grep COMMITTED
Any AIX filesets that are in the committed state should be removed. This may not apply to any third party software you have installed; verify with the third party vendor about what should be done with their software. If you run lslpp -l output without the pipes and greps, you may see obsolete filesets. These should not be removed unless you are sure that none of your software still needs these previous level filesets.
Make sure none of you filesets have been broken:
#lslpp -l|grep BROKEN
Broken base filesets are corrected by forcing the install of the base fileset. Broken PTFs are corrected by reinstalling the PTF in the committed state.
Make sure that your fix database contains information for the level to which you have just migrated:
#instfix -ik <V.R.M.F>_AIX_ML
You should get a message like:
All filesets for <V.R.M.F>_AIX_ML were found.
The final checks are to ensure that your system's applications are running normally.
If you find any problems after the migration, please save your /var/adm/ras directory for analysis.
[ Doc Ref: 91623329313242 Publish Date: Oct. 17, 2000 4FAX Ref: none ]