OpenCore 引导 Ubuntu 失败排查与菜单定制全记录

本文记录一次 OpenCore 多重引导 Linux 的完整排查：BIOS 里直接选 Ubuntu 硬盘能正常进系统，但从 OpenCore 菜单里选同一个硬盘就报错。从报错文字反推加载链条，定位到 shim 兜底路径的问题，用 BlessOverride 绕过 shim 解决，随后把菜单条目的名称与图标改成 Ubuntu 原生样式。文中所有配置值、文件内容、哈希比对均为在 EFI 分区上实际核对过的结果，命令可直接复用。涉及硬件：微星 Z490M S01 主板 + Intel 平台，SMBIOS 机型 iMac19,1，macOS 14.7.2 (23H311) Sonoma，OpenCore 引导。

这次问题的特殊之处在于：报错信息看起来像 OpenCore 的错，实际上完全不是。报错来自 Linux 侧的 shim。搞清"谁在报错"之后，剩下的事情就顺了。

一、环境信息

项目	值
主板	微星 MSI Z490M S01
SMBIOS 机型	`iMac19,1`（board-id `Mac-AA95B1DDAB278B95`）
macOS	14.7.2 (Build 23H311)
引导方式	OpenCore 1.0.1（EFI 文件日期 2024-08-05）
Picker 模式	`External`（OpenCanopy 图形界面）
SecureBootModel	`Disabled`
配置工具	OpenCore Configurator、`PlistBuddy`、`plutil`
OpenCore 的 EFI 挂载点	`/Volumes/Untitled`（`disk1s1`，314.6 MB，FAT32）
Ubuntu 的 EFI 挂载点	`/Volumes/NO NAME`（`disk4s1`，1.1 GB，FAT32）

磁盘布局：

设备	容量	分区
`disk0`	256 GB	Windows：ESP(`disk0s1`) + MSR + NTFS(`disk0s3`) + WinRE
`disk1`	480 GB	macOS：ESP(`disk1s1`) + APFS 容器(`disk2`)
`disk3`	480 GB	数据盘：MSR + exFAT(`disk3s2`，即 Data 卷)
`disk4`	250 GB	Ubuntu：ESP(`disk4s1`) + ext4(`disk4s2`)
`disk5`	240 GB	外置 mSATA（NTFS）

OpenCore 已加载的驱动（UEFI → Drivers）：

驱动	作用
`OpenRuntime.efi`	OpenCore 运行时支撑，必需
`HfsPlus.efi`	HFS+ 文件系统驱动
`OpenCanopy.efi`	图形化引导菜单
`ResetNvramEntry.efi`	菜单里的重置 NVRAM 工具（参数 `--preserve-boot`）

注意这张表里没有 OpenLinuxBoot.efi。这个缺失是后面排查的关键前提之一。

二、问题现象

Ubuntu 的引导行为在两种入口下完全相反：

进 BIOS 启动菜单，直接选 Ubuntu 那块硬盘 → 正常进入系统，一切正常。
开机进 OpenCore 菜单，选同一个条目 → 黑屏后报错，停在错误信息上不动。

OpenCore 菜单里那个 Ubuntu 条目的显示名称是 no name，图标是通用的灰色硬盘。

报错原文两行：

Could not read \EFI\: Invalid Parameter
Error: could not find boot options: Invalid Parameter

同一个 EFI 分区、同一个引导文件，换个入口就失败，说明问题出在"由谁加载它"，而不是文件本身损坏。

三、报错信息逐行解读

这两行字不是 OpenCore 打印的，也不是 GRUB 本身打印的，而是 shim 打印的。这一点在排查初期很关键——如果按"OpenCore 配置错误"的方向去查，会一直在错误的地方打转。

报错行	来源	含义
`Could not read \EFI\: Invalid Parameter`	shim	尝试枚举 ESP 根目录下的 `\EFI\` 目录，UEFI 返回 `EFI_INVALID_PARAMETER`
`Error: could not find boot options: Invalid Parameter`	shim	因为读不到 `\EFI\`，无法确定下一级引导器在哪，于是放弃
`## Application terminated, r = 2`（部分环境下会多出这行）	shim	shim 以错误码退出，控制权交回 OpenCore

EFI_INVALID_PARAMETER 是 UEFI 规范里的一个标准返回码，含义是"传给这个函数的参数不合法"。用在目录枚举场景下，通常意味着拿到的文件句柄不支持按目录方式打开。

确认报错来源的方式很直接：把报错原文丢进搜索引擎，会命中一类场景——shim 在不标准的固件环境下启动时，读不到 \EFI\ 目录。这些案例的共同点都是"shim 被非原生固件拉起"。

四、OpenCore 引导 Linux 的三种方式

OpenCore 本身不直接认识 Linux 内核，引导 Linux 有三条路：

方式	做法	是否需要额外驱动	本机情况
A. OpenLinuxBoot	由 `OpenLinuxBoot.efi` 自动扫描 ext4 分区，直接列出内核	需要 `OpenLinuxBoot.efi` + `ext4_x64.efi`	未安装
B. 链式加载 EFI 引导器	把 `grubx64.efi` 或 `systemd-bootx64.efi` 交给 OpenCore 执行	不需要	本次采用
C. EFISTUB 直接加载内核	把内核当 EFI 程序直接执行，不经 GRUB	不需要，但需要内核支持 EFISTUB	未采用

方式 A 最省事，但要求驱动到位，而且它推荐"不再使用 GRUB"。方式 C 最干净，但 Ubuntu 默认内核配置不一定开启 EFISTUB，改动成本高。

本机的情况落在方式 B 上：UEFI → Drivers 里没有 OpenLinuxBoot.efi，所以 OpenCore 只能靠两条途径发现 Ubuntu 条目——枚举各 ESP 上的兜底路径，或者 Misc → BlessOverride 里显式指定的路径。

这里出现了本次故障的直接原因。按 UEFI 规范，每块 ESP 上都应该有一个"可移动介质兜底路径" \EFI\BOOT\BOOTX64.EFI，用于在 NVRAM 引导项丢失时还能启动。OpenCore 会把各 ESP 上的这个文件枚举成引导条目。菜单里那个显示为 no name 的条目，就是 Ubuntu ESP 上的这个兜底文件。

五、根因定位

排查动作分四步，每步都留下了一个可验证的结果。

5.1 挂载 Ubuntu 的 EFI 分区

diskutil list                      # 先确认分区号
diskutil mount disk4s1             # Ubuntu 的 ESP
diskutil mount disk1s1             # OpenCore 所在的 ESP

挂载后 Ubuntu 的 ESP 出现在 /Volumes/NO NAME。这个卷标后面还会用到。

5.2 列出两个目录的内容

ls -l "/Volumes/NO NAME/EFI/BOOT/"
ls -l "/Volumes/NO NAME/EFI/ubuntu/"

结果：

路径	大小（字节）	说明
`EFI/BOOT/BOOTX64.EFI`	966768	UEFI 兜底路径
`EFI/BOOT/fbx64.efi`	88344	shim 的 fallback 组件
`EFI/BOOT/mmx64.efi`	856280	MokManager
`EFI/ubuntu/shimx64.efi`	966768	安全启动校验层
`EFI/ubuntu/grubx64.efi`	2828168	GRUB 本体
`EFI/ubuntu/mmx64.efi`	856280	MokManager
`EFI/ubuntu/grub.cfg`	126	指向 ext4 分区上的 GRUB 配置
`EFI/ubuntu/BOOTX64.CSV`	108	shim 的二级引导器映射表

两个数字对上了：EFI/BOOT/BOOTX64.EFI 和 EFI/ubuntu/shimx64.efi 都是 966768 字节。

5.3 用哈希确认它们是不是同一个文件

大小相同不代表内容相同，用 SHA256 比对：

shasum -a 256 "/Volumes/NO NAME/EFI/BOOT/BOOTX64.EFI" "/Volumes/NO NAME/EFI/ubuntu/shimx64.efi"

输出：

4c89145e958cf592a6f16552eadf112ef2c1c525e2435c2761e6a99fa88188b3  /Volumes/NO NAME/EFI/BOOT/BOOTX64.EFI
4c89145e958cf592a6f16552eadf112ef2c1c525e2435c2761e6a99fa88188b3  /Volumes/NO NAME/EFI/ubuntu/shimx64.efi

两个哈希完全一致。Ubuntu 安装时把 \EFI\BOOT\BOOTX64.EFI 写成了 shim 的副本。 OpenCore 枚举到的那个"兜底引导文件"，本质上是 shim。

5.4 检查 shim 需要的映射表在哪

EFI/ubuntu/ 里有一个 BOOTX64.CSV，内容：

shimx64.efi,Ubuntu,,This is the boot entry for Ubuntu

这是 shim 用来确定"下一级该加载谁"的映射表。shim 启动后会先在自己的目录里找这份表，读不到就会退回兜底行为——扫描 \EFI\ 目录，去找别的可引导文件。

而 EFI/BOOT/ 目录里只有 BOOTX64.EFI、fbx64.efi、mmx64.efi 三个文件，没有配套的 BOOTX64.CSV。于是链条变成：

flowchart TD
    A1["OpenCore 枚举到 ESP 兜底路径<br/>EFI/BOOT/BOOTX64.EFI"] --> A2["该文件实为 shim 副本<br/>SHA256 与 shimx64.efi 一致"]
    A2 --> A3["shim 在同目录找 BOOTX64.CSV<br/>未找到"]
    A3 --> A4["退回兜底行为<br/>枚举 EFI/ 目录找下一级引导器"]
    A4 --> A5["目录枚举返回<br/>EFI_INVALID_PARAMETER"]
    A5 --> A6["shim 报错退出<br/>grubx64.efi 从未被启动"]

5.5 为什么 BIOS 直接引导却正常

同一个文件，换个入口就成功，差别在于谁去加载它。可以推断的机制是：UEFI 固件自己执行 \EFI\BOOT\BOOTX64.EFI 时，交给 shim 的是固件原生的设备句柄，目录枚举能力完整；而 OpenCore 是通过自己的引导管理逻辑把映像拉起来再调用 StartImage()，shim 拿到的句柄无法完成 \EFI\ 的目录枚举，于是返回 EFI_INVALID_PARAMETER。

不管底层细节如何，一条可操作的规则已经足够清楚：在 OpenCore 下引导 Linux，路径要指向 grubx64.efi，不要指向 shim。

六、解决引导失败

修复动作是把 OpenCore 的 Misc → BlessOverride 指向 \EFI\ubuntu\grubx64.efi，让 OpenCore 直接加载 GRUB，整条链条跳过 shim。

6.1 为什么可以跳过 shim

shim 的唯一职责是在安全启动（Secure Boot）环境下校验下一级引导器的签名。本机 Misc → Security → SecureBootModel 的值是 Disabled，没有任何签名校验需求，shim 在这条链上是多余的中间层。跳过它既不损失功能，也绕开了它读不到目录的问题。

6.2 操作步骤

# ① 备份。改 OpenCore 配置前必须做
sudo cp /Volumes/Untitled/EFI/OC/config.plist /Volumes/Untitled/EFI/OC/config.plist.bak

# ② 添加 BlessOverride 条目
#    原配置里 Misc:BlessOverride 已存在且为空数组，直接追加第 0 项
sudo /usr/libexec/PlistBuddy -c "Add :Misc:BlessOverride:0 string '\EFI\ubuntu\grubx64.efi'" \
     /Volumes/Untitled/EFI/OC/config.plist

# ③ 校验配置文件格式
plutil -lint /Volumes/Untitled/EFI/OC/config.plist

# ④ 回读确认
/usr/libexec/PlistBuddy -c "Print :Misc:BlessOverride" /Volumes/Untitled/EFI/OC/config.plist

第 ④ 步的输出应为：

Array {
    \EFI\ubuntu\grubx64.efi
}

如果习惯用图形工具，也可以在 OpenCore Configurator 里定位到 Misc → BlessOverride，点加号新增一行，填入同样的路径。

路径写法有两个要点：用反斜杠而不是正斜杠，并且不带盘符。BlessOverride 的语义是"在每块被扫描的 ESP 上找这个路径"，所以不需要指明是哪块盘。

改完不需要重置 NVRAM，OpenCore 每次启动都会重新读取 config.plist，直接重启即可。

6.3 一条没走的替代方案

社区里流传另一种做法：把 grubx64.efi 复制到 EFI/BOOT/，覆盖掉那个 shim 副本，同时把 mmx64.efi、fbx64.efi 改名或删除。

这条路的代价是改动了 Linux 侧的 ESP。Ubuntu 执行内核更新或 grub-install 时，有可能把 EFI/BOOT/ 重新写回 shim，问题会复现。BlessOverride 只改 OpenCore 一侧，不动 Linux 分区，升级 Ubuntu 后依然有效，维护成本更低。

七、菜单标题的显示来源

引导修好之后，菜单里那个条目还是显示 no name。这个名称的来源需要先弄清楚。

OpenCore 官方配置手册对标题来源的定义是：当 PickerAttributes 包含 0x0002（OC_ATTR_USE_DISK_LABEL_FILE）时，标题优先取自引导器旁边的 .disk_label 预渲染标签文件；如果没有预渲染标签，则退而使用 .contentDetails（或 .disk_label.contentDetails）文件里的纯文本；两者都不存在时，才回退到条目名本身。

按这个规则，做两件事：在 Ubuntu 的引导器目录里放上文本文件，并确保 PickerAttributes 打开对应的位。

创建的两个文件：

D="/Volumes/NO NAME/EFI/ubuntu"
printf 'Ubuntu' | sudo tee "$D/.contentDetails" > /dev/null
printf 'Ubuntu' | sudo tee "$D/.disk_label.contentDetails" > /dev/null

文件内容的核对结果（用 xxd 看字节，确认没有多余字符）：

.contentDetails              = [Ubuntu]      # 6 字节：55 62 75 6e 74 75
.disk_label.contentDetails   = [Ubuntu]      # 6 字节：55 62 75 6e 74 75

这里有个容易踩的点：文件内容必须严格是标题文本本身，不能带换行符、不能带 BOM、不能有首尾空格。用 echo 而不是 printf 会多出一个换行符，OpenCore 渲染标题时可能出现空白或直接失效。

另外，diskutil info disk4s1 显示这块 ESP 的卷标仍然是 NO NAME。也就是说，菜单里的名称不依赖卷标重命名，而是依赖上面的文本文件。

一个需要你确认的点。 官方手册把 .contentDetails 的生效条件明确挂在 0x0002 位上，而当前 PickerAttributes 的值是 145（0x91），二进制为 1001 0001，不包含 0x0002。按手册字面意思，这种情况下 .contentDetails 不会被读取，标题仍会回退到条目名。

所以：重启进 OpenCore 菜单后，先看一眼那个条目的名称。

如果已经显示 Ubuntu，说明这条路径在本机 OpenCore 版本下按预期生效，无需再动。
如果仍然显示 no name，把 PickerAttributes 从 145 改成 147（0x93，即补上 0x0002）：

sudo /usr/libexec/PlistBuddy -c "Set :Misc:Boot:PickerAttributes 147" \
     /Volumes/Untitled/EFI/OC/config.plist
plutil -lint /Volumes/Untitled/EFI/OC/config.plist

补上 0x0002 之后，这个位会作用于所有条目。macOS 条目会改用 Apple 在 Preboot 卷上预渲染的 .disk_label 标签，Windows 条目找不到对应文件时会回退到条目名，都属于正常表现，不会把菜单搞乱。

八、菜单图标

图标走的是 OpenCore 的另一套机制——flavour。它由 PickerAttributes 里的 0x0080 位控制，和标题是两条独立的线。

8.1 PickerAttributes 的位掩码

官方手册定义的完整位表：

值	名称	作用
`0x0001`	`OC_ATTR_USE_VOLUME_ICON`	使用卷根目录下的 `.VolumeIcon.icns` 作为图标
`0x0002`	`OC_ATTR_USE_DISK_LABEL_FILE`	使用引导器旁边的 `.disk_label` / `.contentDetails` 作为标题
`0x0004`	`OC_ATTR_USE_GENERIC_LABEL_IMAGE`	为无自定义条目的项提供内置标签图
`0x0008`	`OC_ATTR_HIDE_THEMED_ICONS`	某些类别强制使用内置图标（需先有 `0x0001`）
`0x0010`	`OC_ATTR_USE_POINTER_CONTROL`	允许用鼠标或触控板操作菜单
`0x0020`	`OC_ATTR_SHOW_DEBUG_DISPLAY`	在 DEBUG 构建下显示计时与调试信息
`0x0040`	`OC_ATTR_USE_MINIMAL_UI`	精简界面，隐藏关机与重启按钮
`0x0080`	`OC_ATTR_USE_FLAVOUR_ICON`	启用 flavour 机制，按内容描述选择图标与语音提示

本机的取值变化：

值	十六进制	二进制	组合含义
`17`	`0x11`	`0001 0001`	卷图标 + 鼠标控制
`145`	`0x91`	`1001 0001`	卷图标 + 鼠标控制 + flavour 图标
`147`	`0x93`	`1001 0011`	再加上标题文件（见第七节）

原来的 17 不含 0x0080，flavour 机制关闭，所以 Ubuntu 条目只能拿到通用硬盘图标。补上 0x0080 之后，OpenCore 才会去读 flavour 描述。

8.2 flavour 的解析顺序

官方手册定义的 flavour 判定算法按条目类型分流：

工具类条目，读 Tools 里的 Flavour 字段；
自动发现的条目（包括 OpenLinuxBoot 驱动生成的），读引导器旁边的 .contentFlavour 文件；
Entries 里手工指定的条目，若 Flavour 为 Auto 则读 .contentFlavour，否则用 Flavour 字段的值；
读到的值是 Auto 或文件不存在，则按条目类型决定（例如 Windows 自动套用 Windows flavour）。

Flavour 的取值是一串用冒号分隔的名字，总长不超过 64 个可打印 ASCII 字符，最多约五个名字，靠前的优先级更高。手册给的例子是 BigSur:Apple、Windows10:Windows、OpenShell:UEFIShell:Shell。

查找图标时的回落逻辑是逐个名字试过去。手册明确举例：写 Debian:Linux，OpenCore 会先找 Debian.icns，找不到再找 Linux.icns，再找不到就回落到该操作系统的默认图标 HardDrive.icns。

8.3 创建 flavour 文件

printf 'Ubuntu:Linux' | sudo tee "/Volumes/NO NAME/EFI/ubuntu/.contentFlavour" > /dev/null

内容核对：

.contentFlavour = [Ubuntu:Linux]     # 12 字节，无换行

这个值会先匹配 Ubuntu.icns。本机的 OpenCanopy 图标集位于 Resources/Image/Acidanthera/GoldenGate/，里面确实有 Ubuntu.icns：

ls /Volumes/Untitled/EFI/OC/Resources/Image/Acidanthera/GoldenGate/ | grep -iE 'ubuntu|linux'

Linux.icns
Ubuntu.icns
UbuntuMATE.icns

第一个名字就命中，Linux.icns 用不上，它在这里只是保底。图标集里同时还有 Debian.icns、Arch.icns、Fedora.icns、Mint.icns 等一整套发行版图标，如果以后想换成别的发行版图标，改 .contentFlavour 的第一个名字即可。

8.4 两个容易忽略的规则

手册里有两条优先级规则，在换盘或换图标集时会碰到：

外置盘只认带 Ext 前缀的图标。如果条目所在的盘被识别为外置设备，OpenCore 只使用 Ext<Flavour>.icns，再回落 ExtHardDrive.icns。本机的 Ubuntu 盘是内置盘（disk4，internal），所以走 Ubuntu.icns。若把 Ubuntu 装到移动硬盘上，图标集里没有 ExtUbuntu.icns，就会显示 ExtHardDrive.icns，需要自己补图标文件。

.VolumeIcon.icns 的优先级高于 .contentFlavour。如果卷根目录放了 .VolumeIcon.icns，它会盖掉 flavour 指定的图标。排查"改了 flavour 但图标没变"时，先检查卷根有没有这个文件。

8.5 修改 PickerAttributes

# 备份当前状态（此时已含 BlessOverride）
sudo cp /Volumes/Untitled/EFI/OC/config.plist /Volumes/Untitled/EFI/OC/config.plist.bak2

sudo /usr/libexec/PlistBuddy -c "Set :Misc:Boot:PickerAttributes 145" \
     /Volumes/Untitled/EFI/OC/config.plist
plutil -lint /Volumes/Untitled/EFI/OC/config.plist

九、改动清单与证据

9.1 配置文件的改动

改动集中在两个键上，用 plutil 转成 XML 后逐份比对，可以确认没有其他键被意外修改。

config.plist.bak（原始状态）与 config.plist.bak2（加完 BlessOverride）之间，只差一处：

671c671,673
<               <array/>
---
>               <array>
>                       <string>\EFI\ubuntu\grubx64.efi</string>
>               </array>

config.plist.bak2 与当前 config.plist 之间，也只差一处：

691c691
<                       <integer>17</integer>
---
>                       <integer>145</integer>

三份文件的对应关系：

文件	状态	说明
`config.plist.bak`	原始	`BlessOverride` 为空数组，`PickerAttributes` = 17
`config.plist.bak2`	第一步之后	已加 `BlessOverride`，`PickerAttributes` 仍为 17
`config.plist`	当前	已加 `BlessOverride`，`PickerAttributes` = 145

9.2 新增的文件

全部位于 Ubuntu 的 ESP 上，与 OpenCore 的 EFI 分区无关：

路径	大小	内容
`/Volumes/NO NAME/EFI/ubuntu/.contentDetails`	6 字节	`Ubuntu`
`/Volumes/NO NAME/EFI/ubuntu/.disk_label.contentDetails`	6 字节	`Ubuntu`
`/Volumes/NO NAME/EFI/ubuntu/.contentFlavour`	12 字节	`Ubuntu:Linux`

十、验证与回滚

10.1 引导与菜单的验证

# 挂载两个 EFI 分区
diskutil mount disk1s1
diskutil mount disk4s1

# 核对配置值
/usr/libexec/PlistBuddy -c "Print :Misc:BlessOverride" /Volumes/Untitled/EFI/OC/config.plist
/usr/libexec/PlistBuddy -c "Print :Misc:Boot:PickerAttributes" /Volumes/Untitled/EFI/OC/config.plist
/usr/libexec/PlistBuddy -c "Print :Misc:Security:SecureBootModel" /Volumes/Untitled/EFI/OC/config.plist

# 核对三个文本文件的内容与字节数
for f in .contentDetails .disk_label.contentDetails .contentFlavour; do
  printf '%-28s = [' "$f"; printf '%s' "$(cat "/Volumes/NO NAME/EFI/ubuntu/$f")"; echo ']'
done

# 确认图标资源存在
ls /Volumes/Untitled/EFI/OC/Resources/Image/Acidanthera/GoldenGate/ | grep -iE 'ubuntu|linux'

重启后进 OpenCore 菜单，需要确认四件事：

选中 Ubuntu 条目能正常进入系统，不再出现 Could not read \EFI\ 报错。
条目图标是 Ubuntu 的企鹅，不是灰色硬盘。
条目名称显示为 Ubuntu 而不是 no name。若仍是 no name，按第七节末尾把 PickerAttributes 改成 147。
macOS 与 Windows 条目仍能正常引导，图标未被影响。

进入 Ubuntu 后，如果 GRUB 菜单本身也出现在启动流程里，说明链条是 OpenCore → grubx64.efi → GRUB 菜单 → 内核，属于正常情况。

10.2 回滚

配置层面回到加 BlessOverride 之前的状态：

sudo cp /Volumes/Untitled/EFI/OC/config.plist.bak /Volumes/Untitled/EFI/OC/config.plist
plutil -lint /Volumes/Untitled/EFI/OC/config.plist

回到只加 BlessOverride、还没改图标的状态：

sudo cp /Volumes/Untitled/EFI/OC/config.plist.bak2 /Volumes/Untitled/EFI/OC/config.plist

菜单名称与图标想还原成默认，删掉那三个文本文件即可，不影响引导：

sudo rm -f "/Volumes/NO NAME/EFI/ubuntu/.contentDetails" \
           "/Volumes/NO NAME/EFI/ubuntu/.disk_label.contentDetails" \
           "/Volumes/NO NAME/EFI/ubuntu/.contentFlavour"

如果连引导也想还原，就把 BlessOverride 清空，OpenCore 会退回枚举 ESP 兜底路径的行为——也就是最初报错的状态。

十一、结论与注意事项

把这次的经验抽出来，有几点值得单独记住。

报错信息的归属要先确认。 看到 Could not read \EFI\ 就以为是 OpenCore 的配置问题，方向会偏。这两行字来自 shim，判断依据是把它丢进搜索引擎后命中的全是"shim 在非标准固件下启动失败"的案例。先确定谁在报错，再决定查哪一层。

哈希比对能终结"是不是同一个文件"的争论。 文件大小相同不足以下结论，但 SHA256 一致就是铁证。这次能迅速确认 \EFI\BOOT\BOOTX64.EFI 是 shim 副本，靠的就是这一步。

OpenCore 下引导 Linux 应指向 grubx64.efi。 shim 的作用是安全启动签名校验，SecureBootModel = Disabled 时它没有存在意义，反而因为要读 \EFI\ 目录而成为故障点。绕过它既解决问题又少一层依赖。

改 OpenCore 配置要留出可回退的备份点。 这次的两步改动各留了一份备份，config.plist.bak 对应原始状态，config.plist.bak2 对应中间状态。任何一步出问题都能精确定位到是哪次改动导致的。

标题与图标是两套独立机制。 标题受 0x0002 位控制，读取 .contentDetails 一类文本文件；图标受 0x0080 位控制，读取 .contentFlavour。两者互不依赖，可以分开排查，也可以分开回滚。

.contentFlavour 的值决定图标回落链。 Ubuntu:Linux 会先找 Ubuntu.icns，没有才用 Linux.icns。想让图标更贴合发行版，就在第一个位置写对应名字，并确认图标集里有同名 .icns 文件。

文本文件不能带换行符。 .contentDetails、.contentFlavour 这类文件的内容会被当作字符串直接渲染，多一个换行就是多一个字符。用 printf 而不是 echo，改完用 xxd 看字节确认。

皮皮舟印岁月

OpenCore 引导 Ubuntu 失败排查与菜单定制全记录

一、环境信息

二、问题现象

三、报错信息逐行解读

四、OpenCore 引导 Linux 的三种方式

五、根因定位

5.1 挂载 Ubuntu 的 EFI 分区

5.2 列出两个目录的内容

5.3 用哈希确认它们是不是同一个文件

5.4 检查 shim 需要的映射表在哪

5.5 为什么 BIOS 直接引导却正常

六、解决引导失败

6.1 为什么可以跳过 shim

6.2 操作步骤

6.3 一条没走的替代方案

七、菜单标题的显示来源

八、菜单图标

8.1 PickerAttributes 的位掩码

8.2 flavour 的解析顺序

8.3 创建 flavour 文件

8.4 两个容易忽略的规则

8.5 修改 PickerAttributes

九、改动清单与证据

9.1 配置文件的改动

9.2 新增的文件

十、验证与回滚

10.1 引导与菜单的验证

10.2 回滚

十一、结论与注意事项

评论 (0)

发表评论

OpenCore 引导 Ubuntu 失败排查与菜单定制全记录

一、环境信息

二、问题现象

三、报错信息逐行解读

四、OpenCore 引导 Linux 的三种方式

五、根因定位

5.1 挂载 Ubuntu 的 EFI 分区

5.2 列出两个目录的内容

5.3 用哈希确认它们是不是同一个文件

5.4 检查 shim 需要的映射表在哪

5.5 为什么 BIOS 直接引导却正常

六、解决引导失败

6.1 为什么可以跳过 shim

6.2 操作步骤

6.3 一条没走的替代方案

七、菜单标题的显示来源

八、菜单图标

8.1 PickerAttributes 的位掩码

8.2 flavour 的解析顺序

8.3 创建 flavour 文件

8.4 两个容易忽略的规则

8.5 修改 PickerAttributes

九、改动清单与证据

9.1 配置文件的改动

9.2 新增的文件

十、验证与回滚

10.1 引导与菜单的验证

10.2 回滚

十一、结论与注意事项

相关阅读

黑苹果关机异常弹窗「电脑关机是因为出现了问题」排查与解决全记录

华工科技· AI 光互联龙头的"交付瓶颈"与估值再定价

AI Agent 智能体 Skill（技能）详解：从概念到实战

美国8月PPI深度分析：能源通胀再点燃，美联储加息前夜的全球资产定价重估

近封装光学（NPO）深度：AI 数据中心光互联的新主线

评论 (0)

发表评论