无法创建 Moklist：卷已满 - grub 根本无法启动

Question 1

首先，介绍一些背景知识：您报告了一条错误消息：

Couldn't Create Moklist: Volume Full , Something serious has gone wrong, import_mok_state():failed

这是对机器所有者密钥 (MOK) 列表的引用，MOK 是与 Shim 关联的加密密钥。安全启动要求使用密钥对引导加载程序进行签名，以验证二进制文件的真实性。一些公钥存储在计算机的固件或 NVRAM 中；但唯一保证以这种方式存储的密钥属于 Microsoft，而 Microsoft 对于签名内容有规定。长话短说，大多数 Linux 发行版都使用一个名为 Shim（shimx64.efi通常为）的程序，该程序由 Microsoft 签名，并为发布该版本 Shim 的 Linux 发行版添加新密钥。Shim 还可以读取用户可以存储在所谓的 MOK 列表中的新密钥。包括 MOK 列表在内的大部分数据都存储在 NVRAM 中。

您报告的错误消息声称“卷已满”，但这是一个令人困惑的措辞，因为有问题的卷几乎肯定不是磁盘分区，而是 NVRAM 存储，它是非常尺寸有限。

安全启动机制的一部分涉及操作系统供应商定期更新另一个基于 NVRAM 的安全启动密钥池，称为dbx，它是已失效的密钥或二进制哈希列表 - 它们有已知错误或已知恶意软件，因此不应加载。您的 Windows 更新很可能包含一个dbx更新，这可能会将您的 NVRAM 存储推到极限。您的一个屏幕截图显示了一个dbx包含 77 个条目的列表（“禁止签名”）。可能还有其他东西也在占用 NVRAM 存储空间。EFI 定期对 NVRAM 存储执行“垃圾收集”以尝试清理旧数据，但这只是偶尔进行，并不能保证完全有帮助。

与任何已满或几乎已满的资源一样，基于 EFI 的计算机上的已满 NVRAM 也会产生奇怪的结果。我无法准确解释为什么某些 Linux 发行版可以正常启动，而其他发行版却不能，但我的猜测是 NVRAM 已满或几乎已满造成的。有多种方法可以测试这个假设，但我知道的主要方法比较复杂，可能不值得付出努力。

Linux 中显示的启动条目efibootmgr也存储在 NVRAM 中，因此删除旧的/未使用的条目可能已经清除了足够的空间，使系统可以开始工作。但是，如果您只删除了几个条目，那么您可能已经非常接近极限，将来可能会遇到问题。

降低未来遇到问题风险的一种方法是禁用安全启动。就其本身而言，这不会消除dbx或以其他方式减少 NVRAM 上的负载，但如果工具无法读取或修改 MOK 列表，这至少应该使它变得不重要，因为 MOK 仅由 Shim（和相关工具）使用。但是，禁用安全启动会降低系统的整体安全性——如果安装，预启动恶意软件将能够毫无问题地执行。

您也可以删除它dbx本身，或者用你创建的密钥覆盖所有密钥，但这会进入一个相当棘手的领域——并且删除dbx也会降低系统的安全性（尽管不如完全禁用安全启动那么严重）。

Answer

首先，介绍一些背景知识：您报告了一条错误消息：

Couldn't Create Moklist: Volume Full , Something serious has gone wrong, import_mok_state():failed

这是对机器所有者密钥 (MOK) 列表的引用，MOK 是与 Shim 关联的加密密钥。安全启动要求使用密钥对引导加载程序进行签名，以验证二进制文件的真实性。一些公钥存储在计算机的固件或 NVRAM 中；但唯一保证以这种方式存储的密钥属于 Microsoft，而 Microsoft 对于签名内容有规定。长话短说，大多数 Linux 发行版都使用一个名为 Shim（shimx64.efi通常为）的程序，该程序由 Microsoft 签名，并为发布该版本 Shim 的 Linux 发行版添加新密钥。Shim 还可以读取用户可以存储在所谓的 MOK 列表中的新密钥。包括 MOK 列表在内的大部分数据都存储在 NVRAM 中。

您报告的错误消息声称“卷已满”，但这是一个令人困惑的措辞，因为有问题的卷几乎肯定不是磁盘分区，而是 NVRAM 存储，它是非常尺寸有限。

安全启动机制的一部分涉及操作系统供应商定期更新另一个基于 NVRAM 的安全启动密钥池，称为dbx，它是已失效的密钥或二进制哈希列表 - 它们有已知错误或已知恶意软件，因此不应加载。您的 Windows 更新很可能包含一个dbx更新，这可能会将您的 NVRAM 存储推到极限。您的一个屏幕截图显示了一个dbx包含 77 个条目的列表（“禁止签名”）。可能还有其他东西也在占用 NVRAM 存储空间。EFI 定期对 NVRAM 存储执行“垃圾收集”以尝试清理旧数据，但这只是偶尔进行，并不能保证完全有帮助。

与任何已满或几乎已满的资源一样，基于 EFI 的计算机上的已满 NVRAM 也会产生奇怪的结果。我无法准确解释为什么某些 Linux 发行版可以正常启动，而其他发行版却不能，但我的猜测是 NVRAM 已满或几乎已满造成的。有多种方法可以测试这个假设，但我知道的主要方法比较复杂，可能不值得付出努力。

Linux 中显示的启动条目efibootmgr也存储在 NVRAM 中，因此删除旧的/未使用的条目可能已经清除了足够的空间，使系统可以开始工作。但是，如果您只删除了几个条目，那么您可能已经非常接近极限，将来可能会遇到问题。

降低未来遇到问题风险的一种方法是禁用安全启动。就其本身而言，这不会消除dbx或以其他方式减少 NVRAM 上的负载，但如果工具无法读取或修改 MOK 列表，这至少应该使它变得不重要，因为 MOK 仅由 Shim（和相关工具）使用。但是，禁用安全启动会降低系统的整体安全性——如果安装，预启动恶意软件将能够毫无问题地执行。

您也可以删除它dbx本身，或者用你创建的密钥覆盖所有密钥，但这会进入一个相当棘手的领域——并且删除dbx也会降低系统的安全性（尽管不如完全禁用安全启动那么严重）。

Question 2

因此，经过几天的努力，我终于找到了适合我的解决方案，并决定在这里分享它。

解决方案是使用 efibootmgr 并删除旧的/未使用的启动项。我无法解释，也不知道我的 Kubuntu 怎么会在一次非常小的 Windows 10 更新后从正常工作变为无法工作（也许这只是一个巧合），但这就是发生的事情，或者至少据我所知，这似乎是发生的事情。无论如何......

以下是拯救了我一切的三条终端线路：

// 获取 efibootmgr sudo apt-get install efibootmgr

// 运行 efibootmgr sudo efibootmgr

// 删除未使用的启动项 sudo efibootmgr -b 0005 -B 请注意，0005 可能是 0004、0006 等

以下是提供上述信息的视频和文章的链接：

视频“使用 Efibootmgr 修复 EFI 启动问题”

https://www.youtube.com/watch?v=MN-Q5h2Iv8A

文章“如何在 Linux 中删除旧的 EFI 启动项”

https://digitalrobin.net/2020/07/11/how-to-remove-old-efi-boot-entries-in-linux/

当我观看视频并看到未使用的条目时，我突然想到了错误的“完整”部分，这促使我找到了这篇文章。

所以，希望这对某些人有帮助。这对我来说确实是一个学习过程...

Answer