先把结论说清楚：这是一份排查记录
这次记录的目标不是提供一套可以复制粘贴的安装步骤，而是说明在两个相近但并不相同的联想笔记本平台上，怎样区分现象、设计对照并限制结论范围。Harvey 的 Y7000 是主样本，Luminous 的 G5000 是补充样本。
截至整理时，Y7000 能显示 macOS 图形引导，但尚未进入 Recovery；G5000 在关闭一项内存映射相关设置后越过原始早期崩溃，却仍停在 ACPI 初始化附近。两台设备都不能据此宣称“安装成功”或“驱动已经点亮”。
- 不提供 macOS 镜像、密钥、破解文件或可直接复用的 EFI 包。
- 涉及 NullMoth、1401 和 OpenCore 的行为，以各项目当前官方文档为准。
- 所有日志和配置在公开前应移除序列号、MLB、SystemUUID、ROM、MAC、IP 与个人路径。
两台设备与各自的观察范围
Y7000 2025 的机型码为 83LY，搭载 i7-14650HX 与 RTX 5060 Laptop；目标环境为 macOS 15 Sequoia 和 OpenCore。该平台属于笔记本独显环境，不能直接套用驱动项目在台式机上的验证结果。
G5000 是 IRX9 2024 款，主板标识 LNVNB161216，搭载 i7-13650HX（6P + 8E，14 核 20 线程）和 RTX 4060 Laptop。它使用由 1401 生成的 OpenCore DBG-109-2026-09-30 与 USB Recovery，BIOS 观察到安全启动关闭、AHCI、独显模式、虚拟化与超线程开启，Atom/E-Core 保持开启。
| 项目 | Harvey 主样本 | Luminous 对照样本 |
|---|---|---|
| 设备 | Legion Y7000 IRX10（2025，83LY） | Lenovo G5000 IRX9（2024） |
| CPU | Core i7-14650HX，16 核 24 线程 | Core i7-13650HX，14 核 20 线程 |
| GPU | RTX 5060 Laptop 8 GB | RTX 4060 Laptop |
| 当前可见阶段 | 图形引导进度条 | ACPI 初始化附近 |
| 是否进入 Recovery | 否 | 否 |
Y7000：从稳定的早期崩溃建立证据链
Y7000 最初在内核初始化早期稳定崩溃，故障地址多次保持一致。这种可重复性说明它更像稳定的配置、映射或设备初始化问题，而不是一次随机故障。记录中保留了寄存器、错误码、配置版本、校验和与屏幕照片，避免仅凭“最后一行”判断原因。
一个关键校正是：OpenCore 把控制权交给 macOS 后，自己的日志无法继续记录内核后续发生的事情。因此 OpenCore 日志末行相同，不代表两次 macOS 启动结果相同。文章最终把屏幕输出、配置差异和可重复测试组合起来作为判据。
Fault CR2: 0x00000000ff04504c
CPU: 0
Kernel: Darwin 24.6.0
状态：发生于系统初始化完成之前Y7000：详细模式、异步输出与错误卡点
长期保留 -v 详细模式时，屏幕看起来总是停在相同文字附近；去掉 -v 后出现白苹果和进度条，说明此前“停在最后一行”的判断并不足以描述真实执行位置。但这不等于故障消失：图形界面只让整体进度变得可见，进度条仍会停住。
屏幕上还可能交错打印安全子系统、ACPI 和 PCI 相关信息。最后显示的文字只是最后完成输出的一股信息流，不必然是造成停滞的那一步。更可靠的记录方式，是观察是否出现此前没有的新阶段，并把每次变化与唯一配置变量对应起来。
Y7000：用分组对照缩小范围
Harvey 将第三方扩展分组启用和禁用，得到多组“正常 / 崩溃”的对照，再根据集合差异缩小范围。这个方法能定位到一组候选项，却不能直接证明其中某一个就是根因；后续仍需保持其余条件不变，一次只移除一个候选项。
关于 0xF0000000 的进一步分析提示，它可能不是静态固件表里的普通字段，而是运行时设备地址窗口。寄存器偏移与音频控制器初始化序列存在相似之处，因此音频相关扩展被列为优先验证对象，但这一联系目前只是有证据支撑的假设，尚未通过单变量实验确认。
| 配置组 | 启用的第三方扩展数量 | 观察结果 |
|---|---|---|
| 原始基线 | 28 | 崩溃 |
| 分组 A | 27 | 崩溃 |
| 分组 B | 14 | 崩溃 |
| 最小组 | 2 | 可继续启动 |
| 分组 D | 15 | 可继续启动 |
| 分组 E | 9 | 可继续启动 |
Luminous 的 G5000 对照：cpus=1 仍停在 ACPI 阶段
Luminous 在 G5000 上先复现了早期内核崩溃。关闭 Booter → Quirks → DevirtualiseMmio 后，原始崩溃不再出现，系统进入 ACPI 与 CPU 初始化，但连续出现命名空间查找和方法执行错误，最终没有进入 Recovery。
随后在保持 DevirtualiseMmio 关闭的前提下加入 cpus=1，并把相关启动参数加入 NVRAM Delete 以避免旧值残留，启动位置没有明显改善。再关闭 CpuTopologyRebuild.kext、三项强制开启超线程的内核补丁，并移除 ctrsmt=full，仍停留在大致相同的 ACPI 初始化区域。
多次屏幕记录中可见 AE_NOT_FOUND、Namespace lookup failure、Method parse/execution failed，以及与 \_SB.PMAX._STA 有关的可见末行。不过屏幕最后一条 ACPI 信息不等于真正根因，因此报告没有把 PMAX 或 PXDC 直接定为故障来源。
ACPI Exception: AE_NOT_FOUND
ACPI Error: Namespace lookup failure
ACPI Error: Method parse/execution failed
ACPI Error: [PXDC] Namespace lookup failure
ACPI Error: Method parse/execution failed [\_SB.PMAX._STA]为什么与公开 Issue #6 不同
公开 Issue #6 中，相近的 i7-13650HX 平台在关闭 CPU 拓扑和强制超线程相关补丁、使用 cpus=1 后，能够继续到 PCI、NVMe、APFS 与磁盘映像初始化。Luminous 的 G5000 在相似调整后仍停在更早的 ACPI 区域。
这项差异只说明“相似硬件不一定得到相同启动路径”。可能影响结果的变量包括 BIOS 版本、ACPI 表内容、主板批次、1401 / OpenCore 生成版本、实际生效的 NVRAM 参数，以及两份配置中其他未对齐的项目。未完成配置与日志的逐项比对前，不应声称已经找到原因。
- 下一步优先提供脱敏后的 OpenCore 配置摘要、日志和 ACPI 表清单。
- 请求维护者建议一个最小诊断变化，而不是同时改动多个 Quirk 与补丁。
- 对照测试继续记录 BIOS 版本、配置哈希、屏幕照片和是否出现 NVMe / APFS 阶段。
这轮排查留下的方法
第一，修改过配置不等于修改已经生效，必须在日志或屏幕上找到对应证据。第二，详细模式适合观察早期信息，但不能替代图形引导对整体进度的判断。第三，分组测试只能缩小候选集合，确认单一根因仍需单变量复测。
第四，相近硬件是有价值的对照，却不是可以互相替代的同一环境。把 Harvey 与 Luminous 的记录并列，价值就在于保留差异：Y7000 的进展不能套到 G5000，G5000 的 ACPI 停滞也不能反推 Y7000 的根因。
资料、分工与引用说明
Harvey 完成 Y7000 的全部实机操作、屏幕记录和结果确认，并负责本文主线；Luminous 完成 G5000 的实机对照，将结果整理为提交给 NullMoth 维护者的 GitHub 补充报告。WorkBuddy 负责辅助检索公开资料、整理日志与固件数据、生成测试配置草案和文字校对，但不接触硬件，不能独立验证实测结论。
文章引用项目名称和配置字段仅用于说明兼容性研究。转载或引用本文时，请保留作者、标题、原文链接与上述限制；引用外部项目时，应同时遵守其许可证与商标规则。