検証計画とロールバック経路
一言でいうと
エアギャップ環境の作業では、ロールバック経路のない変更は行いません。もう一度外に出て、何かを取得してくることが、不可能だからです。
なぜ必要なのか
接続された環境なら、インストールが間違っても、もう一度取得すれば済みます。エアギャップ環境は違います。何かを削除したのに、それをもう一度取得するには、持ち込み審査をまた通す必要があります。元に戻せない作業1つが、数日を生みます。
そのため、エアギャップ環境の作業手続きの半分は、「何を変えたかを記録して、どう元に戻すかを、あらかじめ決めておくこと」です。
どう動くのか
検証計画
実際のGPUがある環境では、インストールの検証は、この順序です。
# 1. 커널 층
lsmod | grep -c nvidia
ls /dev/nvidia*
# 2. 유저 공간 층
nvidia-smi
nvidia-smi --query-gpu=name,driver_version,memory.total --format=csv
# 3. 컨테이너 주입 층
nvidia-ctk cdi list
nvidia-container-cli info
# 4. 실제 컨테이너
podman run --rm --device nvidia.com/gpu=all <cuda 이미지> nvidia-smi
層を順番に確認することが核心です。4番目だけを試して失敗すると、どの層が問題なのかわかりません。1番目から上がっていけば、失敗した場所が、そのまま原因です。
パッケージの完全性
インストール後も、ファイルがそのままかを確認できます。
dpkg -V nvidia-driver-550 # 설치 시점의 해시와 비교
dpkg -V | head # 전체 검사
出力の形式は、??5??????のような文字列です。5はmd5の不一致(内容が変わった)、cは設定ファイルの表示です。設定ファイルが変わっているのは正常ですが、バイナリが変わっていたなら、調査する必要があります。
バージョンの固定
ドライバーは、特に固定が重要です。カーネルが上がると、DKMSの再ビルドが必要で、エアギャップ環境では、それがもう1回の持ち込みです。
apt-mark hold nvidia-driver-550 nvidia-container-toolkit
apt-mark hold linux-image-generic linux-headers-generic
apt-mark showhold
カーネルまで一緒に固定することが、GPUノードの慣行です。
ロールバック経路
aptは、トランザクションのロールバックを直接サポートしていません(dnfのhistory undoのようなものがありません)。そのため、手動で準備します。
# 설치 전 상태 기록
dpkg -l > /var/log/labhub/before.txt
apt-mark showhold > /var/log/labhub/holds.txt
# 설치 로그 확인
cat /var/log/apt/history.log
grep -A3 'Start-Date' /var/log/apt/history.log | tail -20
# 롤백 (제거)
apt-get purge -y nvidia-container-toolkit
apt-get autoremove -y
/var/log/apt/history.logには、各トランザクションの開始時刻、コマンドライン、インストール/削除されたパッケージが記録されます。このファイルが、事実上のトランザクションログです。
さらに確実なロールバックは、システムスナップショットです。LVMスナップショットやVMスナップショットを、インストール前に取っておけば、どんな失敗からでも元に戻せます。エアギャップ環境のGPUノードの作業前に、これをする組織が多いです。
元に戻してはいけないもの
カーネルやglibcのような基盤パッケージのダウングレードは、危険です。依存関係グラフの根にあるので、元に戻した瞬間に、システム全体が不安定になることがあります。こうしたものは、ロールバックの対象ではなく、そもそも慎重に上げるべき対象です。
現場での姿
ドライバーを削除したら、Xが起動しません。nvidia-driver-*をpurgeすると、ディスプレイドライバーも一緒になくなります。ヘッドレスサーバーなら関係ありませんが、コンソールが必要なワークステーションなら、nouveauへのフォールバックを確認する必要があります。
holdを掛けておいて、忘れます。数か月後に、セキュリティパッチが適用されない理由が、そのholdでした。holdの一覧を、定期的にレビューする手続きが必要で、なぜ掛けたかを記録しておく必要があります。
検証を層に分ける
「GPUが使える」という文は、最低でも4つの層を含みます。下から上へ、1つずつ確認して初めて、どこが壊れているのかがわかります。
4. 프레임워크 torch.cuda.is_available() == True, 실제 연산이 맞는 값을 낸다
3. 컨테이너 파드 안에서 nvidia-smi 가 GPU 를 본다
2. 스케줄러 노드에 nvidia.com/gpu 자원이 광고되어 있다
1. 호스트 nvidia-smi 가 장치를 나열하고 모듈이 로드돼 있다
各層の確認コマンドです。
# 1. 호스트
nvidia-smi && lsmod | grep nvidia
# 2. 스케줄러 — 자원이 0 이면 device plugin 이 안 도는 것
kubectl get nodes -o custom-columns=N:.metadata.name,GPU:.status.allocatable.'nvidia\.com/gpu'
# 3. 컨테이너
kubectl run gpu-check --rm -it --restart=Never \
--image=nvidia/cuda:12.4.0-base-ubuntu22.04 \
--limits=nvidia.com/gpu=1 -- nvidia-smi
# 4. 프레임워크 — 그리고 값이 맞는지까지
python -c "import torch; a=torch.randn(1000,1000,device='cuda'); print((a@a).sum().item())"
4つ目の層(フレームワーク)で、値まで確認することが重要です。is_available()がTrueなのに、実際の演算がNaNを出す場合があります(ドライバーとCUDAのバージョンの不一致、ECCエラー)。
ロールバック経路を、あらかじめ作っておく
エアギャップ環境では、「インターネットからもう一度取得する」ことが不可能なので、元に戻すためのものを先に確保してから、始めます。
- 現在のドライバーのパッケージを保管します:
dpkg-repackや、持ち込み媒体の古いバージョンです。 - 現在のカーネルとモジュールを固定します:
apt-mark holdです。新しいカーネルが入ってモジュールがなくなることが、最もよくある事故です。 - 作業前の状態を記録します:
nvidia-smi -q > before.txt、lsmod、dkms statusです。元に戻したあとに、同じ状態かを照合する基準です。
# 되돌리기
apt-get install --allow-downgrades nvidia-driver-550=550.90.07-0ubuntu1
update-initramfs -u && reboot
update-initramfsを忘れると、再起動のあとに、古いモジュールがそのままロードされて、「元に戻したのに、そのまま」になります。
検証結果を残す形式
## GPU 설치 검증 2026-09-06 (node-gpu-03)
| 층 | 확인 | 결과 |
|---|---|---|
| 호스트 | nvidia-smi | 550.90.07, A100 ×2 인식 |
| 스케줄러 | allocatable | nvidia.com/gpu: 2 |
| 컨테이너 | 파드 안 nvidia-smi | 정상 |
| 프레임워크 | torch matmul | 값 일치, 3.2 TFLOPS |
- 되돌리기 검증: 550.54 로 다운그레이드 후 재부팅 → 정상, 다시 550.90.07 로 복귀
- 남은 위험: 커널 자동 업데이트 (apt-mark hold 로 고정함)
次のラボですること
持ち込み物の完全性マニフェストを作成して検証し、改ざんを再現して、検証が失敗することを確認します。バージョンを固定し、インストールのトランザクション記録を確認して、実際にロールバックを行います。