先吐个槽：写完以后，发现逻辑还是有点混乱。没耐心看完的人，只要看下面的结论就行了：
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。