Oracle Linux 8 Appstream sync fails

I was purposely skipping SRPMs to:

  • Stop the timeouts downloading from
  • Save lots of disk space

I eagerly await the pulp_rpm release.

That feature won’t be in this release, but it will be in the very next one.

Well - since it is a change in behavior it may not be backportable. But now that the patch for the parser bug is out, you could disable “mirror” and thereafter the SRPMs will be skipped over as you expect.

Regrettably, @dralley, I’ve pulled down the 2 files noted in your pull request, and I’m still getting the Pulp task error. :frowning:

@jkalchik, You mean you copied those two files to your local installation? Please don’t do that, that code is from an different development branch than Katello is on, you risk creating more errors if the code is not 100% compatible.

The linked PR was also not intended to fix the Pulp task error, it was intended in response to @John_Beranek’s inquiry about skipping the download of SRPMs. For the bugfix, you just need the pulp_rpm 3.14.3 package whenever it is released into the Katello repos.

1 Like

Not gonna argue that, but I’m getting sort of desperate. I’ve been fighting content download problems for a few months now, and my client management is really starting to lean on me to get this working.

If you need it fixed right now, and you have a lot of memory on the machine, you can edit your pulp settings to set RPM_ITERATIVE_PARSING = False. That will resolve the issue at the expense of using a lot of additional memory. Just remember to disable it once you do get the upgrade, and probably try not to sync a lot of repositories at once (because of the memory usage).

I would reinstall the 3.14.2 RPM though, in case any issues were introduced by replacing those files.

Reinstalled the pulp RPM, set RPM_ITERATIVE_PARSING=false in /etc/pulp/ and changed the timeout to 3000 seconds. It took nearly 3 hours, but did successfully complete.

Thank you.

1 Like

A follow-up sync completed in very short order. I have content delivery working, OFF TO THE RACES.

So, python3-pulp-rpm-3.14.3-1.el8.noarch ended up in the repos, which I applied. Put the config back to “RPM_ITERATIVE_PARSING = True” and had success.

I did see a worker get to 2.6GiB of RAM usage:


We’ve had a couple of patches lately (some already released, some in the works) that should reduce the memory consumption pretty dramatically.