随着 macOS 27 "Golden Gate" 开发者测试版的推送，Asahi Linux 用户曾面临双启动失效的风险。最新进展报告显示，该项目不仅提供了直接恢复路径，还在 Apple 专有视频解码器固件替代方案及 M3 芯片支持上取得两项关键突破。

启动故障根源与修复

2026 年 6 月 30 日发布的 Linux 7.1 进展报告确认，macOS 27 导致的启动故障源于一个此前被忽略的 APFS 元数据标志。从 macOS 12 至 26 版本，系统在决定启动选择器显示内容时均静默跳过该标志，而 macOS 27 开始强制执行检查。由于 Asahi Installer 为满足 Apple 引导程序要求创建的极简 2.5 GB 存根容器从未设置此标志，导致升级后 Asahi 分区在启动选择器中消失。值得注意的是，底层分区布局未变，数据完好无损。

贡献者 "chaos_princess" 通过追踪 Apple 安装程序代码及早期研究录像定位了问题。手动设置该标志后，分区立即恢复可见。目前，Asahi Installer 0.8.3 版本已部署修复：新安装将自动设置标志，受影响用户可通过重新运行安装程序并选择 " 修复 macOS 27 启动选择器兼容性 " 选项恢复访问。此外，团队正在测试一款可在运行中的 Linux 会话直接应用修复的工具，以验证其在边缘情况下的安全性。

测试证实，这一回归影响波及所有在独立分区运行旧版 macOS 的用户，表明 macOS 27 Beta 1 引入了广泛的跨系统回归，而非针对 Linux 的特异性变更。Asahi 团队已向 Apple 提交编号为 FB22994760 的错误报告。

macOS 27 的系统管理控制器 ( SMC ) 固件更新引发了另一问题：电池管理接口返回值从 32 位整数改为单字节，导致 Asahi 电源驱动误判电池失效并触发紧急关机。已在下游内核 7.0.12 中向后移植的补丁解决了此兼容性问题。团队重申，开发者测试版包含永久性固件更新，撤销需完整恢复设备固件，建议仅使用牺牲机进行测试。

M3 芯片支持加速推进

macOS 27 是首个仅支持 Apple Silicon 的版本，随着 Intel 备用方案消失，Asahi Linux 成为在 Apple 硬件原生运行 Linux 的唯一途径。项目持续向主线 Linux 内核提交驱动，其成果将惠及所有架构用户。

在 M3 系列芯片支持上，Asahi 取得显著进展。PCIe、Wi-Fi、蓝牙、NVMe、输入设备及 SMC 传感器均已正常工作。得益于 Apple 硬件架构的一致性，M1/M2 的 cpufreq 驱动仅需添加设备树条目即可适配 M3，音频子系统亦沿用相同架构。CPU 频率调节与 big.LITTLE 任务调度的完善，使后台任务能合理分配至能效核心，显著提升了 M3 Linux 设备的能效表现，缩小了与 macOS 的体验差距。

尽管 M3 GPU 加速尚不可用，且 Installer 暂未面向普通用户开放 M3 安装，但团队表示进展迅速，堪比早期 M1 支持阶段。

自研视频解码固件打破依赖

为解决 Apple Video Decoder ( AVD ) 固件嵌入内核扩展 ( kext ) 且偏移量随版本变动带来的维护难题，Asahi 团队选择了构建自定义固件而非提取 Apple 专有 blob。AVD 模块由裸 ARM Cortex-M3 微控制器控制，不进行固件签名验证。

贡献者 "sofus" 从头编写了最小化自定义固件，负责安装中断处理程序并重播硬件调优值，使底层解码寄存器完全由 Linux 驱动编程。基于此，团队构建了支持 V4L2 Request API 的驱动程序，目前已实现最高 4K 分辨率的 10 位 AVC/H.264 解码。虽然 VP9、HEVC 和 AV1 尚未支持，但该无状态架构为未来通过 VA-API 或 Vulkan Video 实现硬件加速奠定了基础。这一 " 替换而非包装 " 的策略将成为处理类似固件模块的标准模式。

用户自查与修复指南

若在 2026 年 6 月 20 日前安装 macOS 27 开发者测试版后发现 Asahi 分区消失，用户无需担心数据丢失。只需在 macOS 终端重新运行 Asahi Installer 并选择修复选项即可恢复。若曾经历意外关机，请确保内核版本升级至 7.0.12 或更高，以解决 SMC 电池接口变更引发的电源管理问题。

【星途科讯 图文丨赵晶 首发于 ZAKER 科技，转载请注明出处】