|
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
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.
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.
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.
- 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.
- 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
- 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!
- 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
- 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.
- 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.
- 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 |
- 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.
- 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
- 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:
- In normal mode, run lsdev -Cc adapter. Look for
an entry such as:
hiprfmge0 Available 00-03 High Performance 3D Color Graphics Processor
- 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
- 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
- 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._+-]))
- 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.
- 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.
- 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
- 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.
- 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.
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:
- Boot in service mode from the version 4 media.
- At the Installation and Maintenance Menu select option
2:
Change / Show Installation Settings
- At the Installation and Settings screen, verify the
following:
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.
- Press 0 to install with current settings.
- 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.
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.
|
