Installing oneAPI on Fedora

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

Repository configuration
Preventing library issues
Post-Fedora 38
- Repository GPG Key
- Installing Packages

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

priority=150

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

Note: Intel has generated a new GPG key for the repository, so this workaround is no longer necessary.

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:

[oneAPI]
name=Intel® oneAPI repository
baseurl=https://yum.repos.intel.com/oneapi
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://yum.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB
priority=150

Installing Packages

Note: Intel has now fixed their RPM signing as of oneAPI 2024. The older versions still have an invalid package signature though, so the work arounds listed here are only needed for installing older oneAPI packages from the RPM repository.

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.

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.

Ian McInerney