重启后 /sys/fs/pstore 为什么是空的:ramoops 日志丢失的分层排查
从复位证据判断是否真的发生panic
先还原事件,再检查目录。把最后串口输出、电源变化、复位原因和watchdog状态排列成时间线,注明是设备自行重启,还是现场人员断电恢复。若复位原因寄存器会在启动时被清除,应在合适启动阶段保存,而不是等系统运行很久后再读取。
突然掉电、硬件直接reset或完全锁死,都可能没有进入内核dump路径;pstore为空不能证明没有严重故障。本文以上游Linux v6.6为参照,实际行为必须结合已部署vendor kernel和启动链。以下是诊断与受控测试方法,并非具体板卡的实测结论。
先排除看错挂载点和被提前归档
检查/proc/mounts,区分“已挂载但无文件”“普通空目录”和“权限不足”,同时记录查看时间距离启动多久。接着查启动脚本或服务,确认是否在登录之前已经复制并移除记录。
使用systemd时,检查实际unit、服务日志与生效配置。v254服务说明和v254 pstore.conf定义归档行为:该版本external通常写入/var/lib/systemd/pstore及journal,处理后unlink默认开启;发行版覆盖和实际安装版本优先。BusyBox或Buildroot产品未必采用systemd,也可能有自建脚本。先保存已有归档,不能为了排查直接停采集器或删文件。

确认目标内核与后端真的生效
对照启动中的kernel标识、有效DT、命令行和后端注册消息。源码中的DTS只是期望配置,还应确认bootloader加载了对应DTB,而非回退分区中的旧镜像。模块方案需记录加载时刻是否早于目标故障。
查找保留区冲突、probe失败、注册错误及后端选择等证据。v6.6 Kconfig与ramoops实现可作基准,vendor行为不同则回到其实际代码。先做只读采集,以下命令仅为观察示例,不是已在全部发行版验证的脚本。
uname -r
cat /proc/cmdline
cat /proc/mounts
ls -la /sys/fs/pstore
# 仅适用于具备对应工具的systemd系统:
systemctl status systemd-pstore.service
journalctl -b -u systemd-pstore.service
日志权限不足应通过产品批准的支持访问处理,不要为取证大范围放宽内核日志或文件系统保护。
检查记录条件、容量与过滤设置
对照真实dump原因和过滤条件。上游v6.6的max-reason可区分只记录panic与同时记录oops,具体见原因枚举。console历史和panic快照用途不同,只有console区时,不能因没有dmesg-ramoops文件就判断所有记录功能失效。
核对总保留区以及record、console、ftrace、pmsg各自预算,读取驱动实际接受的大小和舍入行为。记录过小会截断上下文,连续事件会覆盖早期内容,压缩与ECC也会影响有效容量。保存文件名、字节数和原始内容,将零长度、部分缺失、陌生类型分别描述,不要统称为空目录。
定位RAM是在什么时候失去内容
若有理由认为写入路径已执行,就沿复位检查内存保留。实验板上分别比较受控暖重启、watchdog与冷启动;核对固件清零、破坏性内存测试以及启动镜像是否覆盖保留区。早期阶段已覆盖的内容,Linux无法在后面恢复。
再次对照CMA、framebuffer等全部内存使用者。不要随机改物理基址或映射属性碰运气,偶尔成功可能掩盖另一种内存冲突。无法确认的保留特性应继续标为未知;旧bootloader某条暖复位路径成功,不能推广到新启动链、另一看门狗或断电。
用最小受控实验缩小范围
选择已备份、具备串口采集和恢复手段的实验设备,固定已批准的触发方式、marker、构建和复位路径,每次只改变一个假设。保存前次启动尾部、下次启动早期输出以及归档时序,不能在现场生产机反复触发panic来凑样本。
| 疑似缺失阶段 | 应寻找的证据 | 下一步 |
|---|---|---|
| 没有写入 | 事件不合条件或后端未就绪 | 审查触发与初始化窗口 |
| 没有保留 | 复位前存在、复位后消失 | 审查固件和复位链 |
| 没有读到 | 挂载、注册或运行配置不符 | 核对有效配置 |
| 已经归档 | 服务日志与匹配副本 | 核对归档生命周期 |
| 部分保留 | 内容截断或旧记录覆盖 | 审查容量与事件顺序 |
唯一marker用于排除旧记录。若实验必须停采集器,需要先获得批准并保存既有归档,实验结束恢复正常采集也属于流程的一部分。
按缺失阶段选择补救与补充观测
后端未就绪就处理初始化,内存被覆盖就处理启动链保留,记录不可读就处理挂载或权限,已归档就去检查副本。没有确定阶段之前,反复修改同一设备树参数往往不会增加有效证据。
ramoops无法覆盖的故障,可评估串口或netconsole,但需写明可靠性条件:网络路径依赖故障时仍工作的驱动和接收端,串口路径依赖可用接口与外部采集器,二者都不能保证捕获所有崩溃。
缺配置步骤时回到首次配置ramoops,找到记录后进入现场证据打包。归档位于只读或易失文件系统时,先核对持久存储边界。需要BSP诊断评估时,请准备两次启动日志、真实复位类型、有效配置和采集器设置。
技术依据与验证范围
官方版本依据:ramoops · binding · kconfig · ramcode · reasons · systemd · pstoreconf