Difference between revisions of "Dealing with checksum mismatch"

From Openembedded.org
Jump to: navigation, search
m (Update checksums.ini moved to Dealing with checksum mismatch: Content was not in line with title.)
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
It happens that incorrect checksums are being committed or that upstream changes tarballs without changing the filename.  In both cases, OE will bail out and complain about a mismatch in checksums. Here are the steps a developer should take to resolve the issue safely.
+
It happens that incorrect checksums are being committed or that upstream changes tarballs without changing the filename.  In both cases, OE will bail out and complain about a mismatch in checksums. This is a potentialy serious issue and it is important to resolve the siutation with care.
  
* Look through "''mtn --diffs --no-merges log conf/checksums.ini| less''" and find the person who committed the current md5sum.
+
Firstly, try a bitbake xxxx -c cleanall and try refetching the download to ensure this wasn't just a bad download. If it continues to fail, post on the mailing list for the layer concerned and ask whether others are seeing the issue. It can also be worth downloading the file externally from bitbake/OE to confirm its not a fetcher issue.
* Contact them and ask them to md5sum their copy again. Compare results if they still have the '''original''' tar file against which the original checksum was generated.
+
  
Then we have three possible scenarios.   
+
If there is some mirror with a bad file on it, that file can be removed and a request needs to be made to the maintainer of the mirror serverIf the original commit was made with an incorrect checksum, this can also generally easily be indetified and corrected.
  
# the original committer does not have the original file anymore or is unsure about its integrity.  In that case, please write to openembedded-devel@lists.linuxtogo.org.  Don't do anything further.
+
If upstream itself has changed the tarball, this is a much more problematic situation and we need to understand why this has happened, what the change is and then made a decision on how to proceeed.
# the original committer generates the same md5sum as you, indicating an error in the original commit.  In this case we can safely commit the update.  Indicate in your commit message that yours and the other person's md5sum matched
+
# the numbers don't match. Then we need to consult upstream and ask if they changed the tarball. Sadly this is something that commonly happens.  After confirmation from upstream we can update checksums.ini.
+
  
 
[[Category:Policy]]
 
[[Category:Policy]]
 +
[[Category:FAQ]]

Revision as of 10:49, 7 November 2012

It happens that incorrect checksums are being committed or that upstream changes tarballs without changing the filename. In both cases, OE will bail out and complain about a mismatch in checksums. This is a potentialy serious issue and it is important to resolve the siutation with care.

Firstly, try a bitbake xxxx -c cleanall and try refetching the download to ensure this wasn't just a bad download. If it continues to fail, post on the mailing list for the layer concerned and ask whether others are seeing the issue. It can also be worth downloading the file externally from bitbake/OE to confirm its not a fetcher issue.

If there is some mirror with a bad file on it, that file can be removed and a request needs to be made to the maintainer of the mirror server. If the original commit was made with an incorrect checksum, this can also generally easily be indetified and corrected.

If upstream itself has changed the tarball, this is a much more problematic situation and we need to understand why this has happened, what the change is and then made a decision on how to proceeed.

Personal tools
Namespaces

Variants
Actions
Navigation
Categories
OE services
Toolbox