From Fedora Project Wiki

< Changes

Revision as of 03:40, 30 January 2019 by Jlinton (talk | contribs) (submit 32-bit containers on 64-bit arm request)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Change aarch64 32-bit containers


Enable 32-bit containers (docker) on 64-bit Arm systems.


Current status

  • Targeted release: Fedora 30
  • Last updated: 2019-01-30
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Arm V8 machines support various levels of 32-bit compatibility. Some are completly compatible with 32-bit hypervisors, OS kernels, and applications, while others don't have any compatibility at all. In the middle are 64-bit systems which are only compatible with 32-bit OSs, or 32-bit applications. Fedora has made the decision not to support both a 32-bit and 64-bit multiarch userspace with the 64-bit kernel/OS. This hasn't been a problem as its been possible to spin up a 32-bit fedora VM to run 32-bit only applications. With the release of the Arm Cortex-A76, the only 32-bit support is in userspace. This means the only way to run 32-bit applications is either via a full set of 32-bit libraries/packages or in a full armv7 container.

Benefit to Fedora

Moving forward it will be harder to find high performace desktop/server class systems which are capable of running a full 32-bit kernel. As fedora is currently building the armv7hf OS images with 32-bit VMs on 64-bit machines, this will enable the possiblity of building within a 32-bit container instead. Similarly this brings us in closer sync with other distro's which can current run docker run -it arm32v7/fedora linux32 bash to spin up a 32-bit arm/fedora enviroment for testing/compiling/etc.


  • Proposal owners: This should be little more than changing the CONFIG_COMPAT in the kernel (and a couple other minor changes), along with verifying that the docker/etc images can be spun up. This change request is being opened to give it a bit more visibility, and prime the discussion. Also because I realized the deadline for change requests is today and its better to get the ball rolling.

Although, container stacks which have mount/library dependencies on the host system will fail. I'm not sure how common that is with flatpak/appimage/etc.If its common maybe it will be better to descope to "support 32-bit docker images"

  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

There should not be any regressions, simply additional functionality.. N/A (not a System Wide Change)

How To Test

Attempt to use existing tools to spin up containers built for the armv7 fedora. Granted a simple docker run is a starting place, but other stacks should have some basic testing as well.

In all cases a an Arm v8 machine with 32-bit EL0 support (check lscpu) is needed.

Then run docker run -it arm32v7/fedora linux32 bash to verify the 32-bit fedora docker container can be spun up sufficiently to run uname -a, dnf install, etc.

N/A (not a System Wide Change)

User Experience

Users should be able to spin up 32-bit fedora containers as well as 32-bit containers for other linux distros.


N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

We can descope to just 32-bit docker, or we can drop this entirely until F31 by again disabling CONFIG_COMPAT.


N/A (not a System Wide Change)

Release Notes