Architecture incompatibility when installing a RPM package in a container


I’m currently working on a ZCU102 board with Petalinux, which has an ARM64 Cortex53 architecutre. I was able to install Docker on it and run containers with images built for the ARM64 arch successfully.

My problem right now is that I am building an image which copies a few RPM packages into it and installs them in the container. These packages have been created specifically for the board and they are succesfully installed directly in the Petalinux system. However, the same installation fails inside the container, which is running in the board, due to: Package <package_name> is intended for a different architecture.

I checked that the output of the lscpu command was the same both when run directly on the board and inside the container, which actually it was:

I tried different base images for the one I’m building, such as Almalinux, Centos, Rockylinux or Fedora, and I get the same error with all of them.

I was wondering if someone had experienced the same issue or could know what the problem might be, since the architecture in which the container is running is obviously compatible with the RPM package.

Thanks in advance for any help!!

What does the arch command returns in the container and riectly on the board?
It might be that one returns aarch64 and the other returns arm64.

Since I know neither ZCU102 board nor Petalinux, I have to ask how did you install Docker? Since Docker does not support it directly, it could be a modified version and you could install Docker CE or Docker Desktop, but I guess it is a verson of Docker CE.

I know a little about rpm, but If I am not mistaken, it supports the --ignorearch flag so you could try to install the packages using that flag and see what happens.

Hi @rimelek !

First of all, thanks for the help!

The arch command returns “aarch64” in the container and directly on the board as well.

The Docker available on the board was installed during the building of the Petalinux image for the board using the petalinux-config tool. This tool allows for the configuration of kernel, file system, libraries and debug options. There is a Petalinux Package Group available which is called “packagegroup-petalinux-ocicontainers”: I enabled it so I could have Docker on the board. It is actually a version of Docker CE.

I tried the --ignorearch flag that you mentioned but it did not work. My solution was to extract the contents of the RPM packages that I needed and created a Docker image that copies the contents in the / path. At the end, it is like performing the installation manually instead of using the rpm command. The only problem was dealing with the dependencies manually: I made use of the ldd command in order to check them and installed the corresponding dependencies in the container.

I know you said you’ve already worked around this, @mmarquez99 , but I’m still curious to know why you were having these troubles.

I’m curious what would be the result if you were to use the dnf command instead. (Which is really preferable to running straight rpm, especially since you mentioned dealing with dependencies, something rpm does only minimally.)

With dnf, the important factor isn’t so much what the system detects as its architecture, but rather what DNF does. (Which in the ideal case is configured correctly from the system, but you never know…)

You can check the value of both arch and basearch for DNF using its config-manager2, e.g. on my Fedora 37 desktop system…

$ dnf config-manager --dump-variables
arch = x86_64
basearch = x86_64
releasever = 37

I’m also curious what the packages you’re trying to install think their own architecture is. That info can be queried with the command:

$ rpm -q --qf '%{arch}' -p <packagefile>.rpm

If there is indeed a mismatch between the package %{arch} and the DNF basearch, it actually supports a --forcearch flag that will let you override the detected/configured architecture. So, it should theoretically be possible to install any1,3 package with a command like,

$ sudo dnf --forcearch weirdArm install <packagefile>.weirdArm.rpm

(Whether the resulting installed package works correctly or not, that’s a different story.)


  1. (Well, not any package. There are a limited set of valid architectures. A dnf --forcearch help will list them, in Fedora 37 it’s…)

    (choose from ‘aarch64’, ‘alpha’, ‘alphaev4’, ‘alphaev45’, ‘alphaev5’, ‘alphaev56’, ‘alphaev6’, ‘alphaev67’, ‘alphaev68’, ‘alphaev7’, ‘alphapca56’, ‘amd64’, ‘armv5tejl’, ‘armv5tel’, ‘armv5tl’, ‘armv6hl’, ‘armv6l’, ‘armv7hl’, ‘armv7hnl’, ‘armv7l’, ‘armv8hl’, ‘armv8l’, ‘athlon’, ‘geode’, ‘i386’, ‘i486’, ‘i586’, ‘i686’, ‘ia32e’, ‘ia64’, ‘loongarch64’, ‘mips’, ‘mips64’, ‘mips64el’, ‘mipsel’, ‘noarch’, ‘ppc’, ‘ppc64’, ‘ppc64iseries’, ‘ppc64le’, ‘ppc64p7’, ‘ppc64pseries’, ‘riscv128’, ‘riscv32’, ‘riscv64’, ‘s390’, ‘s390x’, ‘sh3’, ‘sh4’, ‘sh4a’, ‘sparc’, ‘sparc64’, ‘sparc64v’, ‘sparcv8’, ‘sparcv9’, ‘sparcv9v’, ‘x86_64’)

    …If your RPMs show some architecture value other than one of those, when you query their %{arch}, then that could be the root source of the problem you’re encountering.

  2. I forgot to mention that dnf config-manager is a plugin command, not a base dnf command. You’ll need to have python3-dnf-plugins-core installed to use it.

  3. On further investigation, it’s unlikely that DNF would be willing to install any package from any architecture on a machine. The issue is that unlike straight rpm, it requires that dependencies be satisfied, and if I try to install (e.g.) an aarch64 RPM on my x86_64 machine, DNF will complain that the libraries that package requires, even if it’s just, aren’t available for that architecture. And if it tries to install glibc-2.36-7.fc37.aarch64.rpm to get those libraries, it’ll hit a conflict with the installed glibc-2.36-9.fc37.x86_64.rpm. But at least in those situations, you’ll get a lot more information about the exact nature of the conflict/incompatibility, rather than simply a useless message that something is “intended for a different architecture”.

1 Like