pstore尚未就绪时的早期启动Panic：建立证据覆盖时间线
内核在持久化后端就绪之前已经Panic，修改用户空间的pstore挂载脚本无法补回当时错过的捕获机会。真正需要回答的是：每条证据路径从哪个启动阶段开始可用。本文以Linux v6.12上游实现建立早期故障覆盖时间线，假定项目已有合理的保留内存配置，重点讨论初始化顺序，不重新规划保留区域。
按可观察里程碑绘制时间线
依次列出固件输出、进入内核、早期控制台可用、ramoops驱动初始化、后端成功注册、后续驱动探测，以及用户空间采集。把疑似Panic放在两个里程碑之间，而不是未经测量就写“启动后一秒内”。相同内核在不同固件和设备发现路径下，也可能形成不同顺序。
每个里程碑都要标注证据来源。外部串口记录说明输出了什么，源码审查说明注册动作设计在哪里，保存的配置说明组件内建还是模块化。单一来源不能证明全部事实。未知区间应继续保留，不能用估算时间填满。
找到真正的后端就绪边界
v6.12中，ramoops初始化函数使用postcore_initcall。但该函数注册的是平台驱动，探测过程仍须建立区域并成功调用pstore_register。因此，看到初始化级别声明不能证明更早故障点已有可用后端。依据见ramoops初始化与探测实现。
后端声明dmesg能力后，pstore注册路径才安装kmsg转储器。成功注册消息可作为时间线锚点，但前提是当前控制台确实采集到了它。参见pstore后端注册实现。
按v6.12 Kconfig检查发布配置中的CONFIG_PSTORE_RAM。若后端以模块加载，加载与成功探测之前的时间仍属于空窗。改成内建可能缩短空窗，却不能让尚不存在的依赖提前可用。变更后要重新查注册证据，不能只因内建就宣布覆盖所有早期Panic。
把捕获能力与文件可见性分开
pstore文件系统读取后端后生成用户可见文件，这是取回阶段，区别于为未来故障注册写入者。恢复系统较晚挂载，不等于上次运行的内核也要等到这个挂载时刻才能记录；反过来，在用户空间提前挂载，也无法救回写入者出现之前的Panic。依据见文件系统取回实现。
检查表应分别设置“失败启动时后端是否就绪”和“恢复启动时记录是否可见”。第二项为空，不能直接回答第一项。这样才能避免故障明明发生在init脚本之前，团队却反复调整脚本执行顺序。
# 从成功对照启动收集只读线索
uname -r
cat /proc/cmdline
dmesg | grep -Ei 'ramoops|pstore|persistent store|initcall'
cat /proc/mounts | grep pstore成功对照启动提供参考地标，并不证明失败启动经过完全相同的序列。若有失败时的外部记录，应优先保留原件。只有对照启动出现注册消息时，失败启动的注册状态仍应写成未知，直到故障位置有进一步证据。
选择更早、独立的输出路径
v6.12参数文档说明了earlycon与initcall_debug。平台支持时，无参数earlycon可以利用设备树stdout-path或ACPI信息；指定形式则需要准确的UART及映射。initcall_debug用于追踪初始化调用，但两者都不是观察所有早期指令的普遍保证。参见Linux 6.12内核参数。
向板级负责人取得已确认的接口、电气标准、启动参数和采集配置。在上电或复位前启动外部采集，同时确认已知固件标识与内核标识。没有看到固件消息也可能是采集设置问题，不能直接说固件没有运行。不要猜测UART物理地址，也不要接入不兼容的电气接口。
诊断配置应与发布配置分开保存。更多输出会改变时序，可能影响竞态。若加日志后故障消失，应记录这一变化并比较最早确认的里程碑，不能宣称输出本身已修复产品。
在开发目标上逐段验证
建议矩阵至少包括后端注册之前、注册成功但用户空间尚未运行、以及正常采集已可用三个检查点。每个点写清哪些通道应出现唯一标识，哪些应没有记录，并设置无故障基线，确认外部采集器本身工作正常。
人为Panic或复位只能用于隔离目标，准备批准的恢复镜像，并获得中断工作负载的许可。注册后故障测试只能证明那个较晚检查点，不能代替早期覆盖验证。如果必须精确放置触发点，应针对选定构建审查插桩，并确保生产配置移除测试代码。
用覆盖范围结束调查
- 固定故障构建及后端内建或模块化选择。
- 每个里程碑具有观察证据，或明确标记未知。
- 写入者注册与恢复文件可见性分别跟踪。
- 存在覆盖疑似区间的更早通道，或如实披露空窗。
- 分阶段测试具有预期通道和独立事件标识。
一次没有留下任何存活证据的历史Panic，不能靠今天挂载pstore重新生成。工程目标是缩小故障区间，并让下一次复现具备合适的采集路径。交付时写出最早已证明的检查点及剩余空窗，不要把概念初始化图当成实际板级覆盖证明。
