我在多引导系统上用 systemd-boot 替换 GRUB,在离散分区上有几个 Ubuntu 20.04 和 22.04 实例,因为这些实例正在争夺引导加载程序 grubx64.efi 的控制权,而 systemd-boot 显然可以更好地管理这一点。
安装失败并拒绝配置。特别是,systemd-boot 会忽略配置的引导条目,并且通常系统引导到 grub shell,需要手动引导。
我遵循的过程是推荐的。ESP 是 /dev/sda1,默认挂载到 /boot/efi。引导分区是 /dev/sda2-7,其中 2、4 和 7 最相关,其他仅临时配置。首先,我跑了:
# bootctl install
然后我配置了/boot/efi/loader/loader.conf:
# /boot/efi/loader/loader.conf
# systemd-boot configuration file
timeout 5
#default 4fa9a5bf4498415ead7dea7c2724e90a-*
# From man loader.conf, Options, default, at https://www.freedesktop.org/software/systemd/man/loader.conf.html:
default @saved
console-mode keep
然后我在 /boot/efi/loader/entries 的 .conf 文件中配置了引导条目,所有这些都采用以下形式:
# /boot/efi/loader/entries/sdx4.conf
# Boot entry configuration file.
title sdx4 - Ubuntu Desktop 22.04
linux ../vmlinuz
initrd ../initrd.img
options root=PARTUUID=9d1de6a4-452c-42d2-bf18-acee90032326 rw
然后,在推荐的重新引导时,systemd-boot 会显示一个菜单,其中仅包含默认引导加载程序的选项,该引导加载程序引导至 GRUB shell,并引导至 EFI 配置实用程序。
内核文件保留在 /boot 中,因为 linux-update-symlinks 在 /boot 中创建符号链接 initrd.img 和 vmlinuz 并且 FAT32 不支持符号链接。
bootctl status
返回
System:
Firmware: n/a (n/a)
Secure Boot: disabled
Setup Mode: user
TPM2 Support: no
Boot into FW: supported
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 information
ESP: n/a
File: └─n/a
Random Seed:
Passed to OS: no
System Token: set
Exists: yes
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 249.11-0ubuntu3.1)
File: └─/EFI/BOOT/BOOTX64.EFI
Boot Loaders Listed in EFI Variables:
Title: ubuntu
ID: 0x0000
Status: active, boot-order
Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7
File: └─/EFI/ubuntu/shimx64.efi
Title: ubuntu
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7
File: └─/EFI/debian/shimx64.efi
Title: Linux Boot Manager
ID: 0x0001
Status: active, boot-order
Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7
File: └─/EFI/systemd/systemd-bootx64.efi
Title: UEFI OS
ID: 0x0005
Status: active, boot-order
Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7
File: └─/EFI/BOOT/BOOTX64.EFI
Title: ubuntu
ID: 0x0006
Status: active, boot-order
Partition: /dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7
File: └─EFI/Ubuntu/grubx64.efi
Boot Loader Entries:
$BOOT: /boot/efi (/dev/disk/by-partuuid/3aa3442b-045b-4b22-8e8b-6c01a5571ce7)
Default Boot Loader Entry:
title: sdx7 - Ubuntu Desktop 22.04
id: sdx7.conf
source: /boot/efi/loader/entries/sdx7.conf
linux: ../vmlinuz
initrd: ../initrd.img
options: root=PARTUUID=67027db9-885b-471b-9c01-4b2108e6f7e9 rw
tree /boot/efi
返回
/boot/efi/EFI
├── BOOT
│ ├── BOOTX64.EFI
│ ├── fbx64.efi
│ └── mmx64.efi
├── debian
│ ├── BOOTX64.CSV
│ ├── grub.cfg
│ ├── grubx64.efi
│ ├── mmx64.efi
│ └── shimx64.efi
├── Linux
├── systemd
│ └── systemd-bootx64.efi
└── ubuntu
├── BOOTX64.CSV
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi
5 directories, 14 files
这是一场灾难。没有任何文档提供线索,谷歌也没有。任何关于如何让 systemd-boot 工作的建设性想法将不胜感激。
这不完全是一个答案,但我正在分享我的配置,希望它能引导您找到自己的答案。
我的efi分区内容如下:
这给了我 Arch linux 主线内核和 lts 内核以及一个实时引导 gparted 的选项。
加载程序目录包含:
arch.conf 文件包含:
gparted.conf 文件包含:
我尽我所能确定您需要做的就是摆脱
您的 conf 文件的一部分。
如果您有兴趣,gparted conf 文件会引导 gparted live iso 的提取副本,该副本位于 gparted 目录中的 efi 分区上。它使用位于 gparted 目录树下方的 gparted initrd.img 和 vmlinuz。
希望这会引导您找到可行的解决方案。请注意,initrd.img 和 vmlinuz 文件必须在启动过程开始时位于“/”的 efi FAT 分区上
事实证明systemd-boot没有实现Boot Loader Specification。根据其文档,该命令
bootctl list
是符合后者的引导加载程序条目的语法检查器,并返回:因此,我们看到通过使用 ../ 路径将内核文件的位置指定为位于 EFI 系统分区挂载点的父目录中不仅符合引导加载程序规范的语言(我应该赶紧add 不包含要求内核文件位于 ESP 上的语言)但也包含实现它的代码。
除了我之外,还有人浪费了很多精力。
Das Gummiboot wird gesunken。
漂浮沉船的方法是不符合引导加载程序规范、语法检查器或任何其他文档,而是正如@PonJar 所指出的那样,将内核文件移动到 ESP。
这需要一连串的重新配置,包括手写大量安装脚本来彻底检查内核安装/升级过程,以及实际将内核文件连根拔起以便移植到 ESP(嗯?)。尾巴摇着狗。
使 systemd-boot 符合引导加载程序规范,特别是通过使其能够读取位于任何位置的内核文件,包括正在引导的分区的文件系统上,将使上述全部内容变得不必要。
事实上,systemd-boot 似乎在架构上存在缺陷,并且试图做太多事情。该
kernel-install
命令及其相关bootctl
选项的存在只是为了补偿 systemd-boot 的执行限制或 systemd-bootx64.efi 的执行限制。毕竟,它是一个引导加载程序,它的全部目的是在另一个分区上执行内核,但它不能,结果就是这种复杂性。如果 systemd-boot 可以执行安装的内核,所有必要的配置将是 loader.conf 和 /loader/entries .conf 文件。
我从这篇文章中直接或以其他方式收集的程序,并感谢海报 dalto,包括:
将 ESP 挂载到 /boot/efi
安装 efibootmgr;删除 grub*
从 /etc/kernel 的子目录中删除 zz-update-grub 的所有实例
将 GRUB_CMDLINE_LINUX_DEFAULT 下 /etc/default/grub 中出现的所有内核命令行复制到 /etc/kernel/cmdline
做
# bootctl install
创建并标记为可执行文件 /etc/kernel/postinst.d/zz-systemd-boot (小心剪切和粘贴以下内容,因为这里的格式化界面在脚本上会出现):
#!/bin/sh -e
版本="$1" bootopt=""
如果 [ "$INITRD" = '否' ]; 然后退出 0 fi
如果 [ -n "$DEB_MAINT_PARAMS" ]; 然后'
菲
内核安装添加“$version”“/boot/vmlinuz-$version”
创建并标记为可执行 /etc/kernel/postrm.d/zz-systemd-boot (再次注意接口格式破坏):
#!/bin/sh -e
版本="$1" bootopt=""
如果 [ -z "${版本}" ]; 然后
菲
内核安装删除“$版本”
做:
sudo mkdir -p /etc/initramfs/post-update.d
cd /etc/initramfs/post-update.d/ && sudo ln -s ../../kernel/postinst.d/zz-systemd-boot zz-systemd-boot
最后为当前内核运行 kernel-install。
等待 systemd-boot 的下一个版本,愿原力与您同在。