Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Since yesterday, I'm getting this error in using drush make: "File drupal-7.22.tar.gz is corrupt (wrong md5 checksum)"
Drush version is 5.7. I also got a similar error with comment notify awhile back that my co-worker posted to their issue queue and got it for days, so we just commented that out of the profile for now.
Any ideas?
Comment | File | Size | Author |
---|---|---|---|
#21 | xml.diff | 1.49 KB | moshe weitzman |
Comments
Comment #1
evanmwillhite CreditAttribution: evanmwillhite commentedI just wanted to follow up and say I'm still getting this error, but running drush make with the option '--no-cache' solved it temporarily. So, I guess this is an issue with drush make storing incorrect info during a window of time when a new release is put out there? I want to leave the ticket open as it seems to me the fact that drush make references an incorrect checksum in the first place could still be a problem.
Comment #3
yuchuan1 CreditAttribution: yuchuan1 commentedThis happened to me this morning as well.
>> File file_entity-7.x-2.x-dev.tar.gz?date=1374367521 is corrupt [error]
(wrong md5 checksum)
'--no-cache' solved the issue.
However, after running drush make with no cache option, and run it the second time without no cache option, the issue came back.
Comment #4
ezra-g CreditAttribution: ezra-g commentedWe're experiencing this issue with an invalid checksum on the OG module as part of packaging the Commons distribution: #2047677: Unable to package Commons: invalid checksum on OG..
Comment #5
jgraham CreditAttribution: jgraham commentedExperiencing this same issue with running a local drush makefile. Cleared out ~/.drush/cache and ran with --no-cache. Problem persists.
Error below.
File file_entity-7.x-2.x-dev.tar.gz?date=1374454907 is corrupt (wrong md5 checksum).
file_entity has a dev release from today. I'm guessing this is likely a caching issue or a failure to rebuild/reset the XML at the correct time.
EDIT: As of Wed Jul 24 18:04:39 UTC 2013 XML at http://updates.drupal.org/release-history/file_entity/7.x indicates md5sum should be fbf654f4c6324e076586991cb36b9312 for http://ftp.drupal.org/files/projects/file_entity-7.x-2.x-dev.tar.gz, actual md5sum is bdd6d0fbfada75154fcf0ccad05e1456
Using --ignore-checksums and --force-complete flags are non-functional, checksums still checked build still fails. These details are likely drush issues, the bad checksum is d.o infrastructure.
Comment #6
ezra-g CreditAttribution: ezra-g commentedWe're experiencing this with the Commons nightly dev snapshot, this time with:
Comment #7
yuchuan1 CreditAttribution: yuchuan1 commentedI'm experiencing the following this morning.
It seems to be affecting most frequently with the dev modules.
I've used --no-cache option, but the error still occurs.
Comment #8
jlyon CreditAttribution: jlyon commentedI too was getting this error with any module I specified to use the -dev branch:
Building with the
--no-cache
option did fix the issue for me.Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedI'm seeing it too with the dev snapshot of Drupal 8.x. When I download that tarball and run md5_file() on it, I get checksum of
97545a881b63c7c16c48db35b79883a0
. The Update XML right now has different checksum. See the last [release] element:Comment #10
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI think the problem is that Moshe looked at the XML when Drupal-dev had already been recreated but the packaging job was still running and the XML wasn't rebuilt yet. The timestamp of his comment would support this. (roughly)
This is a problem, especially since the job regularly runs over 2 hours and sometimes it gets stuck and is killed after 4 with the XML in an undefined state.
However, it only affects dev releases.
If somebody wants to resolve this, function package_releases is your friend. It would probably suffice to move the XML rebuilding of packaged projects up a bit and not do a whole-sale XML rebuilding at the end. This would minimize the time gap.
Comment #11
moshe weitzman CreditAttribution: moshe weitzman commentedI am seeing same behavior right now. Is packaging running?
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commentedWhere is package_releases(). I'm looking in project but don't see it in 7.x-2.x
Comment #13
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedpackage-release-nodes.php
has the function.
http://ftp.drupal.org/files/projects/versioncontrol_project-6.x-2.x-dev....
and yes, packaging is running..
Comment #14
moshe weitzman CreditAttribution: moshe weitzman commentedI notice that this code has been ported to Drush in D7 as per #1800186: Update package-release-nodes.php to D7 in Drush. Yet I still see package-release-nodes.php in D7 so I'm confused about where to start for fixing this. Fix in D7 first? If so, what function?
Comment #15
attiks CreditAttribution: attiks commentedFacing the same problem with bootstrap theme and cer project
Comment #16
jblumenfeld CreditAttribution: jblumenfeld commentedSame here with job-scheduler module.
Comment #17
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedplease provide detailed info on how to reproduce the problem. The XML files are update regularly.
Comment #18
drummThey are all updated every 6 hours, so there is plenty of opportunity for them to get stale. Updating the release XML per-project as a queued operation.
Comment #19
moshe weitzman CreditAttribution: moshe weitzman commentedWould be great if someone could answer my question in #14. Thanks.
Comment #20
drummThe drush command, http://drupalcode.org/project/project.git/blob/refs/heads/7.x-2.x:/relea..., is the place to fix this.
Where do you see package-release-nodes.php now?
Comment #21
moshe weitzman CreditAttribution: moshe weitzman commentedAttached patch changes the meaning of release-package-run so that it both creates package files AND writes update XML. It does both jobs before moving on to the next project. I don't know how these commands are scheduled on drupal.org, so this might not be the optimal fix.
I also removed some redundant help.
Comment #22
drummCommitted http://drupalcode.org/project/project.git/commit/2b588e2 and deploying.
As a follow-up, we need to make the
if (is_null($project_id))
code path optional, and not do it unless you specified --all on the command line. We no longer need or want to regenerate all history every 6 hours.Comment #23
moshe weitzman CreditAttribution: moshe weitzman commentedFor anyone listening here, there are also upgrade related problems with dev snapshots. While the bug here is fixed, we won't see the benefit until we make progress at #2132659: [META] Problems with Project Release Packaging
Comment #24
AlfTheCat CreditAttribution: AlfTheCat commentedI'm having this issue too, all of a sudden. A previously working makefile is now not downloading any of the dev releases anymore.
The issue mentioned in #23 is marked as fixed, what is the guidance on this issue now? I'm running Aegir and with this issue in place the platform creation workflow, which is a very important part, is basically broken.
Comment #25
dsnopek@AlfTheCat: This could also just be your Drush cache getting corrupt. Try deleting the specific cached files (or even the whole cache) from ~/.drush/cache/download (where ~ is probably /var/aegir for Aegir).
Comment #26
geerlingguy CreditAttribution: geerlingguy commentedInstalling drush via git (master branch/HEAD), on a fresh new server, and running
drush dl drupal-8.x
, gives me this error:This same command did work on Monday, but hasn't been working tonight, and I'm guessing it's because the XML is out of sync with the actual release tarballs, correct? Using the
--no-cache
option did work. Weird.Comment #27
ar-jan CreditAttribution: ar-jan commentedI'm having this issue as well on the -dev release of views_matrix.
md5sum according to https://www.drupal.org/node/1784126/release:
views_matrix-7.x-1.x-dev.tar.gz 11.27 KB f6ef645f48cbcd91e2ee5d889de5d0f4
This has been the case for the last two months (see #2411559), so it's not a matter of a temporary gap between build/release info.
Comment #28
drummI repackaged views_matrix and the downloaded file and Drupal.org page are now in sync.
Comment #29
ar-jan CreditAttribution: ar-jan commentedThanks @drumm!
Comment #30
ar-jan CreditAttribution: ar-jan commentedHere's another one I just encountered:
File node_clone-7.x-1.x-dev.tar.gz_date=1416365880 is corrupt (wrong md5 checksum)
.Comment #31
drummI repackaged node_clone and the downloaded file and Drupal.org page are now in sync.
Comment #32
JulienF CreditAttribution: JulienF commentedI'm having the same issue under Drush 6.6 for entitycache 1.2 on my development environment.
the --no-cache option doesn't help
I even tried with drush 7 since this is the version used on my live environment and it still doesn't work locally, yet it works on the live environment...
Difference between drush 6 and 7 is that with version 7 the drupal folder gets created by the entitycache module isn't downloaded... I'm not sure this is the behaviour it should have (but this is probably another issue)
Any idea ?
Comment #33
drummMatches https://www.drupal.org/node/2124735 & http://updates.drupal.org/release-history/entitycache/7.x
Can you post the file you get instead when downloading http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz? What IP does
ftp.drupal.org
resolve to for you?Comment #34
JulienF CreditAttribution: JulienF commentedThe file was stored as temp file, so I need to re-run the whole drush make command in debug mode to get its path etc...
So before going into this hassle I've just run the same command as you did and here is the result I have (different from yours):
As you can see, the IP is different and the Hash is different...
Out of curiosity I tried on a different machine under the same network and I'm getting the same result.
Any Idea on why ? and most importantly how to fix that ?
Thanks
Comment #35
drumm185.31.17.249 is a Fastly IP, which is good. However, the point of presence you are hitting is serving a cached error message:
Comment #36
basic CreditAttribution: basic at Drupal Association commentedI've opened a ticket with Fastly. I'll let you know when we've resolved the issues. Thanks for providing the debug information, it should make troubleshooting this straight forward.
Comment #37
basic CreditAttribution: basic at Drupal Association commentedI believe we've found a solution to the problem (503 errors were being returned as 200 status instead -- and probably caching because of this).
I've updated our custom VCL with Fastly, and purged the file in question. I'm curious if there are any other files which may be invalid in our cache, please report any you find.
To purge the file after this change, I ran the following from our infrastructure:
Comment #38
basic CreditAttribution: basic at Drupal Association commentedComment #39
JulienF CreditAttribution: JulienF commentedHello,
I've tried again on the same machine (under the same network, yet the network doesn't have a fixed IP). here is what I'm getting now:
I see no particular error, the IP is not the same now (different from the one drumm had and different from the one I initially had yet the hash is still equal to the one I had with the previous fastly IP which is not the one I should obtain.
Comment #40
drumm23.235.43.249 is also run by Fastly, the CDN we use for ftp.drupal.org, so that is okay. However, when I try that IP, I get the correct file now:
Comment #41
JulienF CreditAttribution: JulienF commentedWell I just tried again, and got served back by the other fastly IP... yet the hash is still the wrong dcec01864f86809d86b8399e11259ca3 one...
After I scratched my head a little bit, I decided to not pipe the result to md5 directly and split the task... great Idea I had... here is the return I'm getting!
<!DOCTYPE html>Our servers are busy, please retry in a few minutes!</html>
Now the question is why am I constantly getting this return instead of being server with the file ?
In case someone has access to some logs, here is my current IP address: 37.209.253.48 Since I'm sitting on a dynamic IP address it is also important to note that I just run a test like now:
4:04 PM
Monday, April 13, 2015
Greenwich Mean Time (GMT)
Thanks ahead for the help!
Comment #42
basic CreditAttribution: basic at Drupal Association commentedI see in our log files:
You're getting a response of 304 Not Modified -- if you tell your browser to empty caches, or try a private browsing / incognito window do you get a real file?
Comment #43
JulienF CreditAttribution: JulienF commentedWell I'm using curl to run those tests and the other case is that this file is being downloaded by drush make, in both cases it doesn't work... I tried to remove the temp file downloaded by drush but it keeps on failing at the md5 checksum check.
Any idea on how could I clear that cache on the terminal ?
Thanks
Comment #44
basic CreditAttribution: basic at Drupal Association commented@JulienF
Can you please paste new output you're receiving from running
curl -v http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz | md5
Comment #45
JulienF CreditAttribution: JulienF commentedhere you go:
curl -v http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz | md5
* Hostname was NOT found in DNS cache
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0* Trying 185.31.17.249...
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0* Connected to ftp.drupal.org (185.31.17.249) port 80 (#0)
> GET /files/projects/entitycache-7.x-1.2.tar.gz HTTP/1.1
> User-Agent: curl/7.37.1
> Host: ftp.drupal.org
> Accept: */*
>
< HTTP/1.1 200 OK
* Server nginx/1.6.0 is not blacklisted
< Server: nginx/1.6.0
< Content-Type: application/octet-stream
< Last-Modified: Thu, 31 Oct 2013 10:55:26 GMT
< ETag: "5272371e-38df"
< Via: 1.1 varnish
< Accept-Ranges: bytes
< Date: Wed, 22 Apr 2015 19:08:27 GMT
< Via: 1.1 varnish
< X-Served-By: cache-sea1922-SEA, cache-fra1246-FRA
< X-Cache: HIT, HIT
< X-Cache-Hits: 2, 8
< X-Timer: S1429729707.337656,VS0,VE0
< X-CFLO-Cache-Result: TCP_MISS
< Content-Length: 14559
< Connection: Keep-Alive
< Age: 1102352
<
{ [data not shown]
100 14559 100 14559 0 0 3707 0 0:00:03 0:00:03 --:--:-- 3706
* Connection #0 to host ftp.drupal.org left intact
6690a64a90a057a5233121d998edd977
It seems its good now!
I've also run a drush make and it ran smoothly.
I know that things are good now but i'm the kind who likes to understand, can I know what was wrong and what solved it ?
Thanks a lot for your help!
Comment #46
basic CreditAttribution: basic at Drupal Association commentedOur FTP content distribution network (Fastly) is configured in a way that minimizes the connections to our origin servers. This works something like this:
Fastly, our CDN, is a giant distributed Varnish server, and we had some example VCL configuration which would rewrite "503 Service Unavailable" errors into a 200 response with the text "Our servers are busy, please retry in a few minutes!".
Since we're using the Origin Shield, our VCL is executed both at the fastly pop closest to you, and at the fastly origin shield pop. If the fastly origin shield pop was unable to retrieve from ftp.drupal.org it would rewrite the error into the 200 "Our servers are busy, please retry in a few minutes!" and the fastly pop closest to you would cache that errored response.
We worked with Fastly support to confirm this behavior, and their engineers have removed that example VCL from their documentation. Removing the VCL code which was causing the "Our servers are busy, please retry in a few minutes!" response to be cached, and clearing the cache, fixed the entitycache-7.x-1.2.tar.gz download.
Comment #47
JulienF CreditAttribution: JulienF commentedThanks for the detailed explanation. Things are clear and in case I encounter this error again I'll know what to dig for first ;-)
Best,
Comment #48
basic CreditAttribution: basic at Drupal Association commentedI believe this was fixed in the last update
Comment #49
sobi3ch CreditAttribution: sobi3ch commentedI don't know is this related but couldn't find better issue. Try to update using drush 6.6 and 6.5.
I couldn't update Drupal core nor jquery_update
Update information last refreshed: Thu, 06/18/2015 - 14:54
Name Installed Version Proposed version Message
Drupal 7.37 7.38 SECURITY UPDATE available
Comment #50
basic CreditAttribution: basic at Drupal Association commented@sobi3ch: this appears to be a permissions issue. If i'm reading the Drush output correctly, "md5_file(/var/www/vhosts/etcc.pl/drupal-7.38.tar.gz): failed to open stream: Permission denied" is saying the md5 checksum function is unable to open the file to validate the checksum on it, which causes drush to think the file has the wrong checksum.
The file only has the wrong checksum in this case because Drush cannot calculate its checksum at all.
If you 'wget http://ftp.drupal.org/files/projects/drupal-7.38.tar.gz' I imagine this file downloads cleanly?
Comment #51
sobi3ch CreditAttribution: sobi3ch as a volunteer commentedHi @basic, thanks for explanation I don't know I didn't notice permission problem.
Comment #53
ressa CreditAttribution: ressa as a volunteer commentedI got this message while trying to download migrate_plus:
I tried again after a few minutes, and now it works fine.
Comment #54
leopathu CreditAttribution: leopathu as a volunteer and at Quilltez for Dofinity commentedActually, just delete the drupal site folder under the drush-backups folder. and try again the update. it might solve the issue