Learn more about these different git repos.
Other Git URLs
Describe the issue Hi, since a few days our EL8 systems are throwing errors, because dnf crashes. The crash occurs, if our systems try to process the repodata from EPEL8. It took a bit, but I found this error message: tmp0iikmess-4c14677185b1c6131977c4089a7d36fcc1f7ca71b4fd3cbe975e4594186a77de-primary.xml.zst: Cannot detect compression type
When do you need this? (YYYY/MM/DD) 2024-05-10
When is this no longer needed or useful? (YYYY/MM/DD) 2032-12-31
If we cannot complete your request, what is the impact? All EL8 systems are unable to use EPEL.
Can you describe how your systems are 'processing' the repodata?
looks like you are running createrepo_c on it? Can you provide the command line and what version of createrepo_c you have there?
Our systems process them through dnf. I got that hint from another system, which mirrors the EPEL repository. If the mirror uses createrepo_c, I don't know, but createrepo_c and dnf refuse to process EPEL.
Output from dnf: [root@mysystem ~]# dnf update platform-python: /builddir/build/BUILD/libdnf-0.63.0/libdnf/dnf-sack.cpp:781: gboolean load_yum_repo(DnfSack, HyRepo, GError*): Assertion `fp_primary' failed. Aborted (core dumped)
Output without EPEL: [root@mysystem~]# dnf config-manager --set-disabled epel [root@mysystem ~]# dnf update Last metadata expiration check: 0:43:41 ago on Fri 10 May 2024 04:08:52 PM CEST. Dependencies resolved. ============================================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================================== Installing:
What does 'rpm -q dnf' output?
I pushed a possible fix to epel8-testing. Do you have any way to test that?
Actually this may be a libsolv issue, what does:
rpm -qi libsolv
output?
You said you were mirroring EPEL, were you using Katello or Satellite to do that?
If so, https://issues.redhat.com/browse/SAT-21884 is the reason. Libsolv is rebuilt and shipped through Katello (/ Satellite), except the rebuilt package doesn't have zstd support enabled.
I'll try to nudge them to get that fixed soon separately from EPEL (which has likely already resolved your issue)
I found that this problem occurs in CentOS 8.2.2004, but CentOS 8.4.2105 does not have this problem The libsolv version in CentOS 8.4 is libsolv-0.7.16-2.el8.x86_64, while the libsolv version in CentOS 8.2 is libsolv-0.7.7-1.el8.x86_64
Now it's back to normal, I found that the index file has changed from zst format to xz format
The issue in the end is that createrepo was updated to 1.0 on the builders and this defaults to using zstd as the compressor for speed issues. This was tested to work with RHEL-8.9 and CentOS Stream 8 which were both shown to work. This was because CentOS Stream 8.4(?) and beyond added the zstd to the libsolv and other tools compilations. This however caused issues for the following reasons: 1. There are systems which have not updated beyond an early version of RHEL or CentOS which did not have this enabled. 2. There are systems which have either Red Hat Satellite or Pulp installed which replaces libsolv with a version which did not have zstd enabled.
EPEL is only tested to work with systems which are on the latest Red Hat Enterprise Linux or CentOS Stream released. For sites needing older versions of releases, they need to point their release to the appropriate /pub/archive/epel/ directory for that release they are staying on. Those sections do not get updates, but it will still 'work' as it did before the 'tip' moved to a newer release.
Release engineering has moved the createrepo flags for EPEL-8 and EPEL-9 to use xz compression which will fix the problem with sites using Red Hat Satellite.
Yeah, so the xz repodata I think will work for everyone, so I am going to go ahead and close this.
Please reopen if you see further issues or file a new ticket.
Metadata Update from @kevin: - Issue close_status updated to: Fixed with Explanation - Issue status updated to: Closed (was: Open)
Good morning,
thank you very much, now the repodata can be processed again from clients and the mirror.
Log in to comment on this ticket.