验证计划与回滚路径

在 LabHub 中继续学习

一句话总结

在隔离网络中，不要进行没有回滚路径的变更。 因为无法再次连接外部网络获取缺失内容。

概念图: 不要进行没有回滚路径的变更。 · 一个无法撤销的操作，就可能耗费数天。 · 关键是按顺序逐层确认。 · 同时锁定内核，是 GPU 节点的常规做法。

为什么需要回滚路径

在联网环境中，即使安装出错，也可以重新下载。隔离网络则不同：删除某项内容后，如果需要重新获取，就必须再次经过导入审批。一个无法撤销的操作，就可能耗费数天。

因此，隔离网络操作流程有一半都在回答两件事：“更改了什么”，以及“如何提前准备回滚”。

它是如何工作的

验证计划

在拥有真实 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

关键是按顺序逐层确认。 如果只执行第四步并看到失败，就无法判断哪一层出了问题；从第一层向上检查时，失败点本身就是原因。

软件包完整性

安装后仍然可以检查文件是否保持原样。

dpkg -V nvidia-driver-550        # 설치 시점의 해시와 비교
dpkg -V | head                   # 전체 검사

输出格式类似 ??5??????。5 表示 md5 不匹配，也就是内容发生变化；c 表示配置文件。配置文件被修改通常正常，但如果二进制文件发生变化，就必须调查。

锁定版本

驱动程序尤其需要锁定。内核升级后需要重新构建 DKMS，而在隔离网络中，这意味着又一次导入流程。

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 无法启动。 purge nvidia-driver-* 时，显示驱动程序也会一起消失。对于无头服务器没有影响，但需要本地控制台的工作站必须确认 nouveau 回退是否可用。

设置 hold 后忘记解除。 几个月后才发现安全补丁没有应用，原因就是此前的 hold。需要定期审查 hold 列表，并记录每一项锁定的原因。

分层验证

“GPU 可以使用”这句话至少包含四个层次。必须从下到上逐层确认，才能知道故障发生在哪里。

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())"

第四步中，必须连计算结果也一起确认。 即使 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 로 고정함)

下一个实验要做什么

为导入内容制作完整性清单并进行验证，模拟篡改并确认验证失败。随后锁定版本、检查安装事务记录，并实际执行回滚。