Does 32-Bit ARM Support Still Exist?

Hi everyone,

I did some browsing recently around the forum and the EndeavourOS ARM GitHub repositories and I was wondering if 32-bit ARM support still exists. From what I’ve been able to tell, it was dropped at some point in the past or maybe it exists somewhere I have yet to look. The main repo from what I’ve been able to tell is only for x86-64 and 64-bit ARM. Does EndeavourOS still support 32-Bit ARM? Thanks in advance!

1 Like

No, EnOS no longer supports 32 bit ARM.
Archlinux ARM still supports armv7h and aarch64 repositories.

However, a lot of armv7h packages are somewhat out of date. For example the
Odroid XU4 which is 32 bit only has this version of kernel
linux-odroid-xu3 4.14.180-3 (linux-odroid-xu3 and linux-odroid-xu4 share the same kernel)


1 Like

Thanks for the response! Makes sense! Speaking of Arch Linux ARM, I’ve taken a look at the state of Arch Linux ARM, and it really doesn’t look very good at all. I noticed that they don’t normally accept contributions neither respond to them. From what I can tell, the community isn’t able to contribute anything to Arch Linux ARM “upstream” whatsoever for the most part due to this.

I’ve noticed all of the solutions to Arch Linux ARM’s problems have mostly simple solutions, yet none of the maintainers actually want to implement them for some unexplained reason. For instance, they refuse to ship Graphene without NEON enabled in their repos (even though to my knowledge, it’s currently the only known fix available) so applications such as the Gnome Desktop don’t currently work on Arch Linux ARM 32-bit.

There are numerous distro-derivatives offering what you want. I don’t believe Arch (or derivatives) support(s) 32-bit any more. Puppy-lInux. antiX- PeppermintOS- LiliDog- BunsenLabs all come to mind

Most of those distros don’t support ARM32 to my knowledge.

I’ve thought about building some of the EndeavourOS ARM64 packages for ARM32 and fix a lot of ALARM’s issues myself for personal use, but I’ve decided against it doing it more than once (just for my own amusement) as ultimately doing something like that in the long term would be similar to maintaining a Gentoo system (with a significant number of package building).

EnOS dropped armv7h for two reasons.

  1. Manpower. It’s just too much for one person to maintain for what little it was being used.
  2. Enos Mirrors. People and/or organizations providing mirrors for the EnOS repositories are
    generously donating storage space and bandwidth. Eliminating the little used armv7h
    repository reduced their storage space by about 1/3.