dmesg是centos 7启动时最准确的硬件日志源，直接读取内核环形缓冲区，记录硬件检测、驱动加载、pci识别、磁盘初始化等底层过程，比/var/log/messages更早更全，且不依赖syslogd服务。
直接看 dmesg 输出，这是最准的硬件日志源
CentOS 7 启动时所有硬件检测、驱动加载、PCI 设备识别、磁盘初始化等过程，都由内核记录在环形缓冲区里，dmesg 就是读取它的唯一可靠方式。它比 /var/log/messages 更早、更底层，且不依赖 syslogd 服务是否运行。
常见错误现象：系统启动卡在“Starting LSB”、硬盘识别不到、网卡没 IP、USB 设备不响应——这些几乎都得先查 dmesg 才能定位。
-
dmesg默认输出全部内容，但通常太多，建议加-T显示带时间戳的可读时间（如[Tue Jul 8 02:45:12 2026]） - 过滤关键硬件信息：
dmesg | grep -i "usb\|pci\|ata\|nvme\|raid\|firmware" - 查看最近硬件错误：
dmesg | grep -i "error\|warn\|fail\|timeout"（注意：很多 “warning” 实际是致命问题，比如nvme 0000:01:00.0: failed to set default aers） - 清空缓冲区前务必先保存：
dmesg > /tmp/dmesg-boot-$(date +%s).log，否则重启后旧日志就丢了
journalctl -k 是 dmesg 的 systemd 封装，但有缓存延迟
journalctl -k 看起来和 dmesg 输出一样，但它读的是 journald 持久化后的内核日志，不是实时环形缓冲区。这意味着：
- 如果
journald服务异常或未启用持久存储（/var/log/journal目录不存在），journalctl -k可能为空或缺失早期日志 - 某些快速失败的硬件初始化（如 BIOS/UEFI 阶段的设备未被内核识别）根本不会进 journald，只留在
dmesg里 - 它支持按时间筛选：
journalctl -k --since "2 hours ago"，但dmesg不支持原生时间范围，得靠grep或awk处理
/var/log/messages 里只有被 syslogd 转发的硬件事件
/var/log/messages 是用户态服务（syslogd/rsyslog）整理后的日志，它只收录内核通过 netlink 或 /dev/log 主动上报的事件，不是全量硬件日志。
典型场景下它会漏掉：
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
- 内核模块加载失败（如
modprobe igb报错但没触发 syslog 上报） - BIOS 设置冲突导致的 SATA 控制器静默降速（
dmesg里有ata1: limiting speed to UDMA/33，/var/log/messages通常没有） - ACPI 表解析错误（
dmesg | grep -i acpi常见，但很少进 messages）
若需用它辅助排查，优先组合：tail -n 200 /var/log/messages | grep -i "kernel\|hardware\|firmware"，避免被大量无关服务日志淹没。
别忽略 /var/log/boot.log 和 dmesg -T 的时间对齐
/var/log/boot.log 记录的是 systemd 启动单元的 stdout/stderr，它本身不含硬件细节，但和 dmesg -T 时间戳对齐后，能帮你确认某个硬件驱动加载是否卡在某个服务启动之前。
例如：网卡没起来 → 查 dmesg -T | grep eth0 发现 “device not found” → 再查 cat /var/log/boot.log | grep -A5 -B5 network，看 network.service 是否因 udev 规则未就绪而超时退出。
容易踩的坑：
-
boot.log默认权限为600，非 root 用户无法读取 - 该文件只在启动时追加，不滚动，旧日志会被覆盖（除非配置 logrotate）
- systemd 默认关闭
boot.log记录，需确认/etc/systemd/system.conf中LogLevel=info且LogTarget=console未被覆盖
真正要盯住硬件问题，dmesg 是第一道门，journalctl -k 是第二道补充，其余日志都是旁证。时间戳不准、服务未就绪、内核未上报——这些都会让日志链断裂，不能只信一个来源。
