CentOS Stream 启动排障

CentOS Stream 是持续交付的发行版，滚动更新会持续替换引导链与内核相关的软件包，「起不来」因此有两类典型来源：更新把引导链改坏了，或者与本轮更新无关的硬件、分区与配置问题。本页只给排查顺序：先判断卡在哪一层，再决定是修引导、换介质启动，还是先把数据取出来。

分层逐级排查

CentOS Stream 的启动现场先与滚动事务时间线对齐：记录最后一次正常引导、更新开始与结束、首次失败的时刻。一次事务完成与新内核已成功启动是不同的验收点，不能只看软件包下载是否结束。

若连安装或救援介质都无法引导，先记录硬件、固件及介质信息，到下载与校验重新核对平台与镜像，再决定是否需要整机支持。

把 Stream 的失败记录整理成一个可比较的现场：哪次事务之前还能启动，默认入口是否随事务改变，仍可进入哪个旧入口。先保存菜单和控制台输出；调查期间保留可恢复状态。

如果日志指向某次更新，先核对该次事务和仓库来源，再决定修复范围。若是本机配置变更引入，记录更改前后差异并按变更记录恢复；不要把仓库混线和本地参数错误当作同一种故障。

引导器、初始内存盘与文件系统的一般排查原理统一见主站启动故障参考 ↗。Stream 这里保留滚动事务的证据与本地更新排障之间的交接关系，避免再维护一套通用修复命令。

官方下载页提供 ISO 的校验说明与 USB 启动介质制作的注意事项，可在同一页找到各架构的介质入口，救援介质因此有明确的官方来源。

本次核对未取得救援模式与 chroot 的具体步骤，因此本页不给救援模式的操作步骤、介质内的菜单选项名称或任何 chroot 命令。能确定的只有来源与顺序：

先取介质：从官方下载页给出的入口与官方镜像取得 ISO，并按其校验说明先验一遍完整性——安装介质同时也是救援介质，介质本身出错会让排障从一开始就不可信；
再决定启动方式：用介质启动后，是进入安装流程还是某种修复入口，取决于介质实际提供的选项；具体选项以介质界面为准；
最后才动系统：在系统能重新启动之前，优先只做读取（看日志、看分区、导出数据），不要对原系统做写入操作。

先确认报错是否确实来自 Stream 所在系统盘。把挂载配置与当前设备清单、最近的磁盘或虚拟机变更对照，记录不能识别的卷和受影响的业务；本页不提供在故障现场重建文件系统的命令。

若现象与滚动事务无关，按主站启动故障参考 ↗判断挂载问题的前提，再交给对应存储组件处置。恢复启动只是中间结果，最终仍需Stream 基线核验与应用检查。

一份可复查的 Stream 事件记录应把更新事务和启动结果放在一起：记录使用的发布线与仓库地址、事务是否完成、第一次失败对应的启动项，以及后来哪种入口恢复可用。把临时恢复与最终修复分开标注，避免把“旧项能启动”写成“更新已验收”。

提交本地常见问题中的支持渠道前，附上脱敏后的事务和启动记录，并明确当前业务是否恢复。仓库来源存在疑问时先回滚动更新排障处理源一致性，不继续扩大系统改动。