Grub2 EFI:我的EFI分区在哪里？

Question

我用USB棒在我的Thinkpad Edge (UEFI)上安装了ubuntu12.04。我想自从出现了一个GRUB菜单之后，它就被EFI搞砸了，它提供了启动一个活动系统、安装或检查磁盘的选项。

当我启动笔记本电脑时，grub只显示它的命令行提示符"grub>“。

在色度环境中手动运行grub-install /dev/sda + update-grub之后，它以恢复模式启动grub，上面写着“文件未找到”。

磁盘按以下方式划分：

/dev/sda1:    ntfs,  1.5GB, SYSTEM DRV
/dev/sda2:    ntfs,  150GB, Windows7 OS
/dev/sda3:    extended
  /dev/sda6:  ext4,  140GB, Ubuntu 12.04
  /dev/sda5:  ntfs, 10.7GB, Lenovo Recovery
/dev/sda4:    ntfs, 16.8GB, a custom additional partition

我猜到标有"SYSTEM“的分区可能是EFI分区，但后来我看到EFI分区是FAT32类型的。这里没有任何FAT32分区！

因此，我无法遵循任何说明如何在EFI支持下安装Grub2的说明。他们都希望我在/boot/efi上挂载EFI分区。我也不能仅仅创建一个EFI分区，因为在大多数情况下-Tos都说它应该是第一个分区(至少它必须是一个主分区)，但是正如您所看到的，我已经有了一个分区1。

在EFI硬件上使用普通的Grub2工具不可能吗？

如果没有，创建EFI分区会解决这个问题吗？我能用分区4吗？

通过使用BootInfo创建的这篇文章可以在这里找到：http://paste.ubuntu.com/1011739/。请注意，这是一个Ubuntu驱动器，是在/dev/sdb，所以你应该忽略这个驱动器。

更新：

由于EFI似乎不是问题所在，所以我使用boot-repair重新安装了(非EFI-)grub。

新的BootInfo可以在这里找到：http://paste.ubuntu.com/1012223/。

现在的问题是，BIOS没有引导，但是给出了错误：

Operating system not found.

更新2(解决方案)：

当您阅读此问题时，遇到相同的问题(未找到操作系统。)时，您可能会在读取答案时错过树的林，因此我在这里重复该解决方案：

在我的例子中，问题是，我意外地将驱动器的引导标志更改为/dev/sda6，这是一个逻辑分区。BIOS在它想要引导的硬盘上搜索引导标志，但只在主分区中查找。如果找不到引导标志，就跳过硬盘驱动器。如果它没有找到任何可引导的驱动器或媒体，您将看到“未找到操作系统”错误。

Answer 1

早些时候(删除？)回答中链接的帮助部分描述了如何使用UEFI引导系统。这就是“本地”引导Linux的意思。

如果在Thinkpad上可用，另一种选择可能是使用CSM或与其等效的函数。这是兼容性支持模块的首字母缩写。这是英特尔的术语。( 规范是由英特尔开发的。)

CSM允许具有UEFI BIOS的系统启动遗留操作系统(非UEFI)，该操作系统只知道如何与遗留BIOS交互。

我的理解是，只有在UEFI硬件上使用所谓的普通(即遗留BIOS) GRUB工具，才能使用像CSM这样的工具。

更新：

在仔细查看OPs分区表之前，我编写了我以前的建议。

显然，该驱动器上的MBR分区是由联想公司设置的。因此Thinkpad Edge必须已经具备某种BIOS兼容性，以允许启动MBR分区驱动器。

如果这是真的，那么擦除当前的分区并使用GPT并不是一个好方法。

我建议您在进行任何重大更改之前，首先了解您的系统当前的工作方式。你能为你的系统收集一个BootInfo摘要吗？您可以通过使用Live /USB启动，同时连接到互联网，选择Try Ubuntu，然后使用这个答案中概述的步骤。

注意:在这一点上，我建议只收集信息。在你对自己的情况有了更好的理解之前，试着应用修复程序可能只会破坏其他一些东西。

我同意罗德·史密斯分析 of 您的BootInfo摘要的观点。Ubuntu已经安装在分区/dev/sda6中。GRUB和grub.cfg在/boot/grub/ on /dev/sda6中似乎是正确设置的。问题是，当前的引导顺序如下所示：

• GRUB引导加载程序是从/dev/sda的扇区0 (MBR)加载的。它将控制权转移到GRUB的core.img，它位于'/dev/sda‘的第1区。
• core.img加载器对文件系统了解得足够多，可以从它认为GRUB所在的地方加载GRUB的其余模块，(,msdos6)/root/grub。
• 当core.img无法从(,msdos6)/root/grub加载GRUB时，GRUB进入救援模式

更新:比较年长的和新的的

我在你的两个烤箱上做了一个比较文件。我列出了我认为下面有显著差异的东西。

• 第07行之前，GRUB在扇区1中的core.img寻找(,msdos6)/root/grub。现在它正在寻找(,msdos6)/boot/grub。换句话说，您通过重新安装GRUB解决了您试图纠正的问题。
• 第47行我无法解释为什么会发生这种情况，但是除了明显仍然存在于第1区的引导文件core.img之外，GRUB还将/boot/grub/core.img添加到/dev/sda6中。(也许这与下一个变化有关？)
• 前面的第77 & 81行用引导标志标记了/dev/sda1。现在，启动标志在您的Ubuntu分区/dev/sda6上。我认为这可能是导致启动问题的原因。尝试将引导标志切换回标记为SYSTEM_DRV的驱动器上的第一个NTFS分区，看看这是否有帮助。(我认为不会有任何伤害。)
• 第154、155和537 (旧) 523 (新) 设置在以前版本的pastebin中是"efi“，现在似乎使用了遗留BIOS的值。特别是，在PARTITIONS & DISKS:一节中，分区sda6以前有属性grub-efi。现在是grub-pc。

还有一些其他的变化似乎不值得详细描述。例如，您对文件/etc/default/grub的编辑已经丢失。文件返回到其默认安装内容。此外，memtest的菜单条目在重新安装后的grub.cfg文件中丢失。

Answer 2

硬盘肯定是为BIOS风格的引导设置的。这方面的具体证据包括：

• 分区表是MBR。虽然理论上可以从MBR分区表启动EFI模式，但据我所知，Windows不支持这种配置。当然，它的安装程序不支持；Windows安装程序支持BIOS上的MBR或EFI上的GPT，但不支持EFI上的MBR或BIOS上的GPT。
• 在/dev/sda上没有ESP。(在/dev/sdb1 1上有EFI引导文件，但这看起来像一个USB闪存驱动器，而不是普通的引导磁盘。)
• Boot脚本输出将GRUB标识为安装在/dev/sda的MBR中。这与BIOS模式的GRUB安装是一致的.
• Boot脚本输出将/Windows/System32 32/winload.exe标识为/dev/sda2 2上的引导文件。如果这是Windows的EFI安装，您会在某个地方看到对winload.efi的引用。

因此，不管问题的根源是什么，它似乎与EFI无关；这是一个直接的BIOS问题。

我看到的最大线索是，从Boot Info脚本输出：

=> Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 1 of 
   the same hard drive for core.img. core.img is at this location and looks 
   for (,msdos6)/root/grub on this drive.

请特别注意对(,msdos6)/root/grub的引用。稍后，在Boot脚本输出中，有/dev/sda6 6上的引导文件列表((,msdos6)在GRUB语言中)。这个列表包括/boot/grub/grub.cfg，但是在root目录中没有提到任何内容。实际上，root目录(不要与名为“root”的/目录混淆)是超级用户的主目录，它通常不保存引导文件。因此，我怀疑GRUB是错误安装的。也许您使用了一些您没有提到的grub-install选项，这是不合适的，或者安装脚本中有一个bug。无论如何，我建议在基于BIOS的计算机上使用通常的程序重新安装GRUB。但是，请注意，如果您的紧急系统启动在EFI模式，这可能会造成复杂，所以您应该确保启动您的紧急系统在BIOS模式。

您可以在Linux中通过查找/sys/firmware/efi目录来检查您的引导模式。如果它是存在的，那么您已经启动了EFI模式。如果没有，您可能已经在BIOS模式下启动了(尽管在EFI模式下启动了该文件，但在某些情况下该文件仍将缺席)。