很多人以为按下电源键屏幕一亮就是操作系统开始干活了。实际上从你按下电源键到桌面出现前几百毫秒里运行的根本不是你装的那个操作系统而是主板固件里的程序。我第一次被这个问题折腾是给一台老笔记本装双系统重启之后直接停在grub rescue黑底白字一行提示进不去 Windows 也进不去 Linux那会儿我连 MBR 和 GPT 都分不清。后来在虚拟机里反复做实验读内核文档翻 GRUB 源码才算把“操作系统启动”这条链路完整串起来。这篇文章就把这条链路从头到尾捋一遍从电源键按下到固件交接再到引导装载程序、内核初始化、服务启动最后聊几个常见的启动故障和排查思路。无论你是正在学操作系统这门课很多人都在看“1.3 操作系统启动”这一节还是平时喜欢自己装系统、折腾双系统的玩家又或者是日常跟 Linux 服务器打交道的运维这套思路都会让你少走很多弯路。1. 按下电源键后的第一段代码固件的交接逻辑计算机通电之后CPU 拿到的第一条指令不是来自硬盘也不是来自操作系统而是来自主板上的一个 ROM 芯片——固件。这一段代码的历史可以追溯到上世纪 80 年代的 BIOS现在则越来越多地被 UEFI 取代。不管名字怎么变固件的职责都一样把硬件初始化好然后找一段可执行代码把控制权移交过去。1.1 BIOS 与 UEFI两种完全不同的接力规则BIOS 是老一代固件运行在 16 位实模式下它设计的时候根本没考虑后来的大内存、多核 CPU 和超大硬盘。它初始化完硬件之后会按照启动顺序逐个检查启动设备在每一个设备上寻找引导记录。如果是 MBR 磁盘它会读第一个扇区的 512 字节检查最后两个字节是不是0x55AA如果是就跳转到这块引导代码里去执行。这套机制非常简单但也非常脆弱MBR 里只能放 446 字节的引导代码空间小得可怜而且一旦 MBR 被损坏整个系统就起不来了。UEFI 的规则完全不同。它把启动流程设计得更像一个小型操作系统固件里有自己的驱动、自己的文件系统解析能力能直接读取 FAT32 格式的 EFI 系统分区ESP然后从分区里的\EFI\BOOT\BOOTX64.EFI这种路径加载引导器。它不再依赖磁盘第一个扇区而是一个实实在在的文件。这意味着引导器可以做得很大很强也意味着分区表必须用 GPT 而不是 MBR。GPT 分区表自带备份和 CRC 校验抗损坏能力比 MBR 强不少。对比项BIOSUEFI运行模式16 位实模式寻址空间小32/64 位保护模式寻址空间大分区表要求MBRGPT引导方式读 MBR 512 字节找0x55AA标志读取 EFI 分区内的.efi文件引导代码容量446 字节限制极多可以是完整文件扩展性极强可交互性基本没有自带文件系统驱动可交互、可入网从我自己的使用体验来说判断一块磁盘走的是 BIOS 还是 UEFI 的坑主要集中在分区表上。你拿着一块 MBR 分区的 U 盘插到一台只开 UEFI 的主板上往往连启动都识别不到。而一块 GPT 分区的盘在老的 Legacy Only 主板上也是同样尴尬。现在大部分主板默认是 UEFI 优先但很多还保留着 CSM兼容支持模块选项打开之后才能从 MBR 磁盘引导。装系统之前先把分区表类型确认好能省掉后面很多麻烦。1.2 Secure Boot 安全启动Windows 11 的硬性要求与常见冲突Secure Boot 是 UEFI 内置的一套安全验证机制。固件里保存着一批受信任的签名数据库引导器、内核、驱动模块在加载之前都要先验签没有签名或者签名不在白名单里直接被拒。微软从 Windows 8 开始要求 OEM 预装设备默认开启 Secure BootWindows 11 更是把它作为硬性门槛。这个机制本意是防止 bootkit 这类恶意软件抢占引导阶段实际使用中最先撞上它的是 Linux 用户。为什么 Linux 有时候起不来因为 Secure Boot 白名单里本来只有微软自己的签名和少数厂商的签名。主流的 Ubuntu、Fedora 这些发行版会花钱拿到微软的签名GRUB 和内核都有签名开 Secure Boot 也能启动。但如果你自己编译了内核或者用了第三方的 GRUB 主题、未签名的内核模块加载的时候就会被拦下来表现就是开机直接黑屏或者停在固件提示界面。我处理这个问题的经验很简单要么关闭 Secure Boot要么把主板安全启动模式从“Windows”改成“Other OS”。如果不想关也可以在 BIOS 里手动导入发行版的签名证书但操作繁琐而且每次升级都要在意一下证书是否失效。另外Windows 11 升级或者恢复镜像时如果 Secure Boot 的密钥库里 dbx 证书过期系统会提示更新安全启动证书这时候去主板官网刷个 BIOS 或者用 Windows Update 推送的证书更新包就行别自己在网上随便找证书下。1.3 U 盘启动与启动顺序装机最常见的入门操作装系统时最常遇到的就是怎么让机器从 U 盘启动。这个操作本身不难难在各种主板的界面五花八门。我见过的典型做法是开机猛按快捷键戴尔一般是 F2 进设置、F12 进一次性启动菜单联想 ThinkPad 多数是 F12华硕是 Del 或者 F8。如果你只是想用 U 盘装一次系统建议用一次性启动菜单而不要改持久启动顺序省得装完第一次重启又往 U 盘里进。进了启动菜单后你会看到一堆奇怪的名字。带 UEFI 前缀的一般是 UEFI 启动项不带的是 Legacy 启动项。同一个 U 盘可能同时出现在两行里比如UEFI: KingstonDataTraveler 3.0和KingstonDataTraveler 3.0。选哪个取决于你目标磁盘的分区表格式和当前系统是否支持一般新机器优先选 UEFI 前缀的那个。如果选错了常常会卡在“Missing operating system”或者直接黑屏。有些主板还要在 BIOS 里打开“USB Boot Support”才能真正识别 U 盘特别是品牌台式机和老一点的笔记本上。2. 引导装载程序谁决定操作系统该从哪开始加载固件把自己的事做完之后接下来登场的就是引导装载程序Bootloader。它要做的事很明确加载操作系统的内核到内存把控制权交过去。但就是在加载内核之前最容易出岔子。GRUB 是 Linux 世界最主流的引导器Windows 也有自己的一套引导链理解它俩的分工双系统问题就解决了一大半。2.1 GRUB 的工作机制与配置文件GRUB 全称是 GRand Unified Bootloader从 Linux 早期一路演变到现在。在 BIOS 时代GRUB 分两个阶段stage1 放在 MBR 那 446 字节里stage2 放在磁盘后面的区域由 stage1 去加载。到了 UEFI 时代流程简化了很多——UEFI 固件直接从 EFI 分区加载grubx64.efi这个文件GRUB 自己再去读/boot/grub/grub.cfg解析菜单配置。grub.cfg看起来很长很复杂但你基本不需要直接编辑它。平时你改的是/etc/default/grub比如设置默认启动项GRUB_DEFAULT0、超时时间GRUB_TIMEOUT5改完之后执行update-grubDebian 系或者grub2-mkconfig -o /boot/grub2/grub.cfgRHEL 系系统会自动扫描已有的内核和操作系统重新生成 grub.cfg。我在刚开始接触的时候傻乎乎地去改 grub.cfg 里的一长串 menuentry升级一次内核就全白费了。记住这条规则改源配置文件再让它重新生成而不是改生成结果。GRUB 最实用的功能之一是传内核参数。比如你想临时进入救援模式、设置单用户或者排查某个内核模块导致的黑屏问题可以在 GRUB 菜单上按e键编辑当前启动项的 linux 那一行在行尾追加参数再按CtrlX启动。这种临时修改不需要写回配置文件重启就恢复原样是用来验证问题的好工具。2.2 双系统引导菜单是怎么识别彼此的双系统引导的核心矛盾在于Windows 的引导管理器根本不认 Linux而 GRUB 可以识别 Windows。所以推荐的安装顺序永远是先装 Windows 再装 Linux。Linux 安装的时候安装器比如 Ubuntu 的 ubiquity会探测磁盘上已有的系统自动生成包含 Windows Boot Manager 的启动菜单。原理上 grub.cfg 里是用一个 menuentry通过chainloader 1或者直接加载bootmgfw.efi把引导权交还给 Windows。但实际操作中经常出问题尤其是在“b850m linux win11 双系统启动”这种新主板环境下。我遇到过的情况包括Windows Boot Manager 的 EFI 引导项不见了、GRUB 菜单里看不到 Windows、或者能看到 Windows 但启动后蓝屏。排查顺序一般是先看 EFI 启动项有没有失效在 BIOS 里用efibootmgr列出所有启动项再确认 EFI 系统分区里\EFI\Microsoft\Boot\bootmgfw.efi这个文件还在不在最后检查 GRUB 有没有真正集成 Windows 项直接用update-grub重新扫描。还有一个容易被忽略的问题Windows 11 要求 TPM、Secure Boot很多 Linux 发行版安装时把 Secure Boot 关了Windows 方面倒是能起来但某些依赖 TPM 的 BitLocker 会出幺蛾子。所以如果你既要 Windows 11 又要 Linux建议保留 Secure Boot选一个带微软签名的发行版或者手动导入发行版证书。省得折腾到最后 Windows 这边又崩了。2.3 “grub rescue ” 与启动分区丢失的修复我文章开头提到的那次 grub rescue就是典型的引导装载程序损坏。这个界面出现的原因基本是GRUB 主体被破坏了或者它找不到 /boot 所在的磁盘/分区。最常见的是 MBR 里的 grub stage1 还在但 stage2 文件所在的分区被删了或 UUID 对不上了。追根溯源可能是重装 Windows 时覆盖了 MBR也可能用分区工具重排了分区导致引导分区号变了。如果只是 GRUB 配置指向错误进入 grub rescue 界面后你可以手动指定根分区输入ls (hd0,gpt1)之类的命令列出分区找到自己的 /boot 分区然后set root...、set prefix...再用insmod normal、normal进入 GRUB 菜单。这一套只适合应急无力根治。更靠谱的做法是拿一个 live USB 启动系统挂载原系统分区chroot 进去重新执行grub-install /dev/sdX和update-grub。这套流程如果你没练过第一次做会有点慌但其实就这么三步先找到原系统的根分区并挂载必要时挂载 /boot 和 EFI 分区再 chroot 到原系统最后重建 GRUB。现在很多发行版的安装 U 盘本身就自带“修复系统”入口Ubuntu 安装器里就有“Try Ubuntu”模式进去就是标准的 live 环境。另外DiskGenius 这类分区工具里的“修复引导记录”功能也能处理一部分启动分区异常对应到“启动分区不存在使用分区工具修正”这类问题可以被当作快速修复的手段但原理上它还是重写了引导扇区如果分区表本身已经错乱还是要先修分区表再谈引导。3. 内核初始化从实模式到用户态的全过程拆解GRUB 把内核加载进内存之后真正的操作系统代码才算开始执行。但这一步不是直接跳到漂亮的登录界面而是内核自己要先“活过来”。这一节我们拆解从引导器交棒到 1 号进程产生的整个过程。3.1 initramfs 的必要性与内核的早期启动说到内核启动很多人第一个问题就是vmlinuz 和 initramfs 到底是什么为什么要有两个文件vmlinuz 是压缩过的内核镜像bootloader 负责把它和 initramfs 一起加载到内存。initramfs 是一个临时根文件系统本质是一个 cpio 归档里面装着启动早期阶段需要的驱动、工具和脚本。为什么要这个临时根文件系统这是因为内核启动时必须挂载真正的根文件系统然后才能继续加载用户态程序。可是访问根文件系统需要存储设备的驱动而绝大多数 Linux 发行版把驱动编译成了内核模块这些模块恰好存放在根文件系统上。这就成了一个典型的鸡生蛋问题没有驱动就挂不了盘挂不了盘就读不到驱动。initramfs 就是用来打破这个循环的先用一个内存里的小文件系统加载必要的存储驱动等真正挂载根文件系统成功后再把 initramfs 扔掉切换到真正的 rootfs。如果你在启动日志里看到过Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block八成就是根文件系统挂载失败要么 initramfs 不对要么root参数指向了错误的设备。虚拟机和物理机上都容易遇到尤其是你在 fstab 里写了一个 UUID实际磁盘的 UUID 又对不上时。3.2 内核入场的三个关键阶段从 bootloader 交出控制权到内核正常运行大致可以分三个阶段。第一阶段是早期汇编代码。内核镜像文件的开头有一段解压代码负责把自己从压缩状态释放到内存里然后建立最基本的页表、段描述符CPU 从实模式切到保护模式再到 64 位长模式。这一阶段的代码量很小但在没有中断、没有内存管理器的情况下运行每一行都至关重要。第二阶段是 C 代码入口也就是start_kernel()。这一步开始出现我们熟悉的操作系统概念初始化进程表、内存管理、调度器、中断子系统、时钟、块设备、文件系统等等。这个阶段的输出会一条条打到控制台和 dmesg 里你可以用dmesg -k去查看。第三阶段是执行/sbin/init。initramfs 方案启动时内核先执行 initramfs 里的 init 脚本或者叫 early userspace它会探测硬件、加载驱动、创建 /dev 节点、挂载 rootfs然后切换到真正的根目录执行真正的 init 程序。在这个切换成功的瞬间系统就从内核态滑入用户态内核初始化宣告完成接下来轮到所有用户态服务出场。3.3 1 号进程的诞生init 与 systemd 的交接PID 为 1 的进程是整个用户态进程树的根。内核做完初始化之后会查找并执行 init 程序。传统上是/sbin/init它由 SysVinit 提供串行地跑一堆/etc/rc*.d/下的启动脚本。后来出现了 Upstart再后来 systemd 出现并逐步成为所有主流 Linux 发行版的默认 init 系统。systemd 把自己伪装成了 /sbin/init所以内核依然执行 /sbin/init实际进入的是 systemd 的世界。systemd 的核心思路是把启动任务拆成一个个 unit然后按依赖关系并行执行。启动目标从sysinit.target开始经历基本系统的初始化然后到multi-user.target如果存在图形界面则到graphical.target。你在开机时看到的桌面登录界面就是这个 target 下图形登录管理器如 GDM、SDDM的产物。理解了这条链你排查启动问题的时候就有了坐标固件阶段看 BIOS 提示引导阶段看 GRUB内核阶段看 dmesg服务阶段看 systemd 的状态和日志。大多数“卡在开机画面”的问题都能通过看日志定位到具体阶段。4. 开机自启服务的编排从 SysVinit 到 systemd系统能进桌面只是启动的第一步真正影响用户体验的是随后一大批服务的启动。Docker、Elasticsearch、Nacos、RabbitMQ、Tomcat哪个服务在开机时失败都会在日志里留下一串报错。这一节讲清楚 systemd 是怎么编排这些服务的以及为什么很多第三方服务在“装的时候没问题一开机就起不来”。4.1 服务启动的依赖管理与并行加速传统 SysVinit 的做法是按顺序执行启动脚本一个脚本跑完再跑下一个简单但慢。systemd 则不同它把每个服务定义成一个 unit 文件通过After、Requires、Wants这些字段声明依赖关系。比如 mysql.service 里有Afternetwork.target就表示网络准备好了才能启动 MySQL而不是整个系统所有服务都排队。systemd 的并行加速体现在没有依赖关系的服务可以同时启动启动过程中服务之间的先后顺序完全由依赖关系决定。它还支持 socket activation就是服务本身可以不用常驻由 systemd 先监听端口等第一个连接到来时才把真正的服务拉起来。这个机制让一些服务在开机时“看起来没启动”却能正常响应。那怎么查看系统开机启动的服务都有哪些呢systemctl list-units --typeservice --staterunning可以看到所有运行中的服务systemctl status某个服务能看到它的加载状态、主进程 PID 和最近日志。systemctl enable和disable用于管理开机自启enable 只是创建了服务单元的符号链接本身不会立即启动服务。服务启动失败时真正要看的是 status 和 journalctl。4.2 第三方服务启动失败的高频原因每天在社区里看到最多的求助都是“docker 启动失败”“elasticsearch 启动失败”“nacos 启动失败”这类问题。这些服务虽然各自不同但失败原因高度集中。服务常见启动失败原因处理思路Docker网络控制器初始化失败、iptables 规则冲突清理 iptables 规则重启 docker 服务必要时切换网络后端Elasticsearchvm.max_map_count过小、不允许用 root 直接启动调高内核参数改用非 root 用户运行RabbitMQErlang 版本不匹配、hostname 变化导致 cookie 不一致对齐 Erlang 与 RabbitMQ 版本检查.erlang.cookieNacos单机模式未关闭集群配置、JDK 版本不符改启动模式安装对应 JDK 版本Tomcat8080 端口被占用、JAVA_HOME 未设置查端口占用配置环境变量PostgreSQLWindows服务账户权限不足、依赖组件被安全软件隔离用默认服务账户检查事件查看器Docker 启动失败最常见的是网络相关报错比如 dockerd 报Error starting daemon: Error initializing network controller或者 iptables 规则冲突。这种情况多半是 Docker 和系统里的防火墙/nftables 抢规则导致的可以尝试清掉 iptables 规则、重启 docker 服务如果长期共存冲突就要考虑配置 Docker 直接用 iptables 还是切换 nftables 后端。Elasticsearch 启动失败十有八九是内存映射区域不足报错是max virtual memory areas vm.max_map_count [65530] is too low。解决方式是一行命令sysctl -w vm.max_map_count262144再写进/etc/sysctl.conf。另外 ES 不允许用 root 用户直接启动这会劝退很多第一次接触 ES 的人。RabbitMQ 启动失败最常见的是 Erlang 版本和 RabbitMQ 版本不匹配或者主机名变化导致 Erlang cookie 不一致。Nacos 启动失败则多半是单机模式没关闭集群配置或者 JDK 版本不对。Tomcat 启动失败十有八九是 8080 端口被占用或者 JAVA_HOME 没有配置。Windows 环境下服务启动失败的原因往往在事件查看器里。PostgreSQL 的 Windows 服务启动失败经常是服务账户的登录权限问题或者 Windows Defender 把共享库隔离了。选服务账户时用默认的 NetworkService比自定义账户少很多坑。4.3 快速定位启动失败服务的排查链路面对任意一个开机启动失败的服务我推荐用同一条链路排查百试不爽。第一步systemctl --failed看系统里哪些服务失败这一步能在桌面系统上一眼看全。第二步systemctl status 服务名看服务的状态描述、主进程是否退出它会直接给出Active: failed (Result: exit-code)这类结论。第三步journalctl -u 服务名 -b看本次启动以来这个服务的完整日志。日志才是各种报错真正藏身的地方比如 Elasticsearch 那个 mmap 错误就是在启动日志末尾。第四步systemctl cat 服务名查看 ExecStart 命令确认启动参数和路径是否正确。很多时候启动失败不是服务本身坏了而是日志目录、配置文件路径、环境变量没配合好。最后如果你改了配置文件想重新加载记得daemon-reload。这个操作经常被忘记导致你改了半天配置服务用的还是旧参数。5. 启动变慢与启动崩溃实际排障的几个典型场景有读者可能觉得操作系统启动讲到这里差不多够概念了但真正动手的时候你面对的往往是“开机动不动两分钟”“开机直接 panic”这种具体问题。这一节把我自己踩过的坑拿出来分成三个典型场景变慢、panic、进不了系统。5.1 用 systemd-analyze 定位“到底谁拖慢了开机”如果你的 Linux 启动明显偏慢先执行systemd-analyze它会告诉你启动总时间、固件时间、内核时间和用户态时间一眼看出去哪了。再执行systemd-analyze blame按耗时排序列出所有服务罪魁祸首直接浮出水面。我在多台机器上发现最常见的滞后服务是networkd-wait-online.service和NetworkManager-wait-online.service它们会等待网络完全就绪才返回在有 DHCP 延迟或者拔了网线的环境下能拖几十秒。这个服务的本意是保证系统启动后网络一定可用但对一般桌面用户来说开机到桌面比网络早几秒完全可以接受所以很多人选择禁用该服务。不过要注意systemd-analyze blame 看到的时间是服务占用的“墙上时间”并不完全等于它拖慢了多少总时间因为依赖关系决定了并行窗口。更准确的做法是用systemd-analyze critical-chain来看关键启动链路系统启动快不快不取决于最慢的服务而取决于关键链条上最慢的那个结点。盲目禁用服务可能导致依赖它的服务启动失败动手前先看清楚依赖。5.2 内核 panic 和 initramfs 缺失的应急处理开机直接卡死、满屏堆栈最后一行写着Kernel panic - not syncing这是最吓人的状态之一。但 panic 信息里往往藏着真正的病因读的时候找 VFS 那一段比如Unable to mount root fs on unknown-block(0,0)说明内核找不到根文件系统。这个原因排序大概是initramfs 损坏或缺失、root参数错误、fstab 里写错 UUID、加密磁盘的密钥没有正确装载。处理思路也很固定如果还能进 GRUB 菜单按e临时编辑内核启动参数检查 root 后面跟的是 UUID 还是设备名实在不行把ro改成rw debug再加systemd.log_leveldebug看更详细的内核日志。如果进不了 GRUB就用 live USB 启动chroot 进原系统重新生成 initramfs。Debian 系用update-initramfs -c -k allRHEL 系用dracut --regenerate-all生成完记得顺便重装一遍 GRUB。我见过太多人重装了系统其实一个 live USB 花十分钟就能救回来。5.3 进不去系统时的最后手段单用户与紧急模式假设你的系统能启动到 initramfs 阶段但随后因为某个服务的 bug 或者错误的 fstab 项导致永远进不了正常模式这时候单用户模式就是保命符。GRUB 菜单里选 recovery mode或者在内核参数后面加single系统会跳过大量服务直接落到 root shell。这个模式下网络和图形桌面都没有但它能让你挂载分区、修改配置。更极端的是 emergency 模式用systemd.unitemergency.target除了 rootfs 只读挂载之外几乎什么都不做。这种模式适合修复那些普通单用户模式下仍然会触发的坏配置——比如你 fstab 里挂了一个不存在的设备导致开机挂载失败系统反复重启。在 emergency 模式里把那一行注释掉就能恢复正常。我的建议是平时在虚拟机上刻意练习一遍这套流程故意改坏 fstab、故意删除 initramfs、故意覆盖 MBR再亲手救回来。这个过程练熟了真遇到磁盘损坏或者系统崩溃的时候你会有底气得多而不是慌慌张张去找维修店。6. 虚拟机、双系统与国产操作系统启动过程中的特殊问题最后聊聊几个特殊场景。很多人学操作系统启动知识是在虚拟机上做实验工作或学习时会碰到国产操作系统还有一批人喜欢装双系统。这三个场景都有自己的坑。6.1 VMware 里启动异常与 VMware Tools 脚本失败虚拟机的启动流程和物理机几乎一样VMware 虚拟出主板、BIOS/UEFI、磁盘控制器虚拟机固件按照同样的步骤寻找引导设备。不同点在于虚拟机里的硬件是虚拟的很多设备驱动来自虚拟化厂商。常见问题之一是“vmware tools 启动脚本未能在虚拟机中成功运行”。这个报错大多数发生在内核升级之后虚拟机的内核模块和 VMware Tools 版本不匹配导致 Tools 的服务脚本执行失败。现在的发行版更推荐安装 open-vm-tools而不是从 VMware 官网下载的闭源 Tools 包。open-vm-tools 在发行版的软件源里就有装上后由 DKMS 机制自动适配新内核省去每次内核升级后的手动重装。虚拟机启动时如果直接报“客户机操作系统已禁用 CPU”通常是 CPU 虚拟化特性没开成嵌套。VMware 的处理器设置里需要勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”而且宿主机的 BIOS 里得先把 VT-x 打开。这个报错还会出现在部分国产操作系统的虚拟机安装中表现很类似先查虚拟化开关基本能解决。6.2 双系统共存时的引导顺序与时间冲突双系统用户除了前面 GRUB 的问题之外还有两个高频坑。第一个是装完 Windows 后 Linux 引导没了第二个是 Windows 和 Linux 时间差了 8 小时。时间冲突的原理很简单Windows 把主板 RTC 当成本地时间Linux 默认把 RTC 当 UTC再按系统设置的时区换算。于是你在 Linux 里看到的是正确的北京时间切到 Windows 里就差了 8 小时。解决办法通常是在 Windows 注册表里添加RealTimeIsUniversal1让 Windows 也用 UTC或者在 Linux 里执行timedatectl set-local-rtc 1让 Linux 直接读本地时间。我习惯改 Windows 注册表因为 Linux 服务器默认都是 UTC保持一致更省心。引导顺序的坑更隐蔽。新装完 Windows 后Windows Boot Manager 会直接把 GRUB 从启动顺序里挤掉看起来像 Linux 整个“消失”了其实系统就是还在只是 GRUB 没被选中。在 BIOS 里把 GRUB 设为第一启动项或者进临时启动菜单选 Linux 那条路径就能救回来。反过来如果装完 Linux 引导后 Windows 不见了多半是 GRUB 没扫描到 Windows Boot Manager用 os-prober 重新探测一次并 update-grub 即可。6.3 麒麟等国产操作系统的启动链路最后说说国产操作系统。麒麟、统信 UOS、openEuler 这类系统本质上都是 Linux 内核的发行版所以启动链路和 Ubuntu、CentOS 高度相似UEFI 固件 - GRUB - 内核 - systemd - 桌面环境。我在虚拟机里装过银河麒麟和统信 UOS它们默认用的就是 GRUB2 和 systemd启动过程的各种调试手段也通用。差异主要集中在两点。一是硬件适配的定制麒麟和 UOS 会在内核里预置特定芯片组、特定显卡和特定国产网卡的驱动所以启动时内核模块的加载顺序和日志与标准发行版不太一样。二是系统里预装的服务不同比如 UOS 的桌面环境、应用商店和若干安全组件会作为系统服务随开机启动这些服务在 systemd 里都有独立的 unit被拖慢时也能用 systemd-analyze blame 定位。如果你在普通 Linux 机器上养成了读 systemd 日志的习惯切到麒麟或 UOS 排障并不需要重新学习。我自己在帮朋友处理麒麟系统的启动慢问题时用的依然是 journalctl 和 systemd-analyze 这套工具只是多了一个注意点这些系统的软件源更新节奏不固定内核升级后尽量重新生成 initramfs避免升级后个别机器起不来。把整个启动链路拆开之后回头看我发现最值得练的不是背命令而是建立“分阶段排查”的直觉。开机起不来的时候先站远一点判断这是固件问题、引导问题、内核问题还是服务问题判断清楚了再拿对应的工具和日志去定位往往十几分钟就能解决。我个人的一个小建议是找一台不怎么重要的旧机器或者开几个虚拟机故意把每个阶段都弄坏一次再亲手修回来。GRUB 被覆盖、initramfs 被删、fstab 写错、Secure Boot 关错这些坑我都踩过但每踩一次就学一批东西。操作系统启动这节课书上读十遍不如在真实环境里救一次。
