当前位置：首页 > news >正文

60 对UEFI引导的深入探究:efi引导程序的位置一定是死的吗?

news 2026/6/12 0:18:04

对UEFI引导的深入探究:efi引导程序的位置一定是死的吗?

对于Windows系统,bootx64.efi和bootmgfw.efi是同一个文件,只是名字不同.他们本质都是bootmgfw.efi,用于引导Windows系统,无法引导其他系统.

所以,即便是Windows系统安装后在EFI分区里产生了bootx64.efi,由于它和bootmgfw.efi相同,所以它也不能引导其他系统(如Linux)启动.

引导Linux系统启动还需要Linux专用的bootx64.efi.虽然名字一致,但其文件本身已经发生了变化.

由于Linux系统是使用grub引导器引导启动,所以在Linux下,计算机的一种可行的启动流程是UEFI->bootx64.efi->grub.相当于bootx64.efi启动了grub(grub也是efi程序),grub引导Linux.

此外,由于grub的强大引导能力,他可以同时引导Windows,Linux,苹果系统等等系统类型.所以,使用Linux和Windows双系统的计算机一般可以使用grub作为引导器,而不是用Windows boot manager.

UEFI启动菜单里的启动项目是存储在主板上的NVRAM(非易失性随机存储介质)里面的,并不存储在硬盘中,所以不能通过操作硬盘处理编辑,但可以通过在UEFI固件里面的设置来更改.

在UEFI启动菜单中,每一个启动项都指向一个efi程序.

Windows boot manager指向bootmgfw.efi
硬盘启动项指向bootx64.efi
如果安装了Linux,UEFI启动菜单里面可能会有一个Linux启动项,笔者没用过,不知道

由此可见,Windows计算机有两种可行的启动过程:

bootx64.efi一定要放在EFI\boot文件夹里面吗?bootmgfw.efi一定要放在EFI\Microsoft\boot文件夹里面吗?如果移动了他们,会发生什么?

为了弄清楚efi引导程序的基本工作原理,笔者进行了控制变量实验.

首先,笔者删除了bootmgfw.efi,留下了bootx64.efi.然后,笔者把bootx64.efi复制到了EFI分区里的各个位置.包括:

EFI分区根目录(\)
*\EFI*
*\EFI\Microsoft*
*\EFI\Microsoft\Recovery*
*\EFI\Microsoft\Boot*

笔者删除了bootx64.efi本来存在的地方,防止干扰.

使用VMWare,笔者测试了在UEFI固件中使用每一份bootx64.efi的启动情况.结果如下:

笔者把\EFI\Microsoft\boot\文件夹里面的所有名字里面含有"BCD"的文件移动到EFI分区里面的其他位置,发现任何bootx64.efi都无法启动.

那么,为什么\EFI\Microsoft\Recovery\里面的bootx64.efi无法引导启动?

为探究其原因,笔者将\EFI\Microsoft\Recovery\里面的BCD文件全部删除,使得该文件夹里面只剩bootx64.efi这一个文件.然后从这个文件成功启动了Windows.

bootx64.efi引导Windows启动的过程主要总结如下:

bootx64.efi首先检测他所在的文件夹里是否有BCD文件,若有,则直接读取它,然后根据这个BCD引导启动.
若它所在的目录里没有BCD文件,则他开始在EFI分区中按照\EFI\Microsoft\boot\BCD这个固定的顺序寻找BCD文件.然后从这个文件引导启动.
如果\EFI\Microsoft\boot\里面没有有效的BCD文件,那么无法引导启动系统.

所以,刚刚的问题就可以解释了.Recovery文件夹里面本来是有BCD文件的,bootx64.efi优先读取这个BCD.

但是这个BCD文件并不是Windows系统的BCD,而是WindowsRE恢复环境的BCD文件.笔者做测试的虚拟机没有WindowsRE,所以无法启动.