|
本文是我翻譯自國外技術(shù)博客的一篇文章，其中講述了 UEFI 的一些基本概念和細(xì)節(jié)。 本文的原始鏈接位于： https://www./2014/01/25/uefi-boot-how-does-that-actually-work-then/ 本人的翻譯水平有限，難免多有疏漏。廢話不多說，請(qǐng)看正文： 又到 AdamW 的講課時(shí)間了，如果你不想聽我的長(zhǎng)篇大論，那么請(qǐng)出門右拐。 Kamil Paral 說我有 寫作癖 ，知道自己的壞習(xí)慣也是件好事。 可能你已經(jīng)在互聯(lián)網(wǎng)上閱讀過有關(guān) UEFI 的大量資料。但是有一些重要事項(xiàng)需要了解：這些資料中的 95% 都毫無價(jià)值。如果你認(rèn)為你已經(jīng)對(duì) UEFI 有所了解，但是如果你的知識(shí)來源并不可靠，那么所掌握的知識(shí)就不過是一堆誤解、謬論、一己之見、信口開河和彌天大謊。先把這些都忘了吧。如果想真正了解有關(guān) UEFI 的權(quán)威知識(shí)，不妨訪問 UEFI 規(guī)范、 mjg59 的博客 、其他靠譜一點(diǎn)的文章/權(quán)威人士——包括 Rod Smith 、 Peter Jones 、Chris Murphy，或者閱讀一些小眾操作系統(tǒng)的文檔，前提是這些操作系統(tǒng)的開發(fā)人員確實(shí)了解 UEFI。 好，準(zhǔn)備工作做完了。我主要想討論啟動(dòng)加載，因?yàn)閷?duì)于大多數(shù)用戶而言，固件在其中扮演著重要角色，同時(shí)，不少網(wǎng)站也針對(duì)這一過程喋喋不休，由此產(chǎn)生不少誤解。 術(shù)語首先，我們了解一些術(shù)語。 BIOS 和 UEFI 都是計(jì)算機(jī)的 固件 類型。BIOS 固件（主要）用于 IBM PC 兼容計(jì)算機(jī) 。UEFI 的通用性更強(qiáng)，可用在非“IBM PC 兼容”系列的計(jì)算機(jī)上。 不存在“UEFI BIOS”。沒有任何一臺(tái)計(jì)算機(jī)會(huì)有“UEFI BIOS”。請(qǐng)不要再說“UEFI BIOS”。BIOS 不是所有 PC 固件的通用術(shù)語，它只是 PC 固件的一種特定類型。計(jì)算機(jī)中包含固件。如果你有一臺(tái) IBM PC 兼容計(jì)算機(jī)，那么固件幾乎肯定就是 BIOS 或 UEFI。如果你運(yùn)行的是 Coreboot ，那么恭喜，你是個(gè)例外，引以為傲吧。 安全啟動(dòng) (Secure Boot) 與 UEFI 不是同一個(gè)概念。請(qǐng)不要將這些術(shù)語混淆使用。安全啟動(dòng) (Secure Boot) 實(shí)際上是 UEFI 規(guī)范的一項(xiàng)可選功能，于 UEFI 規(guī)范版本 2.2 引入。我們稍后會(huì)詳細(xì)討論安全啟動(dòng) (Secure Boot) 到底是什么，但是目前而言，只需要記住它和 UEFI 不同即可。你需要區(qū)分安全啟動(dòng) (Secure Boot) 和 UEFI 的差異，在任何場(chǎng)合，你都應(yīng)當(dāng)了解你實(shí)際上討論的是其中哪一個(gè)。我們首先討論 UEFI，然后我們將把安全啟動(dòng) (Secure Boot) 作為 UEFI 的一項(xiàng)“擴(kuò)展”來進(jìn)行討論，因?yàn)檫@就是安全啟動(dòng) (Secure Boot) 的本質(zhì)。 注釋：UEFI 不是由微軟開發(fā)的，也從來不受微軟控制。它的前身和基礎(chǔ)——EFI，是由 Intel 開發(fā)和發(fā)布的。UEFI 由 UEFI 論壇 進(jìn)行管理。微軟是 UEFI 論壇的成員之一。Red Hat、Apple、幾乎所有主要 PC 制造商、Intel（顯然）、AMD 和 一大批其他主要和次要硬件、軟件和固件公司及組織 也都是 UEFI 論壇的成員。UEFI 是一套業(yè)已達(dá)成廣泛共識(shí)的規(guī)范，其中當(dāng)然也包含各種混亂（我們稍后會(huì)專門討論其中一部分）。UEFI 并不由任何一家公司獨(dú)裁掌控。 參考資料如果想真正了解 UEFI，閱讀 UEFI 規(guī)范是個(gè)不錯(cuò)的方法。這件事并不難，也不需要什么代價(jià)。閱讀 UEFI 規(guī)范相當(dāng)枯燥乏味，但是會(huì)讓你受益匪淺。你可以從 官方 UEFI 網(wǎng)站 下載 UEFI 規(guī)范。盡管下載 UEFI 規(guī)范需要先同意某些條款和條件，但是不會(huì)帶來損失。在我撰寫本文時(shí)，UEFI 規(guī)范的最新版本是 2.4 Errata A （譯者注：現(xiàn)在更新到了 2.4 Errata B ），本文所寫內(nèi)容也基于這一版本。 BIOS 沒有制定相應(yīng)規(guī)范。BIOS 本身就是一項(xiàng)事實(shí)標(biāo)準(zhǔn)，從 20 世紀(jì) 80 年代開始，BIOS 的工作方式就一成不變。這也是誕生 UEFI 的原因之一。 簡(jiǎn)單起見，我們可以把 BIOS 和 UEFI 看成兩種不同的組合。其中一種是 UEFI和 GPT （我們稍后會(huì)討論 GPT）產(chǎn)生之前，IBM PC 兼容計(jì)算機(jī)（以下稱為 PC）所廣泛采用的組合。大部分人可能對(duì)這種組合非常熟悉，對(duì)其中的細(xì)節(jié)了如指掌。那么我們就先來討論在具有 BIOS 固件的 PC 上，啟動(dòng)是如何工作的。 BIOS 啟動(dòng)事實(shí)上，BIOS 啟動(dòng)的工作原理非常非常簡(jiǎn)單。在老式 BIOS PC 上，裝有一個(gè)或多個(gè)磁盤，每個(gè)磁盤中包含 MBR 。MBR 是另一套事實(shí)標(biāo)準(zhǔn)；大體而言，磁盤起始位置以特定格式描述磁盤上的分區(qū)，并包含“啟動(dòng)裝載程序 (boot loader)”，BIOS 固件知道如何執(zhí)行這一小段啟動(dòng)裝載程序代碼。啟動(dòng)裝載程序的職責(zé)是啟動(dòng)操作系統(tǒng)（現(xiàn)代啟動(dòng)裝載程序的大小通常超出了 MBR 空間所能容納的范圍，因此必須采用多階段設(shè)計(jì)，其中 MBR 部分只知道如何從其他位置加載下一階段，我們現(xiàn)在先不著重討論這一過程）。 在啟動(dòng)系統(tǒng)的過程中，BIOS 固件只能識(shí)別系統(tǒng)包含的磁盤。而作為 BIOS 計(jì)算機(jī)的擁有者，你可以告訴 BIOS 固件你想從哪個(gè)磁盤啟動(dòng)系統(tǒng)。而固件本身并不知道其他細(xì)節(jié)，它只會(huì)執(zhí)行在指定磁盤的 MBR 部分所發(fā)現(xiàn)的啟動(dòng)裝載程序，就這么回事。在執(zhí)行啟動(dòng)裝載程序之后，固件本身就不再參與啟動(dòng)。 在 BIOS 組合中，所有的多重啟動(dòng)形式都肯定是在固件層上進(jìn)行處理的。固件層無法真正識(shí)別啟動(dòng)裝載程序或操作系統(tǒng)，甚至連分區(qū)都無法識(shí)別。固件所能執(zhí)行的操作只是從磁盤的 MBR 中運(yùn)行啟動(dòng)裝載程序。你無法從固件外部配置啟動(dòng)過程。 UEFI 啟動(dòng)：背景好，BIOS 組合的背景知識(shí)已經(jīng)明確了。我們現(xiàn)在來看看 UEFI 計(jì)算機(jī)上的啟動(dòng)原理。即使未掌握本文的細(xì)節(jié)，也請(qǐng)記住這一點(diǎn)：UEFI 與 BIOS 完全不同。UEFI 啟動(dòng)原理與 BIOS 絕對(duì)不同。你不能把 BIOS 啟動(dòng)的原理直接套用到原生 UEFI 啟動(dòng)上。你不能把專為 BIOS 啟動(dòng)設(shè)計(jì)的工具應(yīng)用到原生 UEFI 啟動(dòng)的系統(tǒng)上。記住，UEFI 組合完全不同。 還需要了解一個(gè)重點(diǎn)：許多 UEFI 固件實(shí)現(xiàn)了某種 BIOS 兼容模式（有時(shí)候稱為 CSM）。許多 UEFI 固件可以像 BIOS 固件一樣啟動(dòng)系統(tǒng)，它們可以查找磁盤上的 MBR，然后從 MBR 中執(zhí)行啟動(dòng)裝載程序，接著將后續(xù)工作完全交給啟動(dòng)裝載程序。有時(shí)候，其他人誤將此功能稱為“禁用 UEFI”，從語言學(xué)角度而言，這種說法是荒謬的。系統(tǒng)固件是無法“禁用”的。這種說法很愚蠢，不要采用這種說法。但是在其他人這么說的時(shí)候，應(yīng)該了解他們真正想表達(dá)什么。他們討論的是通過 UEFI 固件的一項(xiàng)功能，以“BIOS 風(fēng)格”啟動(dòng)系統(tǒng)，而不是采用原生 UEFI 方式啟動(dòng)系統(tǒng)。 我想解釋一下原生 UEFI 啟動(dòng)。如果你有一臺(tái)基于 UEFI 的計(jì)算機(jī)，其固件具有 BIOS 兼容功能，并且你打算一直使用這項(xiàng)兼容功能，在啟動(dòng)過程中，你的計(jì)算機(jī)看起來就是基于 BIOS 的。你只需要像 BIOS 啟動(dòng)一樣進(jìn)行所需操作即可。如果你確實(shí)有此打算，那么就不要中途變卦。對(duì)于你日常使用的操作系統(tǒng)，強(qiáng)烈建議不要混合使用原生 UEFI 啟動(dòng)和 BIOS 兼容啟動(dòng)，尤其不要在同一塊磁盤上混用。這么做的話，你會(huì)痛不欲生。如果你決定混合使用原生 UEFI 啟動(dòng)和 BIOS 兼容啟動(dòng)，到時(shí)候就別找我哭訴。 為了理清頭緒，我將假設(shè)磁盤采用 GPT ，并且包含用于 EFI 的 FAT32 EFI 系統(tǒng)分區(qū) (ESP)。根據(jù)你對(duì)這些知識(shí)的深入程度，你可能發(fā)現(xiàn)，在進(jìn)行原生 UEFI 啟動(dòng)時(shí)，GPT 磁盤和 EFI FAT32 ESP 并不是必要條件。但是 UEFI 規(guī)范和 GPT 磁盤以及 EFI FAT32 ESP 的聯(lián)系程度相當(dāng)密切。在99%的情況下，你要處理的也正是這樣的組合。除非你在使用 Mac（老實(shí)說，Mac 混亂不堪）。 編輯說明：以下章節(jié)（到缺陷為止）在 2014 年 1 月 26 日（本文發(fā)布的幾小時(shí)后）根據(jù) Peter Jones 的反饋進(jìn)行了大量修訂。本文可視為 v2.0 版本。早期版本的寫作方式不夠嚴(yán)謹(jǐn)，而且內(nèi)容可能會(huì)產(chǎn)生誤解。 UEFI 原生啟動(dòng)：實(shí)際工作原理——背景言歸正傳。本節(jié)將解釋原生 UEFI 啟動(dòng)的實(shí)際工作原理。如果已掌握一定程度的背景知識(shí)，可能更容易深入理解本節(jié)內(nèi)容。 在固件層，UEFI 的基礎(chǔ)架構(gòu)更豐富，可用于處理系統(tǒng)啟動(dòng)。UEFI 遠(yuǎn)不像BIOS 那么簡(jiǎn)單。與 BIOS 不同，UEFI 確實(shí)可以（不同程度上）理解“磁盤分區(qū)”、“啟動(dòng)裝載程序”以及“操作系統(tǒng)”的概念。 你可以稍微看看 BIOS 啟動(dòng)過程，然后再看看 UEFI 啟動(dòng)過程，了解 UEFI 啟動(dòng)過程如何采用多種措施來解決特定問題。 在思考啟動(dòng)過程時(shí)，你會(huì)發(fā)現(xiàn) BIOS/MBR 查找啟動(dòng)裝載程序的方法實(shí)在不怎么樣。BIOS/MBR 非常奇葩：位于磁盤起始位置的這一小段空間包含神奇代碼 (magic code)，而這段神奇代碼只作用于系統(tǒng)固件和寫入此神奇代碼的工具。這種方法有許多問題。
可以想象，在 UEFI 設(shè)計(jì)之初，開發(fā)人員思考過這些問題，并最終提出解決方案。UEFI 固件并不僅僅可以識(shí)別磁盤，它也知道啟動(dòng)裝載程序代碼在每個(gè)磁盤上所處的位置，而且在固件層，UEFI 的基礎(chǔ)架構(gòu)更豐富，可用于處理啟動(dòng)裝載。接下來，我們討論下 UEFI 規(guī)范中定義的相關(guān)內(nèi)容。 EFI 可執(zhí)行文件UEFI 規(guī)范定義了一種可執(zhí)行文件格式，并要求所有 UEFI 固件能夠執(zhí)行此格式的代碼。當(dāng)開發(fā)人員為原生 UEFI 編寫啟動(dòng)裝載程序時(shí)，就必須按照這種格式編寫。這種設(shè)計(jì)非常簡(jiǎn)潔直觀，也無需進(jìn)一步解釋：對(duì)于固件可以執(zhí)行的代碼，固件規(guī)范真正定義了其通用格式，這是件好事。 GPT（GUID 分區(qū)表）格式GUID 分區(qū)表格式與 UEFI 規(guī)范具有密切聯(lián)系，而且，它并不特別復(fù)雜，無需多加解釋。GPT 是 UEFI 規(guī)范提供的良好基礎(chǔ)架構(gòu)之一。GPT 僅僅是分區(qū)表的一種標(biāo)準(zhǔn)——磁盤起始位置的信息定義了磁盤所包含的分區(qū)。相比 MBR/MS-DOS 分區(qū)表，這種分區(qū)表對(duì)分區(qū)的定義要好得多，并且 UEFI 規(guī)范要求 UEFI 兼容固件必須能識(shí)別 GPT（也要求固件能識(shí)別 MBR，以保證向后兼容）。所有這些規(guī)范都是相當(dāng)實(shí)用的基礎(chǔ)架構(gòu)： UEFI 規(guī)范正建立某些功能，固件層上的一切都可依靠固件本身來實(shí)現(xiàn)這些功能。 EFI 系統(tǒng)分區(qū)在修訂本文時(shí)，我才真正思考 EFI 系統(tǒng)分區(qū)的概念，讓我有如醍醐灌頂。實(shí)際上，“EFI 系統(tǒng)分區(qū)”的概念可以解決“奇葩”的 MBR 空間所產(chǎn)生的問題。在磁盤起始位置留出自由空間，用于存放啟動(dòng)裝載程序代碼，但又不定義其容量，種設(shè)計(jì)糟糕透頂。這一點(diǎn)在上文已經(jīng)討論過了。EFI 系統(tǒng)分區(qū)是 UEFI 用于解決這種問題的解決方案。1 具體的解決方案如下：我們要求固件層能夠讀取某些特定的文件系統(tǒng)類型。UEFI 規(guī)范要求兼容固件必須能讀取 FAT 格式的變種（包括 FAT12、FAT16 和 FAT32）。UEFI 規(guī)范實(shí)際扮演的角色就是編纂整理 FAT 文件系統(tǒng)格式的現(xiàn)有解釋，確保在采用 UEFI 時(shí)可以使用那些格式，并規(guī)定 UEFI 兼容固件必須能夠讀取那些格式。UEFI 規(guī)范針對(duì)這方面的具體規(guī)定如下： “可擴(kuò)展固件接口 (EFI) 支持的文件系統(tǒng)基于 FAT 文件系統(tǒng)。EFI 定義了可以明確記錄和測(cè)試的具體 FAT 版本。FAT 的唯一定義必須符合 EFI 規(guī)范及關(guān)聯(lián)參考文檔，對(duì) FAT 唯一定義的實(shí)現(xiàn)必須支持 EFI。為區(qū)分 EFI 文件系統(tǒng)與純 FAT，定義了新的分區(qū)文件系統(tǒng)類型?！?/P> “EFI 系統(tǒng)分區(qū)”是采用 FAT 變種（UEFI 規(guī)范定義的變種之一）格式化的任意分區(qū)，該分區(qū)被賦予特定 GPT 分區(qū)類型，以幫助固件識(shí)別該分區(qū)。此分區(qū)的目的如上所述：固件層確實(shí)可以讀取“普通”磁盤分區(qū)中的數(shù)據(jù)。希望我已明確解釋為何這種設(shè)計(jì)更佳：操作系統(tǒng)可以創(chuàng)建、格式化和掛載分區(qū)（采用廣泛理解的格式），并將啟動(dòng)裝載程序的代碼和固件可能需要讀取的所有其他內(nèi)容放到這個(gè)分區(qū)中，而不用像 MBR 磁盤一樣，將啟動(dòng)裝載程序的代碼寫入磁盤的起始位置空間。 剛開始的時(shí)候，對(duì)我而言，整個(gè) ESP 的設(shè)計(jì)看起來有點(diǎn)匪夷所思且令人困惑，因此我希望本節(jié)可以解釋為何 ESP 實(shí)際上是非常優(yōu)秀的設(shè)計(jì)——真正匪夷所思和令人困惑的設(shè)計(jì)是 BIOS/MBR。若要從操作系統(tǒng)層寫入某些內(nèi)容，唯一的方法是將這些內(nèi)容寫入磁盤起始位置的某部分（但不知道是多少）空間，而并沒有具體規(guī)定其中的具體實(shí)現(xiàn)。如果回過頭再看，這種設(shè)計(jì)并不明智，且難以理解。 正如我們稍后會(huì)強(qiáng)調(diào)的那樣，UEFI 規(guī)范試圖采用更直觀嚴(yán)格的方法——它很少禁止固件執(zhí)行其他操作。UEFI 規(guī)范并不反對(duì)編寫固件，用于執(zhí)行以其他格式寫成的代碼、讀取其他類型的分區(qū)表，以及讀取用UEFI 變種文件系統(tǒng)（非 FAT）格式化的分區(qū)。但是 UEFI 兼容固件必須至少能夠?qū)崿F(xiàn)執(zhí)行 EFI 可執(zhí)行文件、讀取 GPT 分區(qū)表、以及讀取 ESP，因此如果你正編寫操作系統(tǒng)或其他東西，并且想要在 UEFI 兼容固件上運(yùn)行的話，你也得遵循 UEFI 規(guī)范，這就是 EFI 系統(tǒng)分區(qū)的概念非常重要的原因：它允許（至少理論上）將 EFI 可執(zhí)行文件放在以 UEFI FAT 格式化且 GPT 分區(qū)類型正確無誤的分區(qū)上，另外，系統(tǒng)固件要能夠讀取該分區(qū)。這種機(jī)制非常嚴(yán)謹(jǐn)，等價(jià)于 BIOS 中的“固件能夠執(zhí)行放置在 MBR 空間中的啟動(dòng)裝載程序代碼”。 UEFI 規(guī)范為我們提供了三大重要基礎(chǔ)，這些重要基礎(chǔ)是上層架構(gòu)正常運(yùn)行的立足之本：
相比 BIOS 固件所提供的功能，UEFI 的功能要豐富得多。但是，為了完成固件層可以處理多重目標(biāo)（而不僅僅是磁盤）啟動(dòng)的愿景，我們需要其他基礎(chǔ)：需要建立一種機(jī)制，通過這種機(jī)制，固件可以查找各種可能的啟動(dòng)目標(biāo)，并提供相應(yīng)的配置方法。 UEFI 啟動(dòng)管理器UEFI 規(guī)范定義了名為 UEFI 啟動(dòng)管理器的一項(xiàng)功能（Linux發(fā)行版包含名為efibootmgr 的工具，可用于更改 UEFI 啟動(dòng)管理器的配置）。如果你確實(shí)閱讀過 UEFI 規(guī)范，那么就會(huì)發(fā)現(xiàn)，UEFI 規(guī)范對(duì) UEFI 啟動(dòng)管理器作出了如下規(guī)定： “UEFI 啟動(dòng)管理器是一種固件策略引擎，可通過修改固件架構(gòu)中定義的全局NVRAM 變量來進(jìn)行配置。啟動(dòng)管理器將嘗試按全局 NVRAM 變量定義的順序依次加載 UEFI 驅(qū)動(dòng)和 UEFI 應(yīng)用程序（包括 UEFI 操作系統(tǒng)啟動(dòng)裝載程序）。” 好，既然已經(jīng)明確了這一概念，那我們就繼續(xù)吧。不，先等等。我來先把那一項(xiàng)規(guī)定解釋清楚，便于理解。簡(jiǎn)單來說，你可以把 UEFI 啟動(dòng)管理器視為啟動(dòng)菜單。在 BIOS 固件上，固件層的“啟動(dòng)菜單”（當(dāng)然）是，啟動(dòng)時(shí)連接到計(jì)算機(jī)的各個(gè)磁盤——不多不少。但是對(duì)于 UEFI 固件而言，情況有所不同。 UEFI 啟動(dòng)管理器可以進(jìn)行配置——簡(jiǎn)言之，你可以向“啟動(dòng)菜單”添加項(xiàng)或者從中刪除項(xiàng)。固件也可以（事實(shí)上， UEFI 規(guī)范也有此要求）根據(jù)連接到計(jì)算機(jī)的磁盤或根據(jù)某些固件配置，在此啟動(dòng)菜單中“生成”有效項(xiàng)。你也可以檢查啟動(dòng)菜單，確保正確無誤。 UEFI 提供了一種非常優(yōu)秀的機(jī)制，可以從上層架構(gòu)執(zhí)行此操作：你可以從已啟動(dòng)的操作系統(tǒng)中配置系統(tǒng)啟動(dòng)行為。如果已通過 UEFI 啟動(dòng) Linux，就可以使用 efibootmgr 工具來完成所有這些操作。Windows 也有相應(yīng)的工具，但是我對(duì) Windows 下的工具非常不熟悉。我們不妨看一些典型的 efibootmgr 輸出，這些是我從 Fedora 論壇轉(zhuǎn)過來的，稍微進(jìn)行了調(diào)整： [root@system 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 . [root@system directory]# 這個(gè)示例非常清晰。我們可以從中觀察細(xì)節(jié)。 第一行表示，目前你從“啟動(dòng)菜單”的哪個(gè)項(xiàng)進(jìn)行了啟動(dòng)。第二行非常明顯（如果固件的 UEFI 啟動(dòng)管理器顯示了類似啟動(dòng)菜單的界面，那么這一行表示繼續(xù)啟動(dòng)默認(rèn)項(xiàng)之前的超時(shí)）。BootOrder 是列表中啟動(dòng)項(xiàng)的嘗試順序。其余輸出顯示了實(shí)際的啟動(dòng)項(xiàng)。我們稍后會(huì)說明每一個(gè)啟動(dòng)項(xiàng)具體作用。 如果完全正常啟動(dòng) UEFI 固件，而不進(jìn)行任何調(diào)整（我們稍后會(huì)討論），UEFI 固件將按照BootOrder 中列出的順序，嘗試從“啟動(dòng)菜單”中的每個(gè)“項(xiàng)”進(jìn)行啟動(dòng)。因此，在這臺(tái)計(jì)算機(jī)上，UEFI 固件將嘗試啟動(dòng)名為“opensuse”的項(xiàng)，如果啟動(dòng)失敗，然后再嘗試啟動(dòng)名為“Fedora”的項(xiàng)，然后再是“CD/DVD Drive”，接著是第二項(xiàng)“Hard Drive”。 UEFI原生啟動(dòng)：實(shí)際工作原理——啟動(dòng)管理器項(xiàng)那么，這些項(xiàng)的實(shí)際含義是什么？實(shí)際上，UEFI 規(guī)范之所以顯得復(fù)雜，很大程度上是因?yàn)槠渲械牟淮_定因素太多。如果你正在閱讀 UEFI 規(guī)范，那么先做好心理準(zhǔn)備，然后前往 EFI_DEVICE_PATH_PROTOCOL 一節(jié)。但是請(qǐng)注意，這個(gè)協(xié)議是通用的，雖然這個(gè)協(xié)議不涉及啟動(dòng)過程，但是有其他作用——這實(shí)際上就是 UEFI 官方的設(shè)備標(biāo)識(shí)方法，這種標(biāo)識(shí)方法可用于啟動(dòng)管理器項(xiàng)以及各種其他用途。出于各種原因，并不是每一種潛在的 EFI 設(shè)備都像 UEFI 啟動(dòng)管理器項(xiàng)一樣起作用（如果你想從視頻適配器啟動(dòng)，很可能不會(huì)成功）。但是啟動(dòng)菜單中顯然可以包含指向 PXE 服務(wù)器（而不是磁盤分區(qū)）的項(xiàng)。UEFI 規(guī)范進(jìn)行了多項(xiàng)規(guī)定，可以向 UEFI 啟動(dòng)管理器配置中添加除磁盤以外的啟動(dòng)目標(biāo)。 但是對(duì)我們而言，只需要考慮連接到計(jì)算機(jī)的一般磁盤即可。既然這樣，我們來討論下可能遇到的三種啟動(dòng)項(xiàng)類型。 BIOS 兼容啟動(dòng)項(xiàng)在本示例中，Boot0000 和 Boot0004 實(shí)際上是 BIOS 兼容模式啟動(dòng)項(xiàng)，而不是原生 UEFI 啟動(dòng)項(xiàng)。這些啟動(dòng)項(xiàng)不是通過外部工具添加到 UEFI 啟動(dòng)管理器配置中的，而是由固件本身生成的——這也是 UEFI 固件實(shí)現(xiàn) BIOS 兼容啟動(dòng)的常見方式，通過生成 UEFI 啟動(dòng)管理器項(xiàng)，可觸發(fā)指定設(shè)備的 BIOS 啟動(dòng)。至于 UEFI 啟動(dòng)管理器如何呈現(xiàn)給用戶，這是另一個(gè)問題，我們稍后討論。根據(jù)具體固件及其配置，其中有些項(xiàng)可能無法顯示。每一項(xiàng)只會(huì)具有一個(gè)名稱（“CD/DVD Drive”、“Hard Drive”），這表示“如果選中此項(xiàng)，那么就以 BIOS 兼容模式啟動(dòng)本磁盤”（其中，對(duì)于 Boot0000，“本磁盤”為 3,0,00，對(duì)于 Boot0004，“本磁盤”為 2,0,00）。 “回退路徑 (Fallback path)”UEFI 原生啟動(dòng)項(xiàng)Boot0001 項(xiàng)（我虛構(gòu)的，實(shí)際操作中可能不存在，這里只是為了舉例說明）用于通知固件嘗試從特定磁盤啟動(dòng)（以 UEFI 模式而不是 BIOS 兼容模式），但是并沒有向固件提供其他信息。它沒有指定磁盤上的具體啟動(dòng)目標(biāo)，而只是讓固件啟動(dòng)磁盤。 UEFI 規(guī)范定義了一種“回退”路徑 (Fallback path)，用于啟動(dòng)此類啟動(dòng)管理器項(xiàng)，其工作原理類似于 BIOS 驅(qū)動(dòng)器啟動(dòng)：它會(huì)在標(biāo)準(zhǔn)位置查找某些啟動(dòng)裝載程序代碼。但是其中的細(xì)節(jié)和 BIOS 不同。 當(dāng)嘗試以這種方式啟動(dòng)時(shí)，固件真正執(zhí)行的操作相當(dāng)簡(jiǎn)單。固件會(huì)遍歷磁盤上的每個(gè) EFI 系統(tǒng)分區(qū)（按照磁盤上的分區(qū)順序）。在 ESP 內(nèi)，固件將查找位于特定位置的具有特定名稱的文件。在 x86-64 PC 上，固件會(huì)查找文件 \EFI\BOOT\BOOTx64.EFI。固件實(shí)際查找的是 \EFI\BOOT\BOOT{計(jì)算機(jī)類型簡(jiǎn)稱}.EFI，其中，“x64”是 x86-64 PC 的“計(jì)算機(jī)類型簡(jiǎn)稱”。文件名還有可能是 BOOTIA32.EFI (x86-32)、BOOTIA64.EFI (Itanium)、BOOTARM.EFI（AArch32，即32位ARM）和 BOOTAA64.EFI（AArch64，即64位ARM）。然后，固件將執(zhí)行找到的第一個(gè)有效文件（當(dāng)然，文件需要符合UEFI規(guī)范中定義的可執(zhí)行格式）。 這種機(jī)制的設(shè)計(jì)目的不在于啟動(dòng)日常使用的操作系統(tǒng)。它的設(shè)計(jì)目的更像是為了啟動(dòng)可熱插拔、與設(shè)備無關(guān)的介質(zhì)（如 Live 映像和操作系統(tǒng)介質(zhì)）。這也是這種機(jī)制的常見用途。如果查看 Linux 或其他操作系統(tǒng)的 UEFI 兼容 Live 或安裝介質(zhì)，你會(huì)發(fā)現(xiàn)其中包含 GPT，以及位于（或靠近）設(shè)備起始位置的 FAT 分區(qū)，該分區(qū)的 GPT 分區(qū)類型標(biāo)識(shí)為 EFI 系統(tǒng)分區(qū)。在那個(gè)分區(qū)中，會(huì)有一個(gè) \EFI\BOOT 目錄，目錄中至少包含上述特殊命名的文件之一。當(dāng)以原生 UEFI 模式啟動(dòng) Fedora Live 或安裝介質(zhì)時(shí)，就會(huì)采用這種機(jī)制。BOOTx64.EFI（或其他）文件將處理剩余啟動(dòng)過程，從而啟動(dòng)介質(zhì)上包含的真正操作系統(tǒng)。 完全原生 UEFI 啟動(dòng)項(xiàng)Boot0002 和 Boot0003 是存儲(chǔ)設(shè)備上所安裝操作系統(tǒng)的“典型”項(xiàng)。這些項(xiàng)顯示了 UEFI 啟動(dòng)機(jī)制的全部?jī)?yōu)勢(shì)，不僅僅是“從此磁盤啟動(dòng)”，而是“啟動(dòng)此特定磁盤上此特定位置中的這一特定啟動(dòng)裝載程序”。 Boot0002 是由原生 UEFI Fedora 安裝生成的啟動(dòng)項(xiàng)。Boot0003 是由原生 UEFI OpenSUSE安裝生成的啟動(dòng)項(xiàng)。按照字面意思，這些啟動(dòng)項(xiàng)表示“從此分區(qū)加載這一文件”。分區(qū)指的是 HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) 這個(gè)東西：表示某一特定分區(qū)（使用 EFI_DEVICE_PATH_PROTOCOL，我不打算對(duì)此進(jìn)行詳細(xì)介紹。如果你通過固件界面和 efibootmgr 與啟動(dòng)管理器進(jìn)行交互，你也不需要知道其中的細(xì)節(jié)）。文件指的是 (\EFI\opensuse\grubx64.efi) 這個(gè)東西：它僅表示“加載所述分區(qū)上此位置中的文件”。這里所指的分區(qū)基本上始終指的就是充當(dāng) EFI 系統(tǒng)分區(qū)的那個(gè)分區(qū)，因此：可以放心地讓固件訪問 EFI 系統(tǒng)分區(qū)。 UEFI 規(guī)范提供這一機(jī)制，以便操作系統(tǒng)可啟動(dòng)：操作系統(tǒng)將啟動(dòng)裝載程序（作用為加載操作系統(tǒng)內(nèi)核等）安裝到 EFI 系統(tǒng)分區(qū)中，并使用某一名稱（顯然，這一名稱通常來源于操作系統(tǒng)名稱）以及啟動(dòng)裝載程序（EFI 可執(zhí)行格式，用于加載操作系統(tǒng)）的位置向 UEFI 啟動(dòng)管理器配置中添加啟動(dòng)項(xiàng)。 Linux發(fā)行版使用 efibootmgr 工具處理 UEFI 啟動(dòng)管理器。進(jìn)行原生 UEFI 安裝時(shí)，有關(guān)啟動(dòng)裝載方面，Linux 發(fā)行版實(shí)際進(jìn)行的操作相當(dāng)簡(jiǎn)單：它會(huì)創(chuàng)建一個(gè) EFI 系統(tǒng)分區(qū)（如果不存在此分區(qū)），使用相應(yīng)配置將 EFI 啟動(dòng)裝載程序（通常為 grub2-efi，但是也有例外）安裝到 EFI 系統(tǒng)分區(qū)中的正確路徑下，然后調(diào)用 efibootmgr 添加相應(yīng)的 UEFI 啟動(dòng)管理器項(xiàng)（指向其啟動(dòng)裝載程序）。如果已存在 EFI 系統(tǒng)分區(qū)，大部分發(fā)行版會(huì)使用現(xiàn)有分區(qū)（盡管完全可以創(chuàng)建新的 EFI 系統(tǒng)分區(qū)并使用這個(gè)新分區(qū)）：我們已經(jīng)提到過，UEFI 是一種寬松規(guī)范，只要在邏輯上遵循其設(shè)計(jì)，那么有多少個(gè) EFI 系統(tǒng)分區(qū)都沒問題。 配置啟動(dòng)過程（固件 UI）上文描述了 UEFI 規(guī)范定義的基本機(jī)制，用于管理 UEFI 啟動(dòng)過程。固件用戶界面可能不會(huì)明確遵循這一機(jī)制，了解這一點(diǎn)非常重要。不幸的是，UEFI 規(guī)范有意未限制啟動(dòng)過程的呈現(xiàn)方式或用戶配置啟動(dòng)過程的方式，這表示——由于我們也從事 固件工程 ——每個(gè)固件會(huì)有不同的實(shí)現(xiàn)方法，并且其中某些固件的實(shí)現(xiàn)方法較瘋狂。 許多固件的啟動(dòng)配置界面較直觀。優(yōu)秀的固件設(shè)計(jì)至少會(huì)顯示啟動(dòng)順序以及其中的各個(gè)啟動(dòng)項(xiàng)，允許用戶添加/刪除項(xiàng)、更改啟動(dòng)順序或在某次特定啟動(dòng)中忽略原有啟動(dòng)順序（僅針對(duì)那次啟動(dòng)生效，或直接讓固件啟動(dòng)特定菜單項(xiàng)，甚至可以選擇讓固件以 BIOS 兼容模式或 UEFI“回退 (Fallback)”模式“啟動(dòng)這塊磁盤”，我的固件就可以這么操作）。此類界面通?？梢詢H按名稱顯示完整的原生 UEFI 啟動(dòng)項(xiàng)（例如我們上文提到的 Fedora 和 OpenSUSE 示例）；你需要檢查 efibootmgr –v 的輸出，以詳細(xì)了解在調(diào)用這些項(xiàng)時(shí)，它們具體會(huì)嘗試并執(zhí)行哪些操作。 某些固件會(huì)嘗試對(duì)配置進(jìn)行抽象和簡(jiǎn)化，最終結(jié)果良莠不齊。例如，如果可以選擇“啟用或禁用”BIOS 兼容模式，固件很有可能會(huì)為已連接驅(qū)動(dòng)器的 UEFI 啟動(dòng)管理器配置添加或刪除 BIOS 兼容項(xiàng)。如果可以選擇“啟用或禁用”原生 UEFI 啟動(dòng)，那么在用戶“禁用”原生 UEFI 啟動(dòng)時(shí)，固件很有可能更改 UEFI 啟動(dòng)管理器配置，從 BootOrder 中刪除所有原生UEFI啟動(dòng)項(xiàng)。 請(qǐng)謹(jǐn)記，固件界面中的所有配置選項(xiàng)所執(zhí)行的操作就是在后臺(tái)配置 UEFI 啟動(dòng)管理器的行為。如果你能理解以上所有內(nèi)容，那么當(dāng)你更改固件界面中的選項(xiàng)時(shí)，你會(huì)更容易理解其背后的本質(zhì)。 在 BIOS 中，系統(tǒng)不會(huì)始終嘗試優(yōu)先從可移動(dòng)驅(qū)動(dòng)器（CD、USB）進(jìn)行啟動(dòng)，然后再從驅(qū)動(dòng)器啟動(dòng)。根據(jù)實(shí)際情況，結(jié)果可能有所不同。有些 BIOS 固件會(huì)優(yōu)先嘗試從 CD 啟動(dòng)，然后再嘗試從硬盤啟動(dòng)（而不是 USB）。試圖安裝新的操作系統(tǒng)時(shí)，用戶已習(xí)慣于時(shí)常檢查 BIOS 配置，以確保啟動(dòng)順序“正確無誤”。 UEFI 也是如此，但是由于 UEFI 啟動(dòng)管理器機(jī)制的靈活性/復(fù)雜性，這一過程看起來可能顯得陌生而可怕。 在系統(tǒng)嘗試啟動(dòng)固定啟動(dòng)項(xiàng)之前，如果想要確保系統(tǒng)使用“回退(Fallback)”機(jī)制優(yōu)先從可移動(dòng)設(shè)備啟動(dòng)（例如，在安裝 Fedora 時(shí)），需要將可移動(dòng)設(shè)備作為固件的默認(rèn)啟動(dòng)項(xiàng)，或需要相應(yīng)設(shè)置固件。根據(jù)具體固件界面，可能發(fā)現(xiàn)每個(gè)連接的可移動(dòng)設(shè)備都有對(duì)應(yīng)的“菜單項(xiàng)”，你只需要調(diào)整啟動(dòng)順序，把你想要的可移動(dòng)設(shè)備放在首位即可，有時(shí)候你也會(huì)發(fā)現(xiàn)可以直接請(qǐng)求“對(duì)此特定磁盤進(jìn)行 UEFI 恢復(fù)啟動(dòng)”，另外你還可能發(fā)現(xiàn)固件會(huì)嘗試將配置進(jìn)行抽象。我們不知道具體的固件界面是什么樣，因此難以編寫說明。但是既然你已了解背后的工作原理，那么就可能更容易理解固件用戶界面配置的含義。 配置啟動(dòng)過程（通過操作系統(tǒng)）如上所述，與 BIOS 機(jī)制不同，你可以從操作系統(tǒng)層面配置 UEFI 啟動(dòng)過程。如果你的固件比較令人惡心，你可能需要執(zhí)行此操作才能達(dá)成目的。 你可以使用之前提過的 efibootmgr 工具來添加、刪除和修改 UEFI 啟動(dòng)管理器配置中的項(xiàng)，這一工具也具有其他豐富功能。你可以更改啟動(dòng)順序。你可以更改下次啟動(dòng)時(shí)的首要啟動(dòng)項(xiàng)，而不需要使用 BootOrder 列表（如果你或其他某些工具已經(jīng)進(jìn)行過配置，efibootmgr –v 的輸出將包括 BootNext 項(xiàng)，說明下一次啟動(dòng)將加載的菜單項(xiàng)）。Windows 下也有類似的工具。因此如果你難以從固件界面配置 UEFI 啟動(dòng)，但是你可以啟動(dòng)某種原生 UEFI 操作系統(tǒng)，那么你可以考慮從操作系統(tǒng)（而不是固件 UI）進(jìn)行啟動(dòng)配置。 結(jié)論：
在 UEFI 計(jì)算機(jī)上安裝操作系統(tǒng)我們快速瀏覽下上文中與在 UEFI 計(jì)算機(jī)上安裝操作系統(tǒng)相關(guān)的具體結(jié)果。 原生 UEFI 啟動(dòng)和 BIOS 兼容啟動(dòng)用戶有時(shí)會(huì)忽略以下事項(xiàng)：
這適用于（現(xiàn)在暫時(shí)忽略其中的無關(guān)警告）我接觸過的所有操作系統(tǒng)。因此你可能確實(shí)想了解，如何在固件層選擇以原生 UEFI 模式啟動(dòng)可移動(dòng)設(shè)備，以及如何在固件層選擇以 BIOS 兼容模式啟動(dòng)可移動(dòng)設(shè)備，確保在安裝時(shí)可以隨意選擇需要使用的模式。 如果以 BIOS 兼容模式啟動(dòng)安裝介質(zhì)，那么你絕對(duì)無法成功進(jìn)行操作系統(tǒng)的原生 UEFI 安裝，因?yàn)榘惭b程序無法配置 UEFI 啟動(dòng)管理器（除非以原生 UEFI 模式啟動(dòng)安裝介質(zhì)）。 理論上，在以原生 UEFI 模式啟動(dòng)之后，操作系統(tǒng)的安裝程序可通過 BIOS 模式安裝該操作系統(tǒng)，即，將啟動(dòng)裝載程序?qū)懭氪疟P MBR，但是大部分安裝程序無法執(zhí)行此操作，這種做法比較可取。 確定啟動(dòng)模式有時(shí)候，在啟動(dòng)操作系統(tǒng)安裝程序之后，你不確定啟動(dòng)模式為原生 UEFI 模式還是 BIOS 兼容模式。別擔(dān)心。有幾種簡(jiǎn)單方法可以確定啟動(dòng)模式。最簡(jiǎn)單的方法之一是嘗試讀取 UEFI 啟動(dòng)管理器。如果你啟動(dòng)了 Linux 安裝程序或環(huán)境，并且可以運(yùn)行 shell（例如，在 Fedora 安裝程序中是 Ctrl-Alt-F2），請(qǐng)運(yùn)行 efibootmgr –v。如果你啟動(dòng)的是原生 UEFI 模式，那么就可以看到上文所示的 UEFI啟動(dòng)管理器配置。如果你啟動(dòng)的是 BIOS 兼容模式，那么會(huì)看到類似以下內(nèi)容： Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables. Try 'modprobe efivars' as root. 如果啟動(dòng)了其他操作系統(tǒng)，你可以嘗試運(yùn)行該操作系統(tǒng)的內(nèi)置實(shí)用程序，讀取 UEFI 啟動(dòng)管理器，并查看是否顯示了明確輸出或類似錯(cuò)誤?；蛘吣憧梢詸z查系統(tǒng)日志并搜索“efi”和/或“uefi”，從中可能發(fā)現(xiàn)蛛絲馬跡。 啟用原生 UEFI 啟動(dòng)若要啟用原生 UEFI 模式的啟動(dòng)，那么操作系統(tǒng)安裝介質(zhì)必須明確符合我們剛剛說明的所有規(guī)范：具有 GUID 分區(qū)表，和 EFI 系統(tǒng)分區(qū)，啟動(dòng)裝載程序位于正確的“回退”路徑 (Fallback path) 中—\EFI\BOOT\BOOTx64.EFI（其他平臺(tái)可能會(huì)有其他名稱）。如果無法以原生 UEFI 模式啟動(dòng)安裝介質(zhì)，并且無法查出原因，那么請(qǐng)檢查安裝介質(zhì)是否滿足上述條件。顯然，當(dāng)使用 livecd-iso-to-disk 工具將 Fedora 映像寫入 USB 存儲(chǔ)器時(shí)，你必須傳遞 –efi 參數(shù)，才能將存儲(chǔ)器配置為可用 UEFI 模式啟動(dòng)。 強(qiáng)制使用 BIOS 兼容啟動(dòng)如果你的固件難以通過 BIOS 兼容模式從可移動(dòng)介質(zhì)啟動(dòng)，但是你又確實(shí)想通過這種方式啟動(dòng)，那么可以使用一些小把戲：完全禁用該介質(zhì)的原生 UEFI 啟動(dòng)模式。可以通過清除所有 EFI 系統(tǒng)分區(qū)來輕松執(zhí)行此操作（或者，如果使用 livecd-iso-to-disk 從 Fedora 映像創(chuàng)建 USB存儲(chǔ)器，那么只需去掉 –efi 參數(shù)，存儲(chǔ)器就會(huì)變?yōu)椴豢赏ㄟ^ UEFI 模式啟動(dòng)）。如果執(zhí)行完此操作以后，你的固件仍然無法以 BIOS 兼容模式啟動(dòng)介質(zhì)，那么就去吐槽你的固件供應(yīng)商吧（如果還沒吐槽過）。 磁盤格式（MBR vs. GPT）其他注意事項(xiàng)如下：
當(dāng)然，為了給用戶找不自在，許多固件可以通過 BIOS 模式從 GPT 格式的磁盤啟動(dòng)。事實(shí)上，從技術(shù)層面而言，也要求 UEFI 固件能從 MBR 格式的磁盤以 UEFI 模式啟動(dòng)（雖然無法保證）。但是你應(yīng)當(dāng)盡可能避免這種情況。這些注意事項(xiàng)非常重要，因?yàn)樵S多用戶都曾深受其害。例如，以原生 UEFI 模式啟動(dòng)操作系統(tǒng)安裝程序，然后試圖直接安裝到 MBR 格式的磁盤是非常不明智的。很有可能失敗。多數(shù)現(xiàn)代操作系統(tǒng)安裝程序?qū)汛疟P自動(dòng)重新格式化為正確格式（如果你允許安裝程序徹底清除磁盤數(shù)據(jù)），但是，如果你嘗試讓安裝程序“對(duì)此 MBR 格式的磁盤執(zhí)行原生 UEFI 安裝，并且不要重新格式化這塊磁盤，因?yàn)樯厦嬗兄匾獢?shù)據(jù)”，那么就很有可能失敗，盡管技術(shù)層面而言，UEFI 規(guī)范提到了這種配置。具體而言，至少 Windows 和 Fedora 會(huì)明確禁止這種配置。 檢查磁盤格式你可以使用 parted 實(shí)用程序檢查給定磁盤的格式： [adamw@adam 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 格式的磁盤，會(huì)顯示 gpt。你可以從 parted 中通過執(zhí)行 mklabel gpt 或 mklabel msdos 將磁盤重新格式化為其他類型分區(qū)表。這會(huì)破壞磁盤內(nèi)容。 對(duì)于多數(shù)操作系統(tǒng)的安裝程序而言，如果你采用的磁盤配置會(huì)清空目標(biāo)磁盤的所有內(nèi)容，那么根據(jù)執(zhí)行的安裝類型，安裝程序就會(huì)自動(dòng)使用最合適的配置重新格式化磁盤。但是如果你想使用現(xiàn)有磁盤而不格式化，那么你需要檢查該磁盤的格式并三思而后行。 執(zhí)行手動(dòng)分區(qū)時(shí)處理 EFI 系統(tǒng)分區(qū)我只能針對(duì) Fedora 給出權(quán)威建議，但是其中的主要內(nèi)容可能也適用于其他發(fā)行版/操作系統(tǒng)。 執(zhí)行原生 UEFI 安裝，并且采用 GPT 格式的磁盤時(shí)，或者允許 Fedora 重新格式化磁盤（通過刪除所有現(xiàn)有分區(qū)）時(shí)，如果允許 Fedora 自動(dòng)處理分區(qū)，那么 Fedora 就會(huì)自動(dòng)處理 EFI 系統(tǒng)分區(qū)。 但是，如果使用自定義分區(qū)，F(xiàn)edora 會(huì)要求指定 EFI 系統(tǒng)分區(qū)，以供安裝程序使用。如果不執(zhí)行此步驟，安裝程序會(huì)報(bào)錯(cuò)（錯(cuò)誤消息的含義不明）并拒絕啟動(dòng)安裝。 因此，如果執(zhí)行原生 UEFI 安裝并使用自定義分區(qū)，需要確保類型為“EFI 系統(tǒng)分區(qū)”的分區(qū)已掛載到 /boot/efi（這是 Fedora 查找 EFI 系統(tǒng)分區(qū)的路徑）。如果系統(tǒng)上存在現(xiàn)有 EFI 系統(tǒng)分區(qū)，那么僅需將其掛載點(diǎn)設(shè)置為 /boot/efi 即可。如果還沒有 EFI 系統(tǒng)分區(qū)，那么請(qǐng)創(chuàng)建一個(gè)分區(qū)，將其類型設(shè)置為 EFI 系統(tǒng)分區(qū)，大小至少為 200MB（建議 500MB），然后將其掛載點(diǎn)設(shè)置為 /boot/efi。 具體示例總結(jié)：如果購買了 Windows 8 或更高版本的操作系統(tǒng)，那么你的 Windows 基本上肯定是通過原生 UEFI 安裝到 GPT 格式磁盤的。這表示如果你想安裝其他操作系統(tǒng)，并與 Windows 共存，那么需要通過原生 UEFI 方式安裝操作系統(tǒng)。如果你不喜歡 UEFI，并且想要用回老掉牙的 BIOS，那么恐怕就得清空整個(gè)原生 UEFI 的 Windows，而且需要重新將磁盤格式化為 MBR。 缺陷上文解釋了 UEFI 的啟動(dòng)原理(至少解釋得差不多了)。我這種描述方法應(yīng)該還可以吧？ 但是，UEFI 并不完美，也有許多問題。 細(xì)心的讀者可能已經(jīng)留意，我曾經(jīng)提到過，UEFI 規(guī)范提供了一種機(jī)制。這種說法很嚴(yán)謹(jǐn)，也很重要。由于 UEFI 規(guī)范是一種“廣泛共識(shí)”，因此其主要缺點(diǎn)之一（就特定方面而言）是并未提供具體實(shí)現(xiàn)。 如果仔細(xì)閱讀 UEFI 規(guī)范，就會(huì)發(fā)現(xiàn) UEFI 規(guī)范的基本方式是定義 UEFI 兼容固件必須支持的一系列功能。但是 UEFI 規(guī)范并沒有嚴(yán)格規(guī)定這些功能的具體實(shí)現(xiàn)方法。 因此，UEFI 規(guī)范只要求系統(tǒng)固件必須遵循其中描述的所有內(nèi)容，以便滿足 UEFI 兼容固件的要求。但是，規(guī)范本身未規(guī)定操作系統(tǒng)“應(yīng)該”或“必須”怎么做，并且 UEFI 規(guī)范也沒有規(guī)定固件不得支持（或者不期望支持）的功能。換言之，在制定 UEFI 固件時(shí)，需要支持 GPT 格式的磁盤和 FAT 格式的 EFI 系統(tǒng)分區(qū)，并且必須以標(biāo)準(zhǔn)格式讀取 UEFI 啟動(dòng)管理器項(xiàng)等等——但是也可以隨意添加其他未規(guī)定的功能。 從 UEFI 規(guī)范中不難發(fā)現(xiàn)其中的隱喻——UEFI 規(guī)范仔細(xì)設(shè)置了一種良好機(jī)制，用于在固件層處理操作系統(tǒng)（或其他啟動(dòng)項(xiàng)）選擇。但是 UEFI 規(guī)范并不要求一定要這么做，其他廣受贊譽(yù)的規(guī)范也沒有類似規(guī)定。 因此，在實(shí)際使用時(shí)，我們可能遇到各種復(fù)雜情況。例如，Apple Mac 的 HFS+ 分區(qū)中隨附了某些啟動(dòng)裝載程序。UEFI 規(guī)范提到，UEFI 兼容固件必須支持特定 GPT 分區(qū)類型的 UEFI FAT 分區(qū)（標(biāo)識(shí)為“EFI 系統(tǒng)分區(qū)”），但是 UEFI 規(guī)范并沒有提到固件不能識(shí)別其他文件系統(tǒng)類型并從中加載啟動(dòng)裝載程序。（此類分區(qū)是否應(yīng)視為“EFI 系統(tǒng)分區(qū)”，這很難回答，在此不做探討。） 要是所有廠商都能按照 UEFI 規(guī)范嚴(yán)格使用 EFI 系統(tǒng)分區(qū)，那就不會(huì)有這么多問題了。但是 Apple 畢竟是 Apple，它的產(chǎn)品設(shè)計(jì)領(lǐng)先于其他廠商，率先設(shè)計(jì)出了可以從 HFS+ 分區(qū)讀取和加載代碼的固件，導(dǎo)致現(xiàn)在其他廠商不得不緊隨 Apple 的腳步，除非他們不打算支持 Mac。在啟動(dòng)過程設(shè)計(jì)中，Apple 進(jìn)行的工作遠(yuǎn)超出 UEFI 規(guī)范的范圍，因此，如果你想讓其他操作系統(tǒng)以美觀的圖標(biāo)或其他形式顯示在 Mac 的圖形啟動(dòng)菜單上，你所要做的操作將超出 UEFI 規(guī)范的建議范圍。 還有各種類似的極端狀況，使人煩不勝煩，但是我們先不管了。這篇文章夠長(zhǎng)的了。 另外，就像之前提到過的，UEFI 規(guī)范并沒有對(duì)機(jī)制的具體呈現(xiàn)方式進(jìn)行約束。因此，如果一些軟件公司設(shè)計(jì)的操作系統(tǒng)符合 UEFI 規(guī)范，并且可以安裝 EFI 啟動(dòng)裝載程序，并明確命名 EFI 啟動(dòng)管理器項(xiàng)（例如，F(xiàn)edora 和 Windows），那么如果要向用戶提供某種相對(duì)辨識(shí)度較高的漂亮界面，讓用戶可以從中選擇啟動(dòng) Windows 或 Fedora，就得看固件本身設(shè)計(jì)得怎么樣。固件設(shè)計(jì)得越糟糕，操作系統(tǒng)工程師就越不會(huì)遵守 UEFI 規(guī)范，他們?cè)娇赡茉诠碳由狭砥馉t灶。 說句公道話，我們可以在操作系統(tǒng)層實(shí)現(xiàn)更多功能。我們可以用更整潔直觀的方式實(shí)現(xiàn) efibootmgr 的所有功能——例如，我們可以采用“無視下一次啟動(dòng)時(shí)的啟動(dòng)順序，直接啟動(dòng)此項(xiàng)”，同時(shí)將“重新啟動(dòng)到 Windows”作為選項(xiàng)之一。如果開發(fā)人員能夠用更直觀的方式展現(xiàn) efibootmgr 的所有功能，那將會(huì)非常不錯(cuò)。Windows 8 系統(tǒng)在一定程度上采用了這種方式——例如，用戶可以從 Windows 8 設(shè)置菜單中將系統(tǒng)重新啟動(dòng)到固件 UI。但是這還不夠。 這些實(shí)在令人欲哭無淚，因?yàn)?UEFI 本來可以更好地進(jìn)行統(tǒng)一。對(duì)于多重啟動(dòng)，BIOS 不提供任何類型的規(guī)范或標(biāo)準(zhǔn)，因此完全需要在固件層上處理多重啟動(dòng)。我們（這一產(chǎn)業(yè)）已經(jīng)提出了某種處理多重啟動(dòng)的規(guī)范，但是我們從未將其付諸實(shí)施，因此最終不了了之。而每種操作系統(tǒng)都采用自己的多重啟動(dòng)方法，大量開發(fā)人員也自己寫了啟動(dòng)裝載程序，試圖包攬所有操作系統(tǒng)。而所有操作系統(tǒng)和獨(dú)立的啟動(dòng)裝載程序難以互相兼容。我想說的是，在 UEFI 誕生之前，多重啟動(dòng)的實(shí)現(xiàn)方式一團(tuán)混亂。 如果 UEFI——或者基于 UEFI 的某種規(guī)范——要求所有廠商遵循 UEFI 提出的規(guī)范，并要求固件提供直觀的用戶界面，那將會(huì)終結(jié)現(xiàn)階段的混亂情況。但是現(xiàn)實(shí)不如人意，因此 UEFI 的情況完全可能比 BIOS 更糟糕。如果大量固件沒有為 UEFI 啟動(dòng)管理器機(jī)制提供良好的 UI，那么操作系統(tǒng)供應(yīng)商可能放棄 UEFI 啟動(dòng)管理器機(jī)制（或選擇性地進(jìn)行支持），轉(zhuǎn)而在 UEFI 中重現(xiàn) BIOS 多重啟動(dòng)的混亂情況——如此一來，我們就得收拾所有爛攤子，外加 UEFI 啟動(dòng)管理器層的其他影響。在整個(gè) UEFI 啟動(dòng)管理器機(jī)制上，用戶可能裝有多個(gè)啟動(dòng)裝載程序，互相爭(zhēng)搶裝載多個(gè)操作系統(tǒng)的控制權(quán)，而 UEFI 啟動(dòng)管理器機(jī)制只會(huì)機(jī)械地處理各種變量，而無法解決這種混亂情況。 這不是某人靈光閃現(xiàn)的荒唐想法，而是可能實(shí)際發(fā)生的真實(shí)情形。 另外，在這方面產(chǎn)生的 UEFI 缺陷是由一時(shí)疏忽引起的——這些缺陷不受委員會(huì)控制，也不是某人故意為之的結(jié)果。如果你的系統(tǒng)固件很坑爹，無法讓你輕松訪問 UEFI 啟動(dòng)管理器，那么你的發(fā)泄對(duì)象不應(yīng)該是 UEFI 論壇或微軟，當(dāng)然也不是 Fedora 或者我。你應(yīng)該歸咎于系統(tǒng)/主板制造商和他們雇用的傻逼固件開發(fā)人員。凡是大腦健全的人，都能看出來，UEFI 規(guī)范已經(jīng)明確說明，為 UEFI 啟動(dòng)管理器提供某種直觀的用戶界面是非常有益的，所有反人類的固件都是一堆垃圾代碼。的確，UEFI 論壇已經(jīng)意識(shí)到固件工程師難以脫離現(xiàn)有約束重新學(xué)習(xí)新規(guī)范，但是，固件工程師最終還是應(yīng)該與時(shí)俱進(jìn)。 簡(jiǎn)單來說，“所有固件都是垃圾代碼”。這句話通常非常準(zhǔn)確。 安全啟動(dòng) (Secure Boot)我們最后要介紹的，就是安全啟動(dòng) (Secure Boot)。 安全啟動(dòng) (Secure Boot) 并不神奇，也不復(fù)雜。才怪。安全啟動(dòng) (Secure Boot) 復(fù)雜得要命，但是其理論并不復(fù)雜。安全啟動(dòng) (Secure Boot) 本身也并不邪惡。事實(shí)就是如此，你也應(yīng)當(dāng)認(rèn)同這一事實(shí)，除非你認(rèn)為GPG也有惡意。 在 UEFI 規(guī)范（2.4A 版本）的第 28 章對(duì)安全啟動(dòng) (Secure Boot) 進(jìn)行了定義。這種機(jī)制事實(shí)上非常明智。但是其原理卻非常簡(jiǎn)單。UEFI 規(guī)范規(guī)定固件可以包含一系列簽名，并拒絕運(yùn)行未簽名或簽名與固件中包含的簽名不一致的 EFI 可執(zhí)行文件。 就這么簡(jiǎn)單?當(dāng)然不是了，這只是一種簡(jiǎn)單概括。安全問題很復(fù)雜，因此才會(huì)產(chǎn)生通過安全啟動(dòng) (Secure Boot) 來實(shí)現(xiàn)真正安全啟動(dòng)鏈的各種方法。mjg59 可以進(jìn)行詳細(xì)介紹，或者你可以完整閱讀第 28 章。但是其中只涉及了基本概念。 使用公開密鑰加密來驗(yàn)證某個(gè)文件完整性的方法很難判斷其好壞。幾乎所有 Linux 發(fā)行版都依賴這種加密方法——我們?yōu)檐浖灻?，在嘗試安裝未使用我們的密鑰之一簽名的軟件包時(shí)，軟件包管理器將發(fā)出警告。這不是我們的錯(cuò)，我也不認(rèn)為會(huì)有人因?yàn)橐赃@種方式使用公開密鑰加密進(jìn)行簽名而歸咎于操作系統(tǒng)本身。從字面上看，安全啟動(dòng) (Secure Boot) 與這種廣泛認(rèn)可的機(jī)制完全相同，只不過安全啟動(dòng) (Secure Boot) 適用于啟動(dòng)鏈。由于一撮媒體人找錯(cuò)了槽點(diǎn)，并揪著不放，導(dǎo)致大眾受到了廣泛誤導(dǎo)，認(rèn)為安全啟動(dòng) (Secure Boot) 是洪水猛獸。 UEFI 規(guī)范中定義的安全啟動(dòng) (Secure Boot) 并沒有對(duì)固件所信任的密鑰形式及其來源作出規(guī)定，我也不打算介紹所有細(xì)節(jié)，因?yàn)檫^于枯燥乏味，而且本文已經(jīng)挺長(zhǎng)了。但是總的來說，UEFI 規(guī)范只對(duì)執(zhí)行啟動(dòng)鏈的加密驗(yàn)證進(jìn)行了定義。UEFI 規(guī)范甚至沒有涉及用于執(zhí)行這一過程的策略可能產(chǎn)生的問題。這本來并沒有錯(cuò)，因?yàn)檫@樣可以保證其靈活性，并且 UEFI 規(guī)范允許在多個(gè)層面配置涉及的所有機(jī)制。UEFI 規(guī)范中未提及微軟，也沒有和微軟互相勾結(jié)。如果你不信，那么你可以閱讀 UEFI 規(guī)范。我已經(jīng)提供了所有說明。字面上來說，對(duì)于那些反對(duì)在固件規(guī)范中將啟動(dòng)裝載程序加密驗(yàn)證機(jī)制作為可選功能的人，我不予置評(píng)。 實(shí)際使用安全啟動(dòng) (Secure Boot)有關(guān)安全啟動(dòng) (Secure Boot) 的所有不滿并不針對(duì)安全啟動(dòng) (Secure Boot) 機(jī)制本身——雖然發(fā)出這些不滿的人可能不這么認(rèn)為——而是針對(duì)安全啟動(dòng) (Secure Boot) 在實(shí)際操作中的特定實(shí)現(xiàn)方式。 我們唯一在意的是，對(duì)于預(yù)裝 Windows 8 或更高版本 Windows 的 PC 而言，安全啟動(dòng) (Secure Boot) 是默認(rèn)開啟的。 微軟將這些稱為“Windows 硬件認(rèn)證要求”。這些要求并不是什么絕密內(nèi)容，所有人都可以在互聯(lián)網(wǎng)上閱讀。 如果想從微軟那里以低廉的價(jià)格獲得預(yù)裝 Windows 的批量許可，并在機(jī)箱上貼有“微軟認(rèn)證”標(biāo)簽，那么你必須符合這些認(rèn)證要求。微軟的約束力有限：他們不是美國或其他國家/地區(qū)的法律制定者，無論其他人怎么想。即使你銷售的 PC 不符合這些要求，比爾·蓋茨也不會(huì)拿你怎么樣，前提是你不需要預(yù)裝廉價(jià)的 Windows 副本和那張“微軟認(rèn)證”標(biāo)簽。對(duì)于不符合微軟許可計(jì)劃的在售 PC，事實(shí)上并不要求如何配置安全啟動(dòng) (Secure Boot)，甚至根本不需要提供安全啟動(dòng) (Secure Boot) 功能。具有 UEFI 2.2 或更高版本兼容固件的 PC 必須提供安全啟動(dòng) (Secure Boot) 功能，但是并沒有規(guī)定具體的實(shí)現(xiàn)方法（包括關(guān)閉安全啟動(dòng) (Secure Boot) 的方法）。 如果你對(duì)安全啟動(dòng) (Secure Boot) 意見很大，那么就別找借口了，馬上去讀讀微軟認(rèn)證要求吧（http://msdn.microsoft.com/en-us/library/windows/hardware/dn423132.aspx）。你可以搜索“Secure Boot”來閱讀相關(guān)內(nèi)容。從“System.Fundamentals.Firmware.UEFISecureBoot”一節(jié)開始。 你最好讀一遍，但是我對(duì)其內(nèi)容進(jìn)行了總結(jié)。 符合微軟認(rèn)證要求的計(jì)算機(jī)必須滿足以下條件：
符合微軟認(rèn)證要求的 x86 計(jì)算機(jī) 還必須滿足以下附加條件：
符合微軟認(rèn)證要求的 ARM 計(jì)算機(jī) 還必須滿足以下附加條件：
是的，你沒看錯(cuò)。對(duì)于 x86 計(jì)算機(jī)，微軟認(rèn)證要求明確規(guī)定了自然人用戶應(yīng)當(dāng)能夠完全控制安全啟動(dòng) (Secure Boot)（啟用或禁用），或完全控制安全啟動(dòng) (Secure Boot) 的信任密鑰列表。另一個(gè)重點(diǎn)是，盡管認(rèn)證要求規(guī)定，信任密鑰列表必須包括微軟的密鑰，但是其中沒有規(guī)定不允許包括其他密鑰。微軟認(rèn)證要求也明確允許系統(tǒng)包含其他任意數(shù)量的信任密鑰。 這些要求并不完全出于微軟的好意，之所以作出這些規(guī)定，是因?yàn)槿绻贿@么做的話，微軟將面臨大量訴訟2。真正了解 UEFI 和安全啟動(dòng) (Secure Boot) 的用戶可能不會(huì)曲解微軟認(rèn)證要求，這些要求非常清晰明確。這些要求旨在確保認(rèn)證系統(tǒng)的所有者能完全控制安全啟動(dòng) (Secure Boot)，事實(shí)上這些要求也確實(shí)成功確保了這一條件。 如果你有包含 Windows 認(rèn)證的 x86 系統(tǒng)，但是不允許你禁用安全啟動(dòng) (Secure Boot)，那么這就直接違反了認(rèn)證要求，你應(yīng)該馬上投訴。如果市面上存在大量這類系統(tǒng)，那么我們肯定會(huì)有麻煩，可能要給那些巨頭廠商提起訴訟了。但是目前為止，事實(shí)并非如此。在我見過的所有 x86 Windows 認(rèn)證系統(tǒng)中，其固件都有“禁用安全啟動(dòng) (Secure Boot)”選項(xiàng)。 對(duì)于 ARM 計(jì)算機(jī)，認(rèn)證要求顯然更變態(tài)：其中的規(guī)定和 x86 完全相反，不允許禁用安全啟動(dòng) (Secure Boot)，也不允許系統(tǒng)所有者更改信任密鑰。非常糟糕且不合理。這使得微軟認(rèn)證 ARM 系統(tǒng)成為了一個(gè)封閉的環(huán)境。值得注意的是，其他主要 ARM 平臺(tái)甚至更糟糕。Apple 在所有 iDevice 上鎖定了啟動(dòng)裝載程序，而且大部分 Android 設(shè)備的啟動(dòng)裝載程序也是鎖定的。 如果你計(jì)劃購買微軟認(rèn)證 ARM 設(shè)備，請(qǐng)注意這一問題，你將無法控制設(shè)備上的啟動(dòng)項(xiàng)。如果你對(duì)此反感，那就不要購買這樣的設(shè)備，也不要購買 iDevice 或啟動(dòng)裝載程序處于鎖定狀態(tài)的 Android 設(shè)備（你可以購買啟動(dòng)裝載程序未鎖定或無法鎖定的 Android 設(shè)備，但是需要事先進(jìn)行調(diào)查研究）。 目前，就 x86 設(shè)備本身而言，微軟的認(rèn)證要求實(shí)際上明確保障了用戶自由啟動(dòng)系統(tǒng)的權(quán)利。這是件好事。 建議以下內(nèi)容是我在管理系統(tǒng)啟動(dòng)方面的一般建議，不保證其準(zhǔn)確性、可靠性或安全性。
1. 這一整節(jié)都是簡(jiǎn)化過的內(nèi)容——當(dāng)啟動(dòng)已安裝的操作系統(tǒng)時(shí)，無論啟動(dòng)裝載程序是否安裝在“ESP”上，對(duì)固件都沒有影響；固件只會(huì)讀取啟動(dòng)管理器項(xiàng)，然后嘗試訪問特定分區(qū)并執(zhí)行特定可執(zhí)行文件，具體請(qǐng)參閱 pjones 的說明。但是一般會(huì)使用 ESP 來進(jìn)行啟動(dòng)過程，因?yàn)?UEFI 規(guī)范中有相應(yīng)規(guī)定，而且這個(gè)分區(qū)也很方便，固件可以讀取其文件系統(tǒng)。理論上來說，在固件執(zhí)行可移動(dòng)介質(zhì)/回退路徑 (Fallback path) 啟動(dòng)時(shí)，ESP 將不起作用。 2. 注意，這只是我的個(gè)人推斷。在整個(gè)規(guī)范的制定過程中，我都沒有參與，也沒人告訴我這些內(nèi)容。但是根據(jù)已知事實(shí)，明顯可以得出這一推斷。 |
|
|
