正常引導 UEFI 機器
常規 UEFI 引導有多個列表。每個列表包含能夠引導的多個操作系統入口條目，列表存儲在 UEFI 配置變量裏（通常在 NVRAM 裏），引導順序的配置變量與它們一起存儲。它允許多個不同的引導選項，以及正確定義的備選引導順序。在很多場景下，您甚至可以從系統引導菜單（類似於很多 BIOS 中實現的引導設備菜單）中列出並選擇要使用的操作系統/引導加載程序。不幸的是，許多 PC UEFI 實現把這些功能都搞錯了，所以不能正常工作。
從本地磁盤引導時，正確的工作方式是讓引導變量指向
\EFI\$vendor\$bootloader.efi
.efi 文件在 EFI 系統分區（ESP，EFI System Partition）上。ESP 是一種特殊標記的分區，通常用FAT32格式化。
Debian 爲其 efi 引導裝載程序安裝 grub-efi，如下所示：
| 架構 |
路徑 |
| amd64 |
\EFI\debian\grubx64.efi |
| i386 |
\EFI\debian\grubia32.efi |
| arm64 |
\EFI\debian\grubaa64.efi |
| armhf |
\EFI\debian\grubarm.efi |
這裏 GRUB 的每個版本都包含了 GRUB 從那個點位工作所需的所有代碼和配置。
通過像 \EFI\$vendor\ 這樣使用獨立的供應商目錄，UEFI 允許供應商之間完全的互操作性。如果固件開發者有能力就好了... :-( 有些實現完全忽略了引導順序，有些實現過濾了引導順序，只運行自稱是“Windows”的東西，等等。請參閱下面的提示，瞭解如何解決 UEFI 實現中的一些已知錯誤。
從可移動介質引導
ESP 裏如果沒有引導變量指向引導加載程序，或者如果用戶恰當的指定了系統，它也會在某些特定的路徑中尋找引導加載程序。在每個設備上，它將尋找 FAT32 文件系統。在每個文件中，它將查找一個專門命名的引導加載程序文件，同樣，每個體系結構有不同的名稱：
| 架構 |
路徑 |
| amd64 |
\EFI\boot\bootx64.efi |
| i386 |
\EFI\boot\bootia32.efi |
| arm64 |
\EFI\boot\bootaa64.efi |
| armhf |
\EFI\boot\bootarm.efi |
不同的名字是有意的——它允許一個磁盤或 CD 包含多個體繫結構的引導文件，而沒有衝突。
在 Debian 安裝介質上，這些文件中的每一個都是 grub-efi 的副本，具有足夠的內置代碼和配置，可以從那裏找到系統的其餘部分。
debian-installer 支持
debian-installer 對 UEFI 的支持主要包含在兩個模塊中。
首先是 partman-efi 模塊，如果 d-i 識別出它已經在 UEFI 模式下啓動，它將自動加載。partman-efi 可以處理 MS-DOS 和 GPT 分區磁盤，但是在還沒有分區的磁盤上優先使用 GPT。如果有必要，它知道如何用適當的分區類型和文件系統來設置 ESP，並且將確保它在以後被正確地掛載到已安裝的系統上。如果系統已經有一個 ESP，partman-efi 將嘗試使用它，而不是創建一個新的。這是爲了在雙引導系統中與現有操作系統的互操作性。
一旦正常的安裝過程完成，支持 UEFI 的第二個主要組件開始發揮作用：grub-installer。它會將 grub-efi 引導加載程序安裝到 ESP 中的正確位置，並使用 efibootmgr 向固件註冊該引導加載程序。在正常工作的系統上，這應該不需要任何用戶交互就能工作。這個模塊會自動找到 ESP 並把它的文件安裝在正確的位置，不會留下空間導致混淆引導文件保存位置（MBR/MS-DOS系統可能會發生這種情況）。
Wheezy（7.0，2013年5月發佈）中增加了使 UEFI amd64 系統可以直接安裝在 Debian 中的初始支持。後來爲 Jessie（8.0，2015年4月發佈）添加了對 i386 和arm64 系統的支持，以及許多奇怪的問題和錯誤解決方法。關於這些的更多細節見下文。Buster 中增加了對 armhf 的支持（10.0，2019年7月發佈）。
Debian 和 Debian-Installer 中的怪癖、變通方法和特殊 UEFI 特性
在 Wheezy（7.0，2013年5月發佈）中爲 amd64 添加了對 UEFI 安裝的初始支持。這適用於很多用戶，但是不同的用戶報告了問題。其中大部分不是 Debian 的 UEFI 支持中的直接錯誤，但儘管如此，我們還是添加了解決方法來幫助這些人。
當前使用 BIOS 備選引導安裝的雙引導系統
相當多的早期 UEFI 系統預裝了非 UEFI 安裝的 Windows 7（2009年10月發佈），固件設置爲首先嚐試 UEFI 引導，然後嘗試 BIOS 引導。這對用戶來說很好，但是當一個新的操作系統和 Windows 一起安裝的時候，雙重啓動就很困難/不可能了。
debian-installer 現在會警告用戶，如果它在 UEFI 模式下啓動，但只能找到非 UEFI 的現有操作系統安裝。它讓他們可以選擇從現在開始將安裝程序切換到非UEFI 模式，這樣他們就不會破壞潛在的雙引導設置。
強制將 grub-efi 安裝到可移動介質路徑
如前所述，很不幸，許多 UEFI 固件實現存在缺陷。引導條目和引導順序的規範裏，這東西應該如何工作雖然非常明確，但是在不遵守規範的野生場景，有很多系統會出錯。一些系統簡單地忽略添加新啓動條目的有效請求。另一些會接受這些請求，但是卻拒絕使用，除非這些請求將自己描述爲“Windows”或類似的東西。還有許多其他類似的錯誤，這表明許多系統供應商除了“它能在 Windows 上工作嗎？”之外，很少進行測試。
如上所述，在 UEFI 系統上，引導加載程序應該只安裝在 EFI 系統分區（ESP）中正確的特定於供應商的目錄中。但是，由於存在錯誤的固件實現，發行商不敢奢求自己的操作系統在所有 UEFI 固件上都能正確工作。微軟已經解決了這個問題（可以說也使問題變得更糟）——Windows安裝程序也安裝到 ESP 中的可移動媒體路徑（例如，對於 amd64/X64 系統，\EFI\boot\bootx64.efi）。因爲所有固件實現都必須使用此路徑才能運行操作系統安裝程序。所以在所有破損的不完整的 UEFI 實現上， Windows 將始終可以工作，UEFI 系統的供應商可以“很巧合”的將不完整的 UEFI 實現運行起來。不過，這意味着，供應商移除了備選的引導路徑、並且打消了你合理控制引導順序的想法。
所有操作系統的安裝程序都把東西安裝到這個可移動媒體路徑，互相就會形成衝突，文件會相互覆蓋，這是不好的和錯誤的。因此，在 Debian 中我們默認不這麼做。
然而，爲了幫助支持那些不幸擁有這種錯誤 UEFI 系統的人，有一個選項可以強制將 grub-efi 安裝到可移動介質路徑。有一個 d-i Rescue Mode 選項可以強制實現這一點——如果你剛剛在 UEFI 系統上安裝了 Debian，但之後它無法啓動 Debian，這可能會爲你解決這個問題。也可以在使用專家模式的正常安裝運行期間選擇它，或者 Preseed 用戶可以在他們的配置中添加以下選項（對於amd64，調整軟件包名稱以適應其他體系結構）：
grub-efi-amd64 grub2/force_efi_extra_removable boolean true
您也可以通過使用 dpkg-reconfigure grub-efi-amd64 來選擇它。在問的其他問題中，這是一個要尋找的問題：
如果一個可引導的 Debian 安裝程序映像不可用，那麼作爲臨時措施，使用任何可用的方法將 \EFI\debian\grubx64.efi 複製到 \EFI\boot\bootx64.efi （其他操作系統，將存儲設備連接到不同的計算機，等等）。而且你應該可以進入你的系統。一旦你讓它正常啓動，你應該像上面一樣重新配置 grub，這樣你的 Debian 系統將來也會知道這樣做。
警告！如果您不在這裏適當地重新配置 grub，那麼在將來的升級中，grub 包將不知道更新可移動介質路徑中的副本。當 grub 發生變化時，這可能會使您的系統無法啓動。
顧名思義，將 grub-efi 安裝到可移動介質路徑對於在可移動介質上安裝可移植 Debian 非常有用（甚至是必要的）。
手動強制安裝 grub-efi
一些 UEFI 系統（如2013年前後生產的索尼VAIO系統）不允許選擇引導加載程序路徑。有些人聲稱，從救援系統的提示手動轉移和替換文件成功的實現雙啓動。例如：
# mkdir tmp
# mount /dev/sdaX tmp
# cd tmp/EFI/Microsoft/Boot/
# mv bootmgfw.efi bootmgfw.efi.org
# cp ../../debian/shimx64.efi bootmgfw.efi
這種安裝方法對於升級來說並不可靠，最好使用傳統的基於 MBR 的安裝方法，或者使用如上所述的可移動介質。