journalctl -b 是排查现代 linux 开机问题的首选工具，配合 dmesg 查内核级问题、systemd-analyze 定位启动瓶颈，三者协同覆盖 uefi 到服务就绪全链路。

直接看本次开机全过程：journalctl -b 是首选

绝大多数现代 Linux（Ubuntu 22.04+、CentOS 7+、Fedora、Debian 10+）都用 systemd，journalctl -b 就是专为“这次开机从内核加载到桌面/服务就绪”这一整条链设计的。它不依赖文件落盘，只要 systemd-journald 启动成功，日志就在内存+持久化存储里。

• 加 --no-pager 避免卡在分页器里：例如 journalctl -b --no-pager | grep -i "failed\|error"
• 加 -p err 只看错误级及以上（err、crit、alert、emerg），跳过海量 info 日志干扰判断
• 别用 cat /var/log/journal/... 手动读二进制文件——journalctl 才是正确接口，直接 cat 会乱码或报错
• 如果系统卡在启动界面没进登录，但还能切到 tty（Ctrl+Alt+F2），journalctl -b 通常仍可用；若 journald 自身崩溃，则需退而求其次用 dmesg

查硬件/驱动级问题必须用：dmesg

dmesg 输出的是内核环形缓冲区内容，从第一条 printk 开始记，不受用户空间服务影响。哪怕 systemd 没起来、journald 崩溃、甚至系统卡死在 initramfs 阶段，只要内核还在跑，dmesg 就能告诉你 CPU、内存、磁盘、网卡有没有被识别出来。

• 用 dmesg -l warn,err 快速筛出警告和错误，比全量输出高效得多
• dmesg -T 把时间戳转成可读格式（如 [Mon Mar 21 20:15:03 2026]），方便和你手动计时对齐
• 想保存下来给同事看？dmesg > /tmp/dmesg.boot 即可，注意别写进 /var/log/ 下——那里的 /var/log/dmesg 是旧版快照，不一定包含最新启动信息
• 某些笔记本/新主板可能因 UEFI 设置导致 dmesg 缺少 early console 输出，这时要配合 GRUB 参数 loglevel=7 debug 临时启用更细粒度日志

老系统或日志落盘失效时，盯紧这几个文件

不是所有机器都开了 systemd-journal 持久化（默认只存内存），有些容器镜像、精简版系统或配置失误的服务器，journalctl -b 可能返回空或只显示最近几条。这时得翻传统日志路径：

• /var/log/boot.log：SysVinit 风格残留，CentOS 7 早期、Debian 9 常见，记录 rc.sysinit 和服务启动顺序，但内容较简略
• /var/log/messages（RHEL/CentOS）或 /var/log/syslog（Debian/Ubuntu）：含 systemd 启动后各服务的 stdout/stderr，比如 NetworkManager 失败、sshd 绑定端口失败都会写这儿
• /var/log/kern.log：纯内核消息副本，等效于 dmesg 的落盘版，适合对比确认是否丢失了环形缓冲区内容
• 用 less 查，别用 cat ——这些文件动辄几十 MB，cat 会刷屏卡死；tail -n 200 /var/log/messages 看末尾也比全量加载快

查完日志发现没线索？试试 systemd-analyze

有些启动异常不是报错，而是慢——比如某个服务卡住、依赖循环、或 initramfs 解压耗时过长。journalctl 和 dmesg 往往只显示“它没起来”，不告诉你“它卡在哪”。这时候 systemd-analyze 就是定位瓶颈的利器。

• systemd-analyze blame 列出各单元启动耗时，排在最顶的几个就是嫌疑对象
• systemd-analyze critical-chain 展示最长依赖链，能一眼看出哪一环拖垮了整个启动流程
• systemd-analyze plot > boot.svg 导出 SVG 时间线图（需安装 graphviz），适合向非技术人员展示瓶颈位置
• 注意：该命令只分析 systemd 管理的服务，对 kernel/initramfs 阶段无感知——所以得先用 dmesg 排除硬件层卡顿

真正难搞的启动问题，往往横跨多个层级：UEFI 固件 → GRUB 加载 → initramfs 解压 → 内核初始化 → systemd 启动 → 服务依赖。每个环节的日志来源不同，工具也不同，不能只盯一个命令。尤其当 journalctl -b 看起来“一切正常”却起不来时，dmesg 和 systemd-analyze 往往才是破局点。