Deprecation Notice: Dropping Platform ARMv7

[polarathene]

NOTE: ARM64 is not affected. That platform remains relevant to support.

---

Deprecation plans for ARMv7:

Due to the age of the ARMv7 platform and assumed very few if any remaining users of it with this project:

• ARMv7 builds will be dropped as a requirement CI tests to pass.
• Unless there is sufficient interest for ARMv7, publishing ARMv7 image builds to registries (DockerHub, GHCR) will also halt.

Should this decision go ahead to stop publishing for ARMv7, it would then be advised for those affected to upgrade their hardware or maintain their own ARMv7 builds.

---

Additional reasoning:

• ARMv7 doesn't receive any test coverage beyond what AMD64 CI covers. I don't believe any maintainer is able to offer much in support either. Similar to ARM64 (which is still a useful platform to support), our support amounts to successful builds of the image during CI test runs and publishing image releases to registries.
• AFAIK for Raspberry Pi 3 (RPi 3) with 64-bit OS installs ARM64 is supported which is a product from 2016.
• Fedora has plans to drop support for ARMv7 by mid 2023 (relevant in the context of industry support for ARMv7).
• Most of these ARMv7 devices are resource constrained, obsoleted by newer devices around 2016 onwards (ARMv8 across SBC devices), these replacement devices cost around $15-40 USD.

---

Reaching out to users known to use ARM (most interested in ARMv7 at the time):

I have looked through this projects issues and noticed most users that mention their ARMv7 device are RPi users. I have pinged users involved below (apologies for those that are not using ARMv7, or no longer using this project).

Please chime in, if the ARMv7 platform support matters to you. ARM64 will remain.

• Oct 2016 (Original request for ARMv7): @schelv @eratio08 @melkypie @cchance27 @ulm0 @albertoig @Mr5quid
• Dec 2018 - Jun 2020: @soywod @jnovack @maxswjeon @edgeux @nalakawula @suli3 @VincentCATILLON @ktcar214 @bertovanoorspronk @fergalmoran @yajo @radicand
• Feb 2020: @oblitum
• Nov 2020: @dragoneena12 @guysoft
• Dec 2020: @andreasfaerber
• May 2021: @ShinoYasx

[radicand]

I only have interest in the arm64 build. As noted in your comments, it's very easy to enable 64bit mode on RPi hardware. I'd support this move.

[georglauterbach]

I'd also go ahead with this. We will be publishing v11.1.0 in the near future, so we could add this notice to the changelog for v12.0.0 (next major)?

[polarathene]

so we could add this notice to the changelog for v12.0.0 (next major)?

I already added the notice into the changelog for v11.1.0 after I raised this issue to reference it 👍

v12.0.0 is also tagged in this issue for when it will apply.

[guysoft]

Hey am using armv7.
I suggest if you do also provide a tag that points to the arm64bit build. That way I can tell docker to pull the arm64 explicitly (not only a manifest tag) even if you are in a 32bit userspace.

The reason is that I have an arm64bit kernel running in a 32bit userspace.
The default of rpi is still 32bit now, It means you can switch to the 64bit kernel and use the default operating system.

[polarathene]

That way I can tell docker to pull the arm64 explicitly (not only a manifest tag) even if you are in a 32bit userspace.

What is the issue with using the image digest instead of image tag?

I understand it's a little more inconvenient, but it would seem bad practice to publish tags for platform support? Do you know of any well known images that do that still?

Am I mistaken with the RPi supporting 64-bit OS installs as a fix?

[andreasfaerber]

I am no longer using it on ARMv7

[bertovanoorspronk]

I am even so no longer using it on the old ARMv7.
The hardware is upgraded.

[guysoft]

What is the issue with using the image digest instead of image tag?

The issue is that if you have docker in a 32bit user-sapce, but your kernel is 64bit, then docker will only let you pull the 32bit armf version (and will fail if the manifest does not hold one).
However, if you have a tag for 64bit then you can point docker to that and it will download just fine.

[polarathene]

The issue is that if you have docker in a 32bit user-space, but your kernel is 64bit, then docker will only let you pull the 32bit armf version (and will fail if the manifest does not hold one).

That sounds a bit odd that the behaviour would differ from pulling via digest vs tag. I don't have a device to verify that on my end, but I was able to pull the current ARMv7 image via digest despite being on x86/AMD64.

The docker pull docs seem to suggest it's a more specific version than a tag is. If your docker version is quite old, I guess it's possible that you run into a compatibility issue. Otherwise if the digest isn't working, perhaps you can try with the --platform option?

Here is some examples for an older v10 release if you want to verify?:

# Using --platform to pull non-default platform image:
docker pull --platform arm64 mailserver/docker-mailserver:10

# Pull image by digest for v10 ARM64 release:
# https://hub.docker.com/layers/mailserver/docker-mailserver/10.0.0/images/sha256-8f57b7ba80e6b4c7fbba587e1349cb27251d15ef7ed22c5f189bd566a0b2238a
docker pull --platform arm64 mailserver/docker-mailserver@sha256:8f57b7ba80e6b4c7fbba587e1349cb27251d15ef7ed22c5f189bd566a0b2238a

---

However, if you have a tag for 64-bit then you can point docker to that and it will download just fine.

I don't see us publishing tags for such. It is more likely we would continue publishing ARMv7 builds, but if only one user is requesting continued support I am not sure that will continue.

It'd be preferable to drop ARMv7 completely going forward. Have you tried the 64-bit OS support detailed in Feb 2022 on the RPi blog? Is using that or replacing the device not an option?

Publishing images for ARMv7 isn't causing any maintenance gripes AFAIK, but if you have any issues on that platform, there would be no support. If nothing suggested works for you and provided other maintainers are OK with it, ARMv7 can continue to be published.

[guysoft]

Have you tried the 64-bit OS support detailed in Feb 2022 on the RPi blog? Is using that or replacing the device not an option?

Yes, I actually maintain CustomPiOS and had lots of shenanigans with the 64bit distribution. To a point that currently OctoPi 1.0.0 (which I also maintain) is currently building nightly using the Ubuntu 64bit raspberrypi image. I find that for docker that seems more stable on the raspberry pi.

There is also an open issue here:
RPi-Distro/pi-gen#481

I will post in the RPi-Dsitro issue that blog entry and ask if its still beta there.

[radicand]

If anyone must have 32bit userspace but runs a 64bit kernel, know what you can also install k3s (instead of Docker), and it will run in 64 bit mode and pull arm64 automatically (in fact, it won't work with armv7 images in this configuration). This is actually what I do, as my cluster was setup before the official 64bit userspace was GA. You'll need to either be familiar with Kubernetes or willing to learn however.

[georglauterbach]

A PR is incoming (soon) that drops support for Armv7. The latest :edge still has the new F2B changes, so if you need to migrate, you have a bit of time. Rspamd won't make it though, I guess.