I am trying to install Oracle 10g clusterware on an RHEL4 Update2 server, but I get the following message "./runInstaller: line 58: /u01/clusterware/install/.oui: cannot execute binary file"

The server is 32-bit as well as the .oui file. I verified the cksum of the zip file against the oracle download site and that matches. I copied the zip file from the server to my laptop running Fedora and I was able to start the install.

Any ideas as to what the problem is?

Thanks,

Elliot

Make sure the .oui file has execute permissions for the user you're trying to start runInstaller under - to make it simple you could just make it executable for everyone. The message is saying it can't execute it.

Permissions was the first thing I checked when my DBA approached me with the problem. Permissions were set to 755 and oracle:dba owned the file. I tried to start the install as root and I received the same error message. I even tried 777, but the oracle user still can't execute the binary. I have seen a one or two postings about the same problem on other sites, but there was no posted resolution. Below is my "uname -a" output and we are using a recompiled kernel, which is normal for Polyserve.

2.6.9-22.EL-Poly #1 SMP Mon Aug 27 15:32:53 CDT 2007 i686 i686 i386 GNU/Linux

Thanks,

Elliot

Is it the Clusterware (CRS) you're trying to install? Is so it expects the group to be oinstall rather than dba.

In 10gR2 the Clusterware and the ASM and DB should have separate Oracle Homes. It wants the Clusterware oracle home owned by root and grouped to oinstall.

Ok, but the .oui file should still execute and report a problem, like it has done on a Centos 4.x server when I ran the install as root.

Is the partition that the oui file is being run from mounted with the exec option? If it's mounted noexec, you won't be able to run the executable. I've also had programs run in one location and try to run something from /tmp and die on my system (I also mount /tmp noexec) so if it's trying to do that it will also fail.

I was able to resolve the problem, thanks to your tip. Your tip wasn't exactly the problem, but it made me look at the mount point. The mount point was a symlink, which was causing the problem.

That's good news - and it's always more fun to solve it yourself