Ubuntu不提供图形化开机自检进度条，真实硬件检测过程由内核完成并记录在journal日志中，可通过sudo journalctl -b查看完整启动日志，结合systemd-analyze blame和critical-chain分析初始化耗时与依赖阻塞。
Ubuntu没有“开机自检进度”这个标准概念——它不提供类似BIOS/UEFI那种图形化自检条，也不会在启动时主动显示硬件检测步骤。所谓“自检”，实际是内核加载设备驱动、初始化总线、探测PCI/USB设备等过程，这些日志默认被抑制，只在故障时才暴露。
systemd 启动日志怎么看真实初始化过程
Ubuntu 16.04+ 默认使用 systemd，所有启动阶段（包括内核模块加载、服务依赖解析、单元启动顺序）都记录在 journal 中。想看到“真实自检进度”，不是看动画条，而是查日志：
-
sudo journalctl -b：查看本次启动全部日志（含内核dmesg和 systemd 单元启动细节） -
sudo journalctl -b -u systemd-udev-settle.service：查设备节点就绪时刻（常作为“硬件探测完成”标志） -
sudo systemd-analyze blame：列出各服务启动耗时，识别拖慢初始化的单元 -
sudo systemd-analyze critical-chain：显示关键路径上依赖链，看清哪些服务卡住了后续启动
如何让启动过程更“可见”（非GUI）
如果你希望终端启动时少隐藏、多输出，避免黑屏或快速滚动消失，关键是关闭 quiet splash 内核参数：
- 编辑
/etc/default/grub，把GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"改成GRUB_CMDLINE_LINUX_DEFAULT="" - 运行
sudo update-grub生效 - 重启后会看到内核打印（如
usb 1-1: new high-speed USB device）、systemd启动单元名、以及失败服务的红色报错
注意：这不会增加“自检项”，只是取消日志过滤——真正初始化行为由内核和 systemd 自动完成，不可手动增删硬件检测步骤。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
rc.local 不适合做“自检”，但可做启动后校验
/etc/rc.local 在 multi-user.target 之后执行，此时系统已基本就绪。它不能参与内核级设备探测，但适合做轻量级运行时检查：
- 检查关键设备是否存在：
ls /dev/video0 && echo "camera ok" || echo "camera missing" - 验证服务端口是否监听：
ss -tln | grep :8080 && exit 0 || exit 1 - 写入状态到文件供后续诊断：
echo "$(date): rc.local ran" >> /var/log/boot-check.log
别指望它报告“硬盘自检通过”或“内存测试完成”——那些发生在 initramfs 阶段，rc.local 根本接触不到。
真正需要“自检逻辑”的场景怎么处理
如果你的应用有明确的前置依赖（比如必须等摄像头驱动加载完、GPU 初始化成功、或某块 FPGA 配置完成），靠等待固定秒数（如 ExecStartPre=/bin/sleep 10）极不可靠。正确做法是：
- 用
udev规则监听设备事件，触发脚本（例如：当/dev/video0出现时运行你的程序） - 在 service 文件中用
ConditionPathExists=/dev/video0或ConditionPathIsDirectory=/sys/class/video4linux做启动守卫 - 对 NVIDIA GPU，检查
nvidia-smi -L是否返回非空；对 USB 设备，用udevadm wait --subsystem-match=usb --action=add
硬编码等待时间、或幻想系统会给你一个“自检完成信号”，是多数人踩坑的起点——Ubuntu 的初始化是异步、事件驱动的，不是线性流程表。
