本記事の位置づけ
本記事は、
Debian 13(Trixie)で NVIDIA ドライバを「壊さず・詰ませず」導入するための下地作りを行う回です。
ここでは、
- NVIDIA ドライバは まだ入れない
- nouveau の無効化も まだしない
- やるのは ビルド環境とファームウェアの準備だけ
しかし、この回を飛ばすと──
- ドライバ導入時にビルド失敗
- カーネル更新で NVIDIA が突然死
- ブラックスクリーンで復旧不能
という 地獄ルートに直行します。
静かだが最重要な回です。
なぜ「下地」が必要なのか
NVIDIA のプロプライエタリドライバは、
Debian では DKMS(Dynamic Kernel Module Support) を使って管理されます。
これはつまり:
- カーネルが更新されるたびに
- NVIDIA カーネルモジュールを
- その場でビルドし直す
という仕組み。
👉 だから ビルド環境が壊れていると、その瞬間に詰む。
DKMSとは何か(最低限)
DKMS は、
- カーネルと密結合する外部ドライバを
- カーネル更新に追従させる仕組み
です。
NVIDIA ドライバは:
- カーネル内部に含まれない
- しかしカーネルと深く連携する
という性質を持つため、
DKMS なしでは安定運用が不可能。
build-essential が必要な理由
build-essential は以下を含むメタパッケージです。
- gcc / g++
- make
- libc 開発ヘッダ
つまり、
「C/C++で書かれたカーネルモジュールをビルドする最低条件」
NVIDIA ドライバのカーネル部分は
コンパイルが必須。
これが無いと:
- インストール途中でエラー
- あるいは「一見成功したが次の再起動で死亡」
という最悪パターンになる。
linux-headers が無いと何が起きるか
linux-headers は、
- 現在使っているカーネルと
- 完全一致する
- カーネル開発用ヘッダ
です。
これが無いと DKMS は:
- コンパイル対象を見失う
- バージョン不一致で失敗
- カーネル更新時に再ビルド不可
👉 「最初は動いたのに、apt upgrade 後に画面が出なくなる」
原因の9割がここ。
firmware-misc-nonfree の意味
RTX 30 系以降の NVIDIA GPU は、
- GPU 本体
- 電源管理
- 初期化処理
- 周辺機能
の一部に 非公開ファームウェアを必要とします。
Debian 13 ではこれがnon-free-firmware セクションに分離されています。
その中核が:
firmware-misc-nonfreefirmware-linuxfirmware-linux-nonfree
これらが無いと:
- ドライバは入る
- でも GPU が正しく初期化されない
- 結果として不安定・ブラックアウト
という 一番分かりにくい失敗が起きる。
本シリーズで行う方針(結論)
この回では、以下を 先に揃える。
- DKMS が正常に動く環境
- カーネルヘッダとビルド環境
- NVIDIA が要求するファームウェア
そして:
- nouveau はまだ触らない
- NVIDIA ドライバもまだ入れない
- 再起動も不要
👉 次回(第5回)で
nouveau を完全無効化する準備が整う。
この回を飛ばすとどうなるか
正直に書く。
- 表面上は手順通りに見える
- NVIDIA ドライバも一度は入る
- しかし 数日〜数週間後に壊れる
そのとき、
- 何が原因か分からない
- ログイン画面が出ない
- 画面が真っ黒
- 再インストールしか残らない
という流れになる。
この回で分かったこと
- NVIDIA ドライバは「入れる前」が9割
- DKMS・ヘッダ・ビルド環境は必須
- firmware を後回しにすると詰む
- Debian 公式構成だけで十分
- 急がないほうが、最終的に早い
次回予告(第5回)
次回は、
最大の鬼門に入ります。
🔹 第5回:nouveauを完全に殺す
NVIDIAプロプライエタリ導入前の必須作業
- nouveau がなぜ危険か
- 中途半端な共存が地獄な理由
- blacklist と initramfs の正しい扱い
- 失敗例と回避策
👉 この回がシリーズ最大の分岐点。

