当我尝试启动时，系统进入 grub 命令行（修复模式）。如果使用 configfile 命令指向配置文件，系统会立即启动，没有任何问题。因此，很明显 grub 并没有在我认为正确的位置 /boot/grub/grub.cfg 中寻找配置文件。
我已经打印出配置文件，它似乎没有损坏。当我手动指向此文件时，系统也能成功启动。那么为什么 grub 在启动时找不到它呢？
据我了解，如果它启动到 grub“救援”模式，则意味着它找不到 grub.cfg。如果我理解正确的话，无法更新 grub.cfg 不会导致此行为。此外，我此后运行了 grub-mkconfig，但仍然遇到此行为。
答案1
正如@oldfred所说，EFI 下的配置文件中的 UUID 不正确。我输入了正确的 UUID，现在可以正常启动了！
答案2
当你改变 grub 配置文件的内容时，你需要使用 grub-mkconfig “重建”它。
sudo grub-mkconfig -o /boot/grub/grub.cfg
答案3
grubia32.efi寻找grub.cfg使用名为的变量prefix
如果($prefix)/grub.cfg不存在，您将得到 grub 提示符。
这就是configfileGRUB 命令有效的原因，因为您覆盖了 $prefix 的使用（前提是您没有使用这个变量！）
语境
我正在使用一台需要 32 位 EFI 的 2007 年旧款 MacBook。遗憾的是，Ubuntu 的最新安装（20.04 和 22.04）及其衍生发行版（例如 elementaryOS 7.1）不再包含从头开始重建机器所需的文件（当我的机器无法启动时，我才意识到这一点）。
所以我BOOTIA32.EFI从文图伊它包含 grubia32_real.efi （我将其重命名为grubia32.efi），然后我得到了 GRUB 提示符。
我发现了configfileGRUB 命令解决方法，可以手动进入 GRUB 菜单，但也感到很困惑，为什么 GRUB 自己找不到 grub.cfg。我心想，这个定义在哪里？
然后我发现这个答案而看似完全是题外话的东西（使用 grub rescue> 很有趣）却是一个金矿。我使用setGRUB 中的命令转储其所有变量的内容，这时我意识到前缀(hd0,2)在“真正的” grubia32.efi 中设置为。我的 grub.cfg 位于分区 4 中(hd0,gpt4)/boot/grub
于是我又进行了一次搜寻，发现AIO 启动它有一个自定义版本的 grubia32.efi，其前缀是(hd0,gpt1)/AIO/grub
我把这个自定义版本的 grubia32.efi 放进去，/boot/efi/EFI/BOOT并把 grub.cfg 的副本放进去/boot/efi/AIO/grub/grub.cfg，然后 BAM！我的机器调出了 GRUB 菜单，我可以双启动 Linux 发行版了！