从启动程序到根文件系统的排障怎样留下有效证据1. 启动卡死在 init 进程没有任何崩溃 Dump 的现场在手动构建嵌入式 Linux 系统从 U-Boot 引导程序、Linux 内核到 RootFS 根文件系统的过程中最让人头疼的是这种无字死机[ 3.120542] Run /sbin/init as init process [ 3.124890] Kernel panic - not syncing: Attempted to kill init! exitcode0x000000b0 [ 3.132104] CPU: 0 PID: 1 Comm: init Not tainted 6.6.0 #1 [ 3.137450] Hardware name: Custom Embedded Linux Board (DT) [ 3.142981] Call trace: [ 3.145412] [ffff800080012345] dump_backtrace0x0/0x1e0 [ 3.150821] [ffff800080012560] show_stack0x20/0x30 [ 3.155890] [ffff800080800990] panic0x140/0x320 (系统随即挂起板卡电平降低串口彻底无响应)初始化进程init刚一启动就挂了但既没有生成 Core Dump 文件也没有在 Flash 里留下任何 Log。板卡一旦掉电复位内存里的崩溃堆栈消失得干干净净。在系统搭建初期串口输出往往极易丢包磁盘挂载尚不稳定如果不主动打通“Bootloader ➔ Kernel ➔ Init ➔ RootFS”的全链路可观测性防线任何一次底层库依赖缺失、动态链接器ld-linux.so路径错误或驱动加载卡死都会变成无迹可寻的无头悬案。2. 从 Bootloader 到 RootFS 的全链路可观测防线一套成熟的嵌入式 Linux 搭建方案必须在启动全流程的每一个节点埋下证据保留机制第一阶段Bootloader (U-Boot) 日志存留开启 U-Boot 的CONFIG_LOG与cbmem/log console选项将 Bootloader 阶段的 DDR 训练日志与闪存读取状态暂存在固定的 SRAM/DRAM 区域传入内核。第二阶段Kernel 死机日志黑匣子 (Pstore / Ramoops)配置内核的pstore(Persistent Storage) 与ramoops驱动。即使系统遭遇 Panic 或硬件 Watchdog 复位Kernel 崩溃前的printk内存缓冲区也会保留在 RAM 的预留保留区并在下一次启动时自动挂载到/sys/fs/pstore/。第三阶段Init 与 RootFS 启动瀑布图 (Bootchart Trace)通过bootchartd或systemd-analyze统计从内核接管到用户态服务完全拉起的全部进程 CPU / IO 开销绘制启动瀑布图。3. 三阶段日志与 Trace 存留流图4. 关键配置与死机日志保留Pstore/Ramoops C 语言与 DTS 配置要实现死机日志的“黑匣子”保存首先需要在 DeviceTree 中预留出一块物理 RAM防止被内核普通内存分配器覆盖reserved-memory { #address-cells 2; #size-cells 2; ranges; // 预留 1MB 物理内存专用于 Pstore/Ramoops 死机黑匣子 ramoops8f000000 { compatible ramoops; reg 0x0 0x8f000000 0x0 0x100000; // 物理基地址 0x8F000000大小 1MB record-size 0x20000; // dmesg 崩溃日志块大小 (128KB) console-size 0x20000; // 串口控制台日志大小 (128KB) ftrace-size 0x10000; // Ftrace 追踪日志大小 (64KB) pmsg-size 0x10000; // 用户态消息大小 (64KB) }; };同时在 Linux 内核.config中勾选以下核心可观测性选项CONFIG_PSTOREy CONFIG_PSTORE_CONSOLEy CONFIG_PSTORE_RAMy CONFIG_DEBUG_FSy CONFIG_FUNCTION_TRACERy当系统不幸再次触发 Panic 时下一次重启后可以在 RootFS 中编写一段启动诊断 Shell 脚本提取死机证据#!/bin/sh # /etc/init.d/S01pstore_extract.sh MOUNT_POINT/sys/fs/pstore if [ ! -d $MOUNT_POINT ]; then mkdir -p $MOUNT_POINT fi # 挂载 pstore 文件系统 mount -t pstore pstore $MOUNT_POINT if [ -f $MOUNT_POINT/dmesg-ramoops-0 ]; then echo echo [CRITICAL WARNING] Crash Log Found From Previous Boot! echo cat $MOUNT_POINT/dmesg-ramoops-0 | head -n 30 # 归档到持久化 flash 存储中 cp $MOUNT_POINT/* /var/log/crash_dumps/ echo [INFO] Crash dump saved to /var/log/crash_dumps/ fi5. 抓 bootchart 与 systemd-analyze 生成启动瀑布图当系统能够顺利进入用户态后排障的焦点将从“崩溃定位”转向“启动耗时优化”。如果 RootFS 基于 Systemd直接运行以下命令导出启动性能分析数据# 测量启动阶段耗时分布 systemd-analyze # 打印最慢的服务列表 (Blame List) systemd-analyze blame # 导出完整的 SVG 格式启动瀑布图 systemd-analyze plot /var/log/boot_waterfall.svg对于基于 BusyBox 的轻量级 RootFS可以引入bootchart2# 修改内核 bootargs 参数以启动 bootchart 用户态收集器 setenv bootargs ${bootargs} init/usr/bin/bootchartd boot在宿主机 Linux 上渲染 Bootchart 图表pybootchartgui /var/log/bootchart.tgz终端输出的分析数据将精确剥离出拖慢启动的关键进程Startup finished in 1.250s (kernel) 4.821s (userspace) 6.071s firmware-load.service : 2.145s (Waiting for SD Card DMA Timeout) network-init.service : 1.820s (DHCP Blocking Wait) lighttpd.service : 0.410s从 Bootloader 的内存保留 Log到内核的 Pstore 死机黑匣子再到 RootFS 的 Bootchart 瀑布图这套全链路可观测体系彻底消除了嵌入式 Linux 搭建过程中“死机无日志、卡顿靠盲猜”的困境为系统的长久稳定运行留下了铁证。让结果可复查从 bootloader 到 rootfs 的完整 Linux 搭建排障时怎样留下有效证据并不适合靠一句经验结论推进。围绕 启动日志、镜像哈希、失败命令和分区布局 的结论应能被别人复查。保留原始样例、关键日志和操作顺序比在文档里写“已验证”更有用。涉及敏感内容时可以保留脱敏后的结构和哈希保证读者仍能判断材料是否来自同一现场。问题处理完后简短说明修改位置、影响范围和未覆盖情况即可。不要把一次偶然成功写成通用规律若还有前提就把前提说清。控制变更范围处理 启动日志、镜像哈希、失败命令和分区布局 时最容易犯的错误是同时改太多东西升级依赖、调整配置、重写逻辑一起发生最后即使变好也无法解释原因。把变更拆开每次只回答一个问题节奏会慢一点但回退和复盘都更轻松。发布或交接之前再检查调用方是否依赖旧行为。对暂时无法覆盖的场景写下限制读者就能判断这套做法是否适合自己的环境。先还原问题现场先把讨论收回到一次具体执行。把 启动日志、镜像哈希、失败命令和分区布局 写在同一处区分哪些是已有事实、哪些只是推测。很多改动失败并不是实现完全错误而是参与者对运行条件各自理解不同。记录不必很长但要让后来的人知道输入从哪里来、动作在哪一步发生、结果由什么证据支撑。选择足够小的场景先跑一遍观察行为是否符合预期。出现偏差时先核对输入、环境和默认参数再考虑改代码。一次只移动一个变量才能知道变化究竟来自哪里。留下可交接的说明处理完成后不需要额外写一套漂亮的总结。把实际改了什么、为何这样改、还剩哪些前提写在变更附近即可。下一次遇到相似问题时这些材料可以作为起点但仍应先确认当前输入和环境是否相同。
从启动程序到根文件系统的排障怎样留下有效证据1. 启动卡死在 init 进程没有任何崩溃 Dump 的现场在手动构建嵌入式 Linux 系统从 U-Boot 引导程序、Linux 内核到 RootFS 根文件系统的过程中最让人头疼的是这种无字死机[ 3.120542] Run /sbin/init as init process [ 3.124890] Kernel panic - not syncing: Attempted to kill init! exitcode0x000000b0 [ 3.132104] CPU: 0 PID: 1 Comm: init Not tainted 6.6.0 #1 [ 3.137450] Hardware name: Custom Embedded Linux Board (DT) [ 3.142981] Call trace: [ 3.145412] [ffff800080012345] dump_backtrace0x0/0x1e0 [ 3.150821] [ffff800080012560] show_stack0x20/0x30 [ 3.155890] [ffff800080800990] panic0x140/0x320 (系统随即挂起板卡电平降低串口彻底无响应)初始化进程init刚一启动就挂了但既没有生成 Core Dump 文件也没有在 Flash 里留下任何 Log。板卡一旦掉电复位内存里的崩溃堆栈消失得干干净净。在系统搭建初期串口输出往往极易丢包磁盘挂载尚不稳定如果不主动打通“Bootloader ➔ Kernel ➔ Init ➔ RootFS”的全链路可观测性防线任何一次底层库依赖缺失、动态链接器ld-linux.so路径错误或驱动加载卡死都会变成无迹可寻的无头悬案。2. 从 Bootloader 到 RootFS 的全链路可观测防线一套成熟的嵌入式 Linux 搭建方案必须在启动全流程的每一个节点埋下证据保留机制第一阶段Bootloader (U-Boot) 日志存留开启 U-Boot 的CONFIG_LOG与cbmem/log console选项将 Bootloader 阶段的 DDR 训练日志与闪存读取状态暂存在固定的 SRAM/DRAM 区域传入内核。第二阶段Kernel 死机日志黑匣子 (Pstore / Ramoops)配置内核的pstore(Persistent Storage) 与ramoops驱动。即使系统遭遇 Panic 或硬件 Watchdog 复位Kernel 崩溃前的printk内存缓冲区也会保留在 RAM 的预留保留区并在下一次启动时自动挂载到/sys/fs/pstore/。第三阶段Init 与 RootFS 启动瀑布图 (Bootchart Trace)通过bootchartd或systemd-analyze统计从内核接管到用户态服务完全拉起的全部进程 CPU / IO 开销绘制启动瀑布图。3. 三阶段日志与 Trace 存留流图4. 关键配置与死机日志保留Pstore/Ramoops C 语言与 DTS 配置要实现死机日志的“黑匣子”保存首先需要在 DeviceTree 中预留出一块物理 RAM防止被内核普通内存分配器覆盖reserved-memory { #address-cells 2; #size-cells 2; ranges; // 预留 1MB 物理内存专用于 Pstore/Ramoops 死机黑匣子 ramoops8f000000 { compatible ramoops; reg 0x0 0x8f000000 0x0 0x100000; // 物理基地址 0x8F000000大小 1MB record-size 0x20000; // dmesg 崩溃日志块大小 (128KB) console-size 0x20000; // 串口控制台日志大小 (128KB) ftrace-size 0x10000; // Ftrace 追踪日志大小 (64KB) pmsg-size 0x10000; // 用户态消息大小 (64KB) }; };同时在 Linux 内核.config中勾选以下核心可观测性选项CONFIG_PSTOREy CONFIG_PSTORE_CONSOLEy CONFIG_PSTORE_RAMy CONFIG_DEBUG_FSy CONFIG_FUNCTION_TRACERy当系统不幸再次触发 Panic 时下一次重启后可以在 RootFS 中编写一段启动诊断 Shell 脚本提取死机证据#!/bin/sh # /etc/init.d/S01pstore_extract.sh MOUNT_POINT/sys/fs/pstore if [ ! -d $MOUNT_POINT ]; then mkdir -p $MOUNT_POINT fi # 挂载 pstore 文件系统 mount -t pstore pstore $MOUNT_POINT if [ -f $MOUNT_POINT/dmesg-ramoops-0 ]; then echo echo [CRITICAL WARNING] Crash Log Found From Previous Boot! echo cat $MOUNT_POINT/dmesg-ramoops-0 | head -n 30 # 归档到持久化 flash 存储中 cp $MOUNT_POINT/* /var/log/crash_dumps/ echo [INFO] Crash dump saved to /var/log/crash_dumps/ fi5. 抓 bootchart 与 systemd-analyze 生成启动瀑布图当系统能够顺利进入用户态后排障的焦点将从“崩溃定位”转向“启动耗时优化”。如果 RootFS 基于 Systemd直接运行以下命令导出启动性能分析数据# 测量启动阶段耗时分布 systemd-analyze # 打印最慢的服务列表 (Blame List) systemd-analyze blame # 导出完整的 SVG 格式启动瀑布图 systemd-analyze plot /var/log/boot_waterfall.svg对于基于 BusyBox 的轻量级 RootFS可以引入bootchart2# 修改内核 bootargs 参数以启动 bootchart 用户态收集器 setenv bootargs ${bootargs} init/usr/bin/bootchartd boot在宿主机 Linux 上渲染 Bootchart 图表pybootchartgui /var/log/bootchart.tgz终端输出的分析数据将精确剥离出拖慢启动的关键进程Startup finished in 1.250s (kernel) 4.821s (userspace) 6.071s firmware-load.service : 2.145s (Waiting for SD Card DMA Timeout) network-init.service : 1.820s (DHCP Blocking Wait) lighttpd.service : 0.410s从 Bootloader 的内存保留 Log到内核的 Pstore 死机黑匣子再到 RootFS 的 Bootchart 瀑布图这套全链路可观测体系彻底消除了嵌入式 Linux 搭建过程中“死机无日志、卡顿靠盲猜”的困境为系统的长久稳定运行留下了铁证。让结果可复查从 bootloader 到 rootfs 的完整 Linux 搭建排障时怎样留下有效证据并不适合靠一句经验结论推进。围绕 启动日志、镜像哈希、失败命令和分区布局 的结论应能被别人复查。保留原始样例、关键日志和操作顺序比在文档里写“已验证”更有用。涉及敏感内容时可以保留脱敏后的结构和哈希保证读者仍能判断材料是否来自同一现场。问题处理完后简短说明修改位置、影响范围和未覆盖情况即可。不要把一次偶然成功写成通用规律若还有前提就把前提说清。控制变更范围处理 启动日志、镜像哈希、失败命令和分区布局 时最容易犯的错误是同时改太多东西升级依赖、调整配置、重写逻辑一起发生最后即使变好也无法解释原因。把变更拆开每次只回答一个问题节奏会慢一点但回退和复盘都更轻松。发布或交接之前再检查调用方是否依赖旧行为。对暂时无法覆盖的场景写下限制读者就能判断这套做法是否适合自己的环境。先还原问题现场先把讨论收回到一次具体执行。把 启动日志、镜像哈希、失败命令和分区布局 写在同一处区分哪些是已有事实、哪些只是推测。很多改动失败并不是实现完全错误而是参与者对运行条件各自理解不同。记录不必很长但要让后来的人知道输入从哪里来、动作在哪一步发生、结果由什么证据支撑。选择足够小的场景先跑一遍观察行为是否符合预期。出现偏差时先核对输入、环境和默认参数再考虑改代码。一次只移动一个变量才能知道变化究竟来自哪里。留下可交接的说明处理完成后不需要额外写一套漂亮的总结。把实际改了什么、为何这样改、还剩哪些前提写在变更附近即可。下一次遇到相似问题时这些材料可以作为起点但仍应先确认当前输入和环境是否相同。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
