定位Linux启动日志需综合使用journalctl、dmesg、/var/log/文件、GRUB参数调试及服务单元日志：1. journalctl -b查看本次启动；2. dmesg获取内核原始输出；3. 检查/var/log/messages等传统日志；4. GRUB中添加loglevel=7和systemd.log_level=debug；5. journalctl -u service -b分析特定服务。
如果您在系统启动后怀疑存在服务未正常加载、内核模块加载失败或初始化阶段异常，则需回溯启动过程产生的原始日志。Linux 启动日志并非单一文件，而是分散在内核缓冲区、systemd 日志和传统日志目录中。以下是定位与提取启动日志的多种方法：
一、使用 journalctl 查看本次及历史启动日志
journalctl 是 systemd 系统默认的日志管理工具，可精准提取从内核引导到用户空间完成的完整启动链路，支持按启动会话过滤，避免与其他运行时日志混杂。
1、查看当前启动会话的全部日志：
journalctl -b
2、查看上一次启动的日志：
journalctl -b -1
3、仅显示启动阶段（内核+early boot）的错误级别消息：
journalctl -b -p err
4、以反向时间顺序（最新在前）显示启动日志，并高亮关键词：
journalctl -b --no-pager | grep -E "(failed|error|warn|panic|oom)"
二、读取内核环形缓冲区 dmesg 日志
dmesg 缓冲区保存自内核加载起的最原始硬件与驱动级输出，不受用户空间日志服务影响，在 systemd 未启动或崩溃时仍可访问，是诊断硬件兼容性、驱动缺失、内存映射异常的关键依据。
1、显示全部内核启动信息：
dmesg
2、仅显示启动阶段（含 early console 输出）的警告与错误：
dmesg -l warn,err
3、将原始 dmesg 输出保存为文件便于离线分析：
dmesg > /tmp/boot_dmesg.log
4、实时监控新出现的内核消息（适用于复现启动问题）：
dmesg -w
三、检查 /var/log/ 目录下的传统启动日志文件
部分发行版（如 CentOS 7 早期、Debian 9 及更旧版本）仍保留 SysVinit 风格日志写入机制，关键启动事件可能落盘至固定路径，尤其当 journald 持久化未启用时，这些文件是唯一持久化记录。
1、查看系统通用消息日志（含 init 进程、服务启动状态）：
cat /var/log/messages
2、检查内核与硬件相关启动记录（Red Hat/CentOS）：
cat /var/log/dmesg
3、定位引导加载器（GRUB）传递给内核的参数及早期初始化输出：
cat /var/log/boot.log
4、若系统启用了 systemd-journal 持久化，确认日志已落盘至：
/var/log/journal/$(hostname -I | awk '{print $1}' | md5sum | cut -d' ' -f1)/
四、通过 GRUB 启动参数临时启用详细启动输出
默认情况下，多数发行版在启动时隐藏详细日志以提升视觉简洁性；通过修改内核命令行参数，可在下次启动时强制输出全部引导过程信息至控制台，便于肉眼观察卡点位置。
1、重启前编辑 GRUB 菜单：启动时长按 Shift（BIOS）或 Esc（UEFI），选择启动项后按 e 键编辑
2、在 linux 行末尾删除 quiet splash 参数
3、添加 loglevel=7 systemd.log_level=debug 以启用最高级别内核与 systemd 日志
4、按 Ctrl+X 或 F10 启动临时生效的调试模式
五、提取特定服务在启动阶段的初始化日志
当某项关键服务（如 network、sshd、nginx）未能随系统启动就绪，需隔离其自身启动上下文，排除依赖服务或配置语法错误干扰。
1、查看指定服务在本次启动中的完整单元日志：
journalctl -u sshd.service -b
2、追溯该服务启动失败前 50 行关联日志（含依赖单元）：
journalctl -u sshd.service -b -n 50 --no-pager
3、检查服务单元文件是否被屏蔽或禁用：
systemctl is-enabled sshd.service
4、验证服务定义中 ExecStart 指令所调用的二进制是否存在且可执行：
ls -l $(systemctl show -p ExecStart sshd.service | cut -d= -f2 | awk '{print $1}')
