Hello, it seems that most (if not all) of my yum group repositories build repodata/repomd.xml files that reference non-existent *-primary.xml.gz *-filelist.xml.gz and *-other.xml.gz files that do not match the same names as those files that were built.
Rebuilding/invaliding the cache does not help. Rebuilding the groups do not help. Both these operations cause all new files (with new names) to be built, but they never match the ones in repomd.xml. This might have just started to occur after upgrading from 3.74.0 to 3.76.0 but perhaps it was occurring before and was not noticed.
I can see the nexus.log file where it requests and merges all the required members of the yum group repo’s repodata files, but for whatever reason, the repomd.xml that it ends up building doesn’t match the filenames of the other xml.gz that it also creates in the directory.
This issue, of course, makes my yum group repositories completely unusable.
I also have this problem after upgrading to 3.76.0. Not all of my repos saw it. Of course the most used one did. Wondering if its size based as the repos that are ok are all very small. At this point I am looking to download everything out of it, delete it and recreate.
I did an initial test and creating a new repo does not see this issue.
for asset in pbar:
asset["path"] = asset["path"].lstrip("/")
file_path = os.path.join(output_dir, asset["path"])
if not 'repodata' in file_path:
error = download_single_asset(quiet, auth, file_path, no_verify, asset)
For your information, I confirmed via repeated downgrading and upgrading that 3.74.0 works correctly and 3.76.0 does indeed contain this bug. We have left ourselves running 3.74.0 until it gets resolved.
We recently upgraded Nexus Repository Manager from version 3.74.0-05 to 3.76.0-03 and are experiencing the same issue. However, we performed the upgrade a couple of days ago and only noticed the bug today, likely after an upload to the repository.
Unfortunately, we cannot restore a snapshot because, in the meantime, other teams have uploaded significant amounts of data to other repositories.
I understand that it is not possible to downgrade to a previous version—correct me if I’m wrong.
Is there any workaround to manage this situation until a fix is released?
It is a shot in the dark for a workaround, but since Sonatype doesn’t release the source for its yum plugin, I honestly have no clue if it would work or what potential negative implications may occur, but you could try and replace the yum plugin jar file: