Yum Group Repositories not creating correct repomd.xml files in version 3.76.0

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.

Thank you for any help you can provide!

1 Like

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.

I am looking at using nexus3-exporter/nexus3_exporter.py at master · LoadingByte/nexus3-exporter · GitHub with the following changes (adding lstrip and skip of repodata) to support directories in my yum repo (w/o it, it tries to creating files in “/”) and skipping the missing files in repodata.

        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)

Well, the new repo did not work. Same issue. My server is seeing files in repodata that are not in nexus after a full repair has run.

On the system:

Screenshot 2025-01-15 at 12.18.51

In nexus:

The test I ran earlier was with a simple few rpms instead of the entire repo

I have also run a test with an s3 backed repo and a local repo, both see the same issue. My repo is 16G.

Now I can’t get my original test of a small repo to work. Hopefully someone from Sonatype is watching this.

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.

I can confirm this bug as well.

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?

We urgently need a workaround to solve this problem.
Is there an expected release date for a fix or workaround to solve this problem?

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:

{nexus-install-dir}/system/com/sonatype/nexus/plugins/nexus-repository-yum/3.76.0-03/nexus-repository-yum-3.76.0-03.jar

With the following jar file from the 3.74.0 installer:

…system/com/sonatype/nexus/plugins/nexus-repository-yum/3.74.0-05/nexus-repository-yum-3.74.0-05.jar

I would not advise replacing the yum plugin jar with an older version. That is not tested, and is very unlikely to work.

I can let you know that Sonatype is aware of this issue, and we are working on a fix.

Rich

FYI: 3.76.1 is out with a fix for this issue! (NEXUS-45564)

https://help.sonatype.com/en/sonatype-nexus-repository-3-76-0-release-notes.html#what-s-new-in-3-76-1-