说说UEFI
先吐个槽:写完以后,发现逻辑还是有点混乱。没耐心看完的人,只要看下面的结论就行了:
Windows efi引导修复:在安装环境下diskpart+bcdboot
Ubuntu efi引导修复:livecd环境下重装~~(请允许我做出一个悲伤的表情)~~
首先,这篇文章不涉及任何关于UEFI底层操作,也不涉及任何关于GPT分区格式的深入讨论;我只不过是把这几天的烦人经历吐个槽,让路过的人偶尔有一点收获。仅此而已。 先从度娘上扒一些基础知识:
简单说来,bios是固件程序,uefi是高级固件程序;mbr是分区格式,gpt是高级分区格式。理论上有2*2=4种存在方式,(不过在ubuntu论坛上看到好像是有16种……?)和gilgame其实没什么差别对吧。
区别在哪里呢?
抛开底层实现方式的不同,我想问题往往出在安装系统的过程中(安装完还管你是什么固件什么分区格式呢)。4种存在方式中,bios+mbr最为原始,uefi+gpt是大势所趋,这两个搭配没有什么问题;uefi+mbr可以用,但是要用legacy模式(有些也称为csm兼容模式),相当于uefi不存在;bios+gpt太奇葩了,好像没有人用。
细细说来,新旧两种搭配的思维是截然不同的的。
引导方式 | 分区限制 | |
---|---|---|
bios+mbr | 加载磁盘首端的位置固定一段程序 | 4个主分区 |
uefi+gpt | 加载esp分区中的bootx64.efi文件 | 128个分区(windows至多赋予128个盘符) |
哎,等等……突然跳出来一个esp分区是什么鬼……这便是efi下的引导方式的精髓。通过让uefi“理解”分区,将引导文件转移到磁盘的任意一个分区,从而将引导文件“摆脱枷锁”。
这话可怎么说?mbr分区模式下不仅要指定活动分区,而且引导文件也不能过大,只能一级级地载入,效率比较低;如果开机自检的时候载入的文件能一步到位,岂不是会快很多(虽然这些都是我脑补的)?
esp分区要求分区格式为fat系列中的一种(fat12,fat16,fat32),位置不作要求,但是在ubuntu的官方指南中强烈要求esp分区数量不得超过一个。实际上,在各种分区软件中,esp分区的格式都是识别为“efi分区”,而不是fat系列( ╯□╰ )。
说句题外话。有人经常问,说windows安装程序在划磁盘的时候,总是一口气建立了四个分区。没错,因为它建立了这几个分区:
- recover分区,450MB
- efi分区,100MB
- msr分区,128MB
- 你的C分区,99.3GB 这是一种常见的情况。recover分区放置winre环境,efi分区放置引导文件,msr分区鬼知道放了什么~~(因为大家都识别不了)~~,最后才把余下的空间给C分区。
那么各大操作系统对于uefi固件的支援情况怎么样呢?grub(代表linux和unix阵营)分legacy grub(就是grub1)和grub2,前者几乎不支持uefi启动,后者是支持的。bootmgr方面,win7还不能识别uefi,尽管安装的时候会划出esp分区(捂脸);win8以上是原生支持的。
对gpt分区呢?linux阵营好像支持的不错;高贵的mac osx~~(你不就是一个unix叫什么叫)~~也支持;然而windows情况比较复杂(x86_64为例):在xp时代(那是什么年代了)能读写gpt分区但是不能启动;win7原生不支持,必须要手动加载efi文件。反正windows8以上微软强烈要求用uefi+gpt分区。
强烈要求到什么地步呢?就是搞了一个Secure boot。
Secure boot是什么?简单来说,就是签名不通过的引导文件不能启动。在efi的标准中,这个选项与csm是冲突的(很好理解嘛,都csm兼容了还能感觉到uefi固件么)。这里也有许多复杂的事情,什么x86平台的可以关闭,arm平台的不可以关闭……你问我surface1&2装android x86这么难,大概就是这个原因。
来讲讲我这几天折腾的感受:
先装的windows10,再装的ubuntu。ubuntu还算比较智能,写了一个grub2覆盖原来的默认引导文件,把windows启动项往里一扔完事。
但是呢(no zuo no die),windows10实在不好用(而且没有正版),就退回windows8.1(即重新安装)。在这一步中,我把本来分出来的recover分区删掉,把efi分区向前挪,再划分分区。那么问题就来了:引导怎么办呢?
windows的引导不打紧,在安装环境用bcdboot x64重建一下就行;ubuntu的grub引导可是惨了,尽管备份了一次(而且grub.cfg应该还不在efi分区里),但是恢复回去以后居然不认!不认!
在livecd环境下死活装上了grub,然而等待我的是一闪而过的lenovo标志,然后又是windows启动……
究竟出什么问题了呢?个人推测,有以下几种可能性:
- grub.cfg分区数目错误(因为删掉了recover分区)
- grub2没找到/dev/sda7上面的grub.cfg
- uefi固件压根没有理会grub,即grub引导文件不在uefi的引导选项范围内(后几日推测,可能性最大) 所以说……最简单粗暴的方法就是重装ubuntu。
最后再说一句:uefi+gpt模式下,以前一切一切的引导修复、(基于bios的)盗版激活全部失效。很简单,前者基于mbr,后者依赖传统bios。