☰

是什么导致我的 EFI 分区在安装后启动 CentOS 时损坏？

tag-icon • tag-icon centos system-installation grub uefi nouveau
是什么导致我的 EFI 分区在安装后启动 CentOS 时损坏？

我正在尝试在小型 PC 上安装最新的 CentOS 7.5 x64华硕 Eee Box EB1037。它是一个英特尔赛扬 J1900(Bay Trail) 配备板载 NVIDIA GeForce GT 820M。除非首先禁用 Nouveau，否则安装介质将锁定。这可以。但安装并随后重新启动后，EFI 分区似乎已损坏。

这个问题不是关于如何引导进行故障排除，而是了解为什么此引导失败会损坏 EFI 分区并导致 GRUB 失败。

这是安装过程：

  • 将CentOS 7.5烧录到USB
  • 引导至 USB 安装程序（grub 引导加载程序）
  • 编辑 grub 选项以添加“nouveau.modeset=0”

在此输入图像描述

  • 设置时区
  • 软件选择：最小安装（无更改）
  • 网络和主机名：设置主机名
  • 将手动分区设置为“标准分区”（无 LVM）和自动分区布局

在此输入图像描述

  • 安装继续
  • 设置 root 密码和用户帐户（作为管理员）

在此输入图像描述

  • 安装完成
  • 重启
  • 硬盘GRUB出现

在此输入图像描述

我没有更改任何 GRUB 设置（例如禁用 Nouveau）。请参阅此处的默认设置：

在此输入图像描述

尝试使用这些默认值启动 CentOS，它按预期挂起（因为我没有禁用 Nouveau）。我只能看到黑屏。显示器已打开，但键盘指示灯和背光以及光学鼠标 LED 均关闭。键盘对 ctrl-alt-del 不负责。

按住电源按钮执行硬重置。系统第二次启动到硬盘 GRUB 菜单，没有出现任何问题。尝试再次使用默认值启动，它的锁定与之前相同（正如预期的那样，因为我仍然没有禁用 Nouveau）。

请注意，我仍然插入了 CentOS USB 安装程序。在第三次重新启动时（在前两次安装后重新启动之后），系统将我带到 USB GRUB 而不是硬盘。奇怪的。弹出 CentOS USB 并使用 ctrl-alt-del 重新启动。

现在我在屏幕上看到 GRUB 闪现的一条消息，简要表明它无法读取 EFI 分区：

在此输入图像描述

过了一会儿它就消失了，我看到了这个：

在此输入图像描述

系统现在无法再引导至 EFI 分区。

为什么会发生这种情况？ EFI 分区是如何损坏的？

附加信息

安全启动是启用在 BIOS 中无法禁用，但设置为“其他操作系统”。

在此输入图像描述

该设备内部只有一个 SATA 端口，并装有三星 850 Pro 500GB SSD。尽管设置为 AHCI 并且显示为 SATA1 并且是连接到系统的唯一磁盘，CentOS 将其识别为sdb而不是sda，可能是因为它认为 USB 安装介质是sda。但是，它在安装过程中不会将 USB 驱动器显示为第二个磁盘，而是将 Samsung SSD 显示为唯一可见的驱动器。

在此输入图像描述

插入时，GRUB 将连接的 CentOS 安装 USB 介质视为 (hd0)，将板载 SATA 视为 (hd1)。移除 USB 介质后，板载 SATA 将显示为 (hd0)。有趣的是，板载 SATA 被sdCentOS 安装程序视为，但hd被 GRUB 视为。

在此输入图像描述

在此输入图像描述

强调

  • 系统有一个 Nvidia 图形处理器（Optimus？）
  • 安全启动已启用（无法禁用）
  • BIOS 将 USB 磁盘显示为附加的 SATA 磁盘？（sda安装期间，hd0在 GRUB 中）

请注意

我已经可以在安装后通过移除 USB 记忆棒来启动系统，nouveau.modeset=0然后在 上设置和更新 GRUB /boot/efi/EFI/centos/grub.cfg。

问题是要了解是什么损坏了 EFI 分区！

系统启动照片：

在此输入图像描述

答案1

这个名字\EFI\BOOT\grubx64.efi告诉我系统没有使用 CentOS 默认的 UEFI 启动路径，而是后备路径。但后备引导路径是\EFI\BOOT\bootx64.efi，它将被 SecureBoot shim 占用。因此，看起来填充程序已加载，但无法执行下一步：从后备目录加载实际的 GRUB 引导加载程序。

我的理论：

  • 安装以通常的方式设置引导加载程序：\EFI\CentOS\shimx64.efi是 SecureBoot shim 引导加载程序，并且\EFI\CentOS\grubx64.efi是实际的 GRUB 引导加载程序。该路径\EFI\CentOS\shimx64.efi已注册到 UEFI NVRAM 引导变量中。安装程序还（尝试）在默认后备/可移动媒体引导路径中使用 shim 设置第二个副本，\EFI\BOOT\bootx64.efi并将 GRUB 设置为\EFI\BOOT\grubx64.efi.
  • 在安装程序触发的第一次重新启动中，NVRAM 启动变量完好无损，固件执行“热启动”，使用\EFI\CentOS\shimx64.efi和成功启动内核\EFI\CentOS\grubx64.efi。此引导尝试随后导致挂起，因为 Nouveau 未禁用。
  • 然后，某些原因导致固件忘记 NVRAM 引导变量，导致系统尝试从后备路径引导\EFI\BOOT\bootx64.efi。当您告诉 UEFI 从特定磁盘启动但未指定启动加载程序路径时，就会发生这种情况。由于某种原因，这允许加载 SecureBoot 填充程序的后备副本，但随后加载失败\EFI\BOOT\grubx64.efi。请注意，它没有说文件已损坏：这表明该文件不存在。

现在，您可能应该efibootmgr -v查看现有的 UEFI 启动变量，并记下当前设置，或者至少记下 CentOS 启动项，以便在它再次丢失时能够重现它。在这种情况下，您可以从 CentOS 安装介质启动到救援模式并使用命令efibootmgr修复 NVRAM 变量，或者只需使用 UEFI“启动设置”菜单输入正确的设置（如果允许）。 （遗憾的是，我见过的大多数 UEFI 实现都不会。）

您还应该验证后备 GRUB 引导加载程序是否完好无损。该文件应该像/boot/efi/EFI/BOOT/grubx64.efi在 Linux 中一样可访问。验证该文件是否存在并且与/boot/efi/EFI/CentOS/grubx64.efi.

我真的不知道是什么导致 UEFI NVRAM 启动变量在第一次重新启动和第三次重新启动之间丢失。目前存在各种有缺陷的 UEFI 实现。或者您是否重置了“BIOS 设置”，作为对由 Nouveau 引起的挂起进行故障排除的一部分？重置 UEFI“BIOS 设置”可能会也可能不会重置 NVRAM 引导变量，具体取决于 UEFI 实现。

如果事实证明 UEFI NVRAM 引导变量偶尔丢失是一个固件错误，您可以检查 BIOS 升级：运行dmidecode -s bios-version以查看当前版本。根据华硕支持页面，适用于您系统的最新 UEFI BIOS 版本为 1301。华硕通常在 UEFI BIOS 本身中包含更新功能；如果您的系统是这样，您只需将更新文件保存到 EFI 系统分区（= /boot/efiCentOS 中的任何位置），进入 BIOS 设置，从那里激活更新工具，并告诉它更新文件在哪里。

NVRAM 损坏的可能原因之一是efi-pstore内核模块。如果它被启用（或内置到 CentOS 标准内核中）并且在内核崩溃时存储内核日志的功能pstore处于活动状态，则这可能会用一系列包含内核日志的变量将 NVRAM 填充到 100%。这可能导致固件检测到变量存储已损坏并自动重新初始化 NVRAM 引导变量。

如果回退/boot/efi/EFI/BOOT/grubx64.efi实际上未损坏，则无法从回退路径启动可能是由 SecureBoot shim 中的错误引起的，或者是由于 HDD 回退启动路径中过度热衷于实施安全启动（技术上是 UEFI 固件错误未记录的功能）这使得它与 SecureBoot 垫片不兼容）。在这种情况下，更新 SecureBoot 填充程序可能会有所帮助。

相关内容