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:

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, 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.


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


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:
  2. 	#lppchk -v 
    

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

  3. For versions 3.x systems only
    Make sure you are running the correct VRMF levels for the upgrade. These are the suggested levels:
  4. 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  
    
  5. AIX requires certain user and group definitions to remain unchanged. Verify that your /etc/passwd has entries matching the following:
  6. 	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!

  7. 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.
  8. 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
    
  9. 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:
  10. 	#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.

  11. Space requirements for the migration depend on the amount of data stored in the root volume group. For most situations, the following space requirements suffice:
  12. 		/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 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 file system.

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

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

  15. For versions 4.1.x systems only
    There was a set of incorrect 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:
  16. 	#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/ssapin
    
    On 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.efix
    
    After executing the efix script, verify that it worked. Enter:

    # cd /usr/lpp/devices.mca.8f97/deinstl
    # cat *.al | grep ssapin       (Nothing should be found.)
    # cat *.al | grep ipn               (Nothing should be found.)
    There is no APAR available to correct this problem. It will be resolved in the next installation release.
  17. Make sure the operating system supports the hardware platform. Most 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:
  18. 	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
    
  19. Most hardware that was supported previously is still supported. It can become difficult to keep supporting outdated 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.
  20. 4.1

    SABINE GRAPHICS ADAPTER

    To identify it:

    1. In Normal mode, run lsdev -Cc adapter. Look for an entry such as:
    2. 	hiprfmge0 Available 00-03 High Performance 3D Color Graphics Processor
      
    3. 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 reads 1-3.

    4.2 and 4.3

    LAPTOPS

    Any machine requiring pcmcia drivers, which includes 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 
    
  21. 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.
  22. 	#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 
    
  23. Make sure there are no unsupported file names in the /tmp directory. The IEEE POSIX and UNIX Standard portable file name character set consists of:
  24. 		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._+-]))
    
  25. Verify that your Object Data Manager (ODM) files are acceptable. There is no way to completely check the ODM, but a good rule of thumb is to go into the following directories and make sure there are no 0-length files:
  26. 	/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.

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

  29. 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:
  30. 			hd1		/home	
    			hd2		/usr
    			hd3		/tmp
    			hd4		/
    			hd5		blv (a raw lv, not a filesystem)
    			hd9var  	/var	
    
  31. 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.
  32. 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 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:

  1. Boot in Service mode from the version 4 media.
  2. At the Installation and Maintenance Menu, select option 2:
  3.         Change / Show Installation Settings
    
  4. At the Installation and Settings screen, verify the following:
  5. Method of installation
    

    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.

  6. Press 0 to install with current settings.
  7. If you are migrating to AIX Version 4.2 or later, a migration confirmation screen will appear as follows:
  8.         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, 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 ]