linux启动失败应逐层排查：先用journalctl -b查本次启动日志，再用dmesg看内核输出，接着检查/var/log/下boot.log等传统日志，最后验证fstab、文件系统读写性、selinux及服务命令手动执行。
Linux启动失败时，别急着重装系统。真正有效的排查，是顺着启动链路一层层往下看：从内核加载、systemd初始化，到服务启动失败点，每一步都有对应日志和工具可查。
一、先看本次启动的完整日志链（journalctl -b）
这是最直接的入口。systemd 系统把从内核第一条输出到用户空间服务拉起的全过程都记在 journal 里：
- 当前启动全部日志：运行
journalctl -b，从头翻到底，重点关注以Failed、Error、timeout、panic开头的行 - 只看错误级别消息：用
journalctl -b -p err快速过滤出真正报错的部分 - 对比上一次成功启动：执行
journalctl -b -1，两边对照，差异处往往就是故障根源 - 配合关键词高亮：比如刚遇到黑屏卡住，可跑
journalctl -b --no-pager | grep -E "(start|fail|stop|hang)"
二、挖底层硬件与驱动问题（dmesg）
journal 可能没记录到最开始的问题，尤其当 systemd 还没起来就崩了。这时得靠内核自己的“记忆”——dmesg 缓冲区：
- 看全部启动期内核输出：直接运行
dmesg，注意开头几屏，常有ACPI Error、PCIe link down、Unable to handle kernel NULL pointer这类致命提示 - 聚焦警告和错误：用
dmesg -l warn,err，比全屏扫更高效 - 保存离线分析：如果进不了系统，可在救援模式下执行
dmesg > /mnt/sysroot/tmp/dmesg_boot.log导出到外部设备
三、检查传统日志文件（/var/log/ 下的固定路径）
部分发行版或配置下，journal 没开启持久化，关键信息会落盘到传统日志。即使启用了 journal，这些文件也常含额外上下文：
-
/var/log/boot.log：记录 init 进程、udev、网络服务等早期启动步骤，适合看“卡在哪一步” -
/var/log/messages（RHEL/centos）或/var/log/syslog（debian/ubuntu）：汇总系统级事件，搜索starting和failed能串起服务启动顺序 -
/var/log/dmesg：有些系统会把 dmesg 输出自动存一份到这里，相当于备份
四、验证关键配置与依赖（手动触发 + 权限检查）
很多“启动失败”本质不是系统坏了，而是某项配置写错了，或某个目录权限不对：
- 查 fstab 是否合法：运行
mount -a，如果有行报错（如unknown Filesystem type或No such device），说明挂载表有误，系统会卡在 mount 阶段 - 确认 root 分区可读写：在恢复模式下执行
df -h /，若显示Read-only file system，需先mount -o remount,rw / - 检查 SELinux 或 AppArmor 状态：运行
sestatus或aa-status，若为 enforcing 模式且最近改过服务配置，可能是策略拦截了启动 - 模拟 systemd 启动命令：从
systemctl status xxx中复制ExecStart=后的命令，换对应用户手动执行（如sudo -u mysql /usr/libexec/mysqld --daemonize），终端实时输出常暴露配置路径错、目录无写权等细节