Announcement

Collapse
No announcement yet.

Error in MD5 checksums during installation

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error in MD5 checksums during installation

    I'm getting the following error when attempting to install uberSVN-32-1204.sh on a Linux box.

    Verifying archive integrity...Error in MD5 checksums: d41d8cd98f00b204e9800998ecf8427e is different from 85d339059d6b781cac668221d90ebebf
    I've downloaded the 32 and 64 bit installation files to my windows machine, then uploaded it to the Linux server using WinSCP. When uploading, I've used both Text and Binary upload (on separate occassions), but both the installation fails with in MD5 errors.

    Can anyone please help? Thanks.

    ~HP~

  • #2
    Hi there,

    That's a Linux install error rather than an uberSVN specific one. It usually happens when the download is interrupted or when the file is changed somehow while transferring. Assuming that downloading and installing straight onto the Linux box is a no-go please try again with a fresh download and transfer it as binary.

    Comment


    • #3
      That means the file was damaged somehow. Did you verify your download from www.ubersvn.com? We supply the sums on the download page for this reason.

      Comment


      • #4
        checksum confusion

        Originally posted by mbooth View Post
        That means the file was damaged somehow. Did you verify your download from www.ubersvn.com? We supply the sums on the download page for this reason.
        Checking the md5 sum of the 32-bit version gives the following result:
        md5sum ./uberSVN-32-1204.sh
        ecfd0d0e8632fa3e5e9ae4300b0becf0 ./uberSVN-32-1204.sh

        This is is the correct md5 checksum for this file.

        But running the shell file gives the following result:
        ./uberSVN-32-1204.sh
        Verifying archive integrity...Error in MD5 checksums: d41d8cd98f00b204e9800998ecf8427e is different from 85d339059d6b781cac668221d90ebebf

        So, it looks like the MD5 variable in the .sh shell file is different from the md5sum from the command line and the one posted on the website, and different from whatever it's comparing it to during program run.

        I'm downloading it to my windows machine, then uploading it in binary mode to my linux box. What's going on?

        Thanks again.

        Comment


        • #5
          Hi diamondonwheels,

          After some investigation it looks like a potential issue with the mirror you're being automatically directed to.

          Whilst we investigate further, you could download via http://download.nl.eu.ubersvn.com/uberSVN-32-1204.sh.


          Thanks

          Wayne

          Comment


          • #6
            Still the same problem:

            I downloaded it using wget.
            Checked the md5sum:
            md5sum uberSVN-32-1204.sh
            ecfd0d0e8632fa3e5e9ae4300b0becf0 uberSVN-32-1204.sh

            Executing the script:
            ./uberSVN-32-1204.sh
            Verifying archive integrity...Error in MD5 checksums: d41d8cd98f00b204e9800998ecf8427e is different from 85d339059d6b781cac668221d90ebebf

            Hope you can help. Thanks.

            Comment


            • #7
              I've just downloaded that file using the same link, to my Windows desktop to make sure it still successfully passes MD5 against ecfd0d0e8632fa3e5e9ae4300b0becf0. It does. I then FTP'd the file over to my 32bit Linux environment and again ran an MD5 check. It returns ecfd0d0e8632fa3e5e9ae4300b0becf0, as I'd expect. Up to this point, we appear to be in tandem with our experiences.

              I then kicked off the installation, via Scientific Linux 32bit which decompresses and begins as expected without any MD5 issues. This would appear to be the point where our experiences diverge.

              At this stage, I'm not sure what else to suggest. What OS are you running on?

              Comment


              • #8
                I'm running Linux, CentOS:
                CentOS release 4.9 (Final)


                I've given up on this for now and will pay my isp to install it for me.

                Thanks anyway.

                Comment


                • #9
                  I'm sorry that you haven't been able to get the product up and running, diamondwheels. We've done a fair amount testing on this side, since you first reported the problem and for the life of us we're unable to reproduce it. As I said earlier in the thread, we did have some issues with MD5 sums on the Japanese mirror but they were quickly addressed.

                  What I would say is that I don't know how your ISP will be able to assist, as you've already confirmed that the installer package is coming down with the correct MD5 shown. It's only when executing the installer that the MD5 is then failing, so I'd be surprised if your ISP will be able to get you into a better position.

                  Do you have the ability to try a different Linux version? Fedora, Unbuntu, etc? Maybe even a more recent version of CentOS? ATM, the only differentiators that I see are...

                  1) Your net connection
                  2) Your OS (CentOS 4.9 32bit)
                  3) Your OS host (hardware)

                  The main items being raised as potential culprits ATM are...

                  1) File corruption
                  2) Hardware fault (memory)
                  3) OS version incompatibility

                  So if we can eliminate as many of these as possible, that will really help to narrow the field. I'm currently looking for a CentOS 4.9 32bit environment.
                  Last edited by wmellors; 07-10-2012, 10:03 AM.

                  Comment


                  • #10
                    Hi again,

                    I've just completed a CentOS 4.9 32bit install (4.8 > 4.9 upgrade) and still can't reproduce the issue you're seeing.

                    I've also used WinSCP to copy the file over and found that whilst using the 'default' setting resulted in an incorrect MD5, using the 'binary' setting did work and the installer executes without any MD5 problems.

                    Can you confirm that you definitely set the WinSCP copy to use the binary option, as per your first post? Sorry to ask, given you've already stated that you did but this is the only scenario I can get into whereby the MD5 does't match (although that's also in an outright MD5 check, as opposed to only seeing the issue after running the script).

                    Just one more observation, it's interesting that the MD5 check is failing on your installation attempt with exactly the same, incorrect MD5 results via two separate downloads of the installer..

                    Verifying archive integrity...Error in MD5 checksums: d41d8cd98f00b204e9800998ecf8427e is different from 85d339059d6b781cac668221d90ebebf. That this incorrect MD5 is consistently being reported is interesting, because if there was some variance in your system, such as faulty RAM for example I'd expect this to differ on each download/execute attempt. Could it be an issue with WinSCP? Have you tried to use a different client, such as Filezilla to transfer over? Just to confirm, did you wget from the CentOS box directly, on your second attempt? Also, is there any possibility you can try to download the installer via a completely different net connection? Perhaps a home one?

                    Also, just to explain the 'correct' MD5 variances you're seeing..

                    85d339059d6b781cac668221d90ebebf is correct as per the header of the script inside the package, against the binary contents of the package. If you open the installer in an editor, you can see this. It explains why the installer will throw a different MD5 mismatch compared to the full installer MD5 below.

                    ecfd0d0e8632fa3e5e9ae4300b0becf0 is correct against the full installer script, as per our website and a terminal-level MD5 check.


                    Thanks

                    Wayne
                    Last edited by wmellors; 07-10-2012, 05:11 PM.

                    Comment

                    Working...
                    X