我正在尝试从 Dell Vostro 15 上的闪存 Ubuntu Studio 22.04（使用 Rufus 创建）启动（请参阅下面的配置）。我卡在Launching 'EFI\boot\bootx64.efi'...Ubuntu 16.04 已安装，我想保留文件。
开机画面：
戴尔配置：
UEFI 启动顺序：
答案1
Rufus 开发人员在这里。这是一个很难解决的问题，但我现在可以就这个问题给出一个完整的答案。它可能充斥着一些缩略词和术语，但那是因为我真的不想提供一个太过简化以至于变得毫无意义的解释。
- 问题的根源在于，由于当前的 Ubuntu Studio ISO 包含一个大于 4 GB 的文件，Rufus 默认使用 NTFS 作为 USB 介质的文件系统，并且为了确保 Dell Vostro 等系统可以启动它，还确保在 Ubuntu 引导加载程序启动之前加载 NTFS 驱动程序。不幸的是，正如我们所发现的，Rufus 使用的当前 NTFS 驱动程序在回复目录列表请求时并不完全符合 UEFI 标准。
- 因此，Ubuntu 引导加载过程的下一部分称为垫片，尝试通过列出某些特定目录来查找证书时可能会进入无限循环仅当启用安全启动时才会执行此操作。因此，正如 OP 发现的那样，避免此问题的一种方法是禁用安全启动，因为垫片将不会读取目录，也不会强调 NTFS 驱动程序的不兼容部分。
注意：对于那些技术倾向的人来说，问题是垫片使用循环发出读取调用/efi/boot/具有零大小缓冲区的目录的读取调用，并期望（对于兼容的驱动程序来说应该是这种情况）驱动程序会告诉它提供的缓冲区太小，同时返回所需的实际大小。然后它重新进入循环，并期望更新后的缓冲区大小。然而，驱动程序确实返回一个代码来告诉垫片它请求的缓冲区太小，因此它不会更新所需的大小，这意味着垫片不断发出零大小的请求，而驱动程序不断返回“缓冲区太小”永远...
显然，我们将在下一个版本的 Rufus 中修复有问题的驱动程序，以确保它在列出目录时返回实际所需的大小，因为垫片（理所当然地）期待。然而与此同时，甚至在我们发现这个问题之前，开发垫片 最近还发现一些 UEFI 固件（尤其是戴尔的固件）以及未使用我们的 NTFS 驱动程序的固件也未能满足目录列表合规性要求，并遇到了这个无限循环问题。因此，他们还独立应用了修复程序以避免无限循环。然而，他们的修复程序是在 2 月初添加的，而 Ubuntu 用于垫片是在 1 月份制作的，所以它没有进入当前的 Ubuntu Studio。不过，如果 Ubuntu Studio 使用的是更新的垫片代码，OP 很可能永远不会遇到这种启动冻结，并且我们也不会发现 Rufus 的 NTFS 驱动程序不是 100% 符合 UEFI 标准的。
所有这些都意味着，最终，你应该有 4 个选项：
- 在安装过程中暂时禁用安全启动（就像 OP 所做的那样）。
- 在 Rufus 中写入媒体DD 模式代替ISO 模式（记住，鲁弗斯总是提示您选择DD 模式或者ISO 模式并明确地告诉你，如果你在ISO 模式，你应该尝试重新创建驱动器DD 模式）。
- 使用 Rufus 3.23 或更高版本，它将包含符合 UEFI 的驱动程序。
- 使用较新版本的 Ubuntu，其中应包含更新版本的垫片可以处理不兼容的 UEFI 驱动程序或固件。