Ian McInerney photo

Ian McInerney

Research software engineer, Vibration UTC at Imperial College London

Email Google Scholar Arxiv ORCID dblp Zotero LinkedIn Github Gitlab Mastodon

While Intel does not officially support Fedora with their oneAPI packages, they do provide RPM packages via yum/dnf repositories.

Repository configuration

For Fedora versions prior to Fedora 38 (e.g. Fedora 37 and before), the standard Intel instructions will work for installing oneAPI packages

Preventing library issues

As more parts of the oneAPI ecosystem become open source under permissive licenses, oneAPI libraries are being added to the main Fedora repository and being used as dependencies for Fedora packages. For example, the oidn-libs package in the Fedora repository contains libraries that are also provided by the oneAPI repository intel-oneapi-oidn-* pacakges, so adding the oneAPI repository alongside the main Fedora repository can lead to DNF choosing to install the Intel-provided packages containing the libraries instead of the Fedora ones.

DNF installing the Intel packages instead of the Fedora packages is problematic because the Intel packages install the libraries in different directories (e.g. subfolders of /opt/intel/oneapi), so they are not automatically on the search path and so using them requires adding them to the search path manually. This leads to DNF thinking all necessary libraries have been installed, but programs not starting due to missing shared libraries.

To fix this, the oneAPI repository should be added with a priority level below the Fedora repository. Since DNF uses a default priority of 99 and lower priority numbers indicate a higher priority repository, setting the priority level for the oneAPI level to 150 will cause DNF to choose the Fedora packages over the Intel-provided packages when there is a choice. This is done by adding


to the /etc/yum.repos.d/oneAPI.repo file containing the repository configuration.

Post-Fedora 38

Starting in Fedora 38, RPM has switched its cryptographic library to a new one called rpm-sequoia. This change unfortuently leads to several issues using the Intel oneAPI repository

Repository GPG Key

The first issue with the oneAPI repository is a GPG key failure with the error:

error: Certificate 1A8497B11911E097:
  The certificate is expired: The primary key is not live

To work around this issue, disable the GPG checks for the Intel repository in the /etc/yum.repos.d/oneAPI.repo file. A complete repository definition is:

name=IntelĀ® oneAPI repository

Installing Packages

Once the repository GPG-key is ignored, DNF produces further errors when trying to install the packages. These errors are generated by RPM itself, and look like

package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA signature: BAD (package tag 1002: invalid OpenPGP signature)
package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA signature: BAD (package tag 1002: invalid OpenPGP signature)

These errors are caused by the new rpm-sequoia cryptography backend becoming stricter with PGP keys meeting the appropriate standards, and rejecting keys that do not meet them (GitHub issue). In order to allow DNF to install these packages, RPM needs to relax the cryptography signature checks to allow these signatures through.

Currently, the workaround is to globally disable all package signature verification in rpm. This can be done by adding %_pkgverify_level none to the file /etc/rpm/macros.verify.

WARNING: This change will disable all package verification for all repositories/RPMs on the system. It should only be done if you completely trust all repositories on your system.