为什么Ubuntu安装继续失败与‘/dev/sda失败’错误？

Question

目标：我正在尝试将Ubuntu安装到戴尔XPS 8900上。

问题：如果没有Unable to install Grub in /dev/sda，Executing 'grub-install /dev/sda failed.' This is a fatal error.的安装中断，我无法通过Ubuntu安装。而且，boot-repair没有解决这个问题。

安装程序：我使用的是带有Ubuntu22.04LTS安装程序的闪存驱动器。我曾经尝试过用我以前安装过的闪存，并且在我用应用程序创建的另一个闪存上尝试了一个新的安装。注意:我在grub命令中添加了nomodeset和acpi=off，以启动。

解决的Attempts：

• 我试着在askubuntu上使用一些答案来完成grub-安装自己。通过退出安装程序提示符(失败后)并在终端中运行命令，我完成了上述修复。我在这里成功地完成了grub安装。但是，当初始错误在安装过程中部分发生时，由此产生的Ubuntu出现了多个问题。我的服务可能会失败，或者只是没有启动(包括但不限于: networkd-dispatcher.service、NetworkManager.service、fwupd-ereplh.service、apparmor.service、caspermd5.services(?) )，我还留下了安装遗留下来的部分(例如，我的应用程序中还保留了一个名为安装发行版的应用程序 )。
  • 注意：chroot进入/mnt并在unable to allocate pty: No such device中运行grub-install /dev/sda结果

• 最上面的答案建议单击“尝试Ubuntu”，然后使用InstallUbuntu24.04LTS应用程序，这对我不起作用。
• 最上面的答案建议grub安装到错误的设备上，这对我来说不是真的。
• 我现在很绝望，所以我更新了BIOS的最新更新。什么都没做。
• 在运行Try Install应用程序之前，我试过运行grub-install。
  • 注意:在sudo grub-install --root-directory /mnt /dev/sda中运行grub-instal: error: failed to register the EFI boot entry: Operation not permitted.结果
  • 此外，我担心即使我能够在运行Ubuntu安装程序之前成功地运行grub-install，Ubuntu安装程序仍然会失败，因为Ubuntu安装程序可能在没有选项的情况下运行grub。

• boot-repair说NVram被锁住了。我看了关于清除NVRAM的建议的重置CMOS。在重新设置CMOS后，在安装过程中仍然会收到相同的错误消息。

<#>问题：为什么Ubuntu22.04LTS安装由于“/dev/sda失败”错误而继续失败？

Result of boot-info：

• https://pastebin.com/tLfzEF8w
• https://paste.ubuntu.com/p/BQNbny9528/

Result of boot-repair：

• https://pastebin.com/z4ftZ8mW
• https://paste.ubuntu.com/p/Shc4V4xB9T

Answer 1

NVram Locked听起来可能有一些问题，写入UEFI变量，这些变量在Linux中可以通过/sys/firmware/efivars或使用efibootmgr工具访问。

如果您正在访问失败的安装，方法是将其安装在/mnt/chrootdir和chroot下，如对你所链接的AskUbuntu问题的回答中所建议的那样，我建议对/dev和/sys使用mount --rbind而不是mount --bind，因为这两个系统都包含单独的子文件系统，这对于grub-install功能非常重要：

• 如果/dev/pts在着色环境中不可用，则会导致unable to allocate pty: No such device错误。
• 如果/sys/firmware/efi/efivars在着色环境中不可用，则会导致写入UEFI变量的尝试失败.这正是你的首要问题。

但是，如果这没有帮助，您可能需要阅读这是罗德里克·W·史密斯的精彩网页，它解释了其他OSs或But固件实现可能导致的某些问题，并给出了解决这些问题的方法。

在您的sda1磁盘上，显然有一个efi/ubuntu/grub.cfg文件，其内容如下：

search.fs_uuid 2D07-0F0A root hd0,gpt1 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

这似乎不正确:它是通过文件系统UUID查找ESP分区(sda1)，然后假设它应该是一个包含/boot/grub的Linux根文件系统.这不是真的，因为sda1是UEFI，而不是Linux文件系统。

相反，该文件应该包含以下内容：

search.fs_uuid 25f0e88-f20a-4350-9df0-ee8c57ecc455 root hd0,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

您可能也希望将此efi/ubuntu/grub.cfg复制到efi/BOOT/grub.cfg (也在sda1上)，以便GRUB即使以efi/BOOT/BOOTx64.efi的形式启动也可以找到有效的配置。

该配置文件将导致ESP上的grubx64.efi通过文件系统UUID查找真正的Ubuntu分区(sda2)，然后从那里加载任何必要的GRUB模块，并从sda2上的/boot/grub/grub.cfg加载真正的GRUB配置。

您还可能希望将efi/ubuntu/grubx64.efi复制到efi/BOOT/grubx64.efi on sda1中，以确保UEFI回退/可移动媒体引导路径上也有完整的引导文件集。

引导修复输出的这一部分实际上是由efibootmgr -v生成的：

BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0004
Boot0003* UEFI: TOSHIBA TransMemory 1.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/HD(2,GPT,9240a165-d190-4ab6-8a12-46dc207b42ee,0x71e8a0,0x2130)..BO
Boot0004* UEFI: ST2000DM001-1ER164  HD(1,GPT,22c1dbaf-a26e-4408-a6f9-d1fc06b0d615,0x800,0x100000)/File(EFI\boot\bootx64.efi)..BO

它表明，尽管您目前已从USB引导，但您的系统固件已经准备好从sda1启动(由PARTUUID 2c1dbaf-a26e-4408-a6f9-d1fc06b0d615使用文件回退/可移动媒体引导路径EFI/boot/bootx64.efi标识)( ESP上的文件系统是vfat，因此它应该是不区分大小写的.但是一些UEFI固件实现不是这样的)。因此，如果您可以对ESP执行上述更改，系统可能可以从sda1启动。

如果您可以获得运行在UEFI模式下的常规Ubuntu系统，您可以重试sudo grub-install /dev/sda重写引导加载程序，并自动重写Ubuntu的NVRAM引导变量。或者，您也可以使用efibootmgr命令自己尝试并精确修复引导变量：

sudo efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\ubuntu\\grubx64.efi -L Ubuntu 

(此命令要求/dev/sda1作为/boot/efi挂载，efivarfs文件系统安装在/sys/firmware/efi/efivars上。这两种情况都应该由正常的Ubuntu引导过程自动处理。)

如果这在"NVram锁定“或类似的情况下仍然失败，您可能有一个but的UEFI实现，但至少它允许您使用回退/可移动媒体路径引导Ubuntu。