MD5 check of stochastic_full.bank failed

Bowie Wu
Bowie Wu
Joined: 25 Aug 13
Posts: 3
Credit: 8271534
RAC: 1098
Topic 227809

I tried to set up Einstein@home on my raspberry pi, but all WUs' downloads failed. After checking the log, similar to https://einsteinathome.org/content/md5-check-failed-1, the log showed that MD5 check failed for stochastic_full.bank, expected d41d8cd98f00b204e9800998ecf8427e. But this MD5 code seems to be an empty file. After editing the MD5 in client_state.xml, WUs were downloaded successfully. Is this due to something wrong in the server?

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5872
Credit: 117518133587
RAC: 35364125

Thanks for the link to the

Thanks for the link to the similar situation back in 2017.  I've sent a message to Project staff.

Hopefully it will get corrected quickly once they get the report.

Cheers,
Gary.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4312
Credit: 250412263
RAC: 35028

Thanks for the note!I

Thanks for the note!

I fixed the problem in the workunits in the DB. Tasks that are generated now from these workunits should not have this problem anymore. There's not much I can do about the tasks that were already sent.

Indeed the problem is similar to that in the thread you cited, a file that is shared/handled by two workunit generators for two similar applications. In the previous case it was "JPLEPH.405", which is used for both FGRP apps and respective workunit generators. In the current case it's "stochastic_full.bank", which is used for both BRP4 and BRP4G. For FGRP we fixed that by using different download servers for the two Apps. Unfortunately this won't work for BRP4(G). I turned off BRP4 workunit generation until I have a reliable solution for this problem.

Thanks again for the report!

BM

Bowie Wu
Bowie Wu
Joined: 25 Aug 13
Posts: 3
Credit: 8271534
RAC: 1098

Thanks for your

Thanks for your explanation!

 

Cheers

ScienceGizmo
ScienceGizmo
Joined: 10 Dec 20
Posts: 3
Credit: 28291393
RAC: 76

Hi, I joined my rpi to

Hi,

I joined my rpi to this project yesterday and noticed that I'm getting the same error as the OP. I thought I would try their fix of editing client_state.xml however I cannot locate anywhere that the expected checksum is and the only references I have to stochastic_full.bank is the errors mentioned in the event log and in sched_request_einstien.phys.uwm.edu.xml.

 

Any hints on how I may resolve the checksum errors would be appreciated.

ScienceGizmo
ScienceGizmo
Joined: 10 Dec 20
Posts: 3
Credit: 28291393
RAC: 76

So I resolved this and I

So I resolved this and I figured I'd post how in case someone else comes looking...

When I looked at client_state.xml at first it did not have a reference to stochastic_full.bank. I finally did an update for the project and checked again. The event log showed the message:

Thu 21 Jul 00:09:49 2022 | Einstein@Home | [error] expected d41d8cd98f00b204e9800998ecf8427e, got ec76f47a1aef9674beb4768ce416f5c3

The client_state.xml file now had an entry for the stochastic_full.bank file:

<file>
    <name>stochastic_full.bank</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>0.000000</max_nbytes>
    <md5_cksum>d41d8cd98f00b204e9800998ecf8427e</md5_cksum>
    <status>1</status>
    <sticky/>
    <download_url>http://einstein6.aei.uni-hannover.de/EinsteinAtHome/download/330/stochastic_full.bank</download_url>
</file>

I then replaced the md5_cksum from the empty file md5 checksum to the "got" checksum from the error message above (ec76f47a1aef9674beb4768ce416f5c3). Restarted the boinc-client service and the file successfully downloaded. Here is the resulting event log entries:

Thu 21 Jul 15:33:38 2022 | Einstein@Home | Resetting file projects/einstein.phys.uwm.edu/stochastic_full.bank: md5 checksum failed for file
Thu 21 Jul 15:33:40 2022 | Einstein@Home | Started download of stochastic_full.bank
Thu 21 Jul 15:33:48 2022 | Einstein@Home | Finished download of stochastic_full.bank
 

Thanks to the OP and the other posting they linked to.

 

Cheers.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4312
Credit: 250412263
RAC: 35028

Thanks for reporting. It is

Thanks for reporting. It is alarming that this still happens. I thought I fixed it for good. I'll turn off BRP4 work generation until this has been analyzed and fixed.

BM

ScienceGizmo
ScienceGizmo
Joined: 10 Dec 20
Posts: 3
Credit: 28291393
RAC: 76

Unfortunate but I understand.

Unfortunate but I understand. If you get to the point that you want further testing done I'll gladly volunteer.

I think BRP4 is the only work you folks have for the RaspberryPi 4 is it not? 

Bowie Wu
Bowie Wu
Joined: 25 Aug 13
Posts: 3
Credit: 8271534
RAC: 1098

Sorry I just see your post.

Congratulations that you have solved problem by yourself! :) Actually at first I met same problems as you, which made me feel a little bit lost. And I solved the problem almost identically to what you have done. Thank you for posting your solution here. 

Oliver Behnke
Oliver Behnke
Moderator
Administrator
Joined: 4 Sep 07
Posts: 984
Credit: 25171376
RAC: 43

Bernd Machenschalk

Bernd Machenschalk wrote:

Thanks for reporting. It is alarming that this still happens. I thought I fixed it for good. I'll turn off BRP4 work generation until this has been analyzed and fixed.



Update: we analyzed and fixed the issue. BRP4 is enabled again and the work pool is full to the brim :)

Thanks for your patience,
Oliver

Einstein@Home Project

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.