平板无法识别u盘第二个分区-(平板无法识别u盘第二个分区怎么办)

小米平板2采用了目前主流的 UEFI 引导管理机制，具备安全、灵活的特点，也为用户自行定制提供了基础。

小米平板2加电后完成硬件自检与 BIOS 引导，然后将控制权交给 UEFI 。UEFI 的运行过程可以简单理解为：访问 U盘或硬盘里 Fat32 格式的EFI系统分区（ESP），调用后缀为 .efi 的系统启动文件（OS Loader），通过启动文件加载 MIUI 或 Win10 等操作系统，最后把控制权交给新启动的系统，完成启动过程。

但是平板中可能有很多启动文件，UEFI 怎么知道该调用哪个呢？原来，调用过程遵守“按启动序列中的顺序依次调用启动项”的原则。

平板中有两个全局变量，一个存放所电脑有启动项，一个存放启动顺序，这两个变量共同定义了启动序列。UEFI 获得控制权后会先访问这两个变量，以决定下一步的操作。用户可以修改这两个变量的内容，增加自己的启动项，调整启动顺序，以达到优先调用用户的启动文件，启动用户想要的系统的目的。

但有个问题：如果由于用户失误，设置了无法正常启动的文件，那么每次开机时平板都先调用有问题的启动项，导致系统无法正常进入操作系统，那岂不进入了无法控制的状态，导致所谓的“变砖”？

小米平板2设计者充分考虑了这个情况，内置了另一个机制：只要平板识别到 U盘，就会检查 U盘中是否有 Fat32 格式的分区，如果有，则在这个分区中查找 \EFI\Boot\Bootx64.efi 文件。如果找到了，就会自动把这个文件添加到启动项中，并把它设置为启动顺序中的第一个，然后启动该启动项。因此，只要 U盘的这个启动文件正常，你就可以以它为入口，进入某个系统，比如PE，获得控制权去修正之前犯下的错误。因为对 U盘的控制权在你的手里，你可以随时重做 U盘，甚至更换 U盘，因此只要你把 U盘做好，你就一定能取回对平板的控制权。

这就是我经常安慰机友的原因：“小米平板2变砖并不容易，只要屏幕能亮，U口没坏，平板就变不了砖”。平板启动失败后一般会不断尝试重启，即使有时刚开机或强行重启时不识读 U盘，也没有关系，等它自动重启（不通过按电源键重启）后，一般都能恢复识读。

使用 UEFI 的计算机普遍启用了安全启动选项（UEFI Secure Boot），用于避免非授权启动文件的运行。小米平板2也不例外，并且更甚一步，不但启用了安全启动，而且即使用户进入 BIOS 手工把安全启动关闭，一段时间后平板会把它自动打开。

因此，小米平板2的安全启动机制是做得比较严格的，但在保证安全的同时，也降低了用户 DIY 的灵活度。也就有了那个梗：有用户对“游戏尘间”（最早制作小米平板2双系统切换功能的那位高手）吐槽切换操作不方便时，“游戏尘间”建议用户“致电雷军”。

UEFI Secure Boot 的存在，导致只有两种 efi 文件可以成为小米平板2的启动文件：一种是小米公司自己制作的 efi，它可以使用小米平板2最底层的一些机制获得合法运行权，这个文件就是我们在安装 MIUI 后，在 ESP 分区中看到的那个 \EFI\Boot\Bootx64.efi 文件；另一种就是获得了微软CA认证的文件。因为 Secure Boot 最初是由微软公司推出的，多年来微软利用其自身地位强行推广，已经形成广泛使用的既成事实，目前基本上所有使用 UEFI 的计算机主板都集成了微软的 CA 证书，主流的 Linux（如：Ubuntu、Redhat）等操作系统通过取得微软的证书签名，得以在使用 UEFI 的计算机上合法运行。

目前各大操作系统厂商之所以甘于屈居微软的认证体系之下，一是由于反抗即成事实的代价太大，二是微软用实力和信誉做担保，至少到目前做到了公平。但在极端情况下，比如中美脱钩，微软是否还能保证公平，UEFI 是否会成为中国公司的一个软肋，已经成为国内业界的热门话题。这个留到以后再说。

在小米平板2双系统刷机过程中，共涉及三个启动文件，第一个是前面说到的MIUI 的 Bootx64.efi，第二个是 Win10 的启动文件 Bootmgfw.efi，第三个是 Shimx64.efi。后面这两个属于取得微软证书签名的第二种文件，但 Shimx64.efi 不是操作系统的启动文件，它与 rEFInd 共同为用户提供选择界面，让用户决定下一步启动哪个系统。关于 Shimx64.efi 我会在后面详细讲解。

看到这里，你大概能明白小米平板2的双系统开机切换功能为什么不容易实现了：由于安全启动的存在，导致第三方开发者的选择非常有限，只能在狭窄的缝隙中寻找腾挪空间。

在小米平板2上安装双系统，实现双系统切换功能，实际就是要给用户以选择权，让用户能自主决定进入哪个系统。我们使用了 rEFInd 提供的选择机制来实现这个目标。

rEFInd 是一个被广泛用于 UEFI 多系统启动场景的解决方案，最大特点是平台无关和操作简便。它最初被“游戏尘间”用于实现小米平板2刷机和双系统切换，我们继承了“游戏尘间”的思路，将其用于目前这版广泛流传的刷机工具和双系统开机切换方案中。

图1

rEFInd 与 Shimx64.efi 相结合，完美地在刷机和开机时给用户提供了美观、易操作的选择界面，并在一定程度上减少了 UEFI Secure Boot 对用户 efi 的限制。

Shimx64.efi 使用了 Secure Boot 的链式认证机制。前面已经说过，Shimx64.efi 已经取得微软CA认证签名，可以在小米平板2开机时合法运行，链式认证机制允许 Shimx64.efi 对 rEFInd 的 grubx64.efi 进行合法性认证，只要认证通过就可以被 Shimx64.efi 调用。grubx64.efi 的主要功能是给用户提供选择菜单（图1），用户选择某一菜单的操作实际也是调用某个 efi 文件，grubx64.efi 对用户选择的 efi 认证通过后授权其运行。通过这种链式授权方式，减少了 UEFI Secure Boot 对 efi 的限制，未直接获得微软认证的软件只要能由这种链式授权认证通过，也将被允许运行，因此简化了认证过程，用户可以使用的 efi 大为增加。

那么什么样的 efi 能通过这种方式获得授权呢？Shimx64.efi 调用 grubx64.efi 时，会对比小米平板2主板中存放的个人证书（注意：是个人证书，不是微软发布的正式证书），如果 grubx64.efi 已经获得该证书的签名，则认证通过予以运行，否则弹出“验证失败，拒绝访问”的报错。

然后要求用户导入 cer 证书，如果用户能导入对应的 cer 证书文件，则允许 grubx64.efi 运行，否则退出。

用户在 grubx64.efi 提供的选择菜单调用的某个 efi 文件，也是通过这种方法进行认证。因此，用户如果能保证 cer 证书正确导入平板，并且除 Bootx64.efi、Bootmgfw.efi 和 Shimx64.efi 这三个文件外的所有其它 efi 都经过该证书签名，就可以在小米平板2上通过这种链式认证方式得以合法运行。

我们制作的刷机包中提供了个人证书，也就是上图中的 Butterfly_of_Amazon.cer，刷机包中的各个 efi 文件也用该证书进行了签名，因此只要按教程把这个证书导入平板，就可以正常使用刷机包和它提供的开机切换功能。

第一次使用刷机包进行刷机时，由于证书尚未导入，所以需要进入 BIOS 手工关闭安全启动选项，等完成证书导入后就可以省略这个步骤了。

证书是存放在主板上的，导入一次永久有效，哪怕将硬盘中所有分区都删除，也不会影响已导入的证书。但重刷 BIOS 会清除证书，因此每次刷完 BIOS 都会出现蓝色窗口让用户重新导入。

前面电脑讲了小米平板2的启动过程、安全机制和选择机制，有了这些基础，下面说说我们是怎么实现双系统切换功能的。

我们制作的刷机工具提供了两种双系统切换方法：一键切换和开机切换。

1. 一键切换

一键切换的原理相对简单：（1）用户在 MIUI 系统中运行 And2Win，这个 APP 会将 Win10 的 Bootmgfw.efi 改名为 Bootx64.efi，复制到平板的 ESP 分区中替换 MIUI 启动文件 \EFI\Boot\Bootx64.efi，然后重启平板。平板启动时调用 \EFI\Boot\Bootx64.efi，而此时这个文件实际是 Bootmgfw.efi，因此实际启动的将是 Win10；（2）由 Win10 切换到 MIUI 系统的过程类似，用户在 Win10 中运行 Android 快捷方式，它将 MIUI 启动文件 Bootx64.efi 复制回 ESP 分区的 \EFI\Boot\ 中，替换掉 Bootmgfw.efi，然后重启平板，平板启动还是调用 \EFI\Boot\Bootx64.efi，而此时这个文件是 MIUI 的启动文件，因此平板将启动 MIUI 系统。

原理详见下图：

2. 开机切换

如果你安装的是开机切换功能，那么每次启动平板时，会出现下图的系统选择菜单：

左边大图标为进入 Win10 系统，右边大图标为进入MIUI 系统。

原理详见下图：

理论这层窗户纸捅破后，其实很简单。我动笔前觉得这篇文章需要写好几天，可写了3500 字后，却发现画完上面两张流程图后就可以收尾了。

实际在刷机包的研发过程中，我和小伙伴们克服了无数的困难，比如：PE 分辨率太高字体太小问题、安装 Win10 经常异常问题、Win10 映像的驱动集成问题、Remix 和 Lineage、RR 的硬盘克隆问题、第三方 REC 刷入 zip升级包问题、安卓系统下如何自动恢复 rEFInd 启动文件问题、个人证书更换问题、BIOS 刷入工具移植问题、Win10 启动序列自动更改问题、开机切换图标用户DIY问题、ESP 序号变化导致一键切换失效问题、开机切换多按一下确认键问题、启动分区过小导致 Win10 引导文件生成失败问题、Win10 启动分区容量不足导致升级失败问题，等等。每一个问题的解决都花费了我们诸多的心血。由这个项目，我深深体会了将理论知识转换为工程成果需要经历多少艰苦的工作，但这些工作却又无法写进文章，否则显得太过琐碎和庞杂。

现在这个刷机包虽然得到这么多用户的喜欢，但我知道远没有达到完美，比如：安装 Win10 时对异常情况的提示和处理还很不完善，存在很多个例情况不能自动处理，初次使用者容易感到困惑，等等。限于精力，只能以后有时间再电脑慢慢完善了。有愿意进一步了解的朋友欢迎加我微信探讨。