拥有 (2) 个 Linux Mint 20.1 系统 - 一个常规硬件,一个 VMware VM。我已在两者上安装/配置systemd-boot
,但我在每个上看到不同的可用设置。到目前为止,我可以指出的唯一区别是我从常规硬件系统中删除了 GRUB:
常规硬件
System:
Firmware: n/a (n/a)
Secure Boot: disabled
Setup Mode: user
Current Boot Loader:
Product: n/a
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
✗ Support for XBOOTLDR partition
✗ Support for passing random seed to OS
✗ Boot loader sets ESP partition information
ESP: n/a
File: └─n/a
Random Seed:
Passed to OS: no
System Token: not set
Exists: yes
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/82492fa6-1969-4569-851b-269909138b7b)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 245.4-4ubuntu3.4)
File: └─/EFI/BOOT/bootx64.efi (systemd-boot 245.4-4ubuntu3.4)
Boot Loaders Listed in EFI Variables:
Title: Linux Boot Manager
ID: 0x0000
Status: active, boot-order
Partition: /dev/disk/by-partuuid/82492fa6-1969-4569-851b-269909138b7b
File: └─/EFI/systemd/systemd-bootx64.efi
Boot Loader Entries:
$BOOT: /boot/efi (/dev/disk/by-partuuid/82492fa6-1969-4569-851b-269909138b7b)
Default Boot Loader Entry:
title: Linux Mint XFCE 5.4.0-65-generic
id: linuxmint.conf
source: /boot/efi/loader/entries/linuxmint.conf
linux: /linuxmint/vmlinuz
initrd: /linuxmint/initrd.img
options: root=UUID=408c53a0-e8d0-417f-8281-eb0eea0a2318 rw rootflags=subvol=@ iommu=pt
虚拟机
System:
Firmware: UEFI 2.31 (VMware, Inc. 1.00)
Secure Boot: disabled
Setup Mode: user
Current Boot Loader:
Product: systemd-boot 245.4-4ubuntu3.4
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ Default entry control
✓ One-shot entry control
✓ Support for XBOOTLDR partition
✓ Support for passing random seed to OS
✓ Boot loader sets ESP partition information
ESP: /dev/disk/by-partuuid/0a3b1b4f-28e9-44ae-a15e-629a3242f8a6
File: └─/EFI/systemd/systemd-bootx64.efi
Random Seed:
Passed to OS: no
System Token: not set
Exists: yes
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/0a3b1b4f-28e9-44ae-a15e-629a3242f8a6)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 245.4-4ubuntu3.4)
File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 245.4-4ubuntu3.4)
Boot Loaders Listed in EFI Variables:
Title: Linux Boot Manager
ID: 0x0005
Status: active, boot-order
Partition: /dev/disk/by-partuuid/0a3b1b4f-28e9-44ae-a15e-629a3242f8a6
File: └─/EFI/systemd/systemd-bootx64.efi
Title: ubuntu
ID: 0x0004
Status: active, boot-order
Partition: /dev/disk/by-partuuid/0a3b1b4f-28e9-44ae-a15e-629a3242f8a6
File: └─/EFI/ubuntu/shimx64.efi
Boot Loader Entries:
$BOOT: /boot/efi (/dev/disk/by-partuuid/0a3b1b4f-28e9-44ae-a15e-629a3242f8a6)
Default Boot Loader Entry:
title: Linux Mint XFCE 5.4.0-65-generic
id: linuxmint.conf
source: /boot/efi/loader/entries/linuxmint.conf
linux: /linuxmint/vmlinuz
initrd: /linuxmint/initrd.img
options: root=UUID=c15f5a73-6120-4cfd-81ef-c5891e4dbdf6 rw rootflags=subvol=@
我有一种感觉,我删除了一些不应该删除的东西,但我不希望 GRUB 回来(在其软件包升级后,它已经这样做过一次)。
更新#1:我从虚拟机中删除了 GRUB 软件包,验证其 /boot/efi 具有与我的主系统相同的(二进制)文件。仍然出现上述错误。
更新:2:结果sudo efibootmgr -v
:
No BootOrder is set; firmware will attempt recovery
更新 3:结果efivar -l
:
7b59104a-c00d-4158-87ff-f04d6396a915-SecureBootSetup
77fa9abd-0359-4d32-bd60-28f4e78f784b-Kernel_EntRevokeSiStatus
77fa9abd-0359-4d32-bd60-28f4e78f784b-Kernel_ATPSiStatus
77fa9abd-0359-4d32-bd60-28f4e78f784b-Kernel_WinSiStatus
77fa9abd-0359-4d32-bd60-28f4e78f784b-Kernel_SkuSiStatus
77fa9abd-0359-4d32-bd60-28f4e78f784b-Kernel_RvkSiStatus
77fa9abd-0359-4d32-bd60-28f4e78f784b-Kernel_SiStatus
77fa9abd-0359-4d32-bd60-28f4e78f784b-CurrentPolicy
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
97e8965f-c761-4f48-b6e4-9ffa9cb2a2d6-DeploymentModeNv
4599d26f-1a11-49b8-b91f-858745cff824-StdDefaults
答案1
看起来bootctl
“常规硬件”系统上的命令无法确认系统是否已使用systemd-boot
.这可能是因为该系统的 UEFI 固件中存在一些错误或怪癖,或者因为系统实际上尚未启动systemd-boot
。
请在“常规硬件”系统上运行efibootmgr -v
并将输出添加到您的原始帖子中。这将显示 UEFI 启动变量的实际内容:查看原始数据而不仅仅是bootctl
对其进行分析可能会提供更多有关正在发生的情况的线索。
您似乎根本没有任何名称为 的变量8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot*
。就像您所有的 UEFI 启动变量都已被清除一样。这肯定可以解释为什么bootctl status
当前的引导加载程序似乎不确定:它没有找到8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
记录固件当前引导系统的方式的引导变量。
如果删除 GRUB 导致所有引导变量被删除,这可能是一个错误:这是对任何其他引导加载程序的不必要的反社会行为。或者也许这是一个 UEFI 固件错误:一些供应商的 UEFI 固件实现会自动清除任何引用不再存在的磁盘或分区的启动变量,但也许这个在清理方面有点过于热心了? (系统固件更新可能会解决该问题。)
缺少 UEFI 启动变量会导致固件尝试从它能找到的任何磁盘查找 ESP 分区,其顺序可能只有固件程序员知道。当它找到/EFI/BOOT/BOOTX64.EFI
(相对于 ESP 分区的根目录;在 Mint 中,它的完整路径是/boot/efi/EFI/BOOT/BOOTX64.EFI
)时,它将使用它来启动系统。在可移动媒体上,固件可以理解的任何文件系统上的存在/EFI/BOOT/BOOTX64.EFI
可能足以从该媒体启动。
/boot/efi
假设包含 ESP 分区(即文件系统)的磁盘是/dev/sda
,您可能需要运行以下命令:
sudo efibootmgr -b 0000 -c -d /dev/sda -l \\EFI\\systemd\\systemd-bootx64.efi -L "Linux Mint"
这应该创建8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000
引导变量并使其systemd-bootx64.efi
正确指向引导加载程序。它还将为该启动选项提供一个人类可读的名称“Linux Mint”;您也许可以在固件启动设置中看到它(您可能将它们称为“BIOS 设置”)。
它还应该自动创建8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
变量,并使引导选项 0000(即上面刚刚创建的变量)成为目前第一个也是唯一一个活动的引导选项。
如果使用 添加时启动变量似乎没有“粘住” efibootmgr
,那么您的系统肯定有一个奇怪的 UEFI 固件。每个供应商的第一个 UEFI 实现往往存在稍后修复的错误:如果您的“常规硬件”系统不是全新的,它可能仍然具有早期 UEFI 实现之一。您可以尝试看看是否可以在固件设置菜单中添加 UEFI 引导加载程序路径;这样做可能会满足未知条件,使固件拒绝由 . 创建的任何引导变量efibootmgr
。
在这种情况下,您可能还想阅读Roderick W. Smith 关于“靴子妙招”的页面- 它主要是根据 rEFInd 引导加载程序编写的,但它很好地描述了各种 UEFI 固件怪癖和可用的解决方法。