linux系统启动日志需分层查看：1. /var/log/boot.log查早期服务初始化；2. dmesg -t查硬件与驱动级错误；3. journalctl -b查完整systemd启动链，配合-p err或关键词过滤快速定位问题。
系统启动日志是定位开机失败、服务未就绪、硬件识别异常等关键问题的第一手证据。分析时不能只扫屏幕最后几行，要分层聚焦时间线、来源和错误信号。
看哪里：明确三类核心日志源
不同阶段的日志由不同机制生成，需对应查看：
- /var/log/boot.log：记录 systemd 启动早期服务（如 udev、lvm）的初始化过程，适合查“卡在某个服务不动”
- dmesg -T：内核环缓冲区带时间戳输出，重点看硬件检测、驱动加载、内存/PCIe/NVMe 初始化是否报错（搜索 Oops、hung_task、Hardware Error）
-
journalctl -b：完整本次启动的 systemd 日志，覆盖从 init 到用户级服务。用
journalctl -b -p err只看错误级事件，比翻 syslog 更准
怎么看：按时间+服务+关键词快速定位
启动失败往往发生在特定时间点或某个服务之后，别盲目全文搜索：
- 先确认大致故障时间：用
journalctl -b --since "2 min ago"查最后两分钟，再逐步往前推 - 锁定可疑服务：比如图形界面没起来，运行
journalctl -b -u gdm3 -p err（Ubuntu）或journalctl -b -u display-manager（CentOS） - 抓典型关键词：对常见失败场景，直接 grep：
journalctl -b | grep -i "failed\|timeout\|dependency\|refused\|denied"
注意加-i忽略大小写，避免漏掉小写的 “failed”
怎么断：结合状态与上下文交叉验证
单条日志可能误导，要关联前后行为判断真因：
- 看到某服务
Active: failed，立刻执行systemctl status 服务名，看 Loaded 行是否路径正确、Process 行是否被 kill 或 segfault - 若日志里出现
Permission denied，不一定是权限设错——先查 SELinux：sudo ausearch -m avc -ts boot | tail -10（RHEL/CentOS），或sudo aa-status（Ubuntu） - 怀疑磁盘或文件系统问题：
dmesg -T | grep -i "ext4\|xfs\|ata\|nvme"看是否有 I/O timeout、link reset、read failure；再配合sudo smartctl -a /dev/nvme0n1查 SMART 健康值
怎么防：让下次排查更高效
启动日志默认可能不持久，重启后丢失关键线索：
- 启用 journal 持久化：
sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald - 启动失败进不了系统？用 Live USB 启动后挂载原系统根分区，再查
/mnt/var/log/boot.log和dmesg -T --file /mnt/var/log/kern.log - 习惯性加一个启动快照命令：
sudo dmesg -T > ~/dmesg-boot-$(date +%s).log，出问题时有据可查
