无法更新UEFI dbx

Question

我的Ubuntu（20.04）软件提示有新的固件可用：UEFI dbx 77--> 217（？），但当我尝试更新时，出现以下错误信息：

Impossible to update UEFI dbx.
Blocked executable in the ESP, ensure grub and shim are up to date:/boot/efi/EFI/Boot/shimx64.efi Authenticode checksum [_checksum code_] is presente in dbx.

我不太确定这意味着什么，如果我理解正确的话，为什么会从版本77跳到217。关于系统的细节再多一点：

$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          12
On-line CPU(s) list:             0-11
Thread(s) per core:              2
Core(s) per socket:              6
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           165
Model name:                      Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz

- Py-ser

---

Ubuntu的版本在问题中总是有帮助的。此外，CPU信息与问题有何关联？ - David

编辑以添加Ubuntu版本 - Py-ser

其他答案可能是正确的，但有一个小细节：dbx是UEFI安全启动变量，它保存用于识别不受信任的引导加载程序的信息。它实际上没有版本号。很有可能“77->217”注释是说它从77个条目扩展到217个条目。我在2020年购买的一台计算机带有77个dbx条目，自那时以来这个数字已经显著增加。我不知道217是否是当前数字，但这是有道理的。（微软维护着一个更或多或少标准的dbx条目集。） - Rod Smith

Answer 1

我在我的戴尔5820上遇到了类似的问题，使用的是Ubuntu 22.04。我建议检查是否使用了二进制文件。

为此，我建议检查引导项中是否列出了文件/boot/efi/EFI/Boot/shimx64.efi。

efibootmgr -v

在我的情况下，没有列出，但使用了更新一些的文件（注意路径上的细微差异）/boot/efi/EFI/ubuntu/shimx64.efi。

然后我注意到/boot/efi/EFI/Boot/shimx64.efi比/boot/efi/EFI/Boot/中的其他文件要旧几年。

sudo ls -lah /boot/efi/EFI/Boot/

然后我将其移除，升级顺利完成。

sudo rm /boot/efi/EFI/Boot/shimx64.efi

sudo fwupdmgr update

- Benoit

Answer 2

你的Ubuntu Linux 20.04 LTS包含了旧版本的grub2和其他引导软件，这些软件因安全问题在DBX版本217中被列入黑名单。更新PC闪存中的DBX数据库将导致你的系统在未来（在UEFI安全启动模式下）无法启动。这是无法恢复的！

除非你已经升级到不在DBX中被排除在引导之外的Ubuntu 22.04 LTS及其grub2等，否则不建议更新到DBX版本217。fwupdmgr会为你检查兼容性，因此拒绝更新DBX到可能使你的PC系统无法运行的版本。

建议：

1. 不要更新并接受安全风险
2. 将Ubuntu升级到当前版本，如22.04 LTS或22.10，然后再进行DBX版本217的更新。这样应该可以工作并最小化安全风险。

注意：如果更新到DBX版本217，然后从那时起以UEFI-BIOS中禁用安全启动的方式启动系统，那将是没有意义的。那样你将不得不接受更多的安全风险。这还会给其他操作系统带来进一步的风险。回到1）或2）。

请注意，推荐项2) 可能会导致您现有的其他启动介质（如USB存储设备和光盘等）在未来无法启动。因此，请确保您真正需要2)，或者在准备好使用2)之前，暂时使用1)一段时间。

- ansa

---

我正在尝试升级，$ sudo do-release-upgrade -d但是我得到了以下输出：

检查是否有新的Ubuntu版本 请在升级之前安装所有可用的更新。

- LinuxNewbee

Answer 3

请参阅：https://github.com/fwupd/fwupd/issues/5035 简而言之，请升级到最新版本的fwupd。

- Anonymous

---

你能在回答中总结一下那个解决方案吗？如果网页消失了，你的回答对其他人就没有用了。谢谢！ - Will

这是一个bug，维护者已经意识到了，当前的fwupd版本是1.7.5，需要进行改进。 - Gri Ma

@GriMa，我能做些什么还是只能等待？ - Py-ser

Answer 4

他说已经修好了：在未来的固件中修好了 在 https://gitlab.com/fwupd/lvfs-website/-/merge_requests/1363 中修好了。 也许忽略更新请求直到Ubuntu修复它是一个安全但令人烦恼的事情。

- Gri Ma

---

那个链接里面我应该获取什么？你能详细解释一下吗？ - Py-ser

Answer 5

在我的情况下，将fwupdmgr列出的文件移出/boot文件夹是有效的。几周前我从Ubuntu 20.04升级到了22.04，并且获得了DBX的这个更新。

在我的情况下，在/boot/efi/boot-repair/log文件夹中有很多旧文件，所以我将整个log文件夹移出/boot区域。 然后执行"sudo fwupdmgr update"命令并且执行"sudo update-grub"而无需重启。我猜这是主要的事情：在执行"sudo update-grub"之前不要重新启动。

然后我重新启动，我的神圣机器再次恢复正常。

- frank

Answer 6

我遇到了同样的问题。我只是把升级报告中的所有有问题的文件移动到引导文件夹之外的安全位置。确保一切正常运行后，你可以删除移动的文件。

在你的情况下，应该是这样的：

$ sudo mv /boot/efi/EFI/Boot/shimx64.efi ~/Documents
$ sudo fwupdmgr update

如果在运行fwupdmgr后出现其他错误，请将其抱怨的文件移动到您的文档文件夹中。在更新实用程序工作之前，我不得不移动3个“阻止的可执行文件”文件。一旦更新成功，请确保grub是最新版本：

$ sudo update-grub

现在你可以重新启动，一切应该正常工作。你可以删除在你的文档文件夹中被隔离的efi文件夹。

- Joshua Besneatte

---

做同样的事情弄坏了我的启动引导。之后不得不使用一个活动的USB来修复启动引导，才能重新启动电脑。修复完成后，一切似乎都正常工作了，而且再也没有提醒更新UEFI dbx了。 - RobinC