Howdy
I have seen that same problem, with that same version of the java rpms. In
our case it ended up being that the metadata didn't match the filename:
The RPM's internal "Name" tag is different from the filename, so the rpmdb
knows it as "jdk-1.6.0_23-fcs.x86_64", which is not the filename. The chef
yum provider, iirc, is looking in the RPM database for the package using a
parse of the filename, so it looks like "jdk-6u23-linux-x64" isn't
installed. They're not even similar enough to assume that
"jdk-1.6.0_23-fcs" and "jdk-6u23" are the same; the "fcs" can't be assumed
to be insignificant.
So Chef tries to install it, and when RPM gets a look at the file, it reads
the internal "Name" from the metadata and errors out with the "already
installed" message.
On the machines that are throwing that error, you should see the jdk
package already installed if you query the rpmdb. If you use "yum install
/path/to/filename" rather than the "localinstall" subcommand to yum, you
should get a line that starts with "Examining /path/to/filename:
package.x86_64" that will tell you what the package actually contains. I
don't know why "localinstall" suppresses that information.
I fixed this on our systems at the time by changing the name of the rpm in
our yum repos to match what the rpm had in its metadata as the package
name, "jdk-1.6.0_23-fcs.x86_64.rpm". If you're downloading to local cache
on your systems, that might be a quick fix for you, too. I didn't do any
lengthy research into wtf had happened there, so I don't know if there was
some reason upstream or it was just sloppiness.
HTH,
--mandi
On Wed, Jan 25, 2012 at 5:07 PM, bjbq4d@gmail.com wrote:
I have written a simple cookbook to install Sun's JDK via RPM. Once in a
while
I get support questions about it failing during the install process of the
package.
The error is,
{
FATAL: Chef::Exceptions::Exec: package[jdk-6u23-linux-x64.rpm]
(sun_java::default line 23) had an error: yum -d0 -e0 -y --nogpgcheck
localinstall /var/cache/chef/jdk-6u23-linux-x64.rpm returned 1, expected 0
}
When they run the command they see,
{
yum -d0 -e0 -y --nogpgcheck localinstall
/var/cache/chef/jdk-6u23-linux-x64.rpm
This system is not registered with RHN.
RHN support will be disabled.
Transaction Check Error:
package jdk-1.6.0_23-fcs.x86_64 is already installed
}
Which is actually the same exact package they are trying to install. I am
guessing this is an issue with the build/packaging of the rpms being
different.
Has anyone seen this or have any ideas how to fix/avoid this? The easiest
option I could think of is to add a 'not_if' option to the package and to
grep
the output of 'java -version' for the correct version, but I don't like
that
idea since the package resource should handle it.
Here is the resource in question,
{
package javaRPM do
action :install
source "#{Chef::Config[:file_cache_path]}/#{javaRPM}"
options "--nogpgcheck" # sun/oracle doesn't sign their RPMs o_O
notifies :run, "bash[update-alternatives java]", :immediately
end
}