测验：驱动依赖
nvidia-driver-550 是元软件包意味着什么？
- 它几乎不包含实际文件，只通过依赖项列表引入其他软件包
- 表示它是该驱动程序的最新版本
- 只是一个无法安装、仅有名称的虚拟软件包
- 是必须先构建才能使用的源代码包
仓库中没有名为 libcuda1 的软件包，但要求它的软件包却能安装。原因是什么？
- apt 会忽略它
- 其他软件包通过 Provides 提供了这个名称
- 因为不会检查虚拟软件包
- 因为没有版本条件
采用 DKMS 方式引入内核模块时，最常见的失败点是什么？
- 缺少与目标系统内核版本匹配的 linux-headers，导致构建失败
- 软件包内的库版本彼此不匹配
- 构建过程中磁盘空间不足
- 模块软件包的 GPG 签名不匹配
为什么必须同时引入驱动程序和 nvidia-container-toolkit？
- 两者其实是同一个软件包的不同名称
- 两者存在循环依赖，必须一起解析
- 它们来自不同仓库、采用不同版本体系；只准备一方，容器就无法使用 GPU
- 因为安装顺序固定，所以必须一起下载
确认软件包集合在其内部形成闭包（closure）的最可靠方法是什么？
- 核对集合中的文件数量是否与清单一致
- 重新验证所有文件的校验和
- 用该集合建立仓库，仅启用这个仓库并运行安装模拟
- 逐一人工阅读各软件包的 control 文件
在启用了 Secure Boot 的服务器上安装驱动后，模块无法加载。原因是什么？
- 构建模块时的内核与当前运行内核版本不同
- 驱动版本过低，不支持该 GPU
- 未签名的内核模块会被拒绝加载，需要注册 MOK
- PCI 未识别到 GPU 硬件