TT Lab
はじめる
学ぶ 学習パス コース

閉域網へのGPUドライバ搬入と導入

ドライバパッケージ群の形

TT Labで続きを見る

一言でいうと

NVIDIAドライバーは、パッケージ1つではなく、カーネルモジュール / ユーザー空間ライブラリ / ユーティリティ / ディスプレイドライバーの4つの方向が絡み合った、まとまりです。

なぜ必要なのか

nvidia-driver-550だけを取得すれば済むように思えますが、それはメタパッケージです。実際のファイルは1つも入っておらず、依存関係の一覧だけがあります。その一覧をたどると、十数個が出てきます。

どう動くのか

4つの方向

nvidia-driver-550  (메타)
├─ nvidia-kernel-dkms-550        커널 모듈 소스 (DKMS 로 빌드)
│  ├─ dkms
│  ├─ nvidia-kernel-common-550
│  └─ linux-headers-*            <- 커널 버전에 묶인다
├─ nvidia-utils-550              nvidia-smi 등
│  ├─ nvidia-compute-utils-550
│  └─ libnvidia-compute-550      CUDA 런타임 (Provides: libcuda1)
│     └─ libnvidia-cfg1-550
├─ libnvidia-gl-550              OpenGL/GLX/EGL
└─ xserver-xorg-video-nvidia-550 X.Org 드라이버

ここで、エアギャップ環境の観点での落とし穴が、3つ出てきます。

1. linux-headersは、カーネルのバージョンに結び付いています。DKMSがカーネルモジュールをビルドするには、実行中のカーネルのヘッダーが必要です。ところが、カーネルが更新されると、ヘッダーのパッケージ名も変わります。持ち込み時点のカーネルと、インストール対象のカーネルが違うと、ビルドが失敗します。そのため、持ち込み前に、対象サーバーのuname -rを確認することが、最初のステップです。

2. Providesで満たされる依存があります。libnvidia-compute-550は、libcuda1をProvidesします。そのため、libcuda1を要求するパッケージがあっても、リポジトリにlibcuda1という名前のパッケージはありません。この関係を知らずに、「libcuda1がない」と探し回ることが、よくあります。

3. コンテナツールキットは、別のまとまりです。

nvidia-container-toolkit
├─ nvidia-container-toolkit-base     nvidia-ctk, 런타임 바이너리
└─ libnvidia-container-tools         nvidia-container-cli
   └─ libnvidia-container1           공용 라이브러리

ドライバーとツールキットは、リポジトリも違い、バージョン体系も違います。ドライバーは、ディストリビューションのリポジトリやNVIDIAのリポジトリから、ツールキットは、NVIDIAの別のリポジトリから来ます。持ち込むとき、片方だけを用意するミスが多いです。

グラフを解く方法

apt側のツールです。

apt-get install --print-uris -y nvidia-driver-550     # 받을 URI 목록만
apt-get install --download-only -y nvidia-driver-550  # 받기만
apt-cache depends --recurse --no-recommends --no-suggests nvidia-driver-550
apt-rdepends nvidia-driver-550                         # 별도 패키지
dpkg-deb -f pkg.deb Depends                            # 파일에서 직접 읽기

クロージャ(closure)の検査が核心です。バンドルの中のすべてのパッケージが要求するものが、全部バンドルの中にあるか。1つでも外を指していると、内側でインストールが止まります。リポジトリを作成して、apt-get install -s(シミュレーション)を実行してみるのが、最も確実な検査です。

インストール順序の導出

dpkg -iで1つずつインストールするときは、依存が先に来る必要があります。トポロジカルソート(topological sort)の問題です。

libnvidia-cfg1-550
libnvidia-compute-550
nvidia-compute-utils-550
nvidia-utils-550
libnvidia-gl-550
xserver-xorg-video-nvidia-550
nvidia-kernel-common-550
dkms
linux-headers-...
nvidia-kernel-dkms-550
nvidia-driver-550

aptを使えるなら、この順序をaptが自動で決めてくれるので、一覧だけあれば済みます。ただし、順序を導出できることと、aptに任せることは、違います。aptが失敗したとき、どこで途切れたかを読むには、グラフを理解している必要があります。

現場での姿

DKMSビルドの失敗: 持ち込みは成功したのに、インストール中にカーネルモジュールのビルドが失敗します。ログを見ると、ヘッダーがなかったり、コンパイラーのバージョンが合っていなかったりします。そのため、GPUノードは、カーネルの更新をholdで固定していることが多いです。カーネルが上がると、ドライバーをもう一度ビルドする必要があり、エアギャップ環境では、それがもう1回の持ち込みになるからです。

Secure Boot: 署名されていないカーネルモジュールは、Secure Bootが有効なシステムでは、ロードされません。MOK登録の手続きが追加で必要で、これは物理コンソールへのアクセスを要求します。

次のラボですること

持ち込んだと仮定したソースツリーから、.debを直接ビルドして、依存関係グラフをパースし、バンドルの中で解決されない依存を見つけ出し、トポロジカルソートで、インストール順序を導出します。