University of Wisconsin-Madison  My UW
Computing @ UW-Madison

Installing AIX
Tuning AIX
Patching, Fixes, APARs
Compilers
Tips & Tricks

TSM Clients

IBM pSeries Support
TechLib
IBM Redbooks
IBM Documentation Library

Back to DoIT

Special Notices

Please use this information with care. IBM will not be responsible for damages of any kind resulting from its use. The use of this information is the sole responsibility of the customer and depends on the customer's ability to evaluate and integrate this information into the customer's operational environment.

AIX Version 4.x Migration


Contents

About this document
Prerequisite information
The migration process
Pre-Migration checks
Running the migration
Post-Migration checks

About this document

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:

  • users, groups and passwords remain intact
  • volume groups, logical volumes and file systems remain intact
  • most non-IBM applications will remain installed
  • configuration files are saved or preserved automatically

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.


Prerequisite information

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, you would see something like:

  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.


The migration process

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 3.2 PTF directories - for 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 filesystems, 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 entires with rmsrc, 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.


Pre-Migration checks

  1. The consistency of installed licensed program products (LPPs) is a crucial part of successful migrations. Make sure the installed LPPs are consistent by running:
    	#lppchk -v 
                  

    This command should not have any output. Any output returned is error output. You should correct these problems before proceeding.

  2. FOR 3.x SYSTEMS ONLY: Make sure you are running the correct VRMF levels for the upgrade. These are the suggested levels:
    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 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), you should 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  
                  
  3. AIX requires certain user and group definitions to remain unchanged. Verify that your /etc/passwd has entries matching the following:
    	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 3.2 systems, the adm group will appear as follows:

    	adm:!:4:4::/usr/adm:
                  

    The important things to check are that the preceding entries exist and exactly match. 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
                  

    The important thing to check is that the preceding entries exist. You can have more users in the group (that is, the system entry can look like system:!:0:root,james,eddie,rocky,david), but verify that the GIDs are unique (the third colon-separated entry--the first number) and that the users are in the preceding groups.

    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, you can 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!

  4. Jobs that are scheduled during the migration time should be removed or rescheduled until after migration time. It is recommended that all at jobs be removed by saving off the /var/spool/cron/atjobs and removing the file.

    You can verify that no jobs are scheduled by running the following command:

    	#at -l
                  

    Save off 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
                  
  5. The trusted computing base (TCB) consists of a database and tools for checking the system integrity. Verify that your your database is consistent by running:
    	#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:

    • fix the problems
    • circumvent the database
    • disable the TCB (this option has not been tested)

    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.

  6. Space requirements for the migration depend on the amount of data you have stored in the root volume group. For most situations, the following space requirements suffice:
    		/tmp - 15MB free space
    		/    - 10MB free space
    		80MB of unallocated physical partitions in the rootvg
                  

    Check the free space in the filesystems with the following command:

    	#df -kt
                  

    At 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 rootvg 
                  
    Look 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 filesystem.

    If your paging space is less than 32MB, the migration will increase it to 32MB.

  7. Memory requirements are as follows:
    		|   LEVEL   |   MEMORY/TAPE   |   MEMORY/CD   |
    		|-----------|-----------------|---------------|
    		|   4.1.x   |       16MB      |      8MB      |
    		|   4.2.x   |      >16MB      |     >16MB     |
    		|   4.3.x   |       32MB      |      32MB     |
                  

  8. 4.1.x SYSTEMS ONLY: There was a set of bad fixes that went out in version 4.1 that prevents migrations from taking place. Check the level of bos.rte.lvm with the following command:
    	#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.

  9. Make sure the operating system supports the hardware platform. Most RS/6000 machines will run almost any level of the OS. Following is a list of hardware and the earliest release of software under which they were supported:
    	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 being on top). 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 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
                  
  10. Most hardware that was supported previously is still supported. It can become difficult to keep supporting out-dated hardware, so IBM does withdraw support for some devices. Following is a list of all devices that are no longer supported, arranged by the OS and the level at which they were pulled.

    4.1

    SABINE GRAPHICS ADAPTER

    To identify it:

    1. In normal mode, run lsdev -Cc adapter. Look for an entry such as:
      	hiprfmge0 Available 00-03 High Performance 3D Color Graphics Processor
                      
    2. If the system is powered off or inaccessible, check the back of it for the adapter card. The card takes up two slots and should have a sticker near the connector that says 1-3.

    4.2 and 4.3

    LAPTOPS

    Any machine requiring pcmcia drivers (therefore, any laptop) is currently not supported.

    GRAPHICS ADAPTERS

    	  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 
                  
  11. Break all mirrors. You should not have any mirrored copies of a rootvg logical volume during a migration. The lsvg command will display any copies of a logical volume.
    	#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, so you know you booted from hdisk0. With this knowledge, remove the mirror from hdisk1 with the following command:

    	#rmlvcopy hd5 1 
                  
  12. Make sure there are no unsupported filenames in the /tmp directory. The IEEE POSIX and UNIX Standard "portable filename character set" consists of:
    		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 filenames 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._+-]))
                  
  13. Verify that your ODM files are not bad. There is no way to completely check the ODM, but a good check is to go into the following directories and make sure there are no 0-length files:
    	/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.

  14. Make sure that all the logical volumes in your volume groups are sync'ed. To get a listing of the volume groups, run:
    	#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 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.

  15. Verify that your file systems are defaulted to the original values expected by the operating system. Make sure the mapping of logical volumes to file systems is as follows:
    			hd1		/home	
    			hd2		/usr
    			hd3		/tmp
    			hd4		/
    			hd5		blv (a raw lv, not a filesystem)
    			hd9var  	/var	
                  
  16. There are some migration limitations if you are going to 4.3.1 from 4.1. Migration to 4.3.1 will cause the SMIT panels to have duplicate or invalid entries. An APAR has been opened on this issue but is not available yet. For future reference, the APAR number is IX81993. Please call AIX support for the efix if you cannot wait for the APAR to be released. It is uncertain how long it will be before the APAR is available.

  17. Prior to running your migration, make a full operating system backup. A mksysb backup will recreate raw logical volumes but will not restore the data. The mksysb will not back up any file systems that are unmounted.

Running the migration

At AIX 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, you will need to use a circumvention diskette in order to see the install menus. A good way to identify this problem is to notice that the system hangs on c31 when booting off of the install media.

If you are not presented a migration option (and, according to the preceding instructions, you should be presented with it), your pad string could be wrong.

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

  1. Boot in service mode from the version 4 media.

  2. At the Installation and Maintenance Menu select option 2:
            Change / Show Installation Settings
                
  3. At the Installation and Settings screen, verify the following:
    Method of installation
                
    • New and Complete Overwrite (overwrites everything)
    • Preservation (contents of /usr, /, /var, and /tmp will be deleted; only /home and any user created logical volumes will be preserved)
    • Migration (migrates from one release to another [such as 3.2 --> 4.1] and attempts to preserve the existing system configuration but will overwrite /tmp)
      Disks you want to install to
      Primary Language
      Trusted Computing Base
                        
      When 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.

  4. Press 0 to install with current settings.

  5. If you are migrating to AIX 4.2 or later, a migration confirmation screen will appear as follows:
            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.


Post-migration checks

After the migration, you should 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):

        #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 in order 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 4.2.1 to 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 off your /var/adm/ras directory for analysis.

Copyright © 2003 The Board of Regents of the University of Wisconsin System