VMware Workstation の Linux カーネルヘッダーエラー：バージョン一致、ビルド、Secure Boot の診断

「Kernel headers for version … not found」が意味するのは、VMware が現在の Linux ホストカーネル用の vmmon と vmnet を準備できなかったということだけです。任意の headers パッケージを入れれば直るという意味ではありません。まずホスト OS、実行中カーネル、VMware 製品バージョンが公式サポート対象の組み合わせだと確認し、正確な開発パッケージ、ビルドツールチェーン、ビルドログ、Secure Boot 署名を別々に調べます。

Table of Contents

1. まず四つの失敗を区別する

段階	典型的な証拠	対応方向
ビルドツリーが見つからない	`/lib/modules/現在のカーネル/build` がない、読めない、またはリンク切れ	実行中カーネルと完全一致する公式 headers/devel をインストールする
コンパイル失敗	`vmware-modconfig` ログにコンパイラ、API、Makefile、依存関係のエラー	ツールチェーンと VMware/カーネル互換性を確認し、第三者パッチで隠さない
ビルド成功後にロード失敗	`modinfo` では見つかるが、カーネルログに署名、鍵、lockdown が出る	Secure Boot を維持し、VMware とディストリビューションの手順で両モジュールを署名・登録する
製品/ホストが非対応	公式マトリクスにディストリビューション、カーネル、アーキテクチャ、製品の組み合わせがない	パッチ作業を止め、VMware 更新または対応ホストへの移行を計画する

操作前にどの段階で失敗したかを特定します。正しい headers でも非互換なカーネル API は修復できません。ビルド成功だけでは Secure Boot がロードを許可する証明にもなりません。

2. サポートマトリクスが最初のゲート

VMware の完全なバージョン、Linux ディストリビューションのリリース、uname -r、uname -m を記録し、Broadcom の最新 Workstation Pro/Player ホストサポートマトリクスと一項目ずつ照合します。マトリクスは製品バージョン、ディストリビューションのポイントリリース、カーネル上限ごとに異なります。「Linux で動く」ことや「ディストリビューションが保守中」であることは、その組み合わせを VMware がサポートする意味ではありません。ホストサポートと guest OS サポートも別です。

2026-09-01 の確認時点で、マトリクスには特定の Ubuntu、Debian、Fedora、RHEL、SUSE/openSUSE などの組み合わせがありますが、Arch Linux は対応ホストとして記載されていません。Arch の headers 文書はバージョン一致の理解には役立ちますが、そのホストを VMware 対応にはしません。カスタム、mainline、リアルタイム、クラウドベンダー、ローリングリリースのカーネルも、ディストリビューション名だけで推測せず明示的に確認します。

現在の組み合わせが掲載されていなければ、カーネルの無作為なダウングレード、別バージョンからの headers コピー、コミュニティパッチ、vermagic の強制無視を行わないでください。対応可能な経路は、ベンダーがサポートする VMware とホスト/カーネルの組み合わせを使うか、Broadcom とディストリビューションベンダーから例外確認を得ることです。

3. 読み取り専用の棚卸しから始める

VM を正常終了し作業を保存しますが、まだインストール、再起動、署名、再ビルドはしません。次のコマンドはバージョン、パス、状態だけを集めます。任意ツールがなければ対応行は失敗することがありますが、それも記録すべき証拠です。

uname -r
uname -m
cat /etc/os-release
vmware --version
command -v vmware vmware-modconfig gcc cc make perl ld mokutil dkms
cat /proc/version
gcc --version
make --version
ld --version
readlink -f "/lib/modules/$(uname -r)/build"
stat "/lib/modules/$(uname -r)/build"
if test -r "/lib/modules/$(uname -r)/build/Makefile"; then echo build_tree_readable=yes; else echo build_tree_readable=no; fi
command -v mokutil >/dev/null && mokutil --sb-state
command -v dkms >/dev/null && dkms status
modinfo vmmon
modinfo vmnet
lsmod | grep -E '^(vmmon|vmnet) '
find /tmp/vmware-root -maxdepth 1 -type f -name 'vmware-*.log' -print 2>/dev/null
journalctl -k -b --no-pager | grep -Ei 'vmmon|vmnet|module|signature|secure boot|lockdown'

ログを共有する前に、ユーザー名、ホスト名、パス、VM 名、ライセンス情報、ネットワーク情報をマスクします。/tmp 全体、完全なシステムジャーナル、VM 設定、ディスクをアップロードしないでください。コマンドの終了状態も記録します。空の出力、権限拒否、コマンド不在を「正常」と報告してはいけません。

4. 正確に一致させる対象は実行中カーネル

ディストリビューションの release、flavor、アーキテクチャ接尾辞を含む uname -r の全文が対象です。/lib/modules/$(uname -r)/build はそのカーネル用にディストリビューションが提供し、利用可能な設定済みビルドツリーを指す必要があります。ユーザー空間 API 用 kernel-headers だけでは外部モジュールに不足することがあります。たとえば Fedora は kernel-devel を一致するカーネル向けモジュール構築用 headers と Makefile と定義し、kernel-headers はユーザー空間ライブラリ向けです。

「近い」ツリーへのリンクを手作業で作らず、別のコンピュータや別カーネルの /usr/src をコピーしないでください。カーネル release、設定、生成済みヘッダー、シンボルバージョン、コンパイラ前提が違う可能性があります。コンパイルが完了してもロードを拒否されたり、安全でなかったりします。

新しいカーネルをインストールした後でまだ再起動していなければ、現在の対象は古い uname -r のままです。その実行中カーネルの正確なパッケージを取得するか、コンソール回退を備えた保守時間にインストール済みの対応新カーネルを起動します。二つのバージョンを混ぜないでください。

5. インストールコマンドを推測する前にディストリビューション別に確認する

まず各ディストリビューションのパッケージデータベースでファイル所有元を確認します。以下はすべて読み取り専用です。

Debian/Ubuntu：

dpkg-query -W "linux-image-$(uname -r)" "linux-headers-$(uname -r)" build-essential gcc make perl
apt-cache policy "linux-headers-$(uname -r)" build-essential gcc make perl
dpkg-query -S "$(readlink -f "/lib/modules/$(uname -r)/build")/Makefile"

Fedora：

rpm -q "kernel-core-$(uname -r)" "kernel-devel-$(uname -r)" gcc make perl elfutils-libelf-devel
dnf info "kernel-devel-$(uname -r)"
rpm -qf "$(readlink -f "/lib/modules/$(uname -r)/build")/Makefile"

default flavor の SUSE/openSUSE：

rpm -q kernel-default kernel-default-devel gcc make perl
zypper search --installed-only --details kernel-default kernel-default-devel gcc make perl
rpm -qf "$(readlink -f "/lib/modules/$(uname -r)/build")/Makefile"

Arch 標準カーネル。パッケージ識別専用であり、VMware 対応の証明ではありません。

pacman -Qo "$(readlink -f "/usr/lib/modules/$(uname -r)/build")/Makefile"
pacman -Q base-devel

low-latency、real-time、LTS、debug、カスタム flavor ではパッケージ名が異なります。正確な release が見つからなければ、メタパッケージの「最新」を実行中バージョンとみなさず、非公式リポジトリで近似パッケージを探さないでください。

6. 対応組み合わせにだけ正確な依存関係を入れる

対応 Debian/Ubuntu の組み合わせで、公式リポジトリに実行中カーネルの正確なパッケージがある場合だけ、承認された保守時間に実行します。

sudo apt update
sudo apt install "linux-headers-$(uname -r)" build-essential

対応 Fedora の組み合わせでは、Fedora のモジュール開発パッケージと Broadcom の前提条件は次に対応します。

sudo dnf install "kernel-devel-$(uname -r)" gcc make perl elfutils-libelf-devel

SUSE/openSUSE では、現在の kernel flavor/release に一致する公式 kernel-devel/kernel-default-devel と、ディストリビューションが要求するコンパイラを使います。Leap 16 のリリースノートは、モジュール構築にはカーネル構築時と同じコンパイラバージョンが必要だと特に注意しています。あるリリースの GCC パッケージ名を別リリースへコピーしないでください。YaST、公式リポジトリ、そのリリースの文書で正確なパッケージを選びます。

パッケージマネージャーが正確なパッケージは存在しないと報告したら停止します。実行中カーネルがリポジトリから削除済み、リポジトリが不完全、カスタムカーネル、または非対応ホストが一般的な原因です。その失敗を近似バージョンのインストールに置き換えないでください。

7. コンパイラとツールチェーンも一致関係の一部

/proc/version には通常、カーネル構築に使ったコンパイラが記録されています。gcc --version、リンカー、Make と比較します。表示バージョンの違いだけで必ず失敗するわけではありませんが、ビルドログの compiler mismatch、cc、make、perl、ELF 開発ファイル不足、警告のエラー化は、そのディストリビューションと VMware リリースのサポート資料に従って解消します。

Makefile の改変、警告の無効化、コンパイラバージョンの偽装、未知の配布元からのビルド済み vmmon.ko/vmnet.ko 取得は行わないでください。外部モジュールは正確なツリーに対して構築する必要があります。カーネル文書も version magic とシンボルバージョンがロード検査に関わると説明しています。

8. 保守時間に再ビルドしログを保存する

サポートマトリクス、正確なビルドツリー、ツールチェーンがすべて通った後だけ、すべての VMware VM とサービスを停止し、端末から VMware 付属モジュール設定ツールを実行します。ログ名は時刻付きで上書きを拒否し、pipefail でビルド終了コードを保持します。

LogPath="vmware-modconfig-$(date +%Y%m%d-%H%M%S).log"
test ! -e "$LogPath" || exit 1
set -o pipefail
sudo vmware-modconfig --console --install-all 2>&1 | tee "$LogPath"

Broadcom は、インストール/初回起動ログが /tmp/vmware-root/vmware-PID.log に作られる場合もあると説明しています。該当する PID と時刻の最新ログを読み、以前の失敗を今回の実行と混同しないでください。ログを自動削除せず、先に終了コード、VMware バージョン、カーネルバージョン、パッケージ照会結果を保存します。

9. ビルド成功後にモジュールの身元を確認する

ロード前に各モジュールの場所、対象カーネル、署名者を確認します。

uname -r
modinfo -F filename vmmon
modinfo -F vermagic vmmon
modinfo -F signer vmmon
modinfo -F filename vmnet
modinfo -F vermagic vmnet
modinfo -F signer vmnet
journalctl -k -b --no-pager | grep -Ei 'vmmon|vmnet|signature|secure boot|lockdown'

vermagic は現在のカーネルと互換で、ファイルはそのカーネルのモジュールツリー内にあるべきです。signer が空であることだけでは失敗の証明になりません。Secure Boot 状態とカーネルログを併せて判断します。modprobe --force-vermagic、insmod --force、署名強制の無効化でテストを通さないでください。

10. Secure Boot：ビルドとロードは別のゲート

Broadcom は Secure Boot 有効時、vmmon と vmnet の両方に署名が必要で、なければ VM を開始できないと説明しています。Ubuntu、Debian、SUSE の文書も Secure Boot 下の自作外部モジュールに信頼された署名を要求します。

Broadcom の署名 KB は古い Workstation/Ubuntu 環境を例にし、コマンドはディストリビューションごとに異なると明記しています。両モジュールに署名が必要という製品境界の確認に使い、実際の sign-file、MOK パス、鍵管理手順は最新のディストリビューション文書で決めます。古いパスをそのままコピーしないでください。

Secure Boot を「修正」として無効化しないでください。最新の VMware KB とディストリビューションの MOK/モジュール署名手順に従います。秘密鍵を保護し、共有ディレクトリ、サポートチケット、ログに置かないでください。物理または帯域外コンソールで MOK 登録を確認し、両モジュールを署名し、モジュール再ビルドのたびに再検証します。署名、鍵登録、再起動はセキュリティ状態の変更であり、デバイス所有者の承認が必要です。

モジュールはビルドできたのに modprobe や VMware 起動で Key was rejected、Required key not available、signature、lockdown エラーが出る場合は、headers の再ビルドを繰り返さず署名手順へ戻ります。

11. DKMS、ディストリビューションパッケージ、VMware インストーラーを混同しない

DKMS はカーネル更新後に外部モジュールを再構築できますが、VMware 公式インストーラーは通常 vmware-modconfig で vmmon/vmnet を構築します。ディストリビューションの包装がそれらを明示的に登録した場合だけ、dkms status が権威ある証拠になります。DKMS がインストール済みというだけでは、VMware モジュールの管理を意味しません。

Broadcom bundle、ディストリビューションパッケージ、AUR/コミュニティパッケージ、第三者モジュールソースを混在させないでください。まずパッケージマネージャーとインストール記録から所有元を確認します。所有元が不明または重複する場合は、管理者が一つの対応インストール経路を選ぶまで停止します。

12. 証拠から次の手順への表

証拠	結論の境界	次の手順
`build` パスなし、正確なパッケージが公式リポジトリにある	ビルド依存が不足	正確な公式 devel/headers とツールチェーンを入れ、パスを再確認
正確なパッケージがない	旧式/カスタムカーネル、リポジトリ、サポート問題	近似版を入れず、リポジトリ、起動カーネル、マトリクスを確認
ビルドログにカーネル API エラー	headers が誤りとは限らない	VMware/カーネルサポートを確認してベンダーへエスカレーション
compiler/ELF/Make 依存エラー	ツールチェーン不足または不一致	公式ディストリビューション依存と指定コンパイラを使う
`modinfo` で見つかるがログが鍵を拒否	Secure Boot のロード失敗	Secure Boot を維持し `vmmon`、`vmnet` を署名・登録
`vermagic` と `uname -r` が非互換	別カーネル用に構築されたモジュール	ロードを止め、現在の対応カーネル向けに再構築
Arch/カスタム/mainline がマトリクスにない	ベンダーサポートの証明なし	対応組み合わせへ移行またはベンダー案件を開く
変更後に遠隔ホストが起動/通信不能	起動/遠隔回退イベント	帯域外コンソールで既知良好カーネルを選び復元

13. 遠隔ホスト、再起動、ロールバック

カーネルのインストール、MOK 登録、再起動前に、保守時間、VM の正常終了記録、重要 VM の独立バックアップ、現在のパッケージ/カーネル一覧、起動確認済みベンダーカーネル、起動メニューへのアクセス、物理または帯域外コンソールを用意します。スナップショットは独立バックアップではありません。

実行中カーネルや唯一の既知良好カーネルを削除しないでください。確認済みコンソールがない遠隔システムでは再起動前に停止します。新カーネルで起動、ネットワーク、VMware に回帰が起きたら、起動メニューから保持済みの既知良好ベンダーカーネルを選びます。ネットワークとストレージを確認してからディストリビューションのパッケージマネージャーで失敗版を処理し、/lib/modules を手作業で削除しないでください。

VMware 更新が原因なら、変更前に保存した公式メディア/パッケージとベンダー文書で承認済みロールバックを行うか、検証済みホストバックアップを復元します。「コンパイルできるもの」を求めて無作為な旧製品やカーネルを使わないでください。回退後もサポートマトリクス、モジュールパス、署名、VM 起動テストを再確認します。

14. 次の場合は停止してエスカレーションする

ホストディストリビューション、リリース、アーキテクチャ、カーネル、VMware 製品が最新サポートマトリクスにない。
カーネルがカスタム、mainline、real-time、ベンダープレビュー、または正確な開発パッケージがないほど古い。
第三者パッチ、未知のモジュールバイナリ、vermagic 強制、headers コピー、Secure Boot 無効化が必要になる。
ビルドログに説明できないカーネル API、シンボルバージョン、署名、ライセンス、コンパイラのエラーがある。
本番 VM を載せるホストなのに、バックアップ、保守時間、既知良好起動項目、コンソール回退がない。
モジュール/インストールファイルに複数のパッケージマネージャー所有元がある、またはログの由来、時刻、対象カーネルを対応付けられない。

棚卸し、正確なサポートマトリクス行、パッケージ照会、ビルド終了コード、必要部分だけマスクしたログ、modinfo、カーネルログを Broadcom、ディストリビューションベンダー、またはホスト管理者へ送ります。

15. 完了チェックリスト

[ ] VMware 完全バージョン、ディストリビューション、アーキテクチャ、完全な uname -r を記録した。
[ ] 現在の Broadcom マトリクスで正確なホスト/製品/カーネル組み合わせを確認した。
[ ] build は手動リンクやコピーではなく、現在のカーネル用の読める公式ツリーを指す。
[ ] headers/devel、ユーザー空間 headers、ツールチェーン、VMware 互換性を区別した。
[ ] 全パッケージが公式ディストリビューションリポジトリ由来で、実行中 kernel/flavor と完全一致する。
[ ] VM を停止した保守時間にビルドし、終了コードと対応ログを保存した。
[ ] vmmon、vmnet のパス、vermagic、署名、カーネルログを確認した。
[ ] Secure Boot を維持し、必要なら公式手順で両モジュールを署名・登録した。
[ ] 第三者パッチ、未知モジュール、強制ロード、headers コピー、無作為ダウングレードを使っていない。
[ ] 再起動前に独立バックアップ、既知良好カーネル、物理/帯域外回退を用意した。

16. 公式資料

資料は 2026-09-01 に確認しました。サポートマトリクスとカーネル上限は変化します。本文の日付だけに依存せず、実行前に最新ページを開き直してください。

17. 2013 年の原文アーカイブ（出所確認専用）

次のフェンスには source_export の可視本文全体を一字一句そのまま保存しています。末尾空白の正規化も私的値のマスキングも不要でした。不完全な shell 変数、誤った過去のカーネルバージョン形式、廃止済み HTTP 参照は現行コマンドや推奨リンクではなく、不活性な歴史的証拠です。

~~~~markdown

在Ubuntu终端下执行

sudo apt-get install linux-headers-$

eg.
sudo apt-get install linux-headers-3.5.0.25-generic

Referer link:
http://www.vi-toolkit.com/wiki/index.php/Build_host_vmware_kernel_modules
~~~~