Linux启动流程怎么分析_从BIOS到系统就绪详解【指导】

11次阅读

Linux 启动可分六个关键控制点定位故障:先查 UEFI/BIOS 模式(ls /sys/firmware/efi/efivars),再依次排查 GRUB 加载、内核启动、initramfs、根文件系统挂载及 systemd 服务失败原因。

Linux 启动流程怎么分析_从 BIOS 到系统就绪详解【指导】

Linux 启动不是黑盒——只要分清六个关键控制点,你就能在系统卡死、进不了登录界面、甚至 kernel panic 时,快速定位是固件问题、引导损坏、内核加载失败,还是用户空间服务没起来。


怎么看当前系统走的是 BIOS 还是 UEFI?

这是所有分析的起点。错判模式会导致后续排查方向全偏:
BIOS 对应 MBR + grub 阶段 1 加载;UEFI 对应 ESP 分区 + grubx64.efi 直接执行。

  • 运行 ls /sys/firmware/efi/efivars:能列出大量变量 → 确认为 UEFI 模式
  • 运行 efibootmgr -v:有输出且含 ubuntucentos 等启动项 → UEFI
  • 若报错 No such file or directory,且 fdisk -l 显示磁盘用 dos 标签 → 极大概率是 BIOS+MBR

⚠️ 容易踩的坑:有些新 主板 默认启用 UEFI,但安装系统时误选了 Legacy BIOS 模式(或反之),导致 /boot/efi 分区缺失、grub.cfg 不被读取、甚至 GRUB 提示 error: unknown filesystem


GRUB 菜单不出现 / 卡在 black screen 怎么查?

这不是“没反应”,而是 GRUB 阶段 2 没成功加载配置或找不到内核镜像。常见于升级内核后未更新 GRUB 配置、/boot 分区满、或 initramfs 损坏。

  • 开机时狂按 Shift(BIOS)或 Esc(UEFI)强行呼出 GRUB 菜单;失败则说明阶段 1.5 或阶段 2 根本没跑起来
  • 进 Live 系统挂载原系统后检查:ls /boot/vmlinuz-*ls /boot/initramfs-*.img 是否成对存在
  • 重建 GRUB 配置:grub2-mkconfig -o /boot/grub2/grub.cfg(RHEL/CentOS)或 update-grub(Debian/Ubuntu)
  • 确认 /boot/boot/efi 分区未满:df -h /boot*

? 注意:grub.cfg 是生成文件,** 不要手动编辑它 **;修改应通过 /etc/default/grub/etc/grub.d/ 下脚本完成。


内核加载后黑屏 / 卡在“Starting kernel…”怎么办?

说明 GRUB 成功把 vmlinuzinitramfs 加载进内存,但内核无法挂载根文件系统——90% 是驱动缺失或设备路径错误。

  • 开机时在 GRUB 菜单选中条目,按 e 编辑启动参数,在 linux 行末尾加 rd.debug systemd.log_level=debug,再按 Ctrl+X 启动,看卡在哪一步
  • 常见原因:root= 参数指向错误设备(如 /dev/sda2 变成 /dev/nvme0n1p2),或 LVM/RAID/LUKS 设备没在 initramfs 中包含对应模块
  • 检查 initramfs 内容:lsinitrd /boot/initramfs-$(uname -r).img | grep -E "(lvm|raid|crypt|nvme)"
  • 重生成 initramfs:dracut -f(RHEL/CentOS)或 update-initramfs -u(Debian/Ubuntu)

⚠️ 关键细节:UEFI 下若根分区是 Btrfs 或 XFS,某些旧内核 initramfs 默认不带对应驱动,必须显式启用。


systemd 启动卡在某个 service(如 NetworkManager、dbus)怎么诊断?

此时内核已就绪、根文件系统已挂载、/sbin/init 已是 systemd(PID 1),但某个 unit 启动超时或失败,阻塞整个初始化链。

  • 启动后立即运行:systemctl --failed 查看失败单元
  • 查具体日志:journalctl -b -p err(本次启动的错误)或 journalctl -b -u NetworkManager
  • 跳过故障服务临时启动:systemd.unit=multi-user.target(绕过图形 target)或 systemd.mask=NetworkManager.service(禁用该服务)
  • 检查依赖关系:systemctl list-dependencies --reverse .service 看谁在等它

? 最容易被忽略的一点:systemd 的 timeout 默认只有 90 秒,而某些存储设备(如 USB-NAS、iSCSI)初始化慢,会直接被 kill。可通过 DefaultTimeoutStartSec=300s/etc/systemd/system.conf 中延长。

text=ZqhQzanResources