I’m posting this because apparently it hasn’t happened to anyone else except me (heavens knows I searched for help!). The root cause certainly wasn’t obvious to me, so hopefully, this will help someone (maybe me, once I forget about it).
All I needed to do was install a default Oracle Database 11g R1 environment with a starter database for some experimentation. Seems simple.
I had archived a copy of linux_11gR1_database.zip from OTN, so I copied that to my Oracle Enterprise Linux 5 U1 virtual machine and unzipped it (no errors or warnings, mind you). I proceeded to launch the installer as the oracle user and it ran me through the 4-6 screens of questions, prerequisite checks, etc, then the summary screen and started installing. The progress bar on the first task (copying files or similar) quickly progressed to 38% and then stopped…forever (I waited an hour).
So, I checked logfiles…nothing. Checked CPU, memory, disk activity…system (VM) was completely idle. So, I killed it and relaunched. Ran through the same screens, but this time once the progress meter started, I ran strace against the installer process (attached when progress was around 20%). Once it got to 38% again, I waited a little bit to ensure it was once again “stuck” and then stopped strace to review the log…nothing different at the start when compared to the end–all looked fine.
On a complete swag (sorry BAAG!), I found another copy of the linux_11gR1_database.zip file on one of the fileservers at the office (original one was from my laptop) and copied it in to the VM. I proceeded to unzip it, then follow the same exact steps to launch the installer, answer the questions, and proceed to the installation. It worked fine.
Now I need to know why these two were different. As many of you probably know, the unzip utility’s default behavior is to scroll a list of extracted files as it extracts them. This means there’s a ton of output (over 2900 lines) scrolling by faster than you can read them. This is the normal behavior and most people, like me, just enter the command and then check back in a few minutes to see the end of the output. In this case, I need to know if there was some error reported part way through the extraction. So, I unzipped it again, but redirected output to a logfile for review (
unzip linux_11gR1_database.zip > logfile.txt 2>&1). Reviewing that for the word “error” showed that several files (more than 8) were not decompressed properly due to some error condition. Further investigation of the unzip command syntax showed that the “
-q” flag will provide “quiet” output. I tried this and found that the “
-q” option does silence the normal verbose list of files shown by default, but still displays the error messages that would have been helpful to me.
Just for kicks, I tried unzipping the “bad” .zip file on my Mac (by double-clicking it which launches the Archiver utility) and it progressed about half way through and then threw an error and refused to continue.
The moral of the story is that from now on, I’ll always use “
alias unzip='unzip -q'” to ensure I see the errors without all the noise. It also makes you realize that OUI is not just a single binary, but is comprised of many libraries and files, so just because it launches doesn’t mean it has all the necessary files to complete its tasks.
Good news: I figured it out. Bad news: I lost too much time figuring it out. Happy Friday!