Fix Fatal glibc Error: CPU Does Not Support x86-64-v3 on RHEL 10

In this article we will diagnose and fix the RHEL 10 installer or boot failure that prints Fatal glibc error: CPU does not support x86-64-v3.

RHEL 10 requires a CPU that supports the x86-64-v3 instruction set. If the processor is too old, or a hypervisor hides some of those CPU features from a virtual machine, RHEL 10 cannot start and glibc prints this fatal error.

What the glibc x86-64-v3 error means

You typically see this message during install, early boot, or when starting a dynamic binary:

Fatal glibc error: CPU does not support x86-64-v3

RHEL 10 requires the x86-64-v3 CPU feature level. This error means those features are not available to the running system.

On physical hardware, the processor may be too old. In a VM, the physical host may support x86-64-v3 but the hypervisor can hide required CPU features from the guest. Sometimes a deprecation line appears first; either way, glibc refuses to start. There is no kernel module or dnf package that adds the missing instructions to an old CPU.

Quick fix

The fix depends on where RHEL 10 is running:

If the failing system is a VM and you cannot boot far enough to run commands, check the physical host first. A modern host may support x86-64-v3 even when the VM does not, because its virtual CPU model can hide some of those features.

Use the sections below for the exact settings on each platform. Confirm support with the ld.so check when any environment can run a modern glibc.

Check whether your CPU supports x86-64-v3

The easiest way to check is to ask the system’s dynamic linker which x86-64 levels the CPU supports. Run it inside the affected guest when possible, or on the host to see whether the physical CPU itself meets the baseline:

/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v'

On RHEL 10.2 the output shows x86-64-v3 as supported:

  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

Look for x86-64-v3 (supported, searched). If you see that line, the CPU features visible to this system meet RHEL 10’s requirement.

If x86-64-v3 is not marked as supported, RHEL 10 will not run normally on that CPU configuration.

Confirm the CPU model and whether you are in a guest:

lscpu | grep -E 'Architecture|Model name|Hypervisor vendor|Virtualization type'

Architecture:                            x86_64
Model name:                              Intel(R) Core(TM) Ultra 5 135U
Hypervisor vendor:                       KVM
Virtualization type:                     full

My host already exposes x86-64-v3 features to this KVM guest, so install and glibc start succeed when the guest CPU model is left intact.

You can also look at individual CPU flags. This is useful when a VM host should support x86-64-v3, but the guest is missing one or more features. Include lzcnt (often reported as abm on Linux):

grep -m1 '^flags' /proc/cpuinfo | tr ' ' '\n' | grep -E '^(avx|avx2|bmi1|bmi2|fma|f16c|movbe|xsave|lzcnt|abm)$' | sort

abm
avx
avx2
bmi1
bmi2
f16c
fma
movbe
xsave

Do not use AVX2 alone to decide whether a CPU supports x86-64-v3. AVX2 is only one of several required features. The ld.so check above is a better final test.

Some important v3 features include AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, and MOVBE. You do not need to check each one manually if ld.so already reports x86-64-v3 as supported.

If the physical host supports AVX2 but the guest does not expose it, the VM CPU model, EVC setting, or hypervisor CPU-feature handling is the likely cause. That covers deliberate masks and hypervisor bugs (for example the VirtualBox VMM issue fixed in 7.2.10).

Fix on VMware vSphere / ESXi with EVC

On VMware, the usual cause is EVC. EVC makes CPUs across a cluster expose a common set of features so VMs can move between hosts. If that compatibility level is too old, it can hide AVX2 and other features that RHEL 10 needs.

Broadcom documents this exact RHEL 10 failure when EVC is set to an older Sandy Bridge-level baseline. The physical hosts may have AVX2, but the guests never see it, so glibc prints the same fatal message.

1. Confirm every host in the cluster can run an EVC mode of Broadwell or newer (those baselines expose AVX2 and the other features RHEL 10 needs). Use VMware’s hardware compatibility guidance for the cluster.
2. In vCenter, open the cluster → Configure → VMware EVC → Edit, and raise EVC to Broadwell or higher (or turn EVC off only if you accept the migration limits that creates).
3. Power off and power on the affected VMs (systemd soft reboot on RHEL is not enough for CPU feature changes to appear).
4. Boot the RHEL 10 installer again, or from a rescue environment run the ld.so --help check and confirm x86-64-v3 (supported, searched).

If EVC must stay low for older cluster members, RHEL 10 guests cannot live on that cluster. Use RHEL 9 there, or move the guest to a cluster whose EVC already meets Broadwell or newer.

Fix on KVM / libvirt

KVM/QEMU can produce the same problem when the VM is configured with an older CPU model. The physical host may support x86-64-v3, but the guest only sees the features provided by its configured virtual CPU.

Prefer one of:

• host-model or host-passthrough when live migration constraints allow it
• If you use a named CPU model, choose one that exposes the full x86-64-v3 feature set. Haswell or newer is a useful starting point, but verify the result inside the guest with the ld.so command rather than relying only on the CPU model name.

After changing the guest CPU definition, shut down and start the VM, then recheck:

/lib64/ld-linux-x86-64.so.2 --help | grep 'x86-64-v3'

You want the (supported, searched) marker before retrying the RHEL 10 install.

Fix on VirtualBox

If RHEL 10, Rocky Linux 10, AlmaLinux 10, or CentOS Stream 10 fails in VirtualBox even though the host CPU supports x86-64-v3, first check your VirtualBox version. VirtualBox 7.2.10 fixed a VMM issue that could cause CentOS 10 guests to fail with this exact CPU does not support x86-64-v3 message.

VBoxManage --version

If the version is older than 7.2.10, upgrade VirtualBox first, then power the VM fully off and on before retrying the EL10 installer.

If upgrading does not fix the problem, first confirm that the physical CPU itself supports x86-64-v3. VirtualBox cannot provide CPU instructions that the host processor does not have. When the host lacks x86-64-v3, use EL9 or AlmaLinux 10 x86_64_v2 instead.

Fix on physical hardware

If the physical CPU itself does not support x86-64-v3, there is no software setting that can add the missing instructions. Your practical choices are to use newer hardware or continue running an EL9-based distribution on that machine.

• Move the workload to hardware that passes the x86-64-v3 check
• Continue with RHEL 9, Rocky Linux 9, or AlmaLinux 9
• Use AlmaLinux 10 x86_64_v2 if that alternative fits your requirements (see below)

Intel Haswell and AMD Excavator are useful rough reference points, but do not rely on CPU generation alone; check the actual feature support. There is no BIOS toggle that invents AVX2 on a CPU that never had it.

Why RHEL 10 requires x86-64-v3

RHEL versions have gradually raised the minimum CPU features they require. RHEL 9 requires the older x86-64-v2 level, while RHEL 10 requires x86-64-v3.

The v3 level adds newer processor features such as AVX2, FMA, BMI, and LZCNT. These features became common in mainstream Intel Haswell-era and AMD Excavator-era processors, but CPU generation alone is not a reliable compatibility check.

Because RHEL 10 packages are built for this newer baseline, a CPU—or a virtual CPU—that exposes only x86-64-v2 cannot run the standard RHEL 10 x86_64 build. Rocky Linux 10 and CentOS Stream 10 follow the same default. AlmaLinux 10 ships the normal x86_64 (v3) build plus an extra x86_64_v2 architecture for older hardware.

Alternatives when you cannot meet x86-64-v3

AlmaLinux documents that the default AlmaLinux 10 x86_64 build matches RHEL’s v3 baseline, while the extra x86_64_v2 architecture exists for older hardware. Third-party packages built only for RHEL 10’s default x86_64 may still assume v3 and therefore not work with the v2 architecture, so plan rebuilds or limited package sets if you choose that route. The EPEL install guide notes AlmaLinux’s v2 EPEL rebuilds for that case.

For product positioning across rebuilds, see Rocky Linux vs AlmaLinux vs RHEL.

Common problems

How I reproduced the error for testing

I verified this behavior by booting the same CentOS Stream 10 ISO twice under QEMU. With AVX2 hidden from the virtual CPU (Haswell,-avx2), boot failed with the exact glibc error:

[   14.182204] Run /init as init process
Fatal glibc error: CPU does not support x86-64-v3
[   14.182204] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

With the normal Haswell CPU model restored, the same ISO continued booting successfully:

[   23.611792] Run /init as init process
[   23.963365] systemd[1]: Detected architecture x86-64.
Booting initrd of CentOS Stream 10 (Coughlan) dracut-107-11.el10 (Initramfs).

Nothing else changed between the two boots. That matches what happens when VMware EVC, a QEMU CPU model, or another hypervisor setting hides features RHEL 10 needs.

Summary

The Fatal glibc error: CPU does not support x86-64-v3 message means RHEL 10 cannot see all of the CPU features it requires. On physical hardware, this usually means the processor is too old. Inside a VM, the physical CPU may be compatible while the hypervisor exposes an older or restricted virtual CPU.

If this happens in a VM, check the VMware EVC level, KVM/QEMU CPU model, or VirtualBox version. If the physical CPU itself does not support x86-64-v3, use newer hardware, remain on EL9, or consider AlmaLinux 10’s x86_64_v2 build where appropriate.

Confirm support with /lib64/ld-linux-x86-64.so.2 --help and look for x86-64-v3 (supported, searched).

References

• RHEL 10 cannot boot on older CPU that does not support x86-64-v3 (Red Hat KB 7122807)
• Architectures for Red Hat Enterprise Linux 10.2
• Exploring x86-64-v3 for Red Hat Enterprise Linux 10
• RHEL 10 Installation Fails with Fatal glibc CPU Unsupported Error on VMware EVC (Broadcom KB 411056)
• Oracle VirtualBox Change Log (7.2.10 VMM fix for CentOS 10 x86-64-v3)
• VirtualBox 7.2 changelog wiki
• AlmaLinux OS 10 release notes (x86-64-v2 architecture)
• AlmaLinux OS 10 announcement