I get this message over and over and over and over and . . . . and over again at CM tries download the CDH parcel over and over and over and over and . . . and over again. CM 5.2 on CentOS 6.3. Death loop. Will not end. Will not die. COMPLETELY uninstalled and reinstalled CM with the same results. HELP!!!!!
Hi, I've not seen this specific behavior but we'll be happy to help you sort it out. Can you share a few of the lines of the error (from cloudera-scm-agent.log and/or cloudera-scm-server.log) or perhaps screenshots from the Cloudera Manager UI > Parcels distribution page? Thanks.
I've set up a fresh cluster on CentOS 6.3 and CM 5.2, then downloaded/distributed/unpacked CDH 5.2.1 parcel. I did not meet with any hash verification errors.
In your case, are you letting Cloudera Manager fetch CDH 5.2.1 from
or have you mirrored it internally, for example, and are providing it from a known location?
In the end, the simplest check here is probably to find the parcel in two places on your system, and manually collect a sha1sum of the .parcel file.
The checksum of
Find this file
- on the node that runs the Cloudera Manager Server, look in /opt/cloudera/parcel-repo/ and find the file. Run
[root@mynode-1 parcel-repo]# sha1sum CDH-5.2.1-1.cdh5.2.1.p0.12-el6.parcel
Note that in my example here, the parcel's checksum matches the published checksum from the manifest.json in http://archive-primary.cloudera.com/cdh5/parcels/latest/manifest.json. So this is good.
Once you click Distribute / Activate to send this parcel over to your agent nodes, this file is downloaded from the CM Server node to each agent and placed in /opt/cloudera/parcel-cache. Find the .parcel file here and sha1sum it again. The checksum must match.
If either of these locations does not have this checksum, and they are not identical at each step, then something has altered or corrupted the file in transit at some phase.
Gosh, I tried so many things my head is spinning. Most importantly I downloaded the .parcel and .parcel.sha1 from archive.cloudera.com and the CM installer happpily ignored it and kept its download loop going. One thing is a wee bit confusing -- on archive.cloudera.com the hash file is a 41 byte .sha1 file while the CM installer seems to have downloaded a 42 byte .sha file. Not sure what the installer is looking for.
Also, before all of this, I had to MANUALLY install Java 1.7 as the installer.bin just crapped out there. That seemed to (finally) allow CM to install, but then this parcel-of-death loop thingy.
BTW, I'm kind of locked into this -- whenever I log into CM at ...:7180 it jumps to the "downloading parcels" panel. And death ensues . . .
So, trying to move on, I just created a new 6-node CentOS 6.6 cluster with a minimal "expert text" install. The cloudera-manager-installer.bin AGAIN craps out on the Java install. I can't give you the exact contents of the log file right now, but along the lines of (hoping for no typos):
http://archive.cloudera.com/cm5/redhat/6/x86_64/cm/5/RPMS/x86_64/oracle-j2sdk1.7-1.7.0%2Bupdate67-1.... [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=cloudera-manager clean metadata
Trying other mirror.
Error Downloading Packages:
oracle-j2sdk1.7-1.7.0+update67-1.x85_64: failure: RPMS/x86_64/oracle-j2sdk1.7-1.7.0+update67-1.x86_64.rpm from cloudera-manager: [Errno 256] No more mirrors to try.
I FEAR manually installing Java 1.7 on this machine because it will result in loading something like 30 more packages. If these are prerequisites for CM then why doesn't the installer say so? This Java 1.7 update 67 thing has been BRUTAL!!!!!
Running sha1sum on the downloaded parcel (CDH-5.2.1-1.cdh5.2.1.p0.12-el6.parcel yields:
So there IS a hash verification problem!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Okay, I have confirmed that the .parcel file is somehow being clobbered on the way down. I have used wget to retrieve CDH-5.2.1-1.cdh5.2.1.p0.12-el6.parcel several times and each time the file size is correct but running sha1sum on the downloaded file yeilds a different result (different from both the .sha1 file AND each other).
So, I am doing all of this on a CentOS 6.6 machine that is running in a Hyper-V cluster on a Windows Server 2008 R2 host (please spare me the boos and hisses -- it's what I have to work with! :-)).
What is the CM parcel download web site using to download the parcel (i.e., is it using wget or curl or ftp or . . . internally) and where is it downloading from (i.e., from archive.clooudera.com or archive-primary.cloudera.com or . . .)?
BTW, this is the very issue that prompted me to create the CentOS 6.6 cluster. I originally had a CentOS 6.2 cluster that was promoted to 6.3 via updates that had the same behavior.
Finally, is anyone aware of a mechanism whereby these downloads can become so corrupted? I am really stumped by all of this . . .
I solved my problem by equating the keys of manifest.json files and CH-version.sha1:
$ sha1sum CDH-5.3.3-1.cdh5.3.3.p0.5-el6.parcel
Take this result and put in .sha1 file
Then do the same with the manifest.json file in the "hash"
Remember: In manifest.json file has more than one hash line. You need to replace the line that matches the operating system being used.
Sorry about my english writing, I am Brazilian and I am studying English