Dealing with checksum mismatch - Revision history

PaulEggleton at 12:05, 18 February 2013

2013-02-18T12:05:11Z

← Older revision		Revision as of 12:05, 18 February 2013
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 potentially serious issue and it is important to resolve the situation with care.		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.		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.

PaulEggleton: Fix typos; add reinforcing message at the end about just changing the value

2013-02-18T12:04:40Z

Fix typos; add reinforcing message at the end about just changing the value

← Older revision		Revision as of 12:04, 18 February 2013
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 ~~potentialy~~ serious issue and it is important to resolve the ~~siutation~~ with care.		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 potentially serious issue and it is important to resolve the situation 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.		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 ~~indetified~~ and corrected.		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 ~~proceeed~~.		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]]

Rpurdie at 10:49, 7 November 2012

2012-11-07T10:49:31Z

← Older revision		Revision as of 10:49, 7 November 2012
Line 1:		Line 1:
	~~{{Outdated}}~~		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.

	~~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 (unless OE_ALLOW_INSECURE_DOWNLOADS is enabled)~~. ~~Here are~~ the ~~steps~~ a ~~developer should take to resolve the~~ issue ~~safely~~.		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.

	* Look through "''mtn --diffs --no-merges log conf/checksums.ini\| less''" and ~~find~~ the ~~person who committed~~ the ~~current md5sum.~~		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.
	* 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 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 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.~~
	~~# 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]]		[[Category:FAQ]]

PaulEggleton at 16:28, 3 November 2012

2012-11-03T16:28:30Z

← Older revision		Revision as of 16:28, 3 November 2012
Line 1:		Line 1:
			{{Outdated}}

	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 (unless OE_ALLOW_INSECURE_DOWNLOADS is enabled). 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 (unless OE_ALLOW_INSECURE_DOWNLOADS is enabled). Here are the steps a developer should take to resolve the issue safely.

Eric: Undo revision 3298 by Yjytalamago (Talk)

2010-11-24T07:47:57Z

Undo revision 3298 by Yjytalamago (Talk)

← Older revision	Revision as of 07:47, 24 November 2010
(No difference)

91.59.25.60 at 14:42, 14 August 2009

2009-08-14T14:42:17Z

← Older revision		Revision as of 14:42, 14 August 2009
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 (unless OE_ALLOW_INSECURE_DOWNLOADS is enabled). Here are the steps a developer should take to resolve the issue safely.

	* Look through "''mtn --diffs --no-merges log conf/checksums.ini\| less''" and find the person who committed the current md5sum.		* Look through "''mtn --diffs --no-merges log conf/checksums.ini\| less''" and find the person who committed the current md5sum.
Line 11:		Line 11:

	[[Category:Policy]]		[[Category:Policy]]
			[[Category:FAQ]]

Thebohemian: Update checksums.ini moved to Dealing with checksum mismatch: Content was not in line with title.

2008-10-17T12:04:35Z

Update checksums.ini moved to Dealing with checksum mismatch: Content was not in line with title.

← Older revision	Revision as of 12:04, 17 October 2008
(No difference)

Laibsch at 17:10, 4 June 2008

2008-06-04T17:10:02Z

← Older revision		Revision as of 17:10, 4 June 2008
Line 9:		Line 9:
	# 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 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.		# 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]]

Laibsch: New page: 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 c...

2008-06-04T17:09:38Z

New page: 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 c...

New page

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.

* Look through "''mtn --diffs --no-merges log conf/checksums.ini| less''" and find the person who committed the current md5sum.
* 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.

# 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.
# 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.