Verification of checksums fails for a patch file for bacula during syncing portage tree. Reproducible: Always Steps to Reproduce: This concerns today July 28 since morning in CEST time zone. I tried syncing using four different servers with the exact same result. 1. Run `emerge --sync` Actual Results: * Verifying /usr/portage/.tmp-unverified-download-quarantine ...!!! Manifest verification failed: Manifest mismatch for app-backup/bacula/files/5.2.3/bacula-5.2.3-openssl-1.patch BLAKE2B: expected: 32d49a53c8f639e762bd964f4fa1426952ccb2fd595717e015ee9c060e182d9189cf1749cb5e9d90d8712a0b1c3800ad98ba175e48935e7b6d172e6474719456, have: 04329d4485c0a673985eecc9feb8a730f0d6aa987d32eb0086f74d3a5fa9d431acaa0f699b30ba1c5570bd7ee43ecd45cd187dc186345e257191ae7eee4acc31 SHA512: expected: 729f01b5e88230561482cbe87fd185707be28ba92252e54a5111f0154f7d3df9cec9e31ee932bbdb34fe8b5e212cf43dc74d46460f68579e5f953ffe565a7a2c, have: 8587470472b4d0d62920fe633a9e64e5ab0481707025930b716bac603955efa1cd7790bfae7a3b1f0124f7fa4d72a9070039091bb37622e38bdd63e9fb4c4b03 Expected Results: Successful verification and updated Portage tree.
I've just run emerge --sync and the issue is still there.
The issue still persists. In the meantime I used emerge-webrsync which apparently does not check Manifest files and got the updated patch with new checksum (but with Manifest file not updated). I also have a portage git repo cloned so I compared that patch file for which checksum mismatch is reported and a change of "bool" into "booh" (which is wrong and will cause errors) turned out to be the culprit. -@@ -315,7 +315,7 @@ bool tls_postconnect_verify_host(JCR *jc +@@ -315,7 +315,7 @@ booh tls_postconnect_verify_host(JCR *jc ------------------------^ It's interesting that the patch file remains correct in the git repo, but all rsync servers tested provide the version with a typo. Please investigate and fix this.
What's curious is, this file has been there for a *very* long time: ~/git/gentoo/app-backup/bacula/files/5.2.3 $ git log bacula-5.2.3-openssl-1.patch commit 56bd759df1d0c750a065b8c845e93d5dfa6b549d (replaced) Author: Robin H. Johnson <robbat2@gentoo.org> Date: Sat Aug 8 13:49:04 2015 -0700 proj/gentoo: Initial commit This commit represents a new era for Gentoo: Storing the gentoo-x86 tree in Git, as converted from CVS. This commit is the start of the NEW history. Any historical data is intended to be grafted onto this point. Creation process: 1. Take final CVS checkout snapshot 2. Remove ALL ChangeLog* files 3. Transform all Manifests to thin 4. Remove empty Manifests 5. Convert all stale $Header$/$Id$ CVS keywords to non-expanded Git $Id$ 5.1. Do not touch files with -kb/-ko keyword flags. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> X-Thanks: Alec Warner <antarus@gentoo.org> - did the GSoC 2006 migration tests X-Thanks: Robin H. Johnson <robbat2@gentoo.org> - infra guy, herding this project X-Thanks: Nguyen Thai Ngoc Duy <pclouds@gentoo.org> - Former Gentoo developer, wrote Git features for the migration X-Thanks: Brian Harring <ferringb@gentoo.org> - wrote much python to improve cvs2svn X-Thanks: Rich Freeman <rich0@gentoo.org> - validation scripts X-Thanks: Patrick Lauer <patrick@gentoo.org> - Gentoo dev, running new 2014 work in migration X-Thanks: Michał Górny <mgorny@gentoo.org> - scripts, QA, nagging X-Thanks: All of other Gentoo developers - many ideas and lots of paint on the bikeshed I thought the repo copy I used was grafted but whatever, let's not worry about that for a sec. If I check the historical CVS->git conversion repo, we see https://github.com/gentoo/gentoo-historical-2/commit/de33077d887964714e19f9917e2f4199718b9928 -- it's been there (sans typo) since 2012. Now, why has absolutely nobody else reported this? Please give a list of the servers you've synced from? (emerge-webrsync definitely does check signatures by default, by the way, so that sounds odd as well).
(In reply to Sam James from comment #3) > Now, why has absolutely nobody else reported this? > > Please give a list of the servers you've synced from? > > (emerge-webrsync definitely does check signatures by default, by the way, so > that sounds odd as well). Please also give: - emerge --info - the full output of emerge --sync from start to end
https://gentoo.osuosl.org/snapshots/portage-20220730.tar.xz (this would be fetched by emerge-webrsync) and https://gentoo.osuosl.org/snapshots/portage-20220730.tar.xz.gpgsig has a valid signature with the correct patch. /tmp/testing/portage/app-backup/bacula # grep openssl Manifest AUX 5.2.3/bacula-5.2.3-openssl-1.patch 863 BLAKE2B 32d49a53c8f639e762bd964f4fa1426952ccb2fd595717e015ee9c060e182d9189cf1749cb5e9d90d8712a0b1c3800ad98ba175e48935e7b6d172e6474719456 SHA512 729f01b5e88230561482cbe87fd185707be28ba92252e54a5111f0154f7d3df9cec9e31ee932bbdb34fe8b5e212cf43dc74d46460f68579e5f953ffe565a7a2c I don't think I can do much more until I have the info I mentioned.
I've checked every online rsync mirror and they all have the correct copy of the patch.
(In reply to Liongene from comment #1) > I've just run emerge --sync and the issue is still there. Have you tried a different mirror? Or even git sync?
Created attachment 796201 [details] Current output of emerge --sync (July 31, 2022; 18:20 CEST)
Created attachment 796204 [details] emerge --info
I attached what you requested. I tried with the following mirrors: rsync://rsync7.pl.gentoo.org/gentoo-portage rsync://rsync1.pl.gentoo.org/gentoo-portage rsync://rsync1.cz.gentoo.org/gentoo-portage rsync://89.238.71.6/gentoo-portage
I've just reconfigured the base repo to use git for syncing. I removed the content of /usr/portage and ran emerge --sync. Syncing operation finished successfully and now I'm updating the packages.
(In reply to Liongene from comment #11) > I've just reconfigured the base repo to use git for syncing. I removed the > content of /usr/portage and ran emerge --sync. Syncing operation finished > successfully and now I'm updating the packages. I suspect you have/had a random single-bit memory error in the past when bacula-5.2.3-openssl-1.patch was first downloaded / unpacked / written to disk. > -@@ -315,7 +315,7 @@ bool tls_postconnect_verify_host(JCR *jc > +@@ -315,7 +315,7 @@ booh tls_postconnect_verify_host(JCR *jc > ------------------------^ l -> 01101100 h -> 01101000 ^ I've just compared my bacula-5.2.3-openssl-1.patch from a git pull and from an emerge-webrsync and from an archive from a few years ago and they all match. My guess is your emerge --sync was not "deep" enough, perhaps it only checked file metadata and not contents, decided your bacula-5.2.3-openssl-1.patch was up to date and didn't need changing. But then the bad data that has been on disk for an indefinite period, failed later checksum check. Have you had any other issues that might also indicate memory corruption? Does this system have ECC memory? I'd recommend running a memory checker. It is possible the original corruption was external (a bit flip on some Gentoo mirror at some point, that you then pulled down), but that gets increasingly hard to track down, I think. It does make me think that your initial emerge --sync method was not checking checksums when deciding what to copy over (rsync for example, will optimize out checking checksums under certain conditions, unless forced with --checksum).
My system is just an ordinary laptop and my RAM does not have ECC capabilities. But I see no other signs of memory corruption. The corrupted patch was only in .tmp-unverified-quarantine. Now I switched back from git to rsync and everything went fine so I will treat this issue as some kind of glitch and won't be engaging Gentoo Devs in further investigation since I believe you have more important work to do. I close the case.
Thanks. Please let us know if it resurfaces.
