尧图网站建设 
摘要按照 U-Boot、内核、initramfs 和 systemd 四个阶段阅读串口日志快速区分启动、根分区和网络问题。适用对象遇到黑屏、SSH 不通、initramfs 命令缺失或启动停滞的嵌入式 Linux 开发者。本文以串口日志为主要证据不把单条 HDMI 警告直接当成根因。文章目录本篇要解决什么问题本次最关键的实测证据一、启动日志应该怎么看二、检查启动参数三、initramfs 中的检查命令四、常见启动判断五、为什么 HDMI 日志可能拖慢启动六、把“现象”转换成“下一条命令”1. 能进入 (initramfs)2. root 指向 PARTUUID3. 改用 LABEL 时也要验证 LABEL 唯一且真实存在七、BusyBox 环境下为什么命令经常“不好使”八、HDMI warning 应该怎么处理九、本文验收清单小结工作流实测截图专栏导航参考资料本篇要解决什么问题“SSH 连不上”并不等于“系统没启动”。串口排障最重要的能力是先判断系统停在哪个阶段再决定查哪一类问题。串口停留位置说明优先排查U-Boot 前后无内核输出内核可能未被正确加载启动介质、脚本、kernel/DTB 路径Kernel 有输出随后进入 initramfs内核和 initrd 已运行root、LABEL/PARTUUID、块设备能看到login:基本用户空间已经起来IP、路由、sshd、网卡状态大量外设 warning 但继续启动不一定是主因先看是否影响关键启动链路本次最关键的实测证据首次失败时启动参数里的PARTUUID与blkid读取到的真实根分区标识不一致。最终使用与分区实际标签匹配的rootLABELwritable后问题才回到正确的根分区定位路径上。这个案例说明看到 initramfs 后不要猜先做标识交叉验证。一、启动日志应该怎么看串口日志可以按四段阅读U-Boot读取启动脚本、内核、initrd 和设备树Kernel earlycon确认内核是否真正启动initramfs查找和挂载 rootfssystemd/login启动服务并提供登录界面。看到lubancat login:说明系统至少已经完成内核、根文件系统和基本用户空间启动。二、检查启动参数进入目标系统后cat/proc/cmdline重点检查root、rootfstype、rootwait、console和设备树相关参数。本次首次失败时两个关键值如下来源根分区标识/proc/cmdlinerootPARTUUID614e0000-0000blkid /dev/mmcblk0p2PARTUUIDa75e6771-0e02-4512-9ba0-b6163f829d6eLABELwritable二者明显不一致因此 initramfs 无法按启动参数找到 rootfs。最终改为rootLABELwritable与分区标签一致。这里的结论来自“命令行标识”和“块设备实际标识”的交叉验证不是看到 initramfs 就直接猜测存储损坏。三、initramfs 中的检查命令如果启动失败进入(initramfs)可使用blkid ls -l /dev/mmcblk* cat /proc/cmdlineblkid能显示分区 LABEL、UUID 和 PARTUUIDls -l /dev/mmcblk*能确认块设备节点是否存在。BusyBox 不是完整 Ubuntu shell命令选项和工具数量都有限。本次设备识别结果中/dev/mmcblk0p1是 FAT 启动分区/dev/mmcblk0p2是标签为writable的 ext4 根分区。需要只读检查文件时可先挂载mkdir-p/mnt/root /mnt/bootmount-oro /dev/mmcblk0p2 /mnt/rootmount-oro /dev/mmcblk0p1 /mnt/bootls-l/mnt/root/bootls-l/mnt/boot修复前先只读挂载确认目标无误后再决定是否重新以读写方式挂载。例如 BusyBoxls不支持-hls -lh # 可能报 invalid option ls -l # 使用兼容写法本次 initramfs 中还出现过tar: not found。这表示当前救援环境没有打包工具不应继续照抄完整 Ubuntu 下的tar命令应改用带完整工具的恢复系统或把分区挂载到另一台 Linux 主机处理。四、常见启动判断没有任何内核输出检查串口参数、启动介质和 U-Boot有内核输出但找不到 rootfs检查root、分区 LABEL、initramfs能进入 initramfs说明内核和 initrd 已执行但挂载 rootfs 失败能进入 login 但 SSH 不通优先检查网络地址、路由和 sshd而不是重装内核。五、为什么 HDMI 日志可能拖慢启动如果串口反复出现dwhdmi-rockchip ... i2c read err! ddc read failed这说明 HDMI DDC 通信没有正常完成可能与显示器、线缆、供电或显示 overlay 有关。它与根分区挂载是两个独立问题但本次日志中与较长启动时间同时出现。当前尚未完成因果验证不能直接断言它就是全部启动延迟的唯一原因应记录显示器连接状态和 U-Boot 加载的 overlay并做有/无显示设备的对照启动测试。六、把“现象”转换成“下一条命令”启动故障排查最重要的是减少猜测。可以按下面的判断链处理1. 能进入(initramfs)说明 CPU 已经执行了新内核initrd 也已经被加载。此时优先确认块设备和 root 参数cat /proc/cmdline blkid ls -l /dev/mmcblk*不要一看到 initramfs 就重刷系统。2.root指向 PARTUUID把命令行中的值和blkid输出逐字符比较。PARTUUID 改变后即使分区内容完全正常initramfs 仍可能找不到根分区。3. 改用 LABEL 时也要验证 LABEL 唯一且真实存在本文实测使用rootLABELwritable解决的是“启动参数与真实分区标识不一致”这一具体问题并不代表 LABEL 永远优于 PARTUUID。工程上应选择稳定、可维护且与启动脚本一致的标识方式。七、BusyBox 环境下为什么命令经常“不好使”initramfs 中通常只有精简 BusyBox 工具集因此某些 GNU 命令根本不存在同名命令支持的参数比完整 Ubuntu 少/boot/firmware等完整系统路径可能尚未挂载网络和 DNS 也未必可用。所以救援时应先执行最小、只读、可确认目标的操作。能只读挂载就先只读挂载能观察就先观察再决定是否写入。八、HDMI warning 应该怎么处理HDMI DDC 错误可能需要处理但它和 rootfs 挂载失败是两条不同链路。更严谨的做法是做对照实验记录连接显示器时的启动时间和日志记录断开显示器时的启动时间和日志对比 U-Boot overlay、kernel warning 次数和 systemd 到达 login 的时间。只有有了对照数据才能判断它是否是明显启动延迟来源。九、本文验收清单能根据串口判断停在 U-Boot / Kernel / initramfs / systemd 哪一阶段已比较/proc/cmdline与blkid的真实分区标识initramfs 中优先采用只读检查没有把 BusyBox 当成完整 Ubuntu shell没有把单条 HDMI warning 直接定性为启动失败主因修复后能看到正常 login 或进一步进入用户空间。小结串口日志分析的核心是先定位启动阶段再决定查看分区、设备树、驱动还是服务。不要把所有警告都当成导致启动失败的根因。工作流实测截图图1串口 initramfs 环境中 blkid 和 mmc 设备节点输出。图2从 DDR 初始化到 systemd/SSH 就绪的阶段性日志。专栏导航专栏LubanCat RK3588 实时 Linux 开发实战第 9/13 篇上一篇LubanCat RK3588 实时 Linux 开发八RT 内核 DEB 安装、启动校验与安全回滚下一篇LubanCat RK3588 实时 Linux 开发十RT 内核启动后的驱动、网络与服务全面验收参考资料Linux initramfs 文档Linux kernel parameters文中的版本号、接口名、设备地址和测试数据均应以自己的板卡实测为准引用命令前请先确认当前 SDK、内核和启动布局。标签串口调试U-BootinitramfsLinux启动RK3588 LubanCat RK3588 实时 Linux 开发（九）：从 U-Boot 到 initramfs 的串口启动故障分析
摘要按照 U-Boot、内核、initramfs 和 systemd 四个阶段阅读串口日志快速区分启动、根分区和网络问题。适用对象遇到黑屏、SSH 不通、initramfs 命令缺失或启动停滞的嵌入式 Linux 开发者。本文以串口日志为主要证据不把单条 HDMI 警告直接当成根因。文章目录本篇要解决什么问题本次最关键的实测证据一、启动日志应该怎么看二、检查启动参数三、initramfs 中的检查命令四、常见启动判断五、为什么 HDMI 日志可能拖慢启动六、把“现象”转换成“下一条命令”1. 能进入 (initramfs)2. root 指向 PARTUUID3. 改用 LABEL 时也要验证 LABEL 唯一且真实存在七、BusyBox 环境下为什么命令经常“不好使”八、HDMI warning 应该怎么处理九、本文验收清单小结工作流实测截图专栏导航参考资料本篇要解决什么问题“SSH 连不上”并不等于“系统没启动”。串口排障最重要的能力是先判断系统停在哪个阶段再决定查哪一类问题。串口停留位置说明优先排查U-Boot 前后无内核输出内核可能未被正确加载启动介质、脚本、kernel/DTB 路径Kernel 有输出随后进入 initramfs内核和 initrd 已运行root、LABEL/PARTUUID、块设备能看到login:基本用户空间已经起来IP、路由、sshd、网卡状态大量外设 warning 但继续启动不一定是主因先看是否影响关键启动链路本次最关键的实测证据首次失败时启动参数里的PARTUUID与blkid读取到的真实根分区标识不一致。最终使用与分区实际标签匹配的rootLABELwritable后问题才回到正确的根分区定位路径上。这个案例说明看到 initramfs 后不要猜先做标识交叉验证。一、启动日志应该怎么看串口日志可以按四段阅读U-Boot读取启动脚本、内核、initrd 和设备树Kernel earlycon确认内核是否真正启动initramfs查找和挂载 rootfssystemd/login启动服务并提供登录界面。看到lubancat login:说明系统至少已经完成内核、根文件系统和基本用户空间启动。二、检查启动参数进入目标系统后cat/proc/cmdline重点检查root、rootfstype、rootwait、console和设备树相关参数。本次首次失败时两个关键值如下来源根分区标识/proc/cmdlinerootPARTUUID614e0000-0000blkid /dev/mmcblk0p2PARTUUIDa75e6771-0e02-4512-9ba0-b6163f829d6eLABELwritable二者明显不一致因此 initramfs 无法按启动参数找到 rootfs。最终改为rootLABELwritable与分区标签一致。这里的结论来自“命令行标识”和“块设备实际标识”的交叉验证不是看到 initramfs 就直接猜测存储损坏。三、initramfs 中的检查命令如果启动失败进入(initramfs)可使用blkid ls -l /dev/mmcblk* cat /proc/cmdlineblkid能显示分区 LABEL、UUID 和 PARTUUIDls -l /dev/mmcblk*能确认块设备节点是否存在。BusyBox 不是完整 Ubuntu shell命令选项和工具数量都有限。本次设备识别结果中/dev/mmcblk0p1是 FAT 启动分区/dev/mmcblk0p2是标签为writable的 ext4 根分区。需要只读检查文件时可先挂载mkdir-p/mnt/root /mnt/bootmount-oro /dev/mmcblk0p2 /mnt/rootmount-oro /dev/mmcblk0p1 /mnt/bootls-l/mnt/root/bootls-l/mnt/boot修复前先只读挂载确认目标无误后再决定是否重新以读写方式挂载。例如 BusyBoxls不支持-hls -lh # 可能报 invalid option ls -l # 使用兼容写法本次 initramfs 中还出现过tar: not found。这表示当前救援环境没有打包工具不应继续照抄完整 Ubuntu 下的tar命令应改用带完整工具的恢复系统或把分区挂载到另一台 Linux 主机处理。四、常见启动判断没有任何内核输出检查串口参数、启动介质和 U-Boot有内核输出但找不到 rootfs检查root、分区 LABEL、initramfs能进入 initramfs说明内核和 initrd 已执行但挂载 rootfs 失败能进入 login 但 SSH 不通优先检查网络地址、路由和 sshd而不是重装内核。五、为什么 HDMI 日志可能拖慢启动如果串口反复出现dwhdmi-rockchip ... i2c read err! ddc read failed这说明 HDMI DDC 通信没有正常完成可能与显示器、线缆、供电或显示 overlay 有关。它与根分区挂载是两个独立问题但本次日志中与较长启动时间同时出现。当前尚未完成因果验证不能直接断言它就是全部启动延迟的唯一原因应记录显示器连接状态和 U-Boot 加载的 overlay并做有/无显示设备的对照启动测试。六、把“现象”转换成“下一条命令”启动故障排查最重要的是减少猜测。可以按下面的判断链处理1. 能进入(initramfs)说明 CPU 已经执行了新内核initrd 也已经被加载。此时优先确认块设备和 root 参数cat /proc/cmdline blkid ls -l /dev/mmcblk*不要一看到 initramfs 就重刷系统。2.root指向 PARTUUID把命令行中的值和blkid输出逐字符比较。PARTUUID 改变后即使分区内容完全正常initramfs 仍可能找不到根分区。3. 改用 LABEL 时也要验证 LABEL 唯一且真实存在本文实测使用rootLABELwritable解决的是“启动参数与真实分区标识不一致”这一具体问题并不代表 LABEL 永远优于 PARTUUID。工程上应选择稳定、可维护且与启动脚本一致的标识方式。七、BusyBox 环境下为什么命令经常“不好使”initramfs 中通常只有精简 BusyBox 工具集因此某些 GNU 命令根本不存在同名命令支持的参数比完整 Ubuntu 少/boot/firmware等完整系统路径可能尚未挂载网络和 DNS 也未必可用。所以救援时应先执行最小、只读、可确认目标的操作。能只读挂载就先只读挂载能观察就先观察再决定是否写入。八、HDMI warning 应该怎么处理HDMI DDC 错误可能需要处理但它和 rootfs 挂载失败是两条不同链路。更严谨的做法是做对照实验记录连接显示器时的启动时间和日志记录断开显示器时的启动时间和日志对比 U-Boot overlay、kernel warning 次数和 systemd 到达 login 的时间。只有有了对照数据才能判断它是否是明显启动延迟来源。九、本文验收清单能根据串口判断停在 U-Boot / Kernel / initramfs / systemd 哪一阶段已比较/proc/cmdline与blkid的真实分区标识initramfs 中优先采用只读检查没有把 BusyBox 当成完整 Ubuntu shell没有把单条 HDMI warning 直接定性为启动失败主因修复后能看到正常 login 或进一步进入用户空间。小结串口日志分析的核心是先定位启动阶段再决定查看分区、设备树、驱动还是服务。不要把所有警告都当成导致启动失败的根因。工作流实测截图图1串口 initramfs 环境中 blkid 和 mmc 设备节点输出。图2从 DDR 初始化到 systemd/SSH 就绪的阶段性日志。专栏导航专栏LubanCat RK3588 实时 Linux 开发实战第 9/13 篇上一篇LubanCat RK3588 实时 Linux 开发八RT 内核 DEB 安装、启动校验与安全回滚下一篇LubanCat RK3588 实时 Linux 开发十RT 内核启动后的驱动、网络与服务全面验收参考资料Linux initramfs 文档Linux kernel parameters文中的版本号、接口名、设备地址和测试数据均应以自己的板卡实测为准引用命令前请先确认当前 SDK、内核和启动布局。标签串口调试U-BootinitramfsLinux启动RK3588