Unified Extensible Firmware Interface (简体中文)
统一可扩展固件界面(Unified Extensible Firmware Interface) (或简称为UEFI) 是一种新型固件,它引入了一种新的启动系统的方式,该方式有别于传统BIOS系统所使用的“MBR启动代码”(其二者区别见 Arch boot process#Firmware_types )。本文介绍了 什么是UEFI 以及 UEFI在Linux内核中的支持 。若要配置 UEFI 引导器,详见 Boot loaders.
Contents
UEFI 发展历史
- UEFI起始于Intel的EFI 1.x版。
- 从2.0版本起,一个名为UEFI论坛的公司组织接管了其开发工作,并更名为Unified EFI(统一EFI).
- 除非特别指明是EFI 1.x, EFI和UEFI均指代UEFI 2.x固件。
- 自2013年七月24日起,UEFI标准2.4 (发布于013年7月11日)是最新的版本。
- 苹果公司的EFI实现不是EFI 1.x也不是UEFI 2.x而是这两者的混合体。这类固件不被归入到任何(U)EFI规格中,因而并没有一个标准的UEFI固件。除非特别指明,以下说明可通用但部分可能会在Apple Macs上有所不同或是会不起效。
UEFI 引导过程
- 系统开机 - 上电自检(Power On Self Test 或 POST)。
- UEFI 固件被加载,并由它初始化启动要用的硬件。
- 固件读取其引导管理器以确定从何处(比如,从哪个硬盘及分区)加载哪个 UEFI 应用。
- 固件按照引导管理器中的启动项目,加载UEFI 应用。
- 已启动的 UEFI 应用还可以启动其他应用(对应于 UEFI shell 或 rEFInd 之类的引导管理器的情况)或者启动内核及initramfs(对应于GRUB之类引导器的情况),这取决于 UEFI 应用的配置。
UEFI 的多重引导
因为每个操作系统或者提供者都可以维护自己的 EFI 系统分区中的文件,同时不影响其他系统,所以 UEFI 的多重启动只是简单的运行不同的UEFI 程序,对应于特定操作系统的引导程序。这避免了依赖 chainloading 机制(通过一个引导程序加载另一个引导程序,来切换操作系统)。
启动 Microsoft Windows
64位版本的 Windows Vista (SP1+)、Windows 7 和 Windows 8 源生支持通过 UEFI 固件引导,但是这需要将硬盘格式化为 GPT 格式。64位版本的 Windows 系统支持 UEFI-GPT 模式引导或 BIOS-MBR 模式引导,而32位版本的 Windows 系统仅支持 BIOS-MBR 模式引导。具体做法请参考论坛参考文献章节中提供的链接。查看 [这里] 来获得更多信息。
检测 UEFI 固件架构
非 Mac 机
检查目录 /sys/firmware/efi
是否存在,如果存在表明内核已经以 UEFI 模式启动,这种情况下 UEFI 架构等同于内核架构。(例如: 32位 或者 64位)
Apple Mac
2008年以前的 Mac 大都使用 i386-efi 固件, 2008年以后大都使用 x86_64-efi 。有能力运行 Mac OS X Snow Leopard 64位内核的 Mac 都是 x86_64 EFI 1.x 版的固件。 在 Mac OS 下输入以下命令可以找出该 Mac 的 efi 固件:
ioreg -l -p IODeviceTree | grep firmware-abi
如果命令返回 EFI32 则对应的是 i386 EFI 1.x 版本的固件,返回 EFI64 对应的则是 x86_64 EFI 1.x 版的固件. Mac 没有 UEFI 2.x 固件,Apple的 EFI 实现也不完全跟 UEFI 标准兼容。
Secure Boot
关于在 Linux 中 Secure Boot 的概述请参考文章 Rodsbooks' Secure Boot. 本节的重点在于如何在 Arch Linux 中设置安全启动。本节暂时仅介绍在开启 Secure Boot 模式的情况下启动 archiso 的步骤。因为 EFI 程序 PreLoader.efi
和 HashTool.efi
已经添加到 archiso 中,所以在开启 Secure Boot 模式的情况下启动 archiso 是可以的,将会显示一条 "Failed to Start loader...I will now execute HashTool". 的消息。要使用 HashTool 来注册 loader.efi
和 vmlinuz.efi
的 hash 值,执行如下步骤:
- 选择
OK
- 在 HashTool 主菜单先选择
Enroll Hash
,再选择\loader.efi
,然后点击Yes
确认。再选择Enroll Hash
和archiso
,进入 archiso 目录,然后选择vmlinuz-efi
并且点击Yes
确认,最后点击Exit
返回启动设备选择菜单。 - 在启动设备选择菜单选择
Arch Linux archiso x86_64 UEFI CD
。
archiso 启动后会自动以 root 登陆,并且出现 shell 提示符。使用以下命令检查 archiso 是否以 Secure Boot 模式启动:
$ od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
如果以 Secure Boot 模式启动,命令会返回以 1 结尾的五个整数,例如:
6 0 0 0 1
XXXX 部分因不同机器而各不相同。可以使用 tab 补全来获取帮助或者列出 EFI 变量。
此外,另一种方法是执行:
$ bootctl status
Linux 内核中有关 UEFI 的配置选项
UEFI 系统所要求的 Linux 内核配置选项设置如下:
CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_FB_EFI=y CONFIG_FRAMEBUFFER_CONSOLE=y
UEFI运行时变量支持 (efivarfs 文件系统 - /sys/firmware/efi/efivars
). 该选项十分重要,因为它是使用如 /usr/bin/efibootmgr
的工具来操作UEFI运行时变量所必须的。下面的选项已添加进了版本3.10及以上的内核中。
CONFIG_EFIVAR_FS=y
UEFI运行时变量支持 (老式 efivars sysfs 接口 - /sys/firmware/efi/vars
). 应当禁用该选项来防止同时启用 efivarfs 和 sysfs-efivars 所导致的潜在问题。
CONFIG_EFI_VARS=n
GUID 分区表 GPT 配置选项 - UEFI 支持的强制需求
CONFIG_EFI_PARTITION=y
UEFI 变量
UEFI 定义了变量,通过它们操作系统可以与固件进行交互。 UEFI 引导变量只在早期系统启动时由引导加载程序和操作系统使用。UEFI运行时变量允许操作系统来管理固件的某些设置(如UEFI引导管理器)或 UEFI Secure Boot 协议的密钥。你可通过下面的命令来获得变量列表:
$ efivar -l
Linux 内核中的 UEFI 变量支持
Linux 内核通过两个接口来把 EFI 变量数据传递给用户空间:
- 老式 sysfs-efivars 接口 (CONFIG_EFI_VARS) - 由位于
/sys/firmware/efi/vars
的内核模块efivars
生成 - 每个变量数据最大大小为1024B, 不支持 UEFI Secure Boot 变量(由于大小限制),并再也不被上游推荐使用。现仍被上游支持但在 Arch 官方内核中已完全禁用。
- 新式 efivarfs (EFI VARiable FileSystem) 接口 (CONFIG_EFIVAR_FS) - 由位于
/sys/firmware/efi/efivars
的efivarfs
内核模块挂载使用 - 老式 sysfs-efivars 接口的替代品,不限制变量数据大小,支持 UEFI Secure Boot 变量并被上游推荐使用。在3.8版的内核中引入,新的efivarfs
模块在3.10版内核中从旧的efivars
内核模块中分离。
efivarfs 和 sysfs-efivars 的不一致
同时启用老式的 sysfs-efivars 和新式的 efivarfs 会导致数据不一致的问题(更多信息见 https://lkml.org/lkml/2013/4/16/473 )。由于(自从 core/linux-3.11 和 core/linux-lts-3.10)老式的 sysfs-efivars 在 Arch 官方内核中已完全禁用,新式的 efivarfs 将会被继续地启用/支持下去。自2013年10月1日起,在官方源中所有与 UEFI 变量相关的工具都支持 efivarfs.
如果在使用任何用户空间工具访问 EFI VAR 数据前你同时开启了这两者,请禁用其中之一并重新开启另一个接口 (为了刷新数据和防止不一致) :
禁用 sysfs-efivars 并刷新 efivarfs:
# modprobe -r efivars # umount /sys/firmware/efi/efivars # modprobe -r efivarfs # modprobe efivarfs # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
禁用 efivarfs 并刷新 sysfs-efivars:
# umount /sys/firmware/efi/efivars # modprobe -r efivarfs # modprobe -r efivars # modprobe efivars
UEFI 变量正常工作的需求
- EFI 运行时服务支持应出现在内核中 (
CONFIG_EFI=y
, 运行zgrep CONFIG_EFI /proc/config.gz
来核对是否共存 ). - 内核处理器的位数/架构应该与EFI处理器的位数/架构相符。
- 内核应以 EFI 模式(通过 EFISTUB 或 EFI 引导器,而不是 BIOS/CSM 或者同为 BIOS/CSM 的"bootcamp")启动。
- EFI 运行时服务在内核命令行中不应被禁用,即不应使用内核参数
noefi
. -
efivarfs
文件系统应被挂载在/sys/firmware/efi/efivars
, 否则参考下文 #挂载 efivarfs 部分。 -
efivar
应无错列出 (选项-l
) EFI 变量。参见输出内容 #Sample_List_of_UEFI_Variables.
如果 EFI 变量支持在满足以上条件后仍有问题,尝试以下解决方案:
- 如果所有的用户空间工具都不能修改 EFI 变量数据,检查
/sys/firmware/efi/efivars/dump-*
文件是否存在。如果是,删掉,重启,再试一次。 - 如果上面的步骤没有解决问题,尝试以内核参数
efi_no_storage_paranoia
启动以禁用内核 EFI 变量存储空间来防止对 EFI 变量的写入/修改。
挂载 efivarfs
如果 efivarfs
启动时并没有被 systemd 自动挂载在 /sys/firmware/efi/efivars
, 你需要手动挂载来把 EFI 变量支持传递给像 efibootmgr
等的用户空间工具:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
如下通过 /etc/fstab
来自动挂载 efivarfs
也是极好的:
/etc/fstab
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0
用户空间工具
只有少量工具能够访问/修改 UEFI 变量,即
- efivar - 操作 UEFI 变量的库和工具 (被 efibootmgr 用到) - https://github.com/vathpela/efivar - efivar 或 efivar-gitAUR
- efibootmgr - 操作 UEFI 固件启动管理器设置的工具- https://github.com/vathpela/efibootmgr - efibootmgr 或 efibootmgr-gitAUR
- uefivars - 转储 UEFI 变量和 PCI 相关信息 (内部使用 efibootmgr 源码) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 仅支持 efivarfs ,以及 https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 仅支持 sysfs-efivars . AUR 软件包 uefivars-gitAUR
- efitools - 创建与设置自己的 UEFI Secure Boot 证书,密钥和签名过的程序的工具 (需要 efivarfs) - efitools-gitAUR
- Ubuntu的固件测试套件 - https://wiki.ubuntu.com/FirmwareTestSuite/ - fwtsAUR (以及 fwts-efi-runtime-dkmsAUR) 或 fwts-gitAUR
efibootmgr
假设要启动的引导器文件是 /boot/efi/EFI/refind/refind_x64.efi
, /boot/efi/EFI/refind/refind_x64.efi
可被分拆为 /boot/efi
和 /EFI/refind/refind_x64.efi
, 其中 /boot/efi
是 EFI 系统分区的挂载点,假设是 /dev/sdXY
(在这里 X
和 Y
只是真实值的占位符 - 例如:- 位于 /dev/sda1
, X==a
Y==1
).
为确定 EFI 系统分区的设备路径 (此例假设挂载点是 /boot/efi
) (应为 /dev/sdXY
形式), 尝试:
# findmnt /boot/efi TARGET SOURCE FSTYPE OPTIONS /boot/efi /dev/sdXY vfat rw,flush,tz=UTC
检查内核中的 UEFI 变量支持是否正常运行:
# efivar -l
如果 efivar 无错列出变量,那么你可以开始了。如果不是,检查 #Requirements for UEFI Variables support to work properly 中的要求是否全部满足。
然后用 efibootmgr 如下创建启动条目:
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"
在上面的命令中 /boot/efi/EFI/refind/refind_x64.efi
转译为 /boot/efi
和 /EFI/refind/refind_x64.efi
, 进一步译为 /dev/sdX
-> 分区 Y
-> 文件 /EFI/refind/refind_x64.efi
.
'label' 是出现在 UEFI 启动菜单的菜单条目名。用户可随便起名,这并不影响系统启动。更多内容见 efibootmgr GIT README .
FAT32 文件系统大小写不敏感因为它默认不使用 UTF-8 编码格式。这种情况下固件使用大写字母 'EFI' 而不是小写的 'efi', 因此 \EFI\refind\refindx64.efi
或 \efi\refind\refind_x64.efi
都没问题 (当文件系统采用 UTF-8 编码时就不同了).
EFI 系统分区
EFI 系统分区(也称为 ESP 或者 EFISYS)是一个 FAT32 格式的物理分区 (在硬盘主分区表上,而不是 LVM 或软件 RAID 等等) ,从这里 UEFI 固件启动 UEFI 引导器和应用程序。
它与操作系统无关而是作为 EFI 固件要启动的引导器和应用程序的存储空间,是 UEFI 启动所必须。它的分区类型应该是 EFI 系统分区 (见 #GPT_partitioned_disks). 推荐 ESP 大小为 512 MiB 尽管大一点小一点都没问题 (见下面的注意)。更多信息见 Wikipedia:EFI System partition.
GPT 磁盘分区
-
fdisk/gdisk: 创建类型为 EFI System (
EFI System
(在 fdisk 中) 或ef00
(在 gdisk 中)的分区。然后运行mkfs.fat -F32 /dev/<THAT_PARTITION>
格式化为 FAT32 格式。
(或)
-
GNU Parted: 创建一个 FAT32 分区然后在 Parted 中为那个分区设置/激活
boot
参数 (不是legacy_boot
参数).
MBR 磁盘分区
-
fdisk: 使用 fdisk 创建类型为 EFI System 的分区,然后运行
mkfs.fat -F32 /dev/<THAT_PARTITION>
格式化为 FAT32.
RAID 上的 ESP
将 ESP 包含进 RAID1 组是可行的,但是会有数据污染的危险,创建 ESP 时请三思。 细节见 https://bbs.archlinux.org/viewtopic.php?pid=1398710#p1398710 和 https://bbs.archlinux.org/viewtopic.php?pid=1390741#p1390741 .
UEFI Shell
UEFI Shell 是固件的终端,可用于启动包括引导器的 UEFI 程序。除此之外, Shell也可用于采集固件和系统的各种信息,例如内存映射 (memmap), 修改启动管理器变量 (bcfg), 运行分区程序 (diskpart), 加载 UEFI 驱动,编辑文本文件 (edit), 十六进制编辑等等。
获取 UEFI Shell
你可从 Intel 的 Tianocore UDK/EDK2 Sourceforge.net 工程下载以 BSD 许可证发布的 UEFI Shell.
- AUR uefi-shell-svnAUR 包 (推荐) - 为 x86_64 系统提供 x86_64 Shell 以及为 i686 系统提供 IA32 Shell - 直接从 Tianocore EDK2 SVN 最新的源码编译
- Precompiled x86_64 UEFI Shell v2 binary (可能不是最新)
- Precompiled x86_64 UEFI Shell v1 binary (上游再也不更新了)
- Precompiled IA32 UEFI Shell v2 binary (可能不是最新)
- Precompiled IA32 UEFI Shell v1 binary (上游再也不更新了)
Shell v2 在 UEFI 2.3+ 系统上表现最好,并比 Shell v1 优先推荐。Shell v1 应该在所有 UEFI 系统上有效并且与它们遵循的 UEFI 标准版本无关。更多信息见 ShellPkg 和 这封邮件
启动 UEFI Shell
部分基于华硕和 AMI Aptio x86_64 UEFI 固件的主板 (从 Sandy Bridge 起) 提供了一个叫做 "Launch EFI Shell from filesystem device"
的选项。对于这些主板,下载 x86_64 UEFI Shell ,复制进 EFI 系统分区,命名为 <EFI_SYSTEM_PARTITION>/shellx64.efi
(大部分是 /boot/efi/shellx64.efi
) .
Phoenix SecureCore Tiano UEFI 固件已内嵌 UEFI Shell, 可按 F6
, F11
或 F12
键来启动。
重要 UEFI Shell 命令
UEFI Shell 命令通常支持 -b
选项,它在输出的每页末尾暂停。 map
能列出识别出的文件系统 (fs0
, ...) 和存储设备 (blk0
, ...). 运行 help -b
来列出所有可用命令。
更多信息见 http://software.intel.com/en-us/articles/efi-shells-and-scripting/
bcfg
BCFG 命令用于修改 UEFI NVRAM 条目,它能让用户改变启动条目或驱动器选项。在"UEFI Shell Specification 2.0" PDF 文档的83页 (Section 5.3) 有详细描述。
转储当前启动条目:
Shell> bcfg boot dump -v
为 rEFInd (作为例子) 添加一个启动菜单条目,在启动菜单里是第4个 (从0开始计数) 选项:
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"
fs0:
映射到 EFI 系统分区,fs0:\EFI\refind\refind_x64.efi
i是要启动的文件。
删除第4个启动选项:
Shell> bcfg boot rm 3
把第3个启动选项移动到第0 (也就是说第1个是 UEFI 启动菜单的默认启动选项):
Shell> bcfg boot mv 3 0
bcfg 帮助文档:
Shell> help bcfg -v -b
或:
Shell> bcfg -? -v -b
edit
EDIT 命令提供了类似于 nano 界面的基本编辑器,但是功能略少一点。它以 UTF-8 编码并且行尾结束符兼容 LF 和 CRLF.
本例中,编辑在固件 EFI 系统分区 (fs0:
中 rEFInd 的 refind.conf
Shell> fs0: FS0:\> cd \EFI\arch\refind FS0:\EFI\arch\refind\> edit refind.conf
输入 Ctrl-E
以获得帮助。
UEFI Linux 硬件兼容性
主要文章见 HCL/Firmwares/UEFI.
UEFI 可启动介质
从 ISO 创建 UEFI 可启动 USB
教程见 USB flash installation media#BIOS and UEFI Bootable USB.
从光学介质里移除 UEFI 启动支持
大部分32位 EFI Mac 机和部分64位 EFI Mac 机无法从 UEFI(X64)+BIOS 可启动 CD/DVD 启动。如果希望使用光学介质完成安装,可能首先需要移除 UEFI 启动支持。
- 挂载官方安装介质并如前所述获取
archisolabel
.
# mount -o loop input.iso /mnt/iso
- 然后重建 ISO, 使用 libisoburn 的
xorriso
移除 UEFI 光学介质启动支持。确认已设置正确的 archisolabel, 例如 "ARCH_201411"或类似的:
$ xorriso -as mkisofs -iso-level 3 \ -full-iso9660-filenames\ -volid "archisolabel" \ -appid "Arch Linux CD" \ -publisher "Arch Linux <https://www.archlinux.org>" \ -preparer "prepared by $USER" \ -eltorito-boot isolinux/isolinux.bin \ -eltorito-catalog isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \ -output output.iso /mnt/iso/
- 把
output.iso
烧制进光学介质并照常完成安装。
原生无支持情况下测试 UEFI
虚拟机使用 OVMF
OVMF 是一个 tianocore 工程用以对虚拟机支持 UEFI. OVMF 为 QEMU 包含了一个样本 UEFI 固件。
你可从 AUR ovmf-svnAUR 建立 OVMF (有 Secure Boot 支持), 运行如下命令:
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -pflash /usr/share/ovmf/x86_64/bios.bin
仅 BIOS 的系统使用 DUET
DUET 是一个 tianocore 工程用以从 BIOS 启动到完整 UEFI 环境,这与 BIOS 启动操作系统相似。在 http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ 里有广泛讨论。预建立的 DUET 镜像可从其中一个源 https://gitorious.org/tianocore_uefi_duet_builds 下载。教程见 https://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blobs/raw/master/Migle_BootDuet_INSTALL.txt.
也可考虑 http://sourceforge.net/projects/cloverefiboot/ , 它提供的 DUET 镜像可能包含了一些系统的专用补丁,并且比 gitorious 源更新得更频繁。
疑难问题
Windows 7 无法以 UEFI 模式启动
如果你把 Windows 安装进了另一个 GPT 格式的硬盘并且你电脑里还有一个 MBR 格式的硬盘,那么可能 UEFI 固件启动了 CSM 支持(为从 MBR 分区启动的支持) 因而 Windows 无法启动。为解决问题,把 MBR 硬盘的内容合并到 GPT 硬盘中并禁用 MBR 硬盘使用的 SATA 接口或者直接把硬盘拔下来。
有此类问题的主板:
Gigabyte Z77X-UD3H rev. 1.1 (UEFI 版本 F19e)
- 固件启动选项 "UEFI Only" 并不妨碍以 CSM 启动。
Windows 改变了启动次序
某些主板上 (ASRock Z77 Extreme4 确认有此问题) Windows 8 每次启动时改变了 NVRAM 中的启动次序。解决方式是让 Windows Boot Manager 加载另一引导器而不是启动 Windows. Windows 下以管理员模式执行如下命令:
bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi
USB 介质卡在黑屏界面
- 也可能是 KMS 的问题。从 USB 启动时尝试 Disabling KMS.
- 如果不是 KMS 的问题,那么可能是 EFISTUB 启动的 bug (更多信息见 [2] and [3] ). 官方 ISO (Archiso) 和 Archboot iso 都用 EFISTUB (通过 Gummiboot 启动管理器) 来让内核以 UEFI 模式启动。这种情况下参考下文来使用 GRUB 作为 USB 的引导器。
使用 GRUB
- 如 link 所述创建 USB 闪存安装介质。之后按照以下步骤来使用 GRUB 替代 Gummiboot.
- 把
<USB>/EFI/boot/loader.efi
备份为<USB>/EFI/boot/gummiboot.efi
- 创建一个独立的 GRUB 镜像并把它复制为
<USB>/EFI/boot/loader.efi
- 按如下内容创建
<USB>/EFI/boot/grub.cfg
(替换ARCH_YYYYMM
为 USB 盘,例如ARCH_201404
):
grub.cfg for Official ISO
insmod part_gpt insmod part_msdos insmod fat insmod efi_gop insmod efi_uga insmod video_bochs insmod video_cirrus insmod font if loadfont "${prefix}/fonts/unicode.pf2" ; then insmod gfxterm set gfxmode="1024x768x32;auto" terminal_input console terminal_output gfxterm fi menuentry "Arch Linux archiso x86_64" { set gfxpayload=keep search --no-floppy --set=root --label ARCH_YYYYMM linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap initrd /arch/boot/x86_64/archiso.img } menuentry "UEFI Shell x86_64 v2" { search --no-floppy --set=root --label ARCH_YYYYMM chainloader /EFI/shellx64_v2.efi } menuentry "UEFI Shell x86_64 v1" { search --no-floppy --set=root --label ARCH_YYYYMM chainloader /EFI/shellx64_v1.efi }
grub.cfg for Archboot ISO
insmod part_gpt insmod part_msdos insmod fat insmod efi_gop insmod efi_uga insmod video_bochs insmod video_cirrus insmod font if loadfont "${prefix}/fonts/unicode.pf2" ; then insmod gfxterm set gfxmode="1024x768x32;auto" terminal_input console terminal_output gfxterm fi menuentry "Arch Linux x86_64 Archboot" { set gfxpayload=keep search --no-floppy --set=root --file /boot/vmlinuz_x86_64 linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap initrd /boot/initramfs_x86_64.img } menuentry "UEFI Shell x86_64 v2" { search --no-floppy --set=root --file /boot/vmlinuz_x86_64 chainloader /EFI/tools/shellx64_v2.efi } menuentry "UEFI Shell x86_64 v1" { search --no-floppy --set=root --file /boot/vmlinuz_x86_64 chainloader /EFI/tools/shellx64_v1.efi }
另见
- Wikipedia:UEFI
- UEFI Forum - contains the official UEFI Specifications - GUID Partition Table is part of UEFI Specification
- UEFI boot: how does that actually work, then? - A blog post by AdamW
- Wikipedia:EFI System partition
- The EFI System Partition and the Default Boot Behavior
- Linux Kernel x86_64 UEFI Documentation
- Intel's page on EFI
- Intel UEFI Community Resource Center
- Matt Fleming - The Linux EFI Boot Stub
- Matt Fleming - Accessing UEFI Variables from Linux
- Rod Smith - Linux on UEFI: A Quick Installation Guide
- UEFI Boot problems on some newer machines (LKML)
- LPC 2012 Plumbing UEFI into Linux
- LPC 2012 UEFI Tutorial : part 1
- LPC 2012 UEFI Tutorial : part 2
- Intel's Tianocore Project for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox
- FGA: The EFI boot process
- Microsoft's Windows and GPT FAQ
- Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall
- Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive
- Rod Smith - A BIOS to UEFI Transformation
- EFI Shells and Scripting - Intel Documentation
- UEFI Shell - Intel Documentation
- UEFI Shell - bcfg command info
- UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot