功能介绍
常见问题
- 小白一键重装win7旗舰版64位教程_重装教程
- 硬盘windows 7 系统安装图文教程_重装教程
- 如何将Win10系统切换输入法调成Win7模式?
- 深度技巧win8系统下载安装阐明_重装教程
- 最新联想笔记本一键重装教程_重装教程
- 如何应用U盘进行win10 安装系统_重装教程
- 更改Win7系统Temp文件夹存储地位教程(图
- Win10桌面QQ图标被暗藏的再现方法介绍_重
- 在线安装win7系统详细图文教程_重装教程
- 系统一键重装系统_重装教程
- win7升win10教程_重装教程
- 系统盘重装系统官网教程_重装教程
- 简略又实用的xp系统重装步骤_重装教程
- 最详细的n550重装系统图文教程_重装教程
- 最简略实用的winxp重装系统教程_重装教程
uefi原理与编程
核心提示:这种接口用于操作系统自动从预启动的操作环境,加载到一种操作系统上.最近有网友问小编关于uefi原理与编程的内容,下面就让小编给大家介绍uefi原理与编程的内容吧....
uefi全称“统一的可扩大固件接口”(Unified Extensible Firmware Interface), 是一种详细描写类型接口的标准。这种接口用于操作系统主动从预启动的操作环境,加载到一种操作系统上。最近有网友问小编关于uefi原理与编程的内容,下面就让小编给大家介绍uefi原理与编程的内容吧。
参考材料
如果想真正懂得 UEFI,浏览 UEFI 规范是个不错的方法。这件事并不难,也不需要什么代价。浏览 UEFI 规范相当枯燥乏味,但是会让你受益匪浅。你可以从 官方 UEFI 网站 下载 UEFI 规范。尽管下载 UEFI 规范需要先批准某些条款和条件,但是不会带来丧失。在我撰写本文时,UEFI 规范的最新版本是 2.4 Errata A (译者注:现在更新到了 2.4 Errata B ),本文所写内容也基于这一版本。
BIOS 没有制定相应规范。BIOS 本身就是一项事实标准,从 20 世纪 80 年代开端,BIOS 的工作方法就一成不变。这也是出身 UEFI 的原因之一。
简略起见,我们可以把 BIOS 和 UEFI 看成两种不同的组合。其中一种是 UEFI和 GPT (我们稍后会讨论 GPT)产生之前,IBM PC 兼容盘算机(以下称为 PC)所广泛采用的组合。大部分人可能对这种组合非常熟悉,对其中的细节了如指掌。那么我们就先来讨论在具有 BIOS 固件的 PC 上,启动是如何工作的。
BIOS 启动
事实上,BIOS 启动的工作原理非常非常简略。在老式 BIOS PC 上,装有一个或多个磁盘,每个磁盘中包含 MBR 。MBR 是另一套事实标准;大体而言,磁盘起始地位以特定格式描写磁盘上的分区,并包含“启动装载程序 (boot loader)”,BIOS 固件知道如何履行这一小段启动装载程序代码。启动装载程序的职责是启动操作系统(现代启动装载程序的大小通常超出了 MBR 空间所能容纳的领域,因此必须采用多阶段设计,其中 MBR 部分只知道如何从其他地位加载下一阶段,我们现在先不着重讨论这一过程)。
在启动系统的过程中,BIOS 固件只能辨认系统包含的磁盘。而作为 BIOS 盘算机的拥有者,你可以告诉 BIOS 固件你想从哪个磁盘启动系统。而固件本身并不知道其他细节,它只会履行在指定磁盘的 MBR 部分所创造的启动装载程序,就这么回事。在履行启动装载程序之后,固件本身就不再参与启动。
在 BIOS 组合中,所有的多重启动情势都确定是在固件层上进行处理的。固件层无法真正辨认启动装载程序或操作系统,甚至连分区都无法辨认。固件所能履行的操作只是从磁盘的 MBR 中运行启动装载程序。你无法从固件外部配置启动过程。
UEFI 启动:背景
好,BIOS 组合的背景知识已经明确了。我们现在来看看 UEFI 盘算机上的启动原理。即使未控制本文的细节,也请记住这一点:UEFI 与 BIOS 完整不同。UEFI 启动原理与 BIOS 绝对不同。你不能把 BIOS 启动的原理直接套用到原生 UEFI 启动上。你不能把专为 BIOS 启动设计的工具利用到原生 UEFI 启动的系统上。记住,UEFI 组合完整不同。
还需要懂得一个重点:许多 UEFI 固件实现了某种 BIOS 兼容模式(有时候称为 CSM)。许多 UEFI 固件可以像 BIOS 固件一样启动系统,它们可以查找磁盘上的 MBR,然后从 MBR 中履行启动装载程序,接着将后续工作完整交给启动装载程序。有时候,其他人误将此功效称为“禁用 UEFI”,从语言学角度而言,这种说法是荒谬的。系统固件是无法“禁用”的。这种说法很笨拙,不要采用这种说法。但是在其他人这么说的时候,应当懂得他们真正想表达什么。他们讨论的是通过 UEFI 固件的一项功效,以“BIOS 作风”启动系统,而不是采用原生 UEFI 方法启动系统。
我想解释一下原生 UEFI 启动。如果你有一台基于 UEFI 的盘算机,其固件具有 BIOS 兼容功效,并且你打算一直应用这项兼容功效,在启动过程中,你的盘算机看起来就是基于 BIOS 的。你只需要像 BIOS 启动一样进行所需操作即可。如果你确实有此打算,那么就不要中途变卦。对于你日常应用的操作系统,强烈建议不要混杂应用原生 UEFI 启动和 BIOS 兼容启动,尤其不要在同一块磁盘上混用。这么做的话,你会痛不欲生。如果你决定混杂应用原生 UEFI 启动和 BIOS 兼容启动,到时候就别找我哭诉。
为了理清头绪,我将假设磁盘采用 GPT ,并且包含用于 EFI 的 FAT32 EFI 系统分区 (ESP)。根据你对这些知识的深入程度,你可能创造,在进行原生 UEFI 启动时,GPT 磁盘和 EFI FAT32 ESP 并不是必要条件。但是 UEFI 规范和 GPT 磁盘以及 EFI FAT32 ESP 的接洽程度相当密切。在99%的情况下,你要处理的也正是这样的组合。除非你在应用 Mac(诚实说,Mac 混乱不堪)。
编辑阐明:以下章节(到缺点为止)在 2014 年 1 月 26 日(本文发布的几小时后)根据 Peter Jones 的反馈进行了大批修订。本文可视为 v2.0 版本。早期版本的写作方法不够严谨,而且内容可能会产生曲解。
UEFI 原生启动:实际工作原理——背景
言归正传。本节将解释原生 UEFI 启动的实际工作原理。如果已控制必定程度的背景知识,可能更容易深入懂得本节内容。
在固件层,UEFI 的基础架构更丰富,可用于处理系统启动。UEFI 远不像BIOS 那么简略。与 BIOS 不同,UEFI 确实可以(不同程度上)懂得“磁盘分区”、“启动装载程序”以及“操作系统”的概念。
你可以稍微看看 BIOS 启动过程,然后再看看 UEFI 启动过程,懂得 UEFI 启动过程如何采用多种措施来解决特定问题。
在思考启动过程时,你会创造 BIOS/MBR 查找启动装载程序的方法实在不怎么样。BIOS/MBR 非常奇葩:位于磁盘起始地位的这一小段空间包含神奇代码 (magic code),而这段神奇代码只作用于系统固件和写入此神奇代码的工具。这种方法有许多问题。
处理不便——你需要特别工具来写入 MBR,如果要查看 MBR 中包含的内容,唯一的方法几乎就是把 MBR dd 出来,然落后行检查。
如上所述,MBR 本身不足以容纳许多现代启动装载程序。这些启动装载程序会将自身的一小部分安装在 MBR 中,而将其他部分安装到磁盘上的可用空间中。这段可用空间位于惯例 MBR 末尾和第一个分区的起始地位之间。这就会造成很大的问题(其实这全部设计就是个大问题,不过无所谓)。对于第一个分区的起始地位,并没有成文的可靠规定,因此难以确保空间足够。只有一件事情是确定的:这段空间不足以容纳某些启动装载程序的配置。
如果要选择其他启动目标(除磁盘以外),这种设计没有供给任何标准化层或标准化机制,但是用户盼望选择除磁盘以外的启动目标。也就是说,他们盼望实现多重可启动对象——通常是操作系统。在 BIOS/MBR 组合中,实现这种目标的唯一方法是由启动装载程序进行处理;至于如何实现,并没有进行获得广泛认可的规定。虽然实现的方法非常多,但是它们无法彼此协作,而且也都不是获得广泛认可的标准或规定。而在操作系统/操作系统安装层编写工具的难度很大,无法干净利落地处理多重启动。因此这种设计非常混乱。
这种设计没有供给标准方法,让用户可以从除磁盘以外的目标进行启动。本文不会就此问题进行详细讨论,但是请注意,UEFI 启动的另一优势为:它供给了进行启动(例如,从远程服务器进行启动)的标准方法。
固件层以上的其他层无法配置固件的启动行动,BIOS 没有供给相应机制。
可以想象,在 UEFI 设计之初,开发人员思考过这些问题,并最终提出解决方案。UEFI 固件并不仅仅可以辨认磁盘,它也知道启动装载程序代码在每个磁盘上所处的地位,而且在固件层,UEFI 的基础架构更丰富,可用于处理启动装载。接下来,我们讨论下 UEFI 规范中定义的相干内容。
EFI 可履行文件
UEFI 规范定义了一种可履行文件格式,并请求所有 UEFI 固件能够履行此格式的代码。当开发人员为原生 UEFI 编写启动装载程序时,就必须按照这种格式编写。这种设计非常简洁直观,也无需进一步解释:对于固件可以履行的代码,固件规范真正定义了其通用格式,这是件好事。
GPT(GUID 分区表)格式
GUID 分区表格式与 UEFI 规范具有密切接洽,而且,它并不特别复杂,无需多加解释。GPT 是 UEFI 规范供给的良好基础架构之一。GPT 仅仅是分区表的一种标准——磁盘起始地位的信息定义了磁盘所包含的分区。相比 MBR/MS-DOS 分区表,这种分区表对分区的定义要好得多,并且 UEFI 规范请求 UEFI 兼容固件必须能辨认 GPT(也请求固件能辨认 MBR,以保证向后兼容)。所有这些规范都是相当实用的基础架构: UEFI 规范正建立某些功效,固件层上的一切都可依附固件本身来实现这些功效。
EFI 系统分区
在修订本文时,我才真正思考 EFI 系统分区的概念,让我有如醍醐灌顶。实际上,“EFI 系统分区”的概念可以解决“奇葩”的 MBR 空间所产生的问题。在磁盘起始地位留出自由空间,用于存放启动装载程序代码,但又不定义其容量,种设计糟糕透顶。这一点在上文已经讨论过了。EFI 系统分区是 UEFI 用于解决这种问题的解决方案。1
具体的解决方案如下:我们请求固件层能够读取某些特定的文件系统类型。UEFI 规范请求兼容固件必须能读取 FAT 格式的变种(包含 FAT12、FAT16 和 FAT32)。UEFI 规范实际扮演的角色就是编辑收拾 FAT 文件系统格式的现有解释,确保在采用 UEFI 时可以应用那些格式,并规定 UEFI 兼容固件必须能够读取那些格式。UEFI 规范针对这方面的具体规定如下:
“可扩大固件接口 (EFI) 支撑的文件系统基于 FAT 文件系统。EFI 定义了可以明确记载和测试的具体 FAT 版本。FAT 的唯必定义必须符合 EFI 规范及关联参考文档,对 FAT 唯必定义的实现必须支撑 EFI。为区分 EFI 文件系统与纯 FAT,定义了新的分区文件系统类型。”
“EFI 系统分区”是采用 FAT 变种(UEFI 规范定义的变种之一)格式化的任意分区,该分区被赋予特定 GPT 分区类型,以赞助固件辨认该分区。此分区的目标如上所述:固件层确实可以读取“普通”磁盘分区中的数据。盼望我已明确解释为何这种设计更佳:操作系统可以创立、格式化和挂载分区(采用广泛懂得的格式),并将启动装载程序的代码和固件可能需要读取的所有其他内容放到这个分区中,而不用像 MBR 磁盘一样,将启动装载程序的代码写入磁盘的起始地位空间。
刚开端的时候,对我而言,全部 ESP 的设计看起来有点匪夷所思且令人困惑,因此我盼望本节可以解释为何 ESP 实际上是非常优良的设计——真正匪夷所思和令人困惑的设计是 BIOS/MBR。若要从操作系统层写入某些内容,唯一的方法是将这些内容写入磁盘起始地位的某部分(但不知道是多少)空间,而并没有具体规定其中的具体实现。如果回过火再看,这种设计并不明智,且难以懂得。
正如我们稍后会强调的那样,UEFI 规范试图采用更直观严格的方法——它很少禁止固件履行其他操作。UEFI 规范并不反对编写固件,用于履行以其他格式写成的代码、读取其他类型的分区表,以及读取用UEFI 变种文件系统(非 FAT)格式化的分区。但是 UEFI 兼容固件必须至少能够实现履行 EFI 可履行文件、读取 GPT 分区表、以及读取 ESP,因此如果你正编写操作系统或其他东西,并且想要在 UEFI 兼容固件上运行的话,你也得遵守 UEFI 规范,这就是 EFI 系统分区的概念非常重要的原因:它容许(至少理论上)将 EFI 可履行文件放在以 UEFI FAT 格式化且 GPT 分区类型正确无误的分区上,另外,系统固件要能够读取该分区。这种机制非常严谨,等价于 BIOS 中的“固件能够履行放置在 MBR 空间中的启动装载程序代码”。
UEFI 规范为我们供给了三大重要基础,这些重要基础是上层架构正常运行的立足之本:
读取分区表
访问某些特定文件系统中的文件
履行特定格式的代码
相比 BIOS 固件所供给的功效,UEFI 的功效要丰富得多。但是,为了完成固件层可以处理多重目标(而不仅仅是磁盘)启动的愿景,我们需要其他基础:需要建立一种机制,通过这种机制,固件可以查找各种可能的启动目标,并供给相应的配置方法。
UEFI 启动管理器
UEFI 规范定义了名为 UEFI 启动管理器的一项功效(Linux发行版包含名为efibootmgr 的工具,可用于更改 UEFI 启动管理器的配置)。如果你确实浏览过 UEFI 规范,那么就会创造,UEFI 规范对 UEFI 启动管理器作出了如下规定:
“UEFI 启动管理器是一种固件策略引擎,可通过修正固件架构中定义的全局NVRAM 变量来进行配置。启动管理器将尝试按全局 NVRAM 变量定义的次序依次加载 UEFI 驱动和 UEFI 利用程序(包含 UEFI 操作系统启动装载程序)。”
好,既然已经明确了这一概念,那我们就持续吧。不,先等等。我来先把那一项规定解释明确,便于懂得。简略来说,你可以把 UEFI 启动管理器视为启动菜单。在 BIOS 固件上,固件层的“启动菜单”(当然)是,启动时连接到盘算机的各个磁盘——不多不少。但是对于 UEFI 固件而言,情况有所不同。
UEFI 启动管理器可以进行配置——简言之,你可以向“启动菜单”添加项或者从中删除项。固件也可以(事实上, UEFI 规范也有此请求)根据连接到盘算机的磁盘或根据某些固件配置,在此启动菜单中“生成”有效项。你也可以检查启动菜单,确保正确无误。
UEFI 供给了一种非常优良的机制,可以从上层架构履行此操作:你可以从已启动的操作系统中配置系统启动行动。如果已通过 UEFI 启动 Linux,就可以应用 efibootmgr 工具来完成所有这些操作。Windows 也有相应的工具,但是我对 Windows 下的工具非常不熟悉。我们不妨看一些范例的 efibootmgr 输出,这些是我从 Fedora 论坛转过来的,稍微进行了调剂:
[[email protected] directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .
[[email protected] directory]#
这个示例非常清楚。我们可以从中视察细节。
第一行表现,目前你从“启动菜单”的哪个项进行了启动。第二行非常明显(如果固件的 UEFI 启动管理器显示了类似启动菜单的界面,那么这一行表现持续启动默认项之前的超时)。BootOrder 是列表中启动项的尝试次序。其余输出显示了实际的启动项。我们稍后会阐明每一个启动项具体作用。
如果完整正常启动 UEFI 固件,而不进行任何调剂(我们稍后会讨论),UEFI 固件将按照BootOrder 中列出的次序,尝试从“启动菜单”中的每个“项”进行启动。因此,在这台盘算机上,UEFI 固件将尝试启动名为“opensuse”的项,如果启动失败,然后再尝试启动名为“Fedora”的项,然后再是“CD/DVD Drive”,接着是第二项“Hard Drive”。
UEFI原生启动:实际工作原理——启动管理器项
那么,这些项的实际含义是什么?实际上,UEFI 规范之所以显得复杂,很大程度上是因为其中的不断定因素太多。如果你正在浏览 UEFI 规范,那么先做好心理筹备,然后前往 EFI_DEVICE_PATH_PROTOCOL 一节。但是请注意,这个协议是通用的,虽然这个协议不涉及启动过程,但是有其他作用——这实际上就是 UEFI 官方的设备标识方法,这种标识方法可用于启动管理器项以及各种其他用处。出于各种原因,并不是每一种潜在的 EFI 设备都像 UEFI 启动管理器项一样起作用(如果你想从视频适配器启动,很可能不会成功)。但是启动菜单中显然可以包含指向 PXE 服务器(而不是磁盘分区)的项。UEFI 规范进行了多项规定,可以向 UEFI 启动管理器配置中添加除磁盘以外的启动目标。
但是对我们而言,只需要考虑连接到盘算机的一般磁盘即可。既然这样,我们来讨论下可能遇到的三种启动项类型。
BIOS 兼容启动项
在本示例中,Boot0000 和 Boot0004 实际上是 BIOS 兼容模式启动项,而不是原生 UEFI 启动项。这些启动项不是通过外部工具添加到 UEFI 启动管理器配置中的,而是由固件本身生成的——这也是 UEFI 固件实现 BIOS 兼容启动的常见方法,通过生成 UEFI 启动管理器项,可触发指定设备的 BIOS 启动。至于 UEFI 启动管理器如何浮现给用户,这是另一个问题,我们稍后讨论。根据具体固件及其配置,其中有些项可能无法显示。每一项只会具有一个名称(“CD/DVD Drive”、“Hard Drive”),这表现“如果选中此项,那么就以 BIOS 兼容模式启动本磁盘”(其中,对于 Boot0000,“本磁盘”为 3,0,00,对于 Boot0004,“本磁盘”为 2,0,00)。
“回退路径 (Fallback path)”UEFI 原生启动项
Boot0001 项(我虚构的,实际操作中可能不存在,这里只是为了举例阐明)用于通知固件尝试从特定磁盘启动(以 UEFI 模式而不是 BIOS 兼容模式),但是并没有向固件供给其他信息。它没有指定磁盘上的具体启动目标,而只是让固件启动磁盘。
UEFI 规范定义了一种“回退”路径 (Fallback path),用于启动此类启动管理器项,其工作原理类似于 BIOS 驱动器启动:它会在标准地位查找某些启动装载程序代码。但是其中的细节和 BIOS 不同。
当尝试以这种方法启动时,固件真正履行的操作相当简略。固件会遍历磁盘上的每个 EFI 系统分区(按照磁盘上的分区次序)。在 ESP 内,固件将查找位于特定地位的具有特定名称的文件。在 x86-64 PC 上,固件会查找文件 \EFI\BOOT\BOOTx64.EFI。固件实际查找的是 \EFI\BOOT\BOOT{盘算机类型简称}.EFI,其中,“x64”是 x86-64 PC 的“盘算机类型简称”。文件名还有可能是 BOOTIA32.EFI (x86-32)、BOOTIA64.EFI (Itanium)、BOOTARM.EFI(AArch32,即32位ARM)和 BOOTAA64.EFI(AArch64,即64位ARM)。然后,固件将履行找到的第一个有效文件(当然,文件需要符合UEFI规范中定义的可履行格式)。
这种机制的设计目标不在于启动日常应用的操作系统。它的设计目标更像是为了启动可热插拔、与设备无关的介质(如 Live 映像和操作系统介质)。这也是这种机制的常见用处。如果查看 Linux 或其他操作系统的 UEFI 兼容 Live 或安装介质,你会创造其中包含 GPT,以及位于(或靠近)设备起始地位的 FAT 分区,该分区的 GPT 分区类型标识为 EFI 系统分区。在那个分区中,会有一个 \EFI\BOOT 目录,目录中至少包含上述特别命名的文件之一。当以原生 UEFI 模式启动 Fedora Live 或安装介质时,就会采用这种机制。BOOTx64.EFI(或其他)文件将处理剩余启动过程,从而启动介质上包含的真正操作系统。
完整原生 UEFI 启动项
Boot0002 和 Boot0003 是存储设备上所安装操作系统的“范例”项。这些项显示了 UEFI 启动机制的全部优势,不仅仅是“从此磁盘启动”,而是“启动此特定磁盘上此特定地位中的这一特定启动装载程序”。
Boot0002 是由原生 UEFI Fedora 安装生成的启动项。Boot0003 是由原生 UEFI OpenSUSE安装生成的启动项。按照字面意思,这些启动项表现“从此分区加载这一文件”。分区指的是 HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) 这个东西:表现某一特定分区(应用 EFI_DEVICE_PATH_PROTOCOL,我不打算对此进行详细介绍。如果你通过固件界面和 efibootmgr 与启动管理器进行交互,你也不需要知道其中的细节)。文件指的是 (\EFI\opensuse\grubx64.efi) 这个东西:它仅表现“加载所述分区上此地位中的文件”。这里所指的分区基础上始终指的就是充当 EFI 系统分区的那个分区,因此:可以放心肠让固件访问 EFI 系统分区。
UEFI 规范供给这一机制,以便操作系统可启动:操作系统将启动装载程序(作用为加载操作系统内核等)安装到 EFI 系统分区中,并应用某一名称(显然,这一名称通常起源于操作系统名称)以及启动装载程序(EFI 可履行格式,用于加载操作系统)的地位向 UEFI 启动管理器配置中添加启动项。
Linux发行版应用 efibootmgr 工具处理 UEFI 启动管理器。进行原生 UEFI 安装时,有关启动装载方面,Linux 发行版实际进行的操作相当简略:它会创立一个 EFI 系统分区(如果不存在此分区),应用相应配置将 EFI 启动装载程序(通常为 grub2-efi,但是也有例外)安装到 EFI 系统分区中的正确路径下,然后调用 efibootmgr 添加相应的 UEFI 启动管理器项(指向其启动装载程序)。如果已存在 EFI 系统分区,大部分发行版会应用现有分区(尽管完整可以创立新的 EFI 系统分区并应用这个新分区):我们已经提到过,UEFI 是一种宽松规范,只要在逻辑上遵守其设计,那么有多少个 EFI 系统分区都没问题。
配置启动过程(固件 UI)
上文描写了 UEFI 规范定义的基础机制,用于管理 UEFI 启动过程。固件用户界面可能不会明确遵守这一机制,懂得这一点非常重要。不幸的是,UEFI 规范有意未限制启动过程的浮现方法或用户配置启动过程的方法,这表现——由于我们也从事 固件工程——每个固件会有不同的实现方法,并且其中某些固件的实现方法较猖狂。
许多固件的启动配置界面较直观。优良的固件设计至少会显示启动次序以及其中的各个启动项,容许用户添加/删除项、更改启动次序或在某次特定启动中疏忽原有启动次序(仅针对那次启动生效,或直接让固件启动特定菜单项,甚至可以选择让固件以 BIOS 兼容模式或 UEFI“回退 (Fallback)”模式“启动这块磁盘”,我的固件就可以这么操作)。此类界面通常可以仅按名称显示完整的原生 UEFI 启动项(例如我们上文提到的 Fedora 和 OpenSUSE 示例);你需要检查 efibootmgr –v 的输出,以详细懂得在调用这些项时,它们具领会尝试并履行哪些操作。
某些固件会尝试对配置进行抽象和简化,最终成果良莠不齐。例如,如果可以选择“启用或禁用”BIOS 兼容模式,固件很有可能会为已连接驱动器的 UEFI 启动管理器配置添加或删除 BIOS 兼容项。如果可以选择“启用或禁用”原生 UEFI 启动,那么在用户“禁用”原生 UEFI 启动时,固件很有可能更改 UEFI 启动管理器配置,从 BootOrder 中删除所有原生UEFI启动项。
请谨记,固件界面中的所有配置选项所履行的操作就是在后台配置 UEFI 启动管理器的行动。如果你能懂得以上所有内容,那么当你更改固件界面中的选项时,你会更容易懂得其背后的本质。
在 BIOS 中,系统不会始终尝试优先从可移动驱动器(CD、USB)进行启动,然后再从驱动器启动。根据实际情况,成果可能有所不同。有些 BIOS 固件会优先尝试从 CD 启动,然后再尝试从硬盘启动(而不是 USB)。试图安装新的操作系统时,用户已习惯于时常检查 BIOS 配置,以确保启动次序“正确无误”。
UEFI 也是如此,但是由于 UEFI 启动管理器机制的机动性/复杂性,这一过程看起来可能显得陌生而可怕。
在系统尝试启动固定启动项之前,如果想要确保系统应用“回退(Fallback)”机制优先从可移动设备启动(例如,在安装 Fedora 时),需要将可移动设备作为固件的默认启动项,或需要相应设置固件。根据具体固件界面,可能创造每个连接的可移动设备都有对应的“菜单项”,你只需要调剂启动次序,把你想要的可移动设备放在首位即可,有时候你也会创造可以直接恳求“对此特定磁盘进行 UEFI 恢复启动”,另外你还可能创造固件会尝试将配置进行抽象。我们不知道具体的固件界面是什么样,因此难以编写阐明。但是既然你已懂得背后的工作原理,那么就可能更容易懂得固件用户界面配置的含义。
配置启动过程(通过操作系统)
如上所述,与 BIOS 机制不同,你可以从操作系统层面配置 UEFI 启动过程。如果你的固件比较令人恶心,你可能需要履行此操作才干达成目标。
你可以应用之前提过的 efibootmgr 工具来添加、删除和修正 UEFI 启动管理器配置中的项,这一工具也具有其他丰富功效。你可以更改启动次序。你可以更改下次启动时的重要启动项,而不需要应用 BootOrder 列表(如果你或其他某些工具已经进行过配置,efibootmgr –v 的输出将包含 BootNext 项,阐明下一次启动将加载的菜单项)。Windows 下也有类似的工具。因此如果你难以从固件界面配置 UEFI 启动,但是你可以启动某种原生 UEFI 操作系统,那么你可以考虑从操作系统(而不是固件 UI)进行启动配置。
结论:
UEFI固件包含某些非常类似于启动菜单的内容。
可以应用 efibootmgr –v 从任何原生 UEFI 启动的 Linux 操作系统中查询 UEFI 启动配置,也可以应用 efibootmgr 更改配置(有关详细信息,请参阅 man 页面)。
“启动菜单”可以包含表现“以 BIOS 兼容模式启动此磁盘”,“通过回退路径 (Fallback path) 以原生 UEFI 模式启动此磁盘”(将应用上文所述的“寻找 BOOT(某字符串).EFI”方法),或“启动此特定地位(几乎始终为 EFI 系统分区)中的特定 EFI 格式的可履行文件”等含义的项。
UEFI 规范尝试一种优良、简洁的设计,让所有操作系统都将其自身的启动装载程序安装到 EFI 系统分区中,然后在“启动菜单”中添加指向这些启动装载程序的项,同时不得干涉其他目标的启动过程。
你的固件 UI 可以自由实现此机制,虽然具体的实现成果良莠不齐。
在 UEFI 盘算机上安装操作系统
我们快速浏览下上文中与在 UEFI 盘算机上安装操作系统相干的具体成果。
原生 UEFI 启动和 BIOS 兼容启动
用户有时会疏忽以下事项:
如果以“原生 UEFI”模式启动安装介质,安装介质将以原生 UEFI 模式安装操作系统:它将尝试向 EFI 系统分区写入 EFI 格式的启动装载程序,并尝试向 UEFI 启动管理器的“启动菜单”中添加启动项,用于启动该启动装载程序。
如果以“BIOS 兼容”模式启动安装介质,安装介质将以 BIOS 兼容模式安装操作系统:它将尝试向磁盘上的 MBR 空间写入 MBR 类型的启动装载程序。
这实用于(现在暂时疏忽其中的无关警告)我接触过的所有操作系统。因此你可能确实想懂得,如何在固件层选择以原生 UEFI 模式启动可移动设备,以及如何在固件层选择以 BIOS 兼容模式启动可移动设备,确保在安装时可以随便选择需要应用的模式。
如果以 BIOS 兼容模式启动安装介质,那么你绝对无法成功进行操作系统的原生 UEFI 安装,因为安装程序无法配置 UEFI 启动管理器(除非以原生 UEFI 模式启动安装介质)。
理论上,在以原生 UEFI 模式启动之后,操作系统的安装程序可通过 BIOS 模式安装该操作系统,即,将启动装载程序写入磁盘 MBR,但是大部分安装程序无法履行此操作,这种做法比较可取。
断定启动模式
有时候,在启动操作系统安装程序之后,你不断定启动模式为原生 UEFI 模式还是 BIOS 兼容模式。别担心。有几种简略方法可以断定启动模式。最简略的方法之一是尝试读取 UEFI 启动管理器。如果你启动了 Linux 安装程序或环境,并且可以运行 shell(例如,在 Fedora 安装程序中是 Ctrl-Alt-F2),请运行 efibootmgr –v。如果你启动的是原生 UEFI 模式,那么就可以看到上文所示的 UEFI启动管理器配置。如果你启动的是 BIOS 兼容模式,那么会看到类似以下内容:
Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.
如果启动了其他操作系统,你可以尝试运行该操作系统的内置实用程序,读取 UEFI 启动管理器,并查看是否显示了明确输出或类似毛病。或者你可以检查系统日志并搜索“efi”和/或“uefi”,从中可能创造蛛丝马迹。
启用原生 UEFI 启动
若要启用原生 UEFI 模式的启动,那么操作系统安装介质必须明确符合我们刚刚阐明的所有规范:具有 GUID 分区表,和 EFI 系统分区,启动装载程序位于正确的“回退”路径 (Fallback path) 中—\EFI\BOOT\BOOTx64.EFI(其他平台可能会有其他名称)。如果无法以原生 UEFI 模式启动安装介质,并且无法查出原因,那么请检查安装介质是否满足上述条件。显然,当应用 livecd-iso-to-disk 工具将 Fedora 映像写入 USB 存储器时,你必须传递 –efi 参数,才干将存储器配置为可用 UEFI 模式启动。
强制应用 BIOS 兼容启动
如果你的固件难以通过 BIOS 兼容模式从可移动介质启动,但是你又确实想通过这种方法启动,那么可以应用一些小花招:完整禁用该介质的原生 UEFI 启动模式。可以通过扫除所有 EFI 系统分区来轻松履行此操作(或者,如果应用 livecd-iso-to-disk 从 Fedora 映像创立 USB存储器,那么只需去掉 –efi 参数,存储器就会变为不可通过 UEFI 模式启动)。如果履行完此操作以后,你的固件仍然无法以 BIOS 兼容模式启动介质,那么就去吐槽你的固件供给商吧(如果还没吐槽过)。
磁盘格式(MBR vs. GPT)
其他注意事项如下:
如果想履行“BIOS 兼容”类型的安装,那么需要安装到 MBR 格式的磁盘。
如果想履行原生 UEFI 安装,那么需要安装到 GPT 格式的磁盘。
当然,为了给用户找不自在,许多固件可以通过 BIOS 模式从 GPT 格式的磁盘启动。事实上,从技巧层面而言,也请求 UEFI 固件能从 MBR 格式的磁盘以 UEFI 模式启动(虽然无法保证)。但是你应当尽可能避免这种情况。这些注意事项非常重要,因为许多用户都曾深受其害。例如,以原生 UEFI 模式启动操作系统安装程序,然后试图直接安装到 MBR 格式的磁盘是非常不明智的。很有可能失败。多数现代操作系统安装程序将把磁盘主动重新格式化为正确格式(如果你容许安装程序彻底扫除磁盘数据),但是,如果你尝试让安装程序“对此 MBR 格式的磁盘履行原生 UEFI 安装,并且不要重新格式化这块磁盘,因为上面有重要数据”,那么就很有可能失败,尽管技巧层面而言,UEFI 规范提到了这种配置。具体而言,至少 Windows 和 Fedora 会明确禁止这种配置。
检查磁盘格式
你可以应用 parted 实用程序检查给定磁盘的格式:
[[email protected] Downloads]$ sudo parted /dev/sda
GNU Parted 3.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: ATA C300-CTFDDAC128M (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary ext4 boot
2 525MB 128GB 128GB primary lvm
(parted)
注意到 Partition table: msdos 那一行了吗?这是一块 MBR/MS-DOS 格式的磁盘。如果是 GPT 格式的磁盘,会显示 gpt。你可以从 parted 中通过履行 mklabel gpt 或 mklabel msdos 将磁盘重新格式化为其他类型分区表。这会损坏磁盘内容。
对于多数操作系统的安装程序而言,如果你采用的磁盘配置会清空目标磁盘的所有内容,那么根据履行的安装类型,安装程序就会主动应用最合适的配置重新格式化磁盘。但是如果你想应用现有磁盘而不格式化,那么你需要检查该磁盘的格式并三思而后行。
履行手动分区时处理 EFI 系统分区
我只能针对 Fedora 给出权威建议,但是其中的重要内容可能也实用于其他发行版/操作系统。
履行原生 UEFI 安装,并且采用 GPT 格式的磁盘时,或者容许 Fedora 重新格式化磁盘(通过删除所有现有分区)时,如果容许 Fedora 主动处理分区,那么 Fedora 就会主动处理 EFI 系统分区。
但是,如果应用自定义分区,Fedora 会请求指定 EFI 系统分区,以供安装程序应用。如果不履行此步骤,安装程序会报错(毛病消息的含义不明)并拒绝启动安装。
因此,如果履行原生 UEFI 安装并应用自定义分区,需要确保类型为“EFI 系统分区”的分区已挂载到 /boot/efi(这是 Fedora 查找 EFI 系统分区的路径)。如果系统上存在现有 EFI 系统分区,那么仅需将其挂载点设置为 /boot/efi 即可。如果还没有 EFI 系统分区,那么请创立一个分区,将其类型设置为 EFI 系统分区,大小至少为 200MB(建议 500MB),然后将其挂载点设置为 /boot/efi。
具体示例
总结:如果购置了 Windows 8 或更高版本的操作系统,那么你的 Windows 基础上确定是通过原生 UEFI 安装到 GPT 格式磁盘的。这表现如果你想安装其他操作系统,并与 Windows 共存,那么需要通过原生 UEFI 方法安装操作系统。如果你不爱好 UEFI,并且想要用回老掉牙的 BIOS,那么恐怕就得清空全部原生 UEFI 的 Windows,而且需要重新将磁盘格式化为 MBR。
缺点
上文解释了 UEFI 的启动原理(至少解释得差不多了)。我这种描写方法应当还可以吧?
但是,UEFI 并不完善,也有许多问题。
仔细的读者可能已经留心,我曾经提到过,UEFI 规范供给了一种机制。这种说法很严谨,也很重要。由于 UEFI 规范是一种“广泛共鸣”,因此其重要毛病之一(就特定方面而言)是并未供给具体实现。
如果仔细浏览 UEFI 规范,就会创造 UEFI 规范的基础方法是定义 UEFI 兼容固件必须支撑的一系列功效。但是 UEFI 规范并没有严格规定这些功效的具体实现方法。
因此,UEFI 规范只请求系统固件必须遵守其中描写的所有内容,以便满足 UEFI 兼容固件的请求。但是,规范本身未规定操作系统“应当”或“必须”怎么做,并且 UEFI 规范也没有规定固件不得支撑(或者不期望支撑)的功效。换言之,在制定 UEFI 固件时,需要支撑 GPT 格式的磁盘和 FAT 格式的 EFI 系统分区,并且必须以标准格式读取 UEFI 启动管理器项等等——但是也可以随便添加其他未规定的功效。
从 UEFI 规范中不难创造其中的隐喻——UEFI 规范仔细设置了一种良好机制,用于在固件层处理操作系统(或其他启动项)选择。但是 UEFI 规范并不请求必定要这么做,其他广受赞誉的规范也没有类似规定。
因此,在实际应用时,我们可能遇到各种复杂情况。例如,Apple Mac 的 HFS+ 分区中随附了某些启动装载程序。UEFI 规范提到,UEFI 兼容固件必须支撑特定 GPT 分区类型的 UEFI FAT 分区(标识为“EFI 系统分区”),但是 UEFI 规范并没有提到固件不能辨认其他文件系统类型并从中加载启动装载程序。(此类分区是否应视为“EFI 系统分区”,这很难答复,在此不做探讨。)
要是所有厂商都能按照 UEFI 规范严格应用 EFI 系统分区,那就不会有这么多问题了。但是 Apple 毕竟是 Apple,它的产品设计领先于其他厂商,率先设计出了可以从 HFS+ 分区读取和加载代码的固件,导致现在其他厂商不得不紧随 Apple 的脚步,除非他们不打算支撑 Mac。在启动过程设计中,Apple 进行的工作远超出 UEFI 规范的领域,因此,如果你想让其他操作系统以雅观的图标或其他情势显示在 Mac 的图形启动菜单上,你所要做的操作将超出 UEFI 规范的建议领域。
还有各种类似的极端状态,使人烦不胜烦,但是我们先不管了。这篇文章够长的了。
另外,就像之前提到过的,UEFI 规范并没有对机制的具体浮现方法进行束缚。因此,如果一些软件公司设计的操作系统符合 UEFI 规范,并且可以安装 EFI 启动装载程序,并明确命名 EFI 启动管理器项(例如,Fedora 和 Windows),那么如果要向用户供给某种相对辨识度较高的俏丽界面,让用户可以从中选择启动 Windows 或 Fedora,就得看固件本身设计得怎么样。固件设计得越糟糕,操作系统工程师就越不会遵守 UEFI 规范,他们越可能在固件层上另起炉灶。
说句公平话,我们可以在操作系统层实现更多功效。我们可以用更整洁直观的方法实现 efibootmgr 的所有功效——例如,我们可以采用“疏忽下一次启动时的启动次序,直接启动此项”,同时将“重新启动到 Windows”作为选项之一。如果开发人员能够用更直观的方法展现 efibootmgr 的所有功效,那将会非常不错。Windows 8 系统在必定程度上采用了这种方法——例如,用户可以从 Windows 8 设置菜单中将系统重新启动到固件 UI。但是这还不够。
这些实在令人欲哭无泪,因为 UEFI 本来可以更好地进行统一。对于多重启动,BIOS 不供给任何类型的规范或标准,因此完整需要在固件层上处理多重启动。我们(这一产业)已经提出了某种处理多重启动的规范,但是我们从未将其付诸实行,因此最终不了了之。而每种操作系统都采用自己的多重启动方法,大批开发人员也自己写了启动装载程序,试图包揽所有操作系统。而所有操作系统和独立的启动装载程序难以互相兼容。我想说的是,在 UEFI 出身之前,多重启动的实现方法一团混乱。
如果 UEFI——或者基于 UEFI 的某种规范——请求所有厂商遵守 UEFI 提出的规范,并请求固件供给直观的用户界面,那将会终结现阶段的混乱情况。但是现实不如人意,因此 UEFI 的情况完整可能比 BIOS 更糟糕。如果大批固件没有为 UEFI 启动管理器机制供给良好的 UI,那么操作系统供给商可能放弃 UEFI 启动管理器机制(或选择性地进行支撑),转而在 UEFI 中重现 BIOS 多重启动的混乱情况——如此一来,我们就得收拾所有烂摊子,外加 UEFI 启动管理器层的其他影响。在全部 UEFI 启动管理器机制上,用户可能装有多个启动装载程序,互相争抢装载多个操作系统的把持权,而 UEFI 启动管理器机制只会机械地处理各种变量,而无法解决这种混乱情况。
这不是某人灵光闪现的荒谬想法,而是可能实际产生的真实情况。
另外,在这方面产生的 UEFI 缺点是由一时疏忽引起的——这些缺点不受委员会把持,也不是某人故意为之的成果。如果你的系统固件很坑爹,无法让你轻松访问 UEFI 启动管理器,那么你的发泄对象不应当是 UEFI 论坛或微软,当然也不是 Fedora 或者我。你应当归罪于系统/主板制作商和他们雇用的傻逼固件开发人员。凡是大脑健全的人,都能看出来,UEFI 规范已经明确阐明,为 UEFI 启动管理器供给某种直观的用户界面是非常有益的,所有反人类的固件都是一堆垃圾代码。的确,UEFI 论坛已经意识到固件工程师难以脱离现有束缚重新学习新规范,但是,固件工程师最终还是应当与时俱进。
简略来说,“所有固件都是垃圾代码”。这句话通常非常正确。
安全启动 (Secure Boot)
我们最后要介绍的,就是安全启动 (Secure Boot)。
安全启动 (Secure Boot) 并不神奇,也不复杂。才怪。安全启动 (Secure Boot) 复杂得要命,但是其理论并不复杂。安全启动 (Secure Boot) 本身也并不邪恶。事实就是如此,你也应当认同这一事实,除非你认为GPG也有恶意。
在 UEFI 规范(2.4A 版本)的第 28 章对安全启动 (Secure Boot) 进行了定义。这种机制事实上非常明智。但是其原理却非常简略。UEFI 规范规定固件可以包含一系列签名,并拒绝运行未签名或签名与固件中包含的签名不一致的 EFI 可履行文件。
就这么简略?当然不是了,这只是一种简略概括。安全问题很复杂,因此才会产生通过安全启动 (Secure Boot) 来实现真正安全启动链的各种方法。mjg59 可以进行详细介绍,或者你可以完整浏览第 28 章。但是其中只涉及了基础概念。
应用公开密钥加密来验证某个文件完整性的方法很难断定其好坏。几乎所有 Linux 发行版都依附这种加密方法——我们为软件包签名,在尝试安装未应用我们的密钥之一签名的软件包时,软件包管理器将发出警告。这不是我们的错,我也不认为会有人因为以这种方法应用公开密钥加密进行签名而归罪于操作系统本身。从字面上看,安全启动 (Secure Boot) 与这种广泛认可的机制完整雷同,只不过安全启动 (Secure Boot) 实用于启动链。由于一撮媒体人找错了槽点,并揪着不放,导致大众受到了广泛误导,认为安全启动 (Secure Boot) 是洪水猛兽。
UEFI 规范中定义的安全启动 (Secure Boot) 并没有对固件所信任的密钥情势及其起源作出规定,我也不打算介绍所有细节,因为过于枯燥乏味,而且本文已经挺长了。但是总的来说,UEFI 规范只对履行启动链的加密验证进行了定义。UEFI 规范甚至没有涉及用于履行这一过程的策略可能产生的问题。这本来并没有错,因为这样可以保证其机动性,并且 UEFI 规范容许在多个层面配置涉及的所有机制。UEFI 规范中未提及微软,也没有和微软互相勾结。如果你不信,那么你可以浏览 UEFI 规范。我已经供给了所有阐明。字面上来说,对于那些反对在固件规范中将启动装载程序加密验证机制作为可选功效的人,我不予置评。
实际应用安全启动 (Secure Boot)
有关安全启动 (Secure Boot) 的所有不满并不针对安全启动 (Secure Boot) 机制本身——虽然发出这些不满的人可能不这么认为——而是针对安全启动 (Secure Boot) 在实际操作中的特定实现方法。
我们唯一在意的是,对于预装 Windows 8 或更高版本 Windows 的 PC 而言,安全启动 (Secure Boot) 是默认开启的。
微软将这些称为“Windows 硬件认证请求”。这些请求并不是什么绝密内容,所有人都可以在互联网上浏览。
如果想从微软那里以低廉的价格获得预装 Windows 的批量允许,并在机箱上贴有“微软认证”标签,那么你必须符合这些认证请求。微软的束缚力有限:他们不是美国或其他国家/地区的法律制定者,无论其他人怎么想。即使你销售的 PC 不符合这些请求,比尔?盖茨也不会拿你怎么样,前提是你不需要预装便宜的 Windows 副本和那张“微软认证”标签。对于不符合微软允许打算的在售 PC,事实上并不请求如何配置安全启动 (Secure Boot),甚至根本不需要供给安全启动 (Secure Boot) 功效。具有 UEFI 2.2 或更高版本兼容固件的 PC 必须供给安全启动 (Secure Boot) 功效,但是并没有规定具体的实现方法(包含关闭安全启动 (Secure Boot) 的方法)。
如果你对安全启动 (Secure Boot) 意见很大,那么就别找借口了,马上去读读微软认证请求吧(http://msdn.microsoft.com/en-us/library/windows/hardware/dn423132.aspx)。你可以搜索“Secure Boot”来浏览相干内容。从“System.Fundamentals.Firmware.UEFISecureBoot”一节开端。
你最好读一遍,但是我对其内容进行了总结。
符合微软认证请求的盘算机必须满足以下条件:
默认启用安全启动 (Secure Boot)(服务器除外)
在其信任密钥列表中包含微软的密钥
启用安全启动 (Secure Boot) 时,必须禁用 BIOS 兼容模式(如果没记错的话,UEFI 规范也有此请求)
支撑签名黑名单
符合微软认证请求的 x86 盘算机 还必须满足以下附加条件:
容许 自然人禁用安全启动 (Secure Boot)
容许 自然人启用自定义模式,以及修正固件的信任密钥列表
符合微软认证请求的 ARM 盘算机 还必须满足以下附加条件:
不容许 自然人禁用安全启动 (Secure Boot)
不容许 自然人启用自定义模式,以及修正固件的信任密钥列表
是的,你没看错。对于 x86 盘算机,微软认证请求明确规定了自然人用户应当能够完整把持安全启动 (Secure Boot)(启用或禁用),或完整把持安全启动 (Secure Boot) 的信任密钥列表。另一个重点是,尽管认证请求规定,信任密钥列表必须包含微软的密钥,但是其中没有规定不容许包含其他密钥。微软认证请求也明确容许系统包含其他任意数量的信任密钥。
这些请求并不完整出于微软的好意,之所以作出这些规定,是因为如果不这么做的话,微软将面临大批诉讼2。真正懂得 UEFI 和安全启动 (Secure Boot) 的用户可能不会曲解微软认证请求,这些请求非常清楚明确。这些请求旨在确保认证系统的所有者能完整把持安全启动 (Secure Boot),事实上这些请求也确实成功确保了这一条件。
如果你有包含 Windows 认证的 x86 系统,但是不容许你禁用安全启动 (Secure Boot),那么这就直接违背了认证请求,你应当马上投诉。如果市面上存在大批这类系统,那么我们确定会有麻烦,可能要给那些巨头厂商提起诉讼了。但是目前为止,事实并非如此。在我见过的所有 x86 Windows 认证系统中,其固件都有“禁用安全启动 (Secure Boot)”选项。
对于 ARM 盘算机,认证请求显然更变态:其中的规定和 x86 完整相反,不容许禁用安全启动 (Secure Boot),也不容许系统所有者更改信任密钥。非常糟糕且不合理。这使得微软认证 ARM 系统成为了一个封闭的环境。值得注意的是,其他重要 ARM 平台甚至更糟糕。Apple 在所有 iDevice 上锁定了启动装载程序,而且大部分 Android 设备的启动装载程序也是锁定的。
如果你打算购置微软认证 ARM 设备,请注意这一问题,你将无法把持设备上的启动项。如果你对此反感,那就不要购置这样的设备,也不要购置 iDevice 或启动装载程序处于锁定状态的 Android 设备(你可以购置启动装载程序未锁定或无法锁定的 Android 设备,但是需要事先进行调查研究)。
目前,就 x86 设备本身而言,微软的认证请求实际上明确保障了用户自由启动系统的权利。这是件好事。
建议
以下内容是我在管理系统启动方面的一般建议,不保证其正确性、可靠性或安全性。
如果可以的话,每台盘算机只安装一个操作系统。 如果你需要一个以上操作系统,那就多买几台盘算机,或应用虚拟机。这么做的话,事情就简略多了,而且无论你的固件是 BIOS 或 UEFI,或在 UEFI 系统上应用 BIOS 兼容启动,都没什么关系了。你在应用盘算机时也会轻松许多。
如果你确实需要在每台盘算机上安装多个操作系统,那么请在每块磁盘上至少安装一个操作系统。 如果你比较熟悉 BIOS 启动,而且也不需要安全启动 (Secure Boot) 功效,在这种情况下,对于 UEFI 系统,请优先应用 BIOS 兼容启动。这样一来,可能不会有那么多麻烦,也不会造成数据丧失。如果每块磁盘只安装一个操作系统,那么你也可以混杂应用原生 UEFI 和 BIOS 兼容模式。
如果你保持要在每块磁盘上安装多个操作系统, 那么请先懂得本文所写内容。这么做无异于自作孽,不可活,出了问题可别责备操作系统供给商。另外,在这种情况下,也不要混用原生 UEFI 和 BIOS 兼容模式,否则就是雪上加霜。
如果你在应用 UEFI 原生启动,并且不打算自己编译内核/内核模块或在 Linux 上应用 NVIDIA/ATI 私有驱动程序,那么最好启用安全启动 (Secure Boot)。这不会有什么副作用,反而可以带来额外的安全性,用以应对某些卑鄙的攻击类型(尽管目前很少被利用)。
如果打算编译内核/内核模块或应用 NVIDIA/ATI 私有驱动程序,那就最好禁用安全启动 (Secure Boot)。或者你可以启用安全启动 (Secure Boot),然后浏览有关配置信任链和对内核/内核模块签名的阐明。但是这一过程至少需要好几天。
不要在 MBR 格式的磁盘上进行原生 UEFI 安装,也不要在 GPT 格式的磁盘上进行 BIOS 兼容安装(如果没记错的话,除非你的磁盘大小大于 2.2TB,因为 MBR 格式无法辨认那么大的磁盘。如果想在那么大的磁盘上进行 BIOS 兼容安装,那么你可能会卡在 BIOS+GPT 的组合上。虽然这种组合可以正常运行,但是有点不靠谱,而且会牵涉到臭名昭著的“BIOS Boot 分区”)。
信任 mjg59 及其他权威人士,包含我。
1. 这一整节都是简化过的内容——当启动已安装的操作系统时,无论启动装载程序是否安装在“ESP”上,对固件都没有影响;固件只会读取启动管理器项,然后尝试访问特定分区并履行特定可履行文件,具体请参阅 pjones 的阐明。但是一般会应用 ESP 来进行启动过程,因为 UEFI 规范中有相应规定,而且这个分区也很方便,固件可以读取其文件系统。理论上来说,在固件履行可移动介质/回退路径 (Fallback path) 启动时,ESP 将不起作用。
2. 注意,这只是我的个人推断。在全部规范的制定过程中,我都没有参与,也没人告诉我这些内容。但是根据已知事实,明显可以得出这一推断。
关于uefi原理与编程的方法到这里就全部结束了,信任大家观看上面的uefi原理与编程下来都有一种心得了吧,非常感谢大家的观看,感谢大家的支撑,如果想懂得更多的咨询敬请关注小白老鸟Win10升级助手吧。