TITLE : Migration to AIX 4.3.2 - Gotchas, Querks and Watchouts. OS LEVEL : AIX DATE : 17/05/99 VERSION : 1.0 ---------------------------------------------------------------------------- Installation of 4.3.1/4.3.2 from Tape As of this date there is no fix that allows you to migrate or install from 4.3.1 via tape. The workaround for the migration from 3.2 or 4.1 to 4.3.2 using tapes is as follows: The efix is on ftp://service.boulder.ibm.com/aix/efixes/32to432tapemig The file is called 32to432tapemig.tar.Z Get the readme as well. Uncompress it and then untar it with the commands uncompress 32to432tapemig.tar.Z tar -xvf 32to432tapemig.tar and then read the README file for instructions. FIX for problem migrating from 3.2 to 4.3.2 using 4.3.2 tape media: (The symptom of this problem is that commands are 'not found' and the migration fails to complete.) Please change (cd) to the diskette directory. Verify that the permissions on the files are 777: ls -l total 680 -rwxrwxrwx 1 ann staff 261162 Dec 03 10:51 bi_main -rwxrwxrwx 1 ann staff 14 Oct 23 15:06 bi_main.debug -rwxrwxrwx 1 ann staff 75156 Dec 02 14:36 bos.rte.pre_i -rwxrwxrwx 1 ann staff 119 Dec 02 14:38 startup Create the FIX diskette with the following command: # find . -print | backup -ivq Before starting the migration, verify that you can read from the diskette on the 3.2 system. Start the migration as usual, but have the diskette in the diskette drive at the beginning of the migration (when rebooting the system). Leave it in the drive until the migration is complete. ================================================================= Rule of thumb, get your system upgraded to the latest and greatest for your level. This means, micro code for your machine, all software fixes at your level. If you are a 3.2.5.0, you should go to 3.2.5.1.x if you can. Migration installations have many problems if you are not at the latest. It can be done, but you may have to troubleshoot problems after the fact. Micro code on machines and on devices have caused problems after an upgrade, check to make sure you are at the latest and greatest for your equipment. See getting micro code on our web site also. Some devices do not seem to work on migration installations from lower versions of AIX. For example, we have had many customers who were on 3.2.5 and had a single speed cd-rom on their machine. Although a single speed cd-rom, (according to IBM is supported in 4.3.) We have not been able to get it to work. Our customers had to upgrade to a quad speed to read the cd. You can always test your cd-rom with the new software by booting from the CD. If it works, do not go further, get out of the install (turn machine off if you need to.....also make sure you have a backup before you play with a new OS). If it doesn't work, you know that you need to upgrade the micro code, drivers in AIX, or need to get a better cd drive. Also we had problems with density setting supported and tapes supported on 1/4 inch tapes. Some density settings on older (not supported length tapes) did not work after the migration. Check to make sure you have IBM supported tapes, length of tapes, and density before doing a mksysb that will be required to restore system if you have to. If you have to retrieve one file off these tapes, after you have upgraded, if it is the wrong size or density, you will not be able to get it back! Memory Requirements for Aix Version 4.3 has changed. It requires a minimum of 32 MB of physical Memory, 64MB suggested. Initial Paging Space Requirements Aix Version 4.3 requires the initial paging space (/dev/hd6) to be a minimum of 64 MB in size Make sure that you have enough hard disk space for this migration!. Disk Space Requirements (recommendations): / 16 MB /usr 256 MB /var 16 MB /tmp 16 MB This is based on loading Network Support, X11,and CDE. Filesets bos.sysmgt.sysbr (mksysb fileset) and bos.net.nfs.client are not automatically installed in AIX 4.3. Java and Web based System managment are automatically installed =============================================== Assume that tty definition and printers will not migrate correctly. Have this information on paper so that you can recreate if you have to. If it makes it great, if not you are prepared. Printer names changed, and do not migrate well, ttys migrate usually, but the xon/xoff defaults to DTR and the alternate pin defaults to no. Check the definitions if you migrate and the ttys do not work. Also add clocal to runtime and stty (the end of the string) if you are still having problems. ============================ From AIX Version 4.3 Migration Guide: Sendmail Update: The version of Sendmail that is supplied with AIX Version 4.3 has been updated to UCB Version 8.8.8. Compatibility with AIX Version 3.2 and Aix Version 4.1 Sendmail Version 5.6.4 which was supported on AIX Version 3.2.5 and Version 4.1.5 is not compatible with Sendmail Version 8.8.8 which is supplied with AIX Version 4.3. Sendmail Version 8.8.8 will not work with the version 5.6.4 /etc/sendmail.cf configuration file, and there is no utility available to migrate the old file. The Old /etc/sendmail.cf file is saved under /usr/lpp/save.config directory and then overwritten during the migration. You must then reconfigure /etc/sendmail.cf manually. Below is not supported by IBM: If you have made complex changes to sendmail.cf and cannot immediately duplicate those changes in the new file, you can do the following to revert to your old Sendmail environment. PLEASE BE AWARE that Sendmail 5.6.4 is not supported on AIX Version 4.3; so this should be considered a temporary measure only. 1) log in as root 2) stop Sendmail with the following command # stopsrc -s sendmail 3) Save the existing Sendmail files: # cp -p /usr/sbin/sendmail /usr/sbin/sendmail.888 # cp -p /etc/sednmail.cf /etc/sendmail.cf.888 4) Copy back your old Sendmail files: # cp /usr/lpp/save.config/usr/sbin/sendmail /usr/sbin/sendmail # cp /usr/lpp/save.config/etc/sendmail.cf /etc/sendmail.cf # cp /lpp/save.config/etc/sendmail.nl /etc/sendmail.nl 5) Restart Sendmail with the following command: # startsrc -s sendmail -a "-bx -q30m" Compatibility with 4.2 and AIX Version 4.3 Sendmail Version 8.7.0 which is supplied with AIX Version 4.2. and 4.3.0 is partially compatible with Sendmail Version 8.8.8 in that the Version 8.7.0 Sendmail.cf can still be used with the new Sendmail binary. During the migration or update, the old Sendmail.cf file will be retained. However, you may wish to merge in the new options and rewrite rules that have been added to Version 8.8.8 ============================= Migrating NFS and NIS from AIX Version 3.2 When migrating from AIX Version 3.2 the files /etc/rc.nfs and /var/yp/Makefile are not migrated. The migration process saves the old files in /lpp/save.config/etc/rc.nfs and /lpp/save.config/var/yp/Makefile. You must reconfigure your NIS domain name before an NIS client will work. For NIS Servers, the NIS databases are unchanged, but you must reconfigure the NIS domain and restore any changes you may have made to rc.nfs and the Makefile because these files are replaced. User and group information is retained because the passwd and group files are not changed in the migration install. ========================================== TCP/Migration The default for the TCP/IP ipforwarding parameter changed to NO in AIX Version 4. This means you will have to reset it with the no command if your system was originally at AIX Version 3.2.5 and was acting as a gateway. If you do a migration install. you will need to save all your configuration files manually, or be sure that you can quickly and reliably recover these files from your system backup. Remember you may need t save X.25 configuration files, etc. After the migration you can then check the configurations with the default AIX Version 4.3 files. and customize where needed. You may have to reconfigure devices or other items whose configuration information is lost as well as loading any additional software and device drivers.. Any device drivers loaded from a floppy or that were third party may not exist on the new system. If it is a third party device, make sure it is compatible with AIX 4.3.2 and you have the newest driver BEFORE you do the migration. AIX Version 4.3 now includes suport for IP Version 6. Most AIX IP related commands have been enhanced to support both version of IP. However some older networking packages which are not IPv6-aware may have features that cause them to exhibit problems. This can often be resolved by simply changing the entry for that package in the /etc/inetd.conf file from tcp6 to tcp. ===================================== You should make a list of all the programs you have on your system to assure that they will migrate or do if you need to purchase additional upgrades. Develop a list of 3.2.5 IBM products and levels: lslpp -ciq lslpp -ciq | tr ' ' ':' > /tmp/lslpp.op cat /tmp/lslpp.op | cut -f3 -d: > /tmp/lslpp.vers cat /tmp/lslpp .op | cut -f5 -d: > /tmp/lslpp.prod_num cat /tmp/lslpp.op | cut -f7 -d: > /tmp/lslpp.prod_names pr -t -m /tmp/lslpp.prod_num /tmp/lslpp.prod_names /tmp/lspp.vers Sample of 3.2.5 to Version 4.3 programs: Performance Toolbox upgrade required Communication Server V4.2 upgrade required ADSM upgrade required 3270 Host Connect new product C for AIX upgrade required X.25 Support Chargeable program InfoExplorer License Extens withdrawn from marketing ================================ Changed shell script commands: acctdusg, admin, axeb, awk, backbyname, bc,bsh, catman, chuser, cksum, cmp, cp, cpio,csh,ctaqgs, date, delta, df, diff, diskusg, du, ebxa, echo, ed, expr, fold, fsdb, getconf, head, iconv, istat, join, ksh, ksh built-in commands (echo fc jobs trap wait), lex, locale, localedef, lp, lsfs, lsjfs, man, more, nice, nm, nohup, od, pack, paste, pax, renice, sed,sort, strings, stty, tctl, tee, touch, uniq, wc, what and yacc. ======================================= LFT non-supported commands. chcolor, chcursor, chhwkbd, chkeymap, chnumvt, chsound, gm, lscolor, lsscreen, mkbd, open, swkbd. LFT changed commands: chdisp, chfont, chkdb, lsdisp, lsfont, lskdb, mkfont. Non-IBM Display Adapters Customers using Non-IBM display adapters may also be using vendor supplied software specific to those devices which . IBM is now using X11R6.1 compatibility. Remember that there are new X11 Libraries. LOAD the compatibility filesets if you are having problems after the migration, it may help you: bos.compat.cmds bos.compat.imk bos.compat.links bos.compat.lan bos.compat..msg bos.compat.net bos.compat.Netinstl bos.compat.termcap bos.compat.termcap.data ============================== Unsupported Hardware on AIX Version 4.3 7016 PowerServer Model 730 7007 Noteboot Workstation Model N40 7051 Powernetwork Dataserver 7249 Model 851 and 860 7247 Models 821, 822, and 823 9076 PowerParallel System SP1 Graphic adapters not supported Power GTO Accelerator Adaptor Power Gt1 Graphic Adapter 1 Bit Power Gt1b ISO Graphic Adapter Power Gt1x Graphic Adapter 2780 High Performance 8 bit 3 D 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 Fram Buffer Upgrade 7235 GTO acceletor, feature 4350 Gt1 Graphics Adapter, feature 4308 Gt1b Graphics Adapter, Feature 2804 Gt1x Graphics Adapter, feature 9280 High Performance 24-bit 3 D color Graphics Processor High Performance 8 Bit 3 D color Graphics Processor Remember non-IBM graphics adapters must verify that the adapter is supported on AIX Version 4.3. Network Terminal Accelerator is not supported in AIX Version 4.3. =========================== Printer Names Changes: You should be aware that some printer names are different in AIX Version 4. This may cause problems with shell scripts that call the mkvirprt command. ============================================ Compatibility between AIX Version 3.2 and Version 4.3 Generally it is compatible, except if your application uses some of the following: unsupported, user-created loadable kernel extensions X11R3 input device interfaces CIO Lan device driver interface SCSI device configuration methods (IHVs) The nlist() interface DCE threads Remember that any program that must run in all environments such as POWER, POWER2, and POWERPC must be compiled using the common mode option of the compiler. Things to watch for on client machines: Network installation of AIX Version 4.3. clients Service SNA or X.25 HCON CGE expensions for PEX and PEX-PHIGS Font Servers may be required on AIX Version 4.3. clients to handle X-windows ==================================== Migration Tests, Instructions, Post Migration Make sure that you do as many of these pre and post tests as possible. Post migration about inserting the second CD and typing update_all is important to assure your system is migrated correctly. Please do the post migration and pre migration tests. It is also wise to keep the old mksysb from the older level, as well as make a new mksysb as soon as possible. Keep both with dates and format on them. 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 info for bos.obj and all AVAILABLE entries, increases / 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 figures out 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. You should 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 You will also want to 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. You should 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 Trusted Computing Base, you must reinstall and set the Install Trusted Computing Base option to YES. No checking is being performed. If you get other errors from the command, you will want to do one of the following: fix the problems circumvent the database disable the TCB (this option has not been not tested) In order to fix the problems, you must 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 method 1 or 2. 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 You can 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. You can 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 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, you need to 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, you need to 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: a.In normal mode, run lsdev -Cc adapter. Look for an entry such as: hiprfmge0 Available 00-03 High Performance 3D Color Graphics Processor b.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 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, you should verify the disk you booted from by using 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 5th 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: = 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 OLD 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. If you have any, especially in /tmp, you should 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, you should 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 filesystems are defaulted to the original values expected by the operating system. Make sure the mapping of logical volumes to filesystems 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. We do not know 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 filesystems 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 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 padstring:@%$| 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 wrong, you will need to 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. You can find this out 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. You can find this out by running lslv -m hd5. In order to migrate a system, do the following: 1.Boot in service mode from the V4 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. Don't 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 You should get 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 don't 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; you should 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 you have just migrated to: #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. ======================================================================