折腾五天，把 macOS 26 装进了 Z690

黑苹果OpenCore教程踩坑安全启动

柠凉·创建于 2026年10月24日

2,888字·7 分钟阅读

从 10 月 20 日晚上第一次点开 1401 的界面，到 10 月 24 日系统能开机、能上网、能听见声音——整整五天。

中间有三次我以为找到了答案，结果全是误判。真正让它跑起来的，是第四天下午一次几乎放弃式的操作：把 BIOS 恢复默认，然后重新设一遍。

这篇记录踩过的坑、走过的弯路，以及最后那份能用的 EFI。

硬件与结果

部件	型号	状态
CPU	Intel Core i9-13900KF	✅ 原生，大小核都认
主板	MSI MPG Z690 FORCE WIFI	✅
显卡	NVIDIA RTX 4090	⚠️ 需 NullMoth 驱动
内存	128 GB DDR5	✅
有线网卡	Intel I225-V 2.5G	✅ AppleIGC
无线网卡	Intel Wi-Fi 6E AX211	⚠️ 需 HeliPort，无 AirDrop
蓝牙	Realtek USB Bluetooth 5.0	✅

系统是 macOS 26 Tahoe，机型 MacPro7,1，OpenCore 1.0.9。

最大的坑：BIOS

先说结论，因为这个比后面所有技术细节都重要。

第三天下午，所有能改的 EFI 配置都试过了——换 SMBIOS、去虚拟机伪装、降分辨率、精简 kext。屏幕要么停在苹果 logo，要么滚到一半就黑。日志里最刺眼的一行是：

text

DMTF_ERR: code = 9
opendirectoryd: failed to init, err = 3

那时候我以为是 SMBIOS 的问题，也确实换出了效果（DMTF_ERR 消失了），但系统还是进不去安装界面。

后来在 1401 的 Discord 里翻到有人提过一句「先清 CMOS 试试」，抱着死马当活马医的心态进 BIOS 点了「恢复默认设置」，重新配了 Secure Boot = Disabled、Above 4G = Enabled、XHCI Hand-off = Enabled、TPM = Disabled 这几项——然后它就进安装器了。

💡 具体是哪一项在作祟，我至今没定位出来。可能是之前调试时关掉的某个选项，也可能是 TPM 的残留状态。但如果你也卡在同样的地方，先重置 BIOS，再一项项按需打开，能省掉至少两天。

坑一：DMTF_ERR —— 内存槽对不上

这是唯一一个我确定「找到了根因」的问题。

MacPro7,1 是 Mac Pro 2019 的机型标识，苹果给它的 SMBIOS 里定义了 12 个 DIMM 槽。而我这台机器只有 4 条内存，OpenCore 生成的 SMBIOS 表里只有 4 个 Type 17 结构——于是 macOS 的服务进程 opendirectoryd 在解析内存信息时直接崩了。

日志长这样：

text

DMTF_ERR: code = 9
opendirectoryd: failed to init, err = 3

opendirectoryd 是目录服务，它一崩，后面所有依赖它的服务全断——包括 WindowServer。这就是为什么屏幕一直停在代码界面。

解法是把 SystemMemoryStatus 从 Auto 改成 Upgradable：

XML

<key>PlatformInfo</key>
<dict>
  <key>Generic</key>
  <dict>
    <key>SystemProductName</key><string>MacPro7,1</string>
    <key>SystemMemoryStatus</key><string>Upgradable</string>
  </dict>
</dict>

这个值的意思是「内存槽可升级（未填满）」，正是 Mac Pro 期望的状态。

顺便一提：OpenCore 官方文档里说 MacPro7,1 应该用 Filled，但 1401 打包的这个版本根本不认——填进去会报 Invalid SMBIOS system memory status Filled。得用 Upgradable。

坑二：sbvmm —— 把自己伪装成虚拟机

1401 生成的默认 boot-args 里有一项：

text

revpatch=sbvmm

sbvmm 是 RestrictEvents 的一个参数，作用是把系统伪装成虚拟机，用来绕过某些机型限制。

听起来很聪明，实际后果是：macOS 认为自己在虚拟机里跑，于是 WindowServer 找不到物理显示设备。

日志里能看到它连续重试三次：

text

WindowServer: Aqua Session starting...
WindowServer: Aqua Session failed to start
WindowServer: Aqua Session starting...

解法：把 sbvmm 改成 cpuname。

text

revpatch=cpuname

cpuname 只修 CPU 名称显示，不碰虚拟机检测。改完之后 Aqua Session 不再重试。

⚠️ 注意：revpatch 在两处都有——NVRAM > Add 的 boot-args 和 NVRAM > Add 的 7C436110-... 里的 revpatch 变量。只改一处不够，RestrictEvents 两个地方都读。

坑三：Kernel > Block —— 一个"优化"把 USB 全干掉了

这是最后一个坑，也是最阴的一个。

第四天系统已经能用了，我开始收拾 EFI——把旧配置里的一条 Kernel > Block 搬了过来：

XML

<key>Identifier</key><string>com.apple.iokit.IONDRVSupport</string>
<key>Comment</key><string>boot framebuffer IONDRVFramebuffer steals index 0 from NVRMFB</string>

注释写得很有道理：阻止 macOS 自带的 IONDRVFramebuffer 抢占显示索引 0，让 NVIDIA 的 NVRMFB 拿到主显示。

结果开机直接卡死：

text

AppleUSBXHCIPCI::start(0x7f, 0x...) failed: 0xe00002c7
AppleUSBXHCIPCI::start(0x...) failed: 0xe00002c7

0xe00002c7 = kIOReturnUnsupported，USB 3.x 控制器驱动拒绝接管。键盘鼠标全没反应，等于死机。

IONDRVSupport 虽然主要服务图形栈，但 IOKit 里其他组件也间接依赖它。 屏蔽它，USB 控制器初始化就跟着失败。

后来我把这条删了——显示照样正常。因为 NullMoth 驱动本身就能工作，不需要靠屏蔽通用帧缓冲来抢位置。

坑四："需要更新固件" —— 其实是 APFS 标志位

安装器里选好分区，点继续，弹出来一句：

Mac 需要更新固件才能安装到此宗卷，请使用 macOS 扩展（日志式）

黑苹果哪来的固件可更新？查了半天才明白，macOS 在检查 SMBIOS 里的 FirmwareFeatures 字段，看有没有「支持 APFS 启动」这个标志位。

用 UpdateSMBIOSMode = Create 重建 SMBIOS 表时，这个字段没被正确填充，于是安装器认为「这台 Mac 的固件太老，不支持 APFS」，只让选 HFS+。

解法是打开两个开关：

XML

<key>PlatformInfo</key>
<dict>
  <key>Generic</key>
  <dict>
    <key>MaxBIOSVersion</key><true/>
    <key>AdviseFeatures</key><true/>
  </dict>
</dict>

MaxBIOSVersion：把 BIOS 版本强行设成 65535.65535.65535，绕过版本检查
AdviseFeatures：按机型写入推荐的 FirmwareFeatures，补上 APFS 启动位

还有一个更隐蔽的版本：如果目标磁盘没有 EFI 分区（ESP），安装器也会报同样的错。我一度以为 3.6TB 那块机械盘没 ESP，后来换到 NVMe 上才发现不是这个问题。

坑五：AX211 —— 没有原生 Wi-Fi

这条不算坑，是硬件限制。

AX211 在 OpenIntelWireless 的兼容列表里，但它只有两种驱动方式：

驱动	呈现形式	macOS 26 可用	原生 Wi-Fi 菜单
`itlwm.kext`	以太网卡	✅	❌ 需 HeliPort
`AirportItlwm.kext`	原生 Airport	❌ 停更于 Sonoma	✅

AirportItlwm 已经一年多没更新，不支持 Tahoe。所以只能用 itlwm + HeliPort 客户端——系统设置里看不到 Wi-Fi，得靠 HeliPort 菜单栏图标连网。

而且，1401 作者在 Discord 里亲口说过：

the cards are missing hardware features AirDrop needs.. so not gonna expect them to work

AirDrop 和接力永远用不了，这是硬件缺特性，不是驱动能补的。

双系统 + 安全启动：让游戏反作弊闭嘴

系统装好之后遇到个新问题：部分游戏要求开着 Secure Boot 才让进。

Valorant 的 Vanguard 最直接，检测不到 Secure Boot 就拒绝启动；一些用 EAC / BattlEye 的新游也开始跟进。但 OpenCore 的 EFI 文件默认没有签名，Secure Boot 一开，固件直接拒绝加载——开机就进不去了。

这个问题有两条路，取决于你的主板有多"较真"。

方案 A：主板的「宽松模式」（我的做法）

我这块 MSI MPG Z690 FORCE WIFI 的 Secure Boot 是分模式管的：

Code

Settings → Security → Secure Boot
├── Secure Boot Mode:  Standard / Custom
└── Custom 模式下还有 Key Management 和 Image Execution Policy

把 Secure Boot Mode 从 Standard 改成 Custom，Secure Boot 状态依然是 Enabled（游戏检测得到），但执行策略变宽松了——允许未签名的 EFI 直接运行。

于是：

项目	状态
Secure Boot State	✅ Enabled（游戏认）
OpenCore 启动	✅ 正常（未签名也放行）
Windows 启动	✅ 正常（微软证书本来就在 db 里）
需要签名 EFI	❌ 不需要

说白了：这块板子本来就能这么干，我根本没折腾签名和证书。

不过要说清楚：这不等于"安全启动被绕过"。Secure Boot 确实在运行，只是执行策略从"必须签名"放宽到"允许未签名"。对反作弊来说，它看到的 SecureBootEnabled 是 true——但更深层的检测逻辑各家不一样，我不敢打包票所有游戏都吃这套。

方案 B：完整签名 + 导入 BIOS（严格主板）

如果主板没这么宽容（比如某些华硕、戴尔、联想整机，Secure Boot 只有标准模式，或者强制校验 db），就得老老实实做完整签名。

社区有个现成工具：OpenCore Secure Boot Tool（作者：余生的客栈）。

它干的事：

Code

自建一套 PKI（PK / KEK / ISK 三组密钥）
        ↓
用 sbsign 给 OpenCore 的每个 .efi 签名
        ↓
把自签名证书 + 微软三大 PCA 证书 + Windows 提取的证书
一起构建成 db / KEK / PK
        ↓
通过 Set-SecureBootUEFI 写入 BIOS
        ↓
Secure Boot 保持开启，OpenCore 进入信任链

环境要求：

Windows 10 / 11（必须支持 UEFI Secure Boot）
WSL（Ubuntu）+ sbsigntool / efitools / openssl / uuid-runtime
Python 3.10+（或用打包好的 EXE）

核心步骤：

powershell

# 1. 装 WSL
wsl --install

# 2. WSL 内装工具
sudo apt-get install -y sbsigntool efitools openssl uuid-runtime

# 3. 启动工具（需管理员权限）
python main.py

工具界面里依次做四件事：

挂载 ESP → 自动识别 OC 目录和 Windows 启动目录
签名 OC → 递归给所有 .efi 签名（自动备份原始文件）
提取 Win 证书 → 从 bootmgfw.efi 里抽 Authenticode 证书，保证 Windows 也能过验证
构建并导入 → 生成 db/KEK/PK 的 .esl + .p7，写入 BIOS

导入顺序有讲究（Setup Mode 下）：

powershell

Set-SecureBootUEFI db  -ContentFilePath db.esl  -SignedFilePath db.p7
Set-SecureBootUEFI KEK -ContentFilePath KEK.esl -SignedFilePath KEK.p7
Set-SecureBootUEFI PK  -ContentFilePath PK.esl  -SignedFilePath PK.p7

最后一步导入 PK 之后，Secure Boot 就激活了。

工具还会自动给 config.plist 打一个补丁：

XML

<key>UEFI</key>
<dict>
  <key>Quirks</key>
  <dict>
    <key>DisableSecurityPolicy</key><true/>
  </dict>
</dict>

视频教程（B 站，2026-09 发布）：

📺 OpenCore 黑苹果引导开启安全启动工具

两条路怎么选

	方案 A：宽松模式	方案 B：完整签名
适用主板	MSI / 部分技嘉（有 Custom 模式）	华硕、戴尔、联想等严格固件
操作复杂度	⭐ 改一个选项	⭐⭐⭐⭐ 装 WSL、签名、导证书
耗时	1 分钟	1–2 小时
风险	极低	PK 导入后 BIOS 锁定，改回要重置
维护成本	无	Windows 大更新后可能要重签
反作弊兼容性	未知（依赖具体检测）	更"标准"，理论上更安全

先去 BIOS 里翻翻有没有 Secure Boot Mode: Custom。 有的话直接选方案 A，省下来的两小时够打几把游戏了。

方案 B 还有两个坑：一是 keys/ 目录里的私钥千万别传 GitHub（工具自带 .gitignore，但自己也要留神）；二是 Windows 大版本更新可能替换启动文件、带来新证书，到时候得重新提取、重签 db、重新导入——等于再走一遍流程。

⚠️ 关于反作弊，说点实话：Vanguard 对固件状态最敏感，自建 PK 这种"非标准"配置有被风控的可能；EAC / BattlEye 主要看 Windows 内的驱动签名，对固件层关注较少。不管走哪条路，都建议先用小号试，别拿主账号赌。

那些"看起来是版本问题"的假象

这几天我两次误判「版本不匹配」，后来用 PE 结构分析才发现是白忙。

第一次：新旧 EFI 的 OpenCore.efi 大小差 1,592 字节，我以为是不同版本。拆开 PE 头才发现——代码一个字节都不差，差的只是签名块：

	签名大小	时间戳
新 EFI	4,776 字节	含 RFC 3161（2026-10-23 16:00 UTC）
旧 EFI	3,184 字节	无

差的 1,592 字节就是 TSA 证书 + 时间戳 token。

第二次：OpenCanopy.efi 也差 1,592 字节，同样以为是版本不同。结果：

text

主体大小: 151,552 / 151,552   相同
差异字节: 4 个（全在 PE 头的 CheckSum 和 Security Directory）
排除这两处 → 剩余差异 0 字节

同一个文件，只是签名方式不同。

💡 教训：文件大小不同 ≠ 版本不同。想知道真实版本，得拆 PE 结构看主体大小，或者对比去掉签名后的哈希。

分享我的 EFI

折腾完之后，我把配置整理出来开源了：

🔗 ShintoKosei/z690-13900kf-4090-hackintosh

里面有什么：

完整的 BOOT/ + OC/ 目录，可直接刷进 ESP
16 个启用的 kext，5 个 UEFI 驱动
Flavours-OSX26 图形主题（OpenCanopy）
一份 274 行的 README，把这几天踩的坑全写进去了

里面没有什么：

❌ 三码（序列号 / MLB / UUID / ROM 全是占位符）
❌ 安全启动签名（全部剥离了）
❌ NVIDIA 驱动本体（要自己装 NullMoth 驱动）

使用前必须自己生成三码，用 GenSMBIOS 或 OCAuxiliaryTools，机型选 MacPro7,1。不然 App Store 和 iCloud 都登不上。

写在最后

五天里最耗时间的不是技术难度，是每次改完都要重启、等日志、看屏幕。一次循环十几分钟，一天下来也试不了几次。

如果让我重来一遍，顺序会是这样：

先重置 BIOS，只开必需项（Secure Boot 关、Above 4G 开、XHCI Hand-off 开）
SMBIOS 选对，MacPro7,1 + Upgradable，别碰 Kernel > Block
boot-args 去掉 sbvmm
装完系统再折腾主题和分辨率，别在安装阶段加变量

还有一条：别信「换个 U 盘试试」这种建议。我在 Discord 看到一个老哥换了三个 U 盘都没解决，问题根本不在盘上。

现在这台机器开机 20 秒进桌面，4K 分辨率正常，有线无线都能用，蓝牙耳机能连。虽然 AirDrop 用不了、音频还得靠 VoodooHDA 补，但作为一台日常能用的 Mac——它成了。

如果你也在折腾同一套硬件，欢迎来仓库提 issue，或者直接抄走那份 EFI。🍎