Linux启动失败应分阶段排查：一、GRUB阶段检查内核参数与initrd；二、命令行阶段用systemctl查失败服务及依赖；三、聚焦dmesg、journalctl等三类核心日志；四、日志正常时检查挂载、initramfs、文件系统一致性。
Linux启动失败时，日志是唯一可靠的线索。关键不是“看哪些日志”，而是按启动阶段分层抓取——从GRUB画面开始，一层层往下推进，跳过无关信息，直击故障点。
一、黑屏/卡在GRUB阶段：先盯住内核参数
此时系统尚未加载完整日志服务，只能靠视觉线索和手动干预：
- 启动时按 Shift（BIOS）或 Esc（UEFI） 进入GRUB菜单，选中启动项后按 e 编辑
- 检查 linux 行里的 root= 参数：必须指向真实存在的根分区，推荐用
root=UUID=xxx格式；可用blkid命令验证 - 确认 initrd 行路径是否匹配实际文件名（如
/boot/initramfs-6.8.0-xx.img），执行ls /boot/对照查看 - 临时删掉
quiet splash，替换成noquiet nosplash rd.debug systemd.log_level=debug，让屏幕输出更详细
二、能进命令行但没桌面/网络：查失败服务与依赖
说明用户空间已启动，问题出在某个服务阻塞了后续流程：
- 运行
systemctl list-units --state=failed，列出所有失败单元 - 对每个失败服务执行
systemctl status 服务名 -n 50，重点看 Process 行的命令和 status= 后的退出码（如status=217/USER表示用户不存在） - 用
systemctl show 服务名 | grep -E "(Wants|Requires|After)"查它依赖哪些 target 或 service，再逐个systemctl status检查上游是否就绪 - 手动运行
ExecStart=后的命令（加sudo -u 用户名和正确WorkingDirectory），常能暴露权限、路径、环境变量等 systemd 日志里不显示的问题
三、有日志但看不出问题：聚焦三类核心输出
别全刷一遍，锁定三个最有效命令，覆盖硬件→内核→用户空间全链路：
-
dmesg -l err,warn：只看内核级错误，重点关注硬盘识别（sda: unknown partition table）、驱动加载失败、PCIe 初始化异常 -
journalctl -b -p err：本次启动所有错误级日志，快速定位 systemd 在哪个 unit 卡住（如Failed to start NetworkManager） -
journalctl -u systemd-sysusers.service -n 30或cat /var/log/boot.log（若存在）：观察用户组初始化、fstab 挂载、dbus/udev/logind 等基础服务是否成功启动
四、日志干净却起不来：检查底层一致性
常见于误操作后表面正常但功能缺失，比如挂载失败、initramfs 错位、文件系统损坏：
- 执行
mount | grep "on / "确认根分区是否真正以读写方式挂载；若为只读，可能是 fsck 未通过 - 运行
lsinitrd /boot/initramfs-$(uname -r).img | grep -E "(lvm|crypt|nvme)"，确认 initramfs 是否包含当前硬件所需模块 - 强制检查根分区：
umount /dev/sda1 && fsck -y /dev/sda1（需先卸载）；XFS 系统用xfs_repair -v -L /dev/sda1 - 重建 initramfs：
sudo update-initramfs -u -k all（Debian/Ubuntu）或sudo dracut -f（RHEL/CentOS）
