使用自定义的引导加载程序 ID，例如“MyUbuntu”，安装 grub。

Question

使用自定义的引导加载程序 ID，例如“MyUbuntu”，安装 grub。

grub2

3

我可以使用默认的引导加载程序ID“ubuntu”重新安装grub。

但是，如果我使用自定义名称，比如“MyUbuntu”，我无法成功安装grub。

在一个正常启动的Ubuntu 18.04上进行测试安装：

1：删除现有的grub：

rm -r /boot/efi/EFI/*

2：安装新的grub：

grub-install --target=x86_64-efi --bootloader-id=MyUbuntu /dev/sda

3：更新grub： update-grub

系统现在可以进入Grub控制台。 EFI在启动菜单中完美地看到了新的启动项。

刚刚看了一眼/boot/grub/grub.cfg，它仍然显示： menuentry 'Ubuntu' --class ubuntu.....

- MrCalvin

1我有一个自定义的条目，但它实际上不起作用，因为UEFI条目实际上使用的是/EFI/ubuntu/grub.cfg而不是我的/EFI/Ubuntu_18_04/grub.cfg。所以我只有一个有效的UEFI条目，如果我想要更改默认引导，就必须编辑ESP中的grub.cfg。然后我使用grub来引导其他安装。 - oldfred

那么这是一个bug还是设计如此的呢？ - MrCalvin

这是有意为之的，但开发人员多年来一直表示他们想要修复它。显然不是优先考虑的事情。 - oldfred

有什么解决办法吗？我需要一个非默认的EFI文件夹？我在.cfg文件中找了一下，但没有找到任何有用的信息。 - MrCalvin

我相信我看到过有人拥有两个FAT32格式的分区，并来回移动引导标志，改变哪一个是ESP。但是grub可以直接引导任何你想要的安装，链式引导或者使用configfile（加载另一个grub）。 - oldfred

我想知道你是否可以使用非Ubuntu版本的grub-install，例如从Archlinux live.iso启动。也许bootloader-id不会被硬编码到.efi文件中。如果是这样的话，Ubuntu还能正常启动吗？ - MrCalvin

如果你有任何实验，请告诉我们。我曾经尝试过 Fedora，它允许我直接安装到 sdb，并找到了我的 Ubuntu 安装。没有尝试其他实验。 - oldfred

真的起作用了！:-) 我使用了来自Debian buster的grub-install，现在我的引导程序ID是ubuntu2 我可以想象安全启动可能不起作用。似乎Ubuntu硬编码ID的整个原因是引导程序已签名，因此无法修改，当然你可以修改，但那样它就不再被签名了。但是我根本不使用安全启动，所以我不在意。 - MrCalvin

我多年来一直使用你的方法，一点问题都没有，对我来说它就是开箱即用。你说你不使用安全启动，但是你的菜单项指向shimx64.efi。我的菜单项指向grubx64.efi（我也不使用安全启动）。 - mook765

3个回答

1

如 gdeff所提到的, 若要使用自定义--bootloader-id安装Grub，请同时使用 --no-uefi-secure-boot选项。例如：

grub-install                \
  --target=x86_64-efi       \
  --no-uefi-secure-boot     \
  --bootloader-id=MyUbuntu  \
  /dev/sda

此外，请确保您的系统上已禁用SecureBoot。

解释：

只有当您想更好地理解grub-install、grubx64.efi、grub.cfg和SecureBoot之间的交互作用时，才需要阅读下面（不幸而冗长的）解释。

SecureBoot仅会引导由Microsoft进行加密签名的.efi文件。
在Ubuntu系统上，文件/boot/efi/EFI/ubuntu/grubx64.efi通常来自以下两个位置之一：
选项1：grubx64.efi是一个静态的、不变的、由Canonical提供的经过Microsoft签名的、与SecureBoot兼容的“二进制块”Grub引导加载程序。这是默认选项。
选项2：当您运行grub-install时，在您的系统上创建了grubx64.efi。在这种情况下，grubx64.efi没有签名，因此与SecureBoot不兼容。

使用选项1（由Canonical提供的，与SecureBoot兼容的grubx64.efi）：

通常会有两个grub.cfg文件。
第一阶段grub.cfg位于/boot/efi/EFI/ubuntu/grub.cfg
第二阶段grub.cfg位于/boot/grub/grub.cfg
第一阶段grub.cfg文件包含了grubx64.efi需要找到并读取第二阶段grub.cfg文件所需的信息。
第一阶段grub.cfg文件的路径/boot/efi/EFI/ubuntu/grub.cfg不能更改。更改此路径将需要更改grubx64.efi本身。更改grubx64.efi将使签名无效，从而与SecureBoot不兼容。

使用选项2（自定义的grubx64.efi）：

没有第一阶段的grub.cfg文件，因为...
所有定制的grubx64.efi引导加载程序所需的配置信息，以便找到并读取第二阶段的grub.cfg文件（/boot/grub/grub.cfg），直接嵌入在定制的grubx64.efi文件本身中。
这是可能的，因为定制的grubx64.efi引导加载程序与SecureBoot不兼容，因此不需要由Microsoft签名。

如果您使用grub-install命令带有--bootloader_id=参数且不带有--no-uefi-secure-boot参数运行，则：

grub-install将使用由Canonical提供的经过Microsoft签名的grubx64.efi文件。（这是上面的选项1。）
这个grubx64.efi文件和一个定制的phase-1 grub.cfg文件将被安装在：/boot/efi/EFI/$bootloader_id/
然而，在启动时，grubx64.efi文件将尝试读取/boot/efi/EFI/ubuntu/grub.cfg（因为这个路径不能改变）。
如果/boot/efi/EFI/ubuntu/grub.cfg不存在，则引导将失败。
如果/boot/efi/EFI/ubuntu/grub.cfg存在，但来自同一系统上不同的Ubuntu安装，则引导可能会失败，或者grubx64.efi可能会引导到其他Ubuntu系统而不是所需的Ubuntu系统。
附注：在这种情况下（即缺少--no-uefi-secure-boot），可以认为：grub-install应该生成一个错误（或至少是一个大声的警告），而不是悄悄地安装一个很可能配置不正确的引导加载程序。

或者，如果你运行grub-install 带有--no-uefi-secure-boot参数，那么：

grub-install将创建一个定制的（且未签名的）grubx64.efi文件。
/boot/efi/EFI/$bootloader_id/目录下将没有phase-1的grub.cfg文件。
这个grubx64.efi文件将能够自行找到并读取位于/boot/grub/grub.cfg的phase-2的grub.cfg文件。

正如在本答案开头提到的，如果你使用--no-uefi-secure-boot，你需要确保系统上关闭了SecureBoot。

- mpb

0

我使用了一个简单的解决方法。在运行grub-install时，加上--bootloader-id参数，然后再次运行grub-install，不带任何参数。这样会创建一个Ubuntu条目。如果你想要的话，可以删除它，但现在你的ID将会“神奇地”起作用。非常令人恼火，似乎是一个旧的错误。希望对你有所帮助。

- dgow

3这看起来似乎是有效的，但如果删除了"ubuntu"条目，则自定义的引导加载程序ID将无法工作。无需重新运行不带参数的grub-install命令；只需禁用UEFI安全启动并运行grub-install --bootloader-id=myid --no-uefi-secure-boot请参阅使用EFI引导多个Ubuntu版本 - gdeff

@gdeff 你真是救星！谢谢 :) 添加 --no-uefi-secure-boot 会生成一个不同的 grubx64.efi 文件，这样就解决了缺少 EFI/ubuntu 文件夹的问题。 - Tomeg

然后你需要在UEFI中禁用“安全启动”（有些人错误地称之为BIOS）。 - Joepie Es

相关问题

- MrCalvin · Accepted Answer

在我遇到 systemd-boot 作为引导加载程序后，我再也没有回头使用 GRUB。在我的观点中，systemd-boot 更加稳定，并且具有更好的配置方式。而且，“稳定”意味着它不像 GRUB 那样容易受到攻击。GRUB 很容易出问题。只要向您的计算机添加一个新硬盘可能会给您带来很大麻烦（可能是因为无法更改引导加载程序 ID 等原因）。

systemd-boot 的唯一缺点是缺乏安全引导支持，但这对我来说不是问题，并且您的内核必须位于 EFI 分区中，而不是根分区中，这与 GRUB 的情况不同。

通过 systemd-boot，我重新获得了对启动过程的完全控制...是的

它应该成为默认的引导加载程序，而不是 GRUB。

更新，如何操作（Debian/Ubuntu）：
（这只是一个简要指南，但希望能帮你入门。其他来源：Arhlinux..，freedesktop.. 和 readme..）

1：首先从根分区复制内核文件，例如 /boot/vmlinuz-4.9.0-8-amd64 和 /boot/initrd.img-4.9.0-8-amd64，到你的 EFI 分区。你可以将它们放在你喜欢的子文件夹中，甚至可以放在根目录。

2：许多指南说你需要访问 EFI 变量，但我不确定这是否必要。但是为了测试是否拥有权限，请运行 efivar --list。
如果缺少，请安装：apt install efivar

3: 将systemd-boot加载器安装到EFI分区：bootctl --path=/mnt/efi install（使用您自己挂载的EFI分区路径）。

4: 编辑文件/mnt/efi/loader/loader.conf，修改为以下内容：

timeout 5
# default 6a9857a393724b7a981ebb5b8495b9e-*

（还没弄清楚如何在文件中使用自动添加的UUID，所以我只是标记了出来）

5：/mnt/efi/loader/entries/*.conf目录中的每个文件对应systemd-boot菜单中的一个引导项。因此，要添加当前操作系统，请创建一个类似以下内容的文件：

title      Debian 9 :-)
linux      /debian9/vmlinuz-4.9.0-6-amd64
initrd     /debian9/initrd.img-4.9.0-6-amd64
options    root=UUID=084917b7-8be2-4e86-838d-f771a9902e08`

（在步骤1中修改复制的内核文件路径。将UUID修改为根分区的文件系统UUID（使用Linux命令lsblk -o name,uuid））

（一般信息：
bootctl会在您的EFI分区中安装两个引导加载程序文件：）

../BOOT/BOOTX64.EFI
../systemd/systemd-bootx64.efi

这些文件是相同的。您的主板上的EFI BIOS必须引导/指向其中之一。可以直接在BIOS中进行设置，或者使用Linux命令efibootmgr.... 要添加新的启动项，只需创建一个新的/mnt/efi/loader/entries/*.conf文件，该文件指向正确的内核文件和根分区。

内核文件必须位于EFI分区（FAT32）上。 EFI分区的大小必须相应调整。我认为Debian/Ubuntu的内核文件大约为50-60MB。所以如果您有两个安装，您需要120MB的空间。