[已解决]Tumbleweed安装的过程中出错ERROR: No free space in /boot/efi for new kernel

[java2learner]

我前几天安装Tumbleweed的时候出现了如下错误：

Error

Cannot create boot menu entry:
Command [["/usr/bin/sdbootutil", "add-all-kernels"]].
Error output: Thu Dec 18 16:39:23 2025 <3> Snapshot.cc(check):386 snapshot num 1 in future

ERROR: No free space in /boot/efi for new kernel

---

live/net/offline三种镜像都试过了，都会出现同样的错误。ubuntu和leap都没有问题。

[java2learner]

以下内容来自ai。

你遇到的这个报错，本质原因不是“镜像类型（live/net/offline）不同”，而是 Tumbleweed 近一年多引导方案的默认值变了：安装器在 UEFI 下默认使用 GRUB2-BLS（也叫 grubbls），它遵循 Boot Loader Specification（BLS），并且 把 kernel 和 initrd 也放进 EFI System Partition（ESP，挂载到 /boot/efi），所以 ESP 变小（比如很多 Windows 机器只有 100MB）就会直接装不下，从而出现：

ERROR: No free space in /boot/efi for new kernel

这和 Ubuntu / Leap 默认的做法不同：它们通常用“传统 GRUB2”，内核在 Linux 分区的 /boot，ESP 里主要放 EFI 引导器文件本身，所以对 ESP 空间要求小很多。

---

1) 为什么 Tumbleweed（现在）会更“吃”EFI 分区空间？

A. Tumbleweed 现在默认 GRUB2-BLS（grubbls），设计上就需要把内核+initrd放到 ESP

openSUSE 官方在 2025-11-13 的公告里明确写了：Tumbleweed 通过 YaST 安装时，默认 boot loader 从传统 GRUB2 切换为 GRUB2-BLS，BLS 启动项文件放在 /boot/efi/loader/entries。

更关键的是同一篇公告也写了：安装器会建议创建大约 1GB 的 ESP，因为 “所有 kernel 和 initrd 现在都会放在 FAT32 的 ESP 分区里（位于 /boot/efi/opensuse-tumbleweed）”。

这就直接解释了你的问题：不是 Tumbleweed“系统本体”变大了，而是默认引导布局改变，导致 ESP 从“只放引导器”变成“还要放内核和 initrd 的 boot 分区角色”。

B. Btrfs + Snapper 快照集成，会让“需要保留的可启动内核集合”变多

Tumbleweed 默认使用 Btrfs + Snapper 快照。BLS/快照集成的目标是：每个可回滚快照都尽量保持“可启动”。openSUSE 的 systemd-boot 集成文章解释了实现方式：通过 sdbootutil 在 ESP 里生成 Type #1 BLS 启动项，并 把快照里的内核复制到 ESP，同时为这些快照生成匹配的 initrd。

即使你只装一个“标准内核”，随着更新与快照保留策略的存在，ESP 里也往往不止“一份内核+initrd”。

C. 这也是为了更容易接入 FDE（全盘加密）/TPM2/FIDO2 等新特性

GRUB2-BLS 的引入（以及复用 sdbootutil 那套工具链）其中一个动机就是更好支持 systemd 工具栈的全盘加密能力（TPM2/FIDO2 自动解锁等）。openSUSE 的 BLS 介绍文章明确提到：这让 openSUSE 可以复用 systemd-boot 的架构与工具（例如 sdbootutil、snapper/tukit 插件）。

---

2) 你的报错里那行 “snapshot num 1 in future” 是什么？

你日志里这段：

Snapshot.cc(check):386 snapshot num 1 in future

它看起来是 snapper/快照检查时打的日志（通常是 warning/notice 级别），经常在 sdbootutil 处理“为快照生成启动项”过程中出现。

在 openSUSE 论坛的类似案例里，当 ESP 空间不足导致 sdbootutil 失败时，会连带出现一串 “snapshot check failed … not adding snapshot …” 之类信息。也就是说：快照相关提示往往是“引导项生成流程被打断”的伴生输出；真正导致安装终止的是后面的 ESP 空间不足。

（另外一种常见触发条件是机器时间被校正/回拨，导致“某个快照时间戳看起来在未来”，但在你这条错误里，即便把这条 warning 忽略，ESP 空间不足仍然会让安装失败。）

---

3) 为什么 Ubuntu 和 Leap 没这个问题？

因为它们多半仍是“传统模式”：

• 传统 GRUB2：ESP 里放 shimx64.efi/grubx64.efi 之类引导器；真正的 kernel/initrd 在 Linux 分区（/boot）里，GRUB 读取 Linux 文件系统后再加载内核，所以 ESP 压力小。
• Tumbleweed 的 GRUB2-BLS / systemd-boot 路线：BLS 启动项、kernel、initrd 通常都需要放在 ESP 或 XBOOTLDR 分区上，bootloader 才能直接枚举并启动它们，因此需要更大的 ESP。

---

4) 解决办法（不绕弯，按优先级）

方案 1（最简单）：安装时别用 GRUB BLS，改回传统 GRUB2-efi

openSUSE 论坛里跟你几乎同一天（2025-12-18）的案例，解决办法就是在安装总结页把 “GRUB BLS” 改为 “GRUB EFI（传统 grub2-efi）”。该模式不会把内核塞进 ESP，因此 100MB ESP 也更可能够用。

方案 2（按官方新默认走）：把 ESP 做大（至少 ~1GB，更建议留余量）

如果你就是想用 GRUB2-BLS（或 systemd-boot / FDE/TPM 那套新栈），那就按 openSUSE 公告建议：ESP 做到约 1GB 是“必需条件”。

现实里不少 Windows 机器的 ESP 只有 100MB/260MB，双系统时确实会卡住。

方案 3（进阶）：新建第二个 ESP（或 XBOOTLDR），让 openSUSE 用新的

如果你“不能扩容第一个 ESP”（常见于磁盘开头是 ESP，后面紧挨着 Windows 分区），可行的思路是：

• 在磁盘后面划出一个新的 FAT32 分区，标记为 ESP（不同固件支持程度不一）
• 让 openSUSE 把 /boot/efi 挂到这个新 ESP 上，并用 efibootmgr 注册启动项

这属于偏进阶/看机器固件脸色的方案，但在“不能动 Windows ESP”时常被采用。

---

5) 一句话总结你这次的“根因”

你在 2025-12-18 左右安装 Tumbleweed 时，安装器默认走了 GRUB2-BLS（grubbls）；该模式会把 kernel + initrd 放进 ESP（/boot/efi），官方也因此建议 ESP 约 1GB；而你的 ESP 太小，于是 sdbootutil add-all-kernels 无法创建启动项并报 No free space。