Dealing with checksum mismatch: Difference between revisions
No edit summary |
PaulEggleton (talk | contribs) No edit summary |
||
| (One intermediate revision by the same user 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. This is a | It happens occasionally that incorrect SRC_URI 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 potentially serious issue and it is important to resolve the situation with care. | ||
Firstly, try a bitbake xxxx -c cleanall and try | Firstly, try a bitbake xxxx -c cleanall and try re-fetching 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 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 identified 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 | 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 proceed. | ||
Above all, the most important thing is '''not''' to just blindly change the checksum to the current matching value without understanding why the change has occurred - if you do you could then be using source code which has been tampered with as part of your build. | |||
[[Category:Policy]] | [[Category:Policy]] | ||
[[Category:FAQ]] | [[Category:FAQ]] | ||
Latest revision as of 12:05, 18 February 2013
It happens occasionally that incorrect SRC_URI 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 potentially serious issue and it is important to resolve the situation with care.
Firstly, try a bitbake xxxx -c cleanall and try re-fetching 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 identified 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 proceed.
Above all, the most important thing is not to just blindly change the checksum to the current matching value without understanding why the change has occurred - if you do you could then be using source code which has been tampered with as part of your build.