技术帮助 · 发布时间：
物理节点通过 PXE 批量装机时，最容易出问题的并非启动本身，而是节点启动后使用了哪个内核、initrd 和系统镜像。要让物理计算节点的PXE批量装机与镜像版本管理可追踪、可复现，应把版本标识、文件校验、启动入口、硬件适配和回滚方案一并纳入管理。
一、先定义镜像版本：一个版本对应一套明确制品
不要只用“最新版”或“生产镜像”命名。建议采用可读且唯一的标识，例如“debian12-kernel6.1-build202609”，并在清单中记录发行版版本、内核版本、initrd 生成时间、软件包来源、构建配置和适用硬件范围。版本号不必照搬某种格式，但同一标识必须始终对应同一批文件。
把 vmlinuz、initrd、安装源或根文件系统视为一个整体。只替换内核却沿用旧 initrd，可能导致驱动或存储识别不一致。保存构建清单，便于后续确认镜像具体包含什么。
二、固定制品并校验，避免文件被无意覆盖
为每个版本建立独立目录，例如按发行版和构建号分层存放。发布后不要在原目录里直接覆盖文件；新构建使用新目录，旧版本在回滚窗口结束前保留。目录权限应限制为发布流程可写、PXE 服务只读，减少误操作风险。
- 构建完成后生成校验值：sha256sum vmlinuz initrd.img，并把结果写入版本清单。
- 将清单和制品一起归档；节点下载或部署后，可再次计算 SHA-256 并比对，确认传输内容未损坏。
- 若环境对供应链有更高要求，可对清单或制品签名，并在发布端验证签名。校验和能发现文件变化，但单独使用不能证明文件来源可信。
三、让 PXE 启动配置明确指向版本
DHCP 负责提供网络启动信息，TFTP 或 HTTP 可用于传送启动文件；具体方式取决于现有网络服务和固件能力。传统 BIOS 与 UEFI 的启动文件可能不同，不能只验证一种固件模式。使用 iPXE 时，可把菜单项指向明确版本目录，避免所有节点都默认加载一个随时会变的路径。
发布前按节点选择启动项
- 在启动菜单中同时保留当前稳定版和候选版，菜单名称显示完整构建号。
- 先让一台测试节点进入候选启动项，确认能取到对应内核、initrd 和安装源。
- 核对安装后的系统版本、内核版本及关键设备识别情况，再开放给目标节点组。
菜单配置也应纳入版本控制。变更时记录修改人、时间、涉及节点范围和回退到哪个启动项，避免“镜像文件正确、菜单却指错版本”。
四、维护硬件兼容矩阵，不把所有节点当成同一种设备
物理计算节点的PXE批量装机与镜像版本管理还要记录机型、固件启动模式、网卡和存储控制器等差异。比如，同一 Linux 安装镜像在不同存储控制器配置下，可能需要不同驱动支持；较新的硬件也可能要求更新内核或固件。这里应依据实际设备清单验证，不宜仅凭型号相近就判断兼容。
维护一张简明矩阵：节点型号或硬件类别、BIOS/UEFI 模式、可用镜像版本、网卡启动是否成功、系统盘是否可见、安装后网络是否正常。新增硬件或升级内核时，先更新矩阵并完成测试，再扩大部署范围。
五、分批发布并准备可执行的回滚
候选镜像先部署到少量代表性节点，检查启动、磁盘识别、网络连通和基础服务，再分批扩大范围。批次大小按机房管理能力、业务影响和装机窗口决定；没有适用于所有环境的固定比例。出现启动失败或关键设备不可用时，停止后续批次，而不是继续覆盖。
- 发布前记录当前稳定版本及其启动配置，确认旧制品仍可读取。
- 将候选版只分配给测试组，记录失败节点、错误阶段和硬件类型。
- 通过后逐步扩大范围；若出现阻断问题，将节点启动项切回稳定版，并恢复对应安装源或配置。
- 问题修复后生成新的构建号，不在已发布版本上直接替换文件。
做好这五项，物理计算节点的PXE批量装机与镜像版本管理就不只是“留住几个镜像文件”，而是能回答每台机器装了什么、为什么适用，以及出错后如何恢复。
常见问题
镜像文件名写上版本号就够了吗？
不够。还应记录内核、initrd、安装源或根文件系统的对应关系，并用校验值确认文件未被替换。
可以始终使用 latest 路径吗？
可用于测试或便捷入口，但生产启动配置最好指向明确版本。否则路径内容变化后，部署结果难以复现。
旧镜像要保留多久？
至少保留到新版本通过验证且回滚窗口结束。具体期限取决于装机周期、存储空间和故障恢复要求。
校验和能否替代签名？
不能完全替代。校验和适合检查文件完整性；需要确认制品发布来源时，还应采用签名验证和受控的发布权限。
