Error messages from missing CPU features

Two kinds of program fail this way. Some check the processor when they start and stop with a message of their own: the C library of a distribution built for a newer level, the Go runtime, .NET. Others just run until they reach an instruction the processor does not have, and the kernel kills them with the signal SIGILL, which the shell reports as “Illegal instruction”.

Either way, the cause is the processor as the operating system sees it. In a virtual machine that is the CPU model of the hypervisor, which is often older than the hardware, so the fix is usually a setting rather than new hardware.

Fatal glibc error: CPU does not support x86-64-v2#

$ ls
Fatal glibc error: CPU does not support x86-64-v2

The system’s C library, glibc, was built for x86-64-v2, and the processor lacks at least one x86-64-v2 feature: SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CMPXCHG16B or LAHF/SAHF. The dynamic loader checks the level when it starts a program, before any code of the program runs, and exits with status 127. So every dynamically linked program fails with this message: the shell, ls, the package manager.

It comes from Red Hat Enterprise Linux 9 and its rebuilds such as Rocky Linux 9 and AlmaLinux 9, and, below x86-64-v2, from RHEL 10 and its rebuilds as well, because the loader checks the levels in order. SLES 16 and openSUSE Leap 16 printed it under QEMU’s Penryn model, which has SSE4.1; under the models without SSE4.1 their programs died with “Illegal instruction” first (see the examples there). A container from one of these images fails the same way, since a container runs on the processor of its host. Which systems require which level lists more.

Checking the machine. On the affected system nothing dynamically linked runs, not grep and not the loader’s own --help, so check from outside: on the host of the virtual machine or container, or with another system started on the same hardware (how to check). For a virtual machine, the CPU model in its settings decides.

Fixing it. In a virtual machine, choose a CPU model with x86-64-v2 or pass the host’s processor through, in QEMU, libvirt, Proxmox VE, VMware vSphere or Hyper-V. QEMU’s default qemu64 model and the older kvm64 are below x86-64-v2. On hardware below x86-64-v2 the system cannot run; these are the choices.

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

$ docker run --rm redhat/ubi10-minimal bash -c 'echo ok'
Fatal glibc error: CPU does not support x86-64-v3

The same check for a C library built for x86-64-v3, as in Red Hat Enterprise Linux 10, CentOS Stream 10, Rocky Linux 10 and AlmaLinux 10. The processor has x86-64-v2 but lacks a feature of x86-64-v3: AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, or the operating system’s support for the AVX registers (OSXSAVE). The message above is what bash of Red Hat’s UBI 10 minimal image (RHEL 10.2) printed in a run recorded under QEMU’s Nehalem model, an x86-64-v2 processor without AVX, with exit status 127. Under qemu64, below x86-64-v2, it printed the x86-64-v2 message instead.

Frequent causes are Proxmox VE’s default CPU type for new VMs, x86-64-v2-AES, older VMware EVC modes, and Intel’s Pentium and Celeron processors, which lack AVX up to Comet Lake (see x86-64-v3).

Fixing it. In a VM, a CPU model with x86-64-v3, such as Proxmox’s x86-64-v3 or host (details). On an x86-64-v2 machine, RHEL 9 and its rebuilds still run, and AlmaLinux also builds AlmaLinux 10 for x86-64-v2 (requirements).

glibc has the same check for x86-64-v4 and for APX, for systems whose C library is built for them: Fatal glibc error: CPU does not support x86-64-v4 and Fatal glibc error: CPU does not support APX.

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00#

Fatal glibc error: CPU does not support x86-64-v2
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

This is the glibc message during boot. The first program the kernel starts, init, is dynamically linked, so it fails the level check and exits with status 127. The kernel cannot run without init and stops: 0x00007f00 is exit status 127 (0x7f) in the form the kernel reports it. The glibc message is the line before, and it names the level.

The first line is what RHEL 9’s programs print below x86-64-v2: in a run recorded under QEMU’s qemu64 model, bash of Red Hat’s UBI 9 micro image (RHEL 9.8) printed it and exited with status 127, and under Nehalem, an x86-64-v2 model, it ran. The second line is the kernel’s text for an init that exits, from its source; QEMU’s user mode, which the recorded runs use, starts programs rather than a system, so no boot was recorded. The fix is the one for the glibc message. Other failures of init end in exit status 127 too, such as a missing library, so the line above the panic is what tells them apart.

CPU ISA level is lower than required#

$ ./hello
./hello: CPU ISA level is lower than required

The program, or a library it loads, carries a note saying which x86-64 level it needs, and the processor does not have that level. A program built with GCC 14 and -march=x86-64-v3 -mneeded printed this message, with the path it was started by, in a run recorded under QEMU’s Nehalem model, and exited with status 127. The dynamic loader of glibc reads the note before the program starts and exits with status 127; a library loaded later with dlopen fails with the same text. GCC writes the note with -mneeded, and the linker with -z x86-64-v3 and similar options. readelf shows it:

$ readelf -n hello | grep 'ISA needed'
      Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3

Fixing it. Install a build of the program for the level the processor has, for example from a distribution’s baseline packages rather than its x86-64-v3 packages, or give the virtual machine a CPU model with the level (check the level).

Illegal instruction (core dumped)#

$ ./sum
Illegal instruction (core dumped)

The program executed an instruction that the processor does not have, and the kernel stopped it with the signal SIGILL. The program was built for a newer processor, for example with -march=x86-64-v3, or uses a library that was, and it never checked. “Illegal instruction” is the C library’s name for SIGILL, which Bash and other shells print when a program dies from it. “(core dumped)” follows when the system saved a core dump, and is missing otherwise.

Other programs report the same signal in their own words:

fish: Job 1, './sum' terminated by signal SIGILL (Illegal instruction)
Fatal Python error: Illegal instruction

The second line is Python’s faulthandler, which pytest turns on. The exit status is 132 (128 plus 4, the number of SIGILL). Docker reported the same exit code for each container that SIGILL ended in the recorded runs below, which run with docker run --init.

Examples recorded under QEMU 10.0’s user mode with older CPU models:

• import numpy with NumPy 2.5.3 died with SIGILL, on an SSE4.1 instruction (PINSRQ) in a library, under qemu64, below x86-64-v2, which NumPy requires since 2.4. Under Nehalem it imported.
• mongod --version of MongoDB 8.0.32 died with SIGILL, on the AVX instruction VMOVDQA, under Nehalem, which has no AVX (see MongoDB).
• The dynamic loader of SLES 16 and openSUSE Leap 16 has the x86-64-v2 check, but runs an SSE4.1 instruction, PINSRQ, before it. Under QEMU’s qemu64, kvm64 and Conroe models, which lack SSE4.1, ls and bash of their 16.0 images died with SIGILL on that PINSRQ; with Penryn, which has SSE4.1 but not SSE4.2 or POPCNT, the loader printed the glibc message.

Finding the instruction. Run the program under a debugger, which stops at the signal, and print the instruction it stopped on:

$ gdb -q -batch -ex run -ex 'x/i $pc' ./sum

The sum program of the recorded runs, a loop built with GCC 14 and -O3 -march=x86-64-v3, died under QEMU’s Nehalem model on vmovdqa ymm0, ...: VMOVDQA with a YMM register is an AVX instruction, as its page in the instruction reference says, with the CPUID bit that tells whether a processor has it. Then check the machine, and compare its level and features with x86-64-v3 or the extension’s page.

Fixing it. Use a build of the program for the processor, for example one compiled for the baseline or with run-time dispatch, or a processor (or VM CPU model) with the missing extension. Many projects state a minimum; requirements lists some.

zsh: illegal hardware instruction#

% ./sum
zsh: illegal hardware instruction (core dumped)  ./sum

The same SIGILL as Illegal instruction, in the words of zsh, the default shell of macOS. Without a core dump the line lacks “(core dumped)”.

trap invalid opcode#

traps: sum[2166790] trap invalid opcode ip:558d7ecb20a5 sp:7ffec103e980 error:0 in sum[558d7ecb2000+1000]

The kernel log (dmesg or journalctl -k) has a line like this for every program that SIGILL kills without a handler. It names the program and its process ID, the address of the instruction (ip) and the file it was in, with the address and size of the mapping. Newer kernels, such as Linux 7.2, also print the instruction’s offset in the file, as in sum[10a5,558d7ecb2000+1000], which locates the instruction in the file even when it is in a shared library.

The line above shows the form of the line without the offset, as older kernels print it; its program, process ID and addresses are an example, not a recorded line, since QEMU’s user mode, which the recorded runs use, never reaches the kernel’s handler. The kernel limits how many of these lines it logs, and debug.exception-trace = 0 turns them off.

Go: This program can only be run on AMD64 processors#

$ ./hello
This program can only be run on AMD64 processors with v3 microarchitecture support.

A Go program built with GOAMD64=v2, v3 or v4 checks the processor before it runs any Go code, prints this message with its level and exits with status 1. In runs recorded with Go 1.27.1, a program built with GOAMD64=v3 printed the message above under QEMU’s Nehalem model, and one built with GOAMD64=v2 printed it with v2 under qemu64. The default, GOAMD64=v1, runs on every x86-64 processor. The message names the level: v2 means x86-64-v2, v3 x86-64-v3 and v4 x86-64-v4.

Fixing it. Build the program again with a lower GOAMD64, for example GOAMD64=v1 go build, or get the build for older processors if the project publishes one. In a VM, a CPU model with the level also works.

.NET: The current CPU is missing one or more of the following instruction sets#

$ dotnet hello.dll
Fatal error.

The current CPU is missing one or more of the following instruction sets: SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT

Aborted (core dumped)

From .NET 11 on, the runtime needs x86-64-v2 on x86-64 processors, and it checks the instruction sets it lists when it starts. A program built with the .NET SDK 11.0.100-rc.1 printed the lines above in a run recorded under QEMU’s qemu64 model and ended with SIGABRT (exit status 134), which a shell reports as “Aborted”; under Nehalem it ran. Microsoft’s notice of the change shows a shorter message, The current CPU is missing one or more of the baseline instruction sets., which the runtime prints on other architectures. An application compiled ahead of time (Native AOT) for more instruction sets than the baseline stops with The current CPU is missing one or more of the required instruction sets. on a processor without them.

Fixing it. A processor or VM CPU model with x86-64-v2. .NET 10 and earlier still run on the baseline.

The TensorFlow library was compiled to use AVX instructions#

The TensorFlow library was compiled to use AVX instructions, but these aren't available on your machine.

TensorFlow checks, when it is loaded, the instruction sets it was compiled for, and aborts with this message if one is missing; the official binaries use AVX. The same message names other extensions, such as AVX2 or FMA, for builds that use them.

A different message is not an error:

This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.

It lists extensions that the processor has and the build does not use, and TensorFlow runs normally.

Fixing it. A processor or VM CPU model with AVX, or a TensorFlow built from source for the processor.

WARNING: MongoDB 5.0+ requires a CPU with AVX support#

WARNING: MongoDB 5.0+ requires a CPU with AVX support, and your current system does not appear to have that!

The official Docker image of MongoDB prints this warning when /proc/cpuinfo lists no avx, and then starts mongod anyway. Without AVX, mongod died with SIGILL in a run recorded under QEMU’s Nehalem model: mongod --version of MongoDB 8.0.32, from MongoDB’s tarball for Debian 12 rather than the Docker image, stopped on VMOVDQA, and Docker reported exit code 132. Outside Docker there is no warning, only “Illegal instruction”. MongoDB 5.0 and later need AVX on x86-64, which puts the minimum between x86-64-v2 and x86-64-v3: Sandy Bridge and Bulldozer have it, while most of Intel’s Pentium and Celeron models before Tiger Lake do not.

Fixing it. A processor or VM CPU model with AVX. In a VM the host often has AVX while the CPU model hides it; see VMs.

Windows 11 24H2 does not start#

Windows 11 version 24H2 uses the SSE4.2 and POPCNT instructions and does not start on processors without them. There is no message that names the cause, so there is nothing to quote here. Microsoft lists SSE4.2 and POPCNT among the processor requirements of Windows Server 2025, and states that Windows 11 requires the x86-64-v2 instruction sets.

Processors without them are below x86-64-v2, such as Intel’s Core 2 and AMD’s Phenom. In virtual machines, CPU models without SSE4.2 and POPCNT, such as QEMU’s qemu64 and kvm64, cause the same failure; choose a newer model. Coreinfo shows whether a processor has both.

How these messages were checked#

Each message is quoted from the source code of the program that prints it, at the release named in the sources below. Many were also recorded running, in the runs named on this page: programs of their systems or built for the purpose, run under QEMU 10.0’s user mode with the CPU models named, whose output the site’s tests compare with this page. They cover glibc’s x86-64-v2 and x86-64-v3 messages (RHEL 9 and 10, SLES 16 and openSUSE Leap 16), the ISA level note, Go’s and .NET’s messages, and SIGILL with exit status 132 (NumPy, MongoDB, the loaders of SLES 16 and openSUSE Leap 16, and sum). The rest are quoted only: the kernel’s panic and log line, which a user-mode run cannot reach, the shells’ and Python’s words for a signal, the TensorFlow and MongoDB messages, the Native AOT message of .NET and glibc’s checks for x86-64-v4 and APX.