Recently, I installed AlmaLinux 10 x86_64_v2 on several servers, hoping it would breathe new life into my older hardware (purchased between 2010 and 2015). After a few days of testing, however, I decided to revert back to AlmaLinux 9. In this post, I’ll explain the reasons behind this decision.
The Challenge with RHEL 10 and Older CPUs
Starting with RHEL 10, Red Hat dropped support for older CPUs—specifically, those that don’t meet the x86_64_v3 instruction set requirements. This means that standard RHEL 10 (and derivatives like Rocky Linux) won’t run on many pre-2015 processors. AlmaLinux addressed this by releasing a special x86_64_v2 build, targeting older CPUs and giving them a new lease on life. I was optimistic that this would keep my perfectly functional servers out of the recycling bin.
How AlmaLinux 10 x86_64_v2 Works
Linux distributions are built from source code, with the kernel and applications compiled for specific CPU architectures. The standard RHEL 10 and Rocky Linux 10 use x86_64_v3+ compiler flags, while AlmaLinux 10 x86_64_v2 uses x86_64_v2+ flags, making it compatible with older CPUs.
To make this version usable, AlmaLinux provides its own set of repositories (Base, Extra, CRB, etc.) compiled for x86_64_v2. However, as of December 2025, AlmaLinux is the only major provider offering RHEL 10 x86_64_v2 repositories. Popular third-party repositories like ELRepo, RPM Fusion, Remi do not support x86_64_v2, which severely limits the available software.
The Dealbreaker: Limited Third-Party Support
The main issue I encountered was the lack of third-party repository support for x86_64_v2. Essential packages like ZFS, PHP (Remi PHP), Redis, MariaDB (their official repo) and many others are simply unavailable unless you’re willing to compile them from source. Some applications are working like handicap mode, such as Firefox, VLC because the required 3rd party plugins are not available (e.g., H264 library, from RPM Fusion). While I appreciate AlmaLinux’s effort to support older hardware, the ecosystem just isn’t there yet. If most third-party repositories don’t plan to support x86_64_v2, this version isn’t practical for my needs.
Which Version Should You Use?
Choose AlmaLinux 10 x86_64_v2 if you:
- Only need applications from the AlmaLinux repositories
- Don’t mind compiling software and drivers from source
- Want the latest packages (e.g., kernel 6.12, gcc 14.3, OpenSSH 9.9)
- Prefer a longer support lifecycle (EOL: 2030)
Stick with AlmaLinux 9 if you:
- Rely on third-party repositories (e.g., ZFS, PHP 8.4, MariaDB 11, Redis 8.4)
- Prefer not to compile software yourself
- Are okay with older packages (e.g., kernel 5.14, gcc 11.5, OpenSSH 8.7)
- Can accept a shorter support window (EOL: 2027)
In summary, while AlmaLinux 10 x86_64_v2 is a great initiative for legacy hardware, its limited third-party support makes AlmaLinux 9 the more practical choice for now—at least for those who depend on a broader software ecosystem.
Our sponsors:
There is / will be another path to allow older system to use AlmaLinux 10 and avoid the issues you experienced. Source: https://lwn.net/Articles/1010868/
In a nutshell:
1. To accommodate users who have hardware without AVX2 support, AlmaLinux is producing two builds of AlmaLinux 10—one which follows upstream Stream and RHEL with v3-optimized binaries by default, and one which targets x86_64_v2.
2. The AlmaLinux project is expected to take on rebuilding EPEL to support AlmaLinux 10, and AlmaLinux Kitten (the project’s rolling development release) for the v2 builds. (AlmaLinux 10 builds for v3 can use EPEL normally.)
Skimmed and missed the important part of your issue… 3rd Party support.
Obviously, converting all 3rd Party Repositories to v2 will never be tackled by the AlmaLinux project so yes, the only solution for others in a similar situation is to use v9 until EOL and perhaps even after (unsupported) like some Centos 7 users did.