dmesg是查看硬件初始化与固件运行日志的唯一权威工具，因其直接读取内核环形缓冲区，覆盖uefi/bios执行、acpi加载、早期驱动probe等systemd启动前的全过程，而journalctl -b -1仅记录systemd启动后的日志。
journalctl -b -1 不能查看硬件初始化阶段的底层固件运行日志。
原因很明确：
-
journalctl -b -1查的是上一次系统启动时 systemd-journald 所采集的日志，起始时间点是内核完成初始化、systemd 进程（PID 1）开始运行之后。 - 而硬件初始化、固件（如 UEFI/BIOS）运行、ACPI 表加载、早期驱动 probe 等过程，发生在内核启动前或内核启动极早期，此时 systemd-journald 尚未启动，根本不会记录这些内容。
真正能反映该阶段信息的，只有 内核环缓冲区（kernel ring buffer） —— 它由内核自身在启动最早期就建立并持续写入，覆盖从固件移交控制权、解压内核镜像、初始化 CPU/内存/PCIe/USB 控制器，到 early driver 初始化的全过程。
✅ 正确查看硬件初始化与固件运行日志的方法
用 dmesg 查看完整内核启动日志（含固件交互）
这是最直接、最权威的方式：
dmesg
它默认输出全部内核消息，包括：
- EFI firmware version、SMBIOS info、ACPI table loading（如 DSDT/SSDT）
- PCIe link training、NVMe controller reset、USB host controller init
- 固件报错（如
ACPI Error,UEFI: Failed to get variable,Firmware bug） - 内存初始化（
e820: update [mem ...] usable → reserved）、TPM、IOMMU setup
⚠️ 注意：
dmesg输出需 root 权限才能看到全部内容（尤其涉及固件/安全模块），建议加sudo：sudo dmesg
聚焦固件与硬件初始化的关键行
常用过滤方式：
-
查看所有固件相关消息（EFI/UEFI/ACPI/SMBIOS）：
sudo dmesg | grep -i "efi\|uefi\|acpi\|smbios\|firmware"
-
查看硬件探测失败或警告（如设备未识别、驱动绑定失败）：
sudo dmesg -l err,warn | grep -i "pci\|usb\|nvme\|eth\|failed\|unable"
-
查看启动初期（前 5 秒）的硬件初始化快照：
sudo dmesg -T | awk '$1 ~ /^\[/ && substr($1,2,5)+0 <p>（注：<code>-T</code> 显示人类可读时间戳，需内核支持；若不支持，可用 <code>dmesg -t | head -n 200</code> 替代）</p>
❌ 为什么 journalctl -b -1 不适用？
-
-b -1仅读取/var/log/journal/中持久化（或本次启动缓存）的 systemd 日志，最早条目通常始于systemd[1]: Starting Initialize hardware...或kmod-static-nodes.service启动之后，已错过固件执行、内核解压、early console、ACPI 枚举等关键阶段。 - 即使启用了
Storage=persistent，journald 仍无法捕获内核启动前和 kernel logbuf 初始化前的任何事件。
✅ 补充：获取更底层信息的辅助手段
-
查看开机时的
dmesg快照（静态快照，不含实时变化）：sudo cat /var/log/dmesg # 多数发行版在 shutdown 时保存上一次的 dmesg 输出
-
检查 UEFI 变量（需
efivarfs挂载）：ls /sys/firmware/efi/efivars/ 2>/dev/null || echo "Not booted in UEFI mode"
-
使用
fwts（Firmware Test Suite）做固件健康检查（需安装）：sudo fwts --show-progress --log-level=3 acpi
不复杂但容易忽略：固件和硬件初始化日志不在 journalctl 范围内，dmesg 才是唯一入口。
