Installing Oracle E-Business Suite 11.5.10.2 on Oracle Enterprise Linux 5 update 1

Oracle recently announced certification
for E-Business Suite 11i on Oracle Enterprise Linux 5

So, today I gave it a try, together with a colleague.

The requirements for installing
E-Business Suite on OEL5 can be found in Metalink Note 316806.1

Basically this was the note I followed.

We set up a Virtual Machine running OEL5
– Update 1, and applied all the prerequisites mentioned in the
Installation Update Notes (Metalink Note 316806.1)

After installation of OEL, the
following packages were downloaded from
http://oss.oracle.com/projects/compat-oracle/files/Enterprise_Linux/

• compat-libstdc++-egcs-1.1.2-1

• compat-libcwait-2.1-1

• compat-oracle-el5-1.0-5

• openmotif21-2.1.30-11.EL5

• binutils-2.15

Under “Setting the environment”,
bullet 2 there is an instruction to modify ld. Because there was an
existing ld binary, we decided to backup this one and then create the
symbolic link.

# mv /usr/bin/ld /usr/bin/ld.org
# ln -s /usr/bin/ld215 /usr/bin/ld

We were then instructed to download and
apply the OS library patch 6078836 from OracleMetaLink and
create the following symbolic link (the patch will instruct you to
copy libdb.so.2 to /usr/lib only):

# ln -s /usr/lib/libdb.so.2 /usr/lib/libdb.so.3

After this, things became rather
interesting…

(Quote from the Installation Update
Notes:)

For Oracle
Enterprise Linux 5, Red Hat Enterprise Linux 5 and SUSE Linux
Enterprise Server 10 customers, the LD_ASSUME_KERNEL environment
variable should be unset before starting the installation. The
installation fails when the LD_ASSUME_KERNEL variable is set by the
adgetlnxver.sh file during the course of the installation.

Patch 6365595
contains the fix for adgetlnxver.sh file. The below mentioned
procedure is a guideline for replacing the adgetlnxver.sh file in the
Oracle Applications 11i shiphome.

1. Download the patch 6365595 from OracleMetalink.
2. Follow the Oracle
   Applications Installation guide and set up the stage area.
3. Set the STAGE_TOP environment variable to the top level
   directory of the stage area that contains the subdirectories
   startCD, oraApps, oraDB, oraiAS and oraAppDB. Make sure that the
   stage area is read writable.
4. Create the following directories in the stage area.
   #
   mkdir -p $STAGE_TOP/oraDB/Disk3/db/stage/appsutil/bin
   # mkdir -p
   $STAGE_TOP/oraApps/Disk5/app/l/stage/bin
5. Copy the adgetlnxver.sh file in the patch 6365595 to the
   following directories created in earlier step.
   # cp -p
   6365595_PATCH_TOP/ad/bin/adgetlnxver.sh
   $STAGE_TOP/oraDB/Disk3/db/stage/appsutil/bin
   # cp -p
   6365595_PATCH_TOP/ad/bin/adgetlnxver.sh
   $STAGE_TOP/oraApps/Disk5/appl/stage/bin
6. Update the zip archive with the fix (adgetlnxver.sh file).
   #
   cd $STAGE_TOP/oraDB/Disk3/db/stage
   # zip -u dboh0_appsutil
   appsutil/bin/adgetlnxver.sh
   # cd
   $STAGE_TOP/oraApps/Disk5/appl/stage
   # zip -u ad_CORE0
   bin/adgetlnxver.sh

(End Quote)

When we applied the above instructions,
we found out that $STAGE_TOP/oraDB/Disk3/db/stage/dboh0_appsutil.zip
could not be modified this way. Somehow, zip -u wouldn’t update the
zip file. Instead, we unzipped this file into a different location,
copied the patched adgetlnxver.sh into its appropriate location, and
zipped the directory structure using zip -r and put the new zip file
back into place. ad_CORE0.zip didn’t report any problems. It just
told us that adgetlnxver.sh was added to the archive (with 79%
compression).

Having completed all of the remaining
pre-installation activities, we fired off rapidwiz.

Rapidwiz reported problems on the
system utilities check: PD KSH wasn’t found. I couldn’t find it on
the OEL Cd’s, so I just ignored the warning (found some post on otn
forums that it could be safely ignored…) and started the
installation. It went on fine, until the Post Install Checks were
performed.

The Post install checks failed for DBC
file, HTTP, JSP and PHP. Apparently the DBC hadn’t been created,
HTTP, JSP and PHP failing subsequently.

We opened a terminal and started
investigating. First, we sourced the Applications Tier environment
file. Funny enough, after sourcing this file, we weren’t able to do
much more than change directories. Commands like ls, ps, etc. simply
didn’t work anymore, because of missing libraries (librt.so.1,
libdl.so.2, etc). We got the feeling that somehow, LD_ASSUME_KERNEL
was being set, even though we applied the patched version of it to
the zipfiles in the stage area of 11i before starting the
installation. Sourcing the environment file once again and issuing

$unset LD_ASSUME_KERNEL

we were able again to do ls, ps, etc.
Apparently, LD_ASSUME_KERNEL was being set after all…

Then, we found out that
$AD_TOP/bin/adgetlnxver.sh was the original (unpatched) version. We
copied the file from the patch once again, this time straight into
$AD_TOP/bin, and ran autoconfig again (we tried this earlier with
errors as a result). This worked. Autoconfig completed successfully.

We restarted the application processes
using adstrtal.sh and ran the Post Install Checks by rapidwiz once
more. This time everything checked OK.

Now, we have to upgrade our database to
10G Release 2, because 9i is not supported on OEL5.

We will be busy for a while…