CPU 機能の不足によるエラーメッセージ

このようにして失敗するプログラムには 2 種類あります。一方は起動時にプロセッサーを確認し、独自のメッセージを出して停止します。より新しいレベル向けにビルドされたディストリビューションの C ライブラリ、Go ランタイム、.NET がこれにあたります。もう一方は、プロセッサーにない命令に到達するまでそのまま動き続け、カーネルがシグナル SIGILL でそれを終了させます。シェルはこれを「Illegal instruction」と報告します。

いずれの場合も、原因はオペレーティングシステムから見たプロセッサーです。仮想マシンではそれはハイパーバイザーの CPU モデルであり、ハードウェアより古いことがよくあるため、多くの場合、直すのに必要なのは新しいハードウェアではなく設定の変更です。

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

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

システムの C ライブラリである glibc が x86-64-v2 向けにビルドされており、プロセッサーに x86-64-v2 の機能 (SSE3、SSSE3、SSE4.1、SSE4.2、POPCNT、CMPXCHG16B、LAHF/SAHF) のうち少なくとも 1 つが欠けています。動的ローダーはプログラムを起動するとき、プログラム自身のコードが実行される前にレベルを確認し、終了ステータス 127 で終了します。そのため、動的リンクされたすべてのプログラム (シェル、ls、パッケージマネージャー) がこのメッセージで失敗します。

このメッセージは Red Hat Enterprise Linux 9 と、Rocky Linux 9 や AlmaLinux 9 などの派生ディストリビューションで出ます。x86-64-v2 に満たない場合は、ローダーがレベルを順に確認するため、RHEL 10 とその派生ディストリビューションでも出ます。SLES 16 と openSUSE Leap 16 は、SSE4.1 を持つ QEMU の Penryn モデルの下でこのメッセージを出力しました。SSE4.1 を持たないモデルの下では、それより先に各プログラムが「Illegal instruction」で終了しました (そちらの例を参照してください)。コンテナーはホストのプロセッサー上で動くため、これらのイメージのコンテナーも同じように失敗します。ほかのシステムはシステムごとに必要なレベルに載っています。

マシンの確認。 影響を受けたシステムでは動的リンクされたものは何も動かず、grep もローダー自身の --help も動かないので、外側から確認してください。仮想マシンやコンテナーのホスト上で、または同じハードウェア上で起動した別のシステムで確認します (確認方法)。仮想マシンの場合、結果を決めるのはその設定の CPU モデルです。

直し方。 仮想マシンでは、x86-64-v2 を持つ CPU モデルを選ぶか、ホストのプロセッサーをパススルーしてください。QEMU、libvirt、Proxmox VE、VMware vSphere、Hyper-V のいずれでも設定できます。QEMU のデフォルトの qemu64 モデルと、それより古い kvm64 は x86-64-v2 に満たないモデルです。x86-64-v2 に満たないハードウェアではシステムは動きません。取れる選択肢を参照してください。

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

Red Hat Enterprise Linux 10、CentOS Stream 10、Rocky Linux 10、AlmaLinux 10 のように、C ライブラリが x86-64-v3 向けにビルドされている場合の同じチェックです。プロセッサーは x86-64-v2 を持っていますが、x86-64-v3 の機能のいずれかが欠けています。その機能とは AVX、AVX2、BMI1、BMI2、F16C、FMA、LZCNT、MOVBE、そしてオペレーティングシステムによる AVX レジスターのサポート (OSXSAVE) です。上のメッセージは、Red Hat の UBI 10 minimal イメージ (RHEL 10.2) の bash を QEMU の Nehalem モデル (AVX を持たない x86-64-v2 のプロセッサー) の下で実行して記録したもので、終了ステータスは 127 でした。x86-64-v2 に満たない qemu64 の下では、代わりに x86-64-v2 のメッセージを出力しました。

よくある原因は、Proxmox VE が新しい VM に使うデフォルトの CPU タイプ x86-64-v2-AES、古い VMware EVC モード、そして Comet Lake まで AVX を持たない Intel の Pentium と Celeron プロセッサーです (x86-64-v3 を参照)。

直し方。 VM では、Proxmox の x86-64-v3 や host など、x86-64-v3 を持つ CPU モデルを使います (詳細)。x86-64-v2 のマシンでも RHEL 9 とその派生ディストリビューションはまだ動きます。また、AlmaLinux は AlmaLinux 10 を x86-64-v2 向けにもビルドしています (要件)。

glibc には、C ライブラリが x86-64-v4 や APX 向けにビルドされたシステムのための同じチェックもあります。メッセージは Fatal glibc error: CPU does not support x86-64-v4 と 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

これは起動中に出る glibc のメッセージです。カーネルが最初に起動するプログラムである init は動的リンクされているため、レベルのチェックに失敗して終了ステータス 127 で終了します。カーネルは init なしでは動けないので停止します。0x00007f00 は、終了ステータス 127 (0x7f) をカーネルが報告する形式で表したものです。glibc のメッセージはその前の行にあり、レベルを示しています。

1 行目は、x86-64-v2 に満たない場合に RHEL 9 のプログラムが出力するものです。QEMU の qemu64 モデルの下で実行して記録したところ、Red Hat の UBI 9 micro イメージ (RHEL 9.8) の bash がこれを出力して終了ステータス 127 で終了し、x86-64-v2 のモデルである Nehalem の下では動きました。2 行目は init が終了したときのカーネルの文言で、カーネルのソースから引用したものです。記録に使った QEMU のユーザーモードは、システムではなくプログラムを起動するため、システムの起動は記録していません。直し方は glibc のメッセージと同じです。ライブラリが見つからない場合など、init のほかの失敗も終了ステータス 127 で終わるため、それらを見分ける手がかりはパニックの上の行です。

CPU ISA level is lower than required#

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

プログラム、またはそれが読み込むライブラリに、必要な x86-64 レベルを示すノートが含まれており、プロセッサーがそのレベルを持っていません。GCC 14 と -march=x86-64-v3 -mneeded でビルドしたプログラムを QEMU の Nehalem モデルの下で実行して記録したところ、起動に使われたパスを付けてこのメッセージを出力し、終了ステータス 127 で終了しました。glibc の動的ローダーはプログラムが始まる前にノートを読み、終了ステータス 127 で終了します。後から dlopen で読み込むライブラリも同じ文言で失敗します。ノートは、GCC が -mneeded で、リンカーが -z x86-64-v3 などのオプションで書き込みます。readelf で表示できます。

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

直し方。 プロセッサーが持つレベル向けにビルドされたプログラムをインストールしてください。たとえば、ディストリビューションの x86-64-v3 パッケージではなくベースラインのパッケージを使います。または、仮想マシンにそのレベルを持つ CPU モデルを与えてください (レベルの確認)。

Illegal instruction (core dumped)#

$ ./sum
Illegal instruction (core dumped)

プログラムがプロセッサーにない命令を実行し、カーネルがシグナル SIGILL でプログラムを停止させました。プログラムが新しいプロセッサー向けに (たとえば -march=x86-64-v3 で) ビルドされているか、そのようにビルドされたライブラリを使っており、しかもプロセッサーを一度も確認していません。「Illegal instruction」は C ライブラリが SIGILL に付けた名前で、プログラムがこのシグナルで終了すると Bash などのシェルがこれを出力します。「(core dumped)」は、システムがコアダンプを保存したときに続き、そうでなければ付きません。

ほかのプログラムは、同じシグナルを独自の言葉で報告します。

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

2 行目は Python の faulthandler で、pytest はこれを有効にします。終了ステータスは 132 (128 に SIGILL の番号 4 を足した値) です。以下の記録は docker run --init で実行したもので、Docker は SIGILL で終了したそれぞれのコンテナーについて同じ終了コードを報告しました。

古い CPU モデルを使い、QEMU 10.0 のユーザーモードで記録した例です。

• NumPy 2.5.3 での import numpy は、x86-64-v2 に満たない qemu64 の下で、ライブラリ内の SSE4.1 命令 (PINSRQ) により SIGILL で終了しました。NumPy は 2.4 以降 x86-64-v2 を必要とします。Nehalem の下ではインポートできました。
• MongoDB 8.0.32 の mongod --version は、AVX を持たない Nehalem の下で、AVX 命令 VMOVDQA により SIGILL で終了しました (MongoDB を参照)。
• SLES 16 と openSUSE Leap 16 の動的ローダーには x86-64-v2 のチェックがありますが、その前に SSE4.1 命令 PINSRQ を実行します。SSE4.1 を持たない QEMU の qemu64、kvm64、Conroe モデルの下では、両者の 16.0 イメージの ls と bash がその PINSRQ で SIGILL により終了しました。SSE4.1 は持つものの SSE4.2 も POPCNT も持たない Penryn では、ローダーが glibc のメッセージを出力しました。

命令の特定。 シグナルで停止するデバッガーの下でプログラムを実行し、停止した位置の命令を表示します。

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

記録に使った sum プログラム (GCC 14 と -O3 -march=x86-64-v3 でビルドしたループ) は、QEMU の Nehalem モデルの下で vmovdqa ymm0, ... で終了しました。YMM レジスターを使う VMOVDQA は AVX 命令です。このことは命令リファレンスのこの命令のページに、プロセッサーがその命令を持つかどうかを示す CPUID ビットとともに書かれています。次にマシンを確認し、そのレベルと機能を x86-64-v3 または該当する拡張のページと比べてください。

直し方。 プロセッサーに合ったビルドのプログラムを使ってください。たとえば、ベースライン向けにコンパイルしたビルドや、実行時ディスパッチを使うビルドです。あるいは、欠けている拡張を持つプロセッサー (または VM の CPU モデル) を使ってください。多くのプロジェクトは最小要件を明示しています。いくつかを要件に載せています。

zsh: illegal hardware instruction#

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

Illegal instruction と同じ SIGILL を、macOS のデフォルトのシェルである zsh の言葉で表したものです。コアダンプがない場合、この行に「(core dumped)」は付きません。

trap invalid opcode#

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

カーネルログ (dmesg または journalctl -k) には、ハンドラーなしで SIGILL により終了したプログラムごとに、このような行が残ります。この行は、プログラムとそのプロセス ID、命令のアドレス (ip)、命令があったファイルを、マッピングのアドレスとサイズとともに示します。Linux 7.3 など新しいカーネルは、sum[10a5,558d7ecb2000+1000] のようにファイル内での命令のオフセットも出力するため、命令が共有ライブラリにある場合でもファイル内の位置がわかります。

上の行は、古いカーネルが出力する、オフセットのない形式を示しています。そのプログラム、プロセス ID、アドレスは例であり、記録した行ではありません。記録に使った QEMU のユーザーモードは、カーネルのハンドラーに到達しないためです。カーネルはこの行を記録する数を制限しており、debug.exception-trace = 0 で出力を止められます。

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

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

GOAMD64=v2、v3、v4 でビルドした Go プログラムは、Go のコードを実行する前にプロセッサーを確認し、自分のレベルを含むこのメッセージを出力して終了ステータス 1 で終了します。Go 1.27.1 で実行して記録したところ、GOAMD64=v3 でビルドしたプログラムが QEMU の Nehalem モデルの下で上のメッセージを出力し、GOAMD64=v2 でビルドしたプログラムが qemu64 の下で v2 を含む同じメッセージを出力しました。デフォルトの GOAMD64=v1 は、すべての x86-64 プロセッサーで動きます。メッセージはレベルを示します。v2 は x86-64-v2、v3 は x86-64-v3、v4 は x86-64-v4 を意味します。

直し方。 GOAMD64=v1 go build のように、より低い GOAMD64 でプログラムをビルドし直すか、プロジェクトが古いプロセッサー向けのビルドを公開していればそれを入手してください。VM では、そのレベルを持つ CPU モデルでも解決できます。

.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)

.NET 11 以降、ランタイムは x86-64 プロセッサーで x86-64-v2 を必要とし、起動時に、メッセージに挙げた命令セットを確認します。.NET SDK 11.0.100-rc.1 でビルドしたプログラムを QEMU の qemu64 モデルの下で実行して記録したところ、上の行を出力し、SIGABRT (終了ステータス 134) で終了しました。シェルはこれを「Aborted」と報告します。Nehalem の下では動きました。Microsoft による変更の告知には、より短いメッセージ The current CPU is missing one or more of the baseline instruction sets. が載っていますが、これはランタイムがほかのアーキテクチャーで出力するものです。ベースラインより多くの命令セット向けに事前コンパイル (Native AOT) したアプリケーションは、それらを持たないプロセッサー上で The current CPU is missing one or more of the required instruction sets. を出して停止します。

直し方。 x86-64-v2 を持つプロセッサーまたは VM の CPU モデルを使ってください。.NET 10 以前は、まだベースラインで動きます。

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 は読み込まれるときに、コンパイル時に対象とした命令セットを確認し、どれかが欠けているとこのメッセージを出して中断 (abort) します。公式のバイナリは AVX を使います。AVX2 や FMA など、ほかの拡張を使うビルドでは、同じメッセージがそれらの拡張の名前を挙げます。

これとは別の次のメッセージは、エラーではありません。

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.

これは、プロセッサーが持っていてビルドが使っていない拡張を挙げるもので、TensorFlow は通常どおり動きます。

直し方。 AVX を持つプロセッサーまたは VM の CPU モデルを使うか、そのプロセッサー向けにソースからビルドした TensorFlow を使ってください。

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!

MongoDB の公式 Docker イメージは、/proc/cpuinfo に avx がないとこの警告を出力し、それでも mongod を起動します。QEMU の Nehalem モデルの下で実行して記録したところ、AVX がないため mongod は SIGILL で終了しました。Docker イメージではなく MongoDB の Debian 12 向け tarball に含まれる MongoDB 8.0.32 の mongod --version が VMOVDQA で停止し、Docker は終了コード 132 を報告しました。Docker の外では警告は出ず、「Illegal instruction」だけが出ます。MongoDB 5.0 以降は x86-64 で AVX を必要とするため、最小要件は x86-64-v2 と x86-64-v3 の間に位置します。Sandy Bridge と Bulldozer は AVX を持ちますが、Tiger Lake より前の Intel の Pentium と Celeron のほとんどのモデルは持っていません。

直し方。 AVX を持つプロセッサーまたは VM の CPU モデルを使ってください。VM では、ホストが AVX を持っていても CPU モデルがそれを隠していることがよくあります。VM を参照してください。

Windows 11 24H2 が起動しない#

Windows 11 バージョン 24H2 は SSE4.2 と POPCNT の命令を使っており、これらを持たないプロセッサーでは起動しません。原因を示すメッセージは出ないため、ここに引用できるものはありません。Microsoft は SSE4.2 と POPCNT を Windows Server 2025 のプロセッサー要件に挙げており、Windows 11 には x86-64-v2 の命令セットが必要だと述べています。

これらを持たないプロセッサーは、Intel の Core 2 や AMD の Phenom など、x86-64-v2 に満たないものです。仮想マシンでは、QEMU の qemu64 や kvm64 など、SSE4.2 と POPCNT を持たない CPU モデルでも同じ失敗が起きます。より新しいモデルを選んでください。Coreinfo で、プロセッサーが両方を持つかどうかがわかります。

これらのメッセージの確認方法#

各メッセージは、それを出力するプログラムのソースコードから、下の出典に挙げたリリースの時点のものを引用しています。多くは実際に動かして記録もしており、その実行はこのページの各所で示しています。対象は各システムのプログラムや、この目的のためにビルドしたプログラムで、示した CPU モデルを使い QEMU 10.0 のユーザーモードで動かしました。サイトのテストは、その出力をこのページと比較しています。記録した対象は、glibc の x86-64-v2 と x86-64-v3 のメッセージ (RHEL 9 と 10、SLES 16 と openSUSE Leap 16)、ISA レベルのノート、Go と .NET のメッセージ、そして終了ステータス 132 の SIGILL (NumPy、MongoDB、SLES 16 と openSUSE Leap 16 のローダー、sum) です。残りは引用のみです。ユーザーモードの実行では到達できないカーネルのパニックとログの行、シグナルに対するシェルと Python の文言、TensorFlow と MongoDB のメッセージ、.NET の Native AOT のメッセージ、そして glibc の x86-64-v4 と APX のチェックです。