1. 为什么会这样？先搞清楚Windows和Linux的引导关系
1.1 一个真实的重装现场
先说说我自己遭遇过的情况。有一台实验室的备用电脑，我用U盘装好了Ubuntu和Windows双系统，平时默认进Ubuntu写代码，Windows偶尔用来跑一些Windows-only的工业软件。本来用得挺顺，直到有一天Windows系统出了点问题，我想都没想就用系统U盘重装了一遍Windows。重装过程一切正常，结果装完重启，屏幕上直接弹出一行字，大意是找不到操作系统，连Windows也进不去。折腾了半天才发现，问题根本不是Windows装坏了，而是Ubuntu的引导程序GRUB被Windows重装过程覆盖掉了。
后来跟几个同事聊，发现这个坑几乎每个人在玩双系统时都踩过一遍。只要你先装了Linux，后装或重装Windows，大概率会让Linux从启动菜单里消失。这跟Windows好不好用、Ubuntu版本新不新都没关系，是两者引导机制的设计差异导致的。
所以这篇文章就是把我当时完整的排查过程和几种修复方案整理出来。不光是告诉你"照着敲几条命令就行"，还会把每个步骤背后的原理讲清楚——知道为什么这么做，遇到Boot-Repair失效、盘符错乱这些特殊情况你才有办法自己判断。
1.2 Legacy BIOS模式下：Windows如何"吃掉"MBR
要理解引导丢失，得先知道电脑开机时发生了什么。传统的Legacy BIOS引导模式（也就是很多人说的BIOS启动、MBR启动），主板会去读硬盘第一扇区——也就是主引导记录MBR。MBR一共512字节，前446字节是引导代码，后面是分区表。引导代码做什么呢？它负责把操作系统的引导程序找出来，然后把控制权交给它。
Linux用的GRUB引导程序，在Legacy模式下就是把自己的引导代码写进MBR这446字节里。GRUB可以认识ext4文件系统，所以它能够直接读取/boot目录下的配置文件，弹出你熟悉的那紫底白字的启动菜单。
问题就出在Windows身上。Windows重装时，会把MBR整个抹掉重写，完全用自己的引导代码替换掉GRUB的引导代码。Windows的引导代码只有一个功能——寻找并启动Windows的bootmgr，也就是Windows Boot Manager。它压根不支持Linux的文件系统，也不会去辨认硬盘上哪个分区是Ubuntu。于是，MBR里GRUB的入口没了，自然开机就再也看不到那个双系统菜单。
这里有个关键细节：这个状态下，你的Ubuntu系统和所有数据其实都还在硬盘上，一个字节都没丢。丢的只是引导入口，就像一栋房子门牌被摘了，房子本身还好好的。
1.3 UEFI模式下：ESP分区里的启动项为何被删
现在新电脑大部分已经是UEFI引导了，情况稍有不同，但结果是一样的。
UEFI模式下，硬盘上会有一个专门的EFI系统分区（ESP分区），Fat32格式，小几百MB。主板固件开机时会去扫描这个分区里的EFI文件，然后把它们作为启动项列出来。Windows重装时会在ESP分区里建一个EFI/Microsoft/Boot/bootmgfw.efi文件，并把这个文件设为固件的第一启动项。
而Ubuntu安装时，会把GRUB的EFI程序写到ESP分区的EFI/ubuntu/目录下，文件名通常是shimx64.efi（因为Ubuntu启用安全启动）或grubx64.efi。正常情况下，UEFI固件里会有两个启动项，一个是"Ubuntu"，指向GRUB；一个是"Windows Boot Manager"，指向Windows的bootmgfw.efi。
关键问题来了：重装Windows的时候，安装程序可能做两件事。第一，它会清理EFI分区中其他系统的启动文件，尤其是当你选择了"删除所有分区再安装"这种干净安装方式时；第二，它会直接修改UEFI固件里的BootOrder变量，把自己设为第一位。如果固件里之前指向GRUB的启动项被删掉了，那开机就直接进Windows。更狠的情况是GRUB入口和Windows入口都在，但顺序变了，不仔细看BIOS菜单根本不知道Ubuntu还活着。
所以，不管你是老电脑还是新电脑，只要后装Windows，GRUB就面临着被覆盖或者被删除的命运。这就是文章标题里那个问题的根源。
2. 动手之前先诊断：你的电脑是哪种引导模式
2.1 在Windows里确认磁盘分区表类型
修复引导之前，必须搞清楚自己电脑到底是Legacy BIOS还是UEFI模式。同一个问题，两种模式下的修复方法完全不同。搞错方向可能折腾一晚上还是进不去系统。
如果你现在还能进Windows（引导没彻底丢，只是GRUB没了），最快的判断方式是在Windows里打开命令提示符（管理员权限），输入：
diskpart list disk看输出结果，磁盘那一行的"Gpt"列，如果带星号，说明磁盘是GPT分区表，使用的是UEFI引导；如果不带星号，说明是MBR分区表，对应Legacy BIOS引导。
另外一个更直观的方法：在Windows里打开"系统信息"，看"BIOS模式"这一项，如果显示"UEFI"，那就是UEFI模式；显示"传统"，那大概率是Legacy。
但如果你现在连Windows都进不去（引导全丢，开机黑屏），那就稍微麻烦点，得靠BIOS设置界面来判断。重启电脑，开机时按Del或F2进入固件设置，找"Boot Mode"或"Boot Option"这一类选项，看看是UEFI还是Legacy，一般是二选一的关系。有些电脑默认只支持UEFI，那就不用纠结了。
2.2 从Live USB查看分区结构，确认Ubuntu的系统分区
无论如何，修复引导都需要一个UbuntuLiveUSB。如果你手头没有，找一台正常的电脑，用Rufus或自带的“启动盘创建器”做一个Ubuntu安装U盘就行。制作过程不多说，只要是Ubuntu的ISO镜像，用UEFI方式写入U盘，基本都能在不同电脑上通用。
从U盘启动后，选择"试用Ubuntu"而不是"安装Ubuntu"，进入Live桌面环境。打开终端，运行下面的命令看磁盘结构：
sudo fdisk -l这个命令会列出所有磁盘和分区。你需要找两样东西：一个是Ubuntu的根分区（挂载点写着/、大小跟你安装Ubuntu时给的容量对得上），另一个是EFI系统分区（类型显示EFI System，大小100-500MB不等，在UEFI模式下才有）。如果当时安装Ubuntu时没有单独分/boot，那/boot就是根分区里的一个目录，不用额外处理。
再确认一下分区里的数据还在不在，防止重装Windows时误删了Linux分区。挂载根分区，比如：
sudo mount /dev/nvme0n1p6 /mnt ls /mnt可以看到bin、etc、home、usr这些熟悉的Linux目录，说明Ubuntu安然无恙。看到这个，心里就踏实了，接下来不管怎么折腾都不会丢数据。
2.3 快速判断：到底该走哪条修复路线
经过上面的诊断，你现在应该能回答这几个问题：
| 问题 | 判断依据 | 对应修复方案 |
|---|---|---|
| 分区表是GPT还是MBR？ | fdisk -l 输出里的Disklabel type | GPT走UEFI路线，MBR走Legacy路线 |
| 有没有ESP分区？ | fdisk -l输出里有没有EFI System | 有就挂载它，没有就说明是Legacy |
| Ubunut根分区数据还在吗？ | mount之后有没有bin、etc等目录 | 在，就放心修；不在，先找分区恢复 |
| /boot是独立分区吗？ | 有没有大小几百MB的Linux分区 | 独立的话修复时要单独挂载它 |
这样一个表列下来，方向就清晰了。接下来分别说两种模式的修复动作，你可以直接跳到符合自己情况的那一节。
3. 最快的修复路线：用Boot-Repair一键恢复引导
3.1 准备Boot-Repair的环境
如果你不想跟命令行较劲，那我强烈建议先试Boot-Repair这个工具。它的原理很简单：扫描整个磁盘，找出所有操作系统的安装位置，然后帮你重新安装GRUB，并让GRUB接管启动。整个过程基本是图形化点按钮，非常省事。
在Live Ubuntu桌面里，打开终端，输入以下命令安装：
sudo apt update sudo add-apt-repository ppa:yannubuntu/boot-repair sudo apt install boot-repair -y安装好之后运行：
boot-repair它会自动检测你的磁盘信息，然后给你两个大按钮——"推荐修复"和"高级选项"。
3.2 执行修复并处理可靠性问题
先点"推荐修复"。Boot-Repair会做一堆事情：挂载你的Ubuntu根分区、重新安装GRUB、更新grub.cfg配置文件、如果检测到Windows也会把它加进启动菜单。过程大概几分钟，输出一堆日志，最后它会弹出一个URL，类似paste.ubuntu.com/xxxx，这个是修复日志的链接。
这里有个坑我必须提醒一下：Boot-Repair修复过程中需要联网。它的某些步骤会重新下载grub相关软件包，断网的情况下很可能报错，比如grub-install失败，或者update-grub的os-prober找不到Windows。所以请确认你的Live系统已经连上网络再执行修复。
修复完成之后，提示信息一般会说"请重启试试"。这时候把U盘拔掉，正常重启，如果看到GRUB菜单蹦出来，里面同时有Ubuntu和Windows两个选项，那恭喜你，问题解决了。
3.3 Boot-Repair修不好时说明什么
然而事情往往没那么顺利。我遇到过几次Boot-Repair明明提示成功，重启后却依然直接进Windows，或者干脆黑屏。这种情况并不代表工具没用，而是说明系统里有它搞不定的因素。
最常见的两种情况：
- 如果是UEFI模式，Boot-Repair可能识别不到ESP分区或者挂载出错，导致GRUB写入了错误的EFI路径，固件压根找不到它。
- 如果Linux是逻辑卷（LVM）或者整个盘做了加密，Boot-Repair默认方案可能没能力正确处理，GRUB装不上。
对于第一种情况，解决办法是改用高级选项并手动指定ESP挂载点。在高级选项里找到"GRUB location"那一栏，选择你的ESP分区并设置挂载点，一般写/boot/efi。对于第二种情况，就得老老实实走手动chroot修复路线，这也是下文的重头戏。
老话说得好，工具解决不了的事情，动手敲命令一定能解决。接下来就是我认为最有价值的一部分——手动修复的完整过程。
4. 手工修复GRUB：chroot方案的完整步骤
4.1 chroot的原理：把系统"借壳还魂"
手动修复GRUB的核心是chroot。打个比方，你现在用Live USB启动，这个系统是"临时借来"的；而硬盘上的Ubuntu是个完整的操作系统，但无法自己启动。chroot命令可以让你临时把这个Live系统的根目录切换到你硬盘上那个Ubuntu的根目录里，就好像"借壳还魂"——用Live USB的内核，去操作硬盘上那个真实的Ubuntu环境。
一旦chroot进去，你运行的命令（比如grub-install、update-grub）就都以为自己在硬盘上那个Ubuntu系统里运行，这样生成的配置文件、安装的引导代码就会写到正确的位置。
整个过程比较长，分成六个环节来讲，每一步的命令我都会给出，并标注每条命令的作用。
4.2 挂载根分区和系统目录
进入Live桌面，打开终端。先用fdisk -l确认分区情况，我以我的实际环境举例，假设Ubuntu根分区是/dev/nvme0n1p6，ESP分区是/dev/nvme0n1p1。如果你用的是SATA硬盘，盘符会变成/dev/sda类似的形式。
第一步，把根分区挂载到/mnt：
sudo mount /dev/nvme0n1p6 /mnt这一步如果你是UEFI模式并且有独立的ESP分区，还需要把它挂载到/mnt/boot/efi：
sudo mkdir -p /mnt/boot/efi sudo mount /dev/nvme0n1p1 /mnt/boot/efi如果你的Ubuntu当时把/boot单独分出来，那还要先挂载/boot分区，再挂ESP。顺序不能乱，先挂根，再挂/boot，最后挂/boot/efi：
sudo mount /dev/nvme0n1p5 /mnt/boot sudo mount /dev/nvme0n1p1 /mnt/boot/efi接下来挂载虚拟文件系统。chroot进去之后，Live系统的内核需要看到这些动态的目录才能真正干活：
sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run这里特别说一下/run，有些人只挂载前三个，结果chroot之后update-grub偶尔会出现奇怪的警告。把/run也绑上去，很多莫名问题都能避免。
4.3 复制DNS配置并chroot
进入chroot环境之前，还有一个小动作推荐做一下：拷贝Live系统的DNS配置到/mnt/etc/resolv.conf。为什么会用到它呢，因为后面执行update-grub时，如果检测到os-prober相关的包缺失，可能会尝试联网更新元数据，没有DNS就会失败。
sudo cp -a /etc/resolv.conf /mnt/etc/resolv.conf然后进入chroot环境：
sudo chroot /mnt敲完之后你会发现命令行提示符变了，比如变成root@ubuntu:/#，这说明你已经在硬盘上那个Ubuntu系统内部了，后面所有命令都会作用在那个系统上。
4.4 安装GRUB：UEFI和Legacy两条路线
现在进入关键环节。根据你之前的诊断结果，选其中一种执行。
Legacy BIOS模式下，把GRUB安装到硬盘的MBR位置。注意目标不是某个分区，而是整块磁盘，比如/dev/sda：
grub-install /dev/sda执行成功后，会输出Installation finished. No error reported。这代表GRUB引导代码已经成功写进MBR。
UEFI模式下，安装GRUB到ESP分区。在chroot环境里，ESP分区已经挂载在/boot/efi，所以命令是：
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu关于--bootloader-id，它决定EFI启动菜单里显示的名称。用ubuntu也可以，用grub或者你想起的任何名字都行，关键是后面重启的时候你要能找到这个条目。
装完GRUB本体之后，生成启动菜单配置文件：
update-grub这个命令会扫描系统的所有分区，查找已安装的操作系统，并写入/boot/grub/grub.cfg。输出里如果能找到类似"Found Windows Boot Manager on /dev/nvme0n1p1"这样的信息，说明Windows也成功加入了GRUB菜单。
这里有个常见问题：update-grub提示没找到Windows。原因是新版Ubuntu默认禁用了os-prober（Windows的探测脚本）。处理方式很简单：
echo "GRUB_DISABLE_OS_PROBER=false" >> /etc/default/grub update-grub重新跑一遍，Windows就出现了。
4.5 修复UEFI启动项并调整顺序
Legacy模式下，grub-install和update-grub做完就能重启。但UEFI模式还有最后一步，确认UEFI固件里有没有生成对应的启动项。如果不进BIOS设置，你可以在chroot里用efibootmgr直接查看和添加。
先查看当前启动项：
efibootmgr输出里会看到BootOrder、Boot0000、Boot0001这些条目。如果里面没有Ubuntu相关的条目，手动添加一条：
efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Ubuntu" --loader '\EFI\ubuntu\shimx64.efi'注意--part后面的数字对应ESP分区号（我这里是1），--loader是ESP分区内的EFI文件路径，反斜杠的路径格式不能写错。
如果Ubuntu条目已经有了但排在Windows后面，用-o参数调整顺序：
efibootmgr -o 0000,0001把代表Ubuntu的编号放在最前面，Windows编号放后面。重启后就能看到GRUB菜单了。
做完这些，退出chroot环境（输入exit），然后重启：
exit sudo umount -R /mnt sudo reboot如果一切顺利，熟悉的GRUB菜单应该回来了。
5. 修复之后的新麻烦：Windows时间不对、默认启动项不对
5.1 UTC时钟引发的Windows时间错乱
很多人在修复完引导、能正常进入双系统之后，又冒出另一个经典问题：Windows里面显示的时间和Ubuntu里面相差8小时。这不是什么随机故障，背后是两套系统对硬件时钟（RTC）的认知不同。
Linux默认把硬件时间当作UTC（协调世界时）来理解，然后根据时区设置换算成本地时间显示。Windows则默认把硬件时间直接当作本地时间。如果北京时间是早上8点，Windows认为硬件时间也是8点，而Ubuntu认为硬件时间是UTC的8点，换算成北京时间就是16点。两个系统交替使用同一块硬件时钟，就差了8小时。
如果你觉得改Linux这边更顺手，可以在Ubuntu终端里执行：
timedatectl set-local-rtc 1这会让Linux也把硬件时间当成本地时间，跟Windows保持一致。执行完可以再执行timedatectl确认输出里没有提示RTC in local TZ的问题。改完以后重启一次Windows，时间显示就正常了。我个人比较推荐这个方案，因为Windows对时间同步的依赖更强，改Linux一处就能同时兼顾。
5.2 GRUB默认启动项指向了Windows
另一个小问题是，GRUB菜单虽然回来了，但每次开机默认进入Windows，倒计时结束自动选择Windows。这是因为GRUB的default配置默认是0，而菜单里第一项可能就是Windows项。特别是当os-prober把Windows放在Ubuntu之前时，就会这样。
想要默认进Ubuntu，编辑GRUB配置文件：
sudo nano /etc/default/grub看GRUB_DEFAULT这一行，默认是0，代表第一个菜单项。如果Ubuntu项是第N项（从0开始数），就把数字改成N。更新完配置后：
sudo update-grub这样重启后默认就回到Ubuntu。还有一种更直观的办法，在GRUB菜单界面按e临时编辑启动项，把quiet splash后面加上自己的参数，但那只对当前启动有效，配置持久化还是得改文件。
6. 吃一堑长一智：以后怎么规划双系统引导
6.1 把引导入口和系统盘分离
这次修好之后，我重新审视了自己的装机规划。当初图省事，把Ubuntu和Windows装在了一块硬盘的两个分区里，结果重装Windows时MRB被覆盖，连带两个系统的引导一起失效。后来我在另一台机器上尝试了一种更省心的方案——准备两块独立的硬盘，一块装Windows，另一块装Ubuntu。引导文件也在各自的硬盘上互不干扰，重装任何一个系统都不会影响另一个。
如果你只有一块硬盘，想尽量避免重装Windows导致的引导覆盖，可以试试把GRUB装到U盘或者独立的启动分区。做法是：安装Ubuntu时选择手动分区，让/boot挂载到单独的ext4分区（不用太大，1GB足够），然后grub-install时把引导代码指向这个分区所在的磁盘。这样Windows重装只会覆盖自己磁盘的MBR或ESP，GRUB保存在独立区域，仍然能启动。缺点是开机时需要手动选择从哪个设备启动，不过BIOS里设置一下启动顺序也就解决了。
6.2 平时备份EFI分区的关键目录
说到备份，很多人装了Linux好几年都没备份过EFI分区，直到出问题才后悔。EFI分区整个也就几百MB，备份非常快。在Ubuntu正常运行时，执行：
sudo cp -a /boot/efi/EFI /home/用户名/efi_backup_日期下次引导丢了，进Live USB，把备份拷回ESP分区的EFI目录，再配合grub-install的--efi-directory参数，十分钟就能恢复。这比在网上找各种教程从头排查要快太多。
6.3 重装Windows前留好后路
最后提醒一句，如果你确定了短期内还要重装Windows，请在重装之前手动把Ubuntu修复工具准备妥当。具体来说：把Ubuntu Live USB先做好；记下自己Ubuntu根分区在哪个磁盘哪个分区编号（比如/dev/nvme0n1p6）；有条件的把上面说的EFI目录备份一份存到U盘或移动硬盘。这三样东西都准备好了，重装Windows就是有惊无险的小事一桩。
重装Windows时也选择一下——如果不想让Windows覆盖整个磁盘的引导记录，可以在安装程序选择安装位置时，确保只选择你想要放Windows的那个分区，而不是直接选"删除全部现有分区"。Windows安装程序在写入引导时，有了现有引导文件会增加覆盖面积，其中也包括Linux的那部分入口。
我在后来的实践里养成了一个习惯：所有涉及系统安装的机器，都在手边备一个Live USB，上面同时放了Ubuntu镜像和Boot-Repair工具。双系统引导丢了这件事，听起来吓人，其实只要摸清了原理、知道数据还在，修复就是一条命令和几条命令的区别。希望这篇文章能把这条"一条命令"的路讲明白，让你下次遇上引导丢失的时候，心里有底，手上不慌。
