3. 启动日志基础
在OTA升级过程中，设备从断电到系统可用、再到升级服务启动，会持续产生大量文本记录，这些记录统称为启动日志。启动日志不是单一文件，而是由引导程序、内核、init进程、系统服务、升级代理等多个来源按时间顺序写入的集合。理解启动日志的定义、级别、格式，以及内核日志与应用日志的分工，是后续做升级失败定位、时序还原和自动化分析的基础。
一、启动日志的定义与来源
启动日志（Boot Log）指设备从上电复位开始，到系统进入稳定运行状态期间，由各启动阶段组件输出的诊断信息。它通常包含以下来源：
- Bootloader日志：如U-Boot、LK，输出DDR初始化、分区表、镜像校验、启动槽选择等信息。
- 内核日志：由Linux内核通过printk输出，记录驱动加载、设备探测、文件系统挂载、内存与CPU初始化。
- init与系统服务日志：如systemd、Android init、rc脚本，记录服务启动、属性设置、挂载动作。
- 应用与升级代理日志：OTA客户端、升级守护进程、网络模块输出的业务级信息。
这些日志可能分别落在串口、/dev/kmsg、dmesg、logcat、journalctl或厂商私有日志文件中。做OTA分析时，第一步往往是把多源日志按时间戳对齐，形成一条完整的启动时间线。
二、日志级别：从紧急到调试
日志级别用于表达事件的严重程度，决定日志是否被输出、是否触发告警。Linux内核与多数系统日志采用syslog级别，数值越小越严重：
| 级别 | 数值 | 含义 | OTA场景示例 |
|---|---|---|---|
| EMERG | 0 | 系统不可用 | 内核panic，升级中断 |
| ALERT | 1 | 必须立即处理 | 根分区损坏 |
| CRIT | 2 | 严重错误 | 镜像校验失败 |
| ERR | 3 | 错误 | 挂载失败、服务启动失败 |
| WARNING | 4 | 警告 | 分区空间不足、版本回退 |
| NOTICE | 5 | 正常但重要 | 切换到B槽启动 |
| INFO | 6 | 一般信息 | 服务启动完成 |
| DEBUG | 7 | 调试信息 | 驱动探测细节 |
实际分析中，ERR与WARNING是排查重点，但NOTICE级别的“槽位切换”“版本标记”往往才是OTA成功与否的关键证据。不能只盯错误级别，否则容易漏掉状态迁移信息。
三、日志格式：字段决定可分析性
典型内核日志格式如下：
[ 2.345678] init: Starting service 'otad'...
[ 2.346120] otad: [INFO] slot=B, retry=0, reason=boot_success
[ 2.350991] EXT4-fs (mmcblk0p12): mounted filesystem
[ 2.412003] otad: [ERROR] verify image failed, crc=0x8f2a expected=0x1c4d
可拆解为：时间戳（内核启动秒数或UTC时间）、来源标签（init、otad、内核子系统）、级别、消息体。应用日志如logcat还会带PID、TID、Tag。分析脚本通常用正则提取这些字段，再按时间排序、按Tag聚合。
四、内核日志与应用日志：区别与联系
二者最核心的区别在于运行空间与职责。内核日志运行在内核态，关注硬件、驱动、内存、文件系统等底层资源；应用日志运行在用户态，关注业务逻辑、升级流程、网络交互。内核日志一旦出错，往往导致系统无法启动；应用日志出错，通常表现为升级失败但系统仍可运行。
二者的联系体现在因果链上：内核日志负责“系统能不能起来”，应用日志负责“升级有没有做成”。例如内核日志显示EXT4-fs error，应用日志随后出现verify image failed，说明根因在存储或镜像写入，而非网络下载。分析时必须把两类日志串起来看，不能孤立判断。
五、案例：一次OTA启动失败的日志复盘
某设备升级后反复重启，抓取日志片段：
[ 1.982001] init: Starting service 'otad'...
[ 2.010334] otad: [INFO] current slot=A, target slot=B
[ 2.045120] otad: [ERROR] open /dev/block/by-name/misc failed: No such file
[ 2.046001] init: Service 'otad' exited with status 1
[ 2.050220] init: Rebooting into recovery...
复盘结论：应用日志明确报出misc分区节点缺失，属于用户态访问路径问题；内核日志中并无存储驱动报错，说明硬件与驱动正常。修复方向是检查by-name符号链接生成规则，而不是更换内核。这个案例说明：先看应用日志定位失败动作，再回内核日志排除底层故障，是高效的排查顺序。
六、方法流程：从原始日志到可分析数据
- 采集：串口抓取全量启动输出，同时导出dmesg、logcat、journalctl。
- 归一：统一时间戳格式，标注来源与级别。
- 过滤：保留ERR/WARNING/NOTICE，以及含slot、version、verify、mount等关键词的行。
- 关联：按时间窗口把内核事件与应用事件配对，形成因果链。
- 归档：将本次升级的日志与版本号、槽位、结果一起入库，供后续对比。
掌握启动日志的定义、级别、格式以及内核与应用日志的分工，才能在OTA升级分析中快速判断“问题出在底层还是业务层”。这是后续日志解析、时序还原和自动化告警的共同基础。