Asahi Linux、macOS 27ベータ版による起動障害を修正――Apple独自ビデオデコーダーのカスタムファームウェア開発など大きな進展も
2026年7月8日 09:35
macOS 27「Golden Gate」デベロッパーベータをインストールした環境で、Asahi Linuxとのデュアルブートが起動しなくなる問題が発生していたが、このほど直接修復する経路が提供された。2026年6月30日に公開された「Linux 7.1」進捗レポートによると、この問題の修正に加え、Apple独自のビデオデコーダー（AVD）を代替するカスタムファームウェアの開発や、M3チップ対応の急速な進展など、数カ月前には技術的に困難とみられていた複数のブレイクスルーが報告されている。
■macOS 27による起動障害の原因と修復方法
進捗レポートによると、macOS 27で起動障害が発生した原因は、これまで無視されていたAPFSのメタデータフラグが1つ欠けていたためであると判明した。macOS 12から26までのすべてのバージョンでは、起動ディスクの選択画面（ブートピッカー）に表示するボリュームを決定する際、このフラグが設定されていなくても無視されていた。しかし、macOS 27からこのフラグのチェックが厳格化されたという。
Asahi Linuxのインストーラーは、Appleのブートローダーを動作させるために最小限の「スタブAPFSコンテナ」（約2.5GBの最小限のmacOS環境）を作成するが、このコンテナに当該フラグを設定していなかった。そのため、macOS 27にアップグレードすると、データ自体は一切破壊されずパーティション構成も変わらないまま、Asahi Linuxのパーティション全体が起動ディスク選択画面から消失する現象が発生していた。
この原因は、プロジェクトのコントリビューターである「chaos_princess」氏が、AppleのmacOSインストーラーのコードや過去のブートローダー研究の記録を追跡して突き止めた。テスト用のAsahiコンテナに手動でこのフラグを設定したところ、即座にmacOS 27の起動画面に表示されるようになったという。
この修正はすでに「Asahi Installer バージョン 0.8.3」に組み込まれている。新規インストール時には自動でフラグが設定されるほか、すでに影響を受けているユーザーは、macOS側からインストーラーを再実行し、「Fix macOS 27 boot picker compatibility（macOS 27起動画面互換性の修正）」オプションを選択することで、データを失わずに起動環境を復元できる。また、稼働中のLinuxセッション内から修復を適用できるLinuxネイティブの修復プログラムも開発されているが、エッジケースでファイルシステムを破損しないか検証中のため、現在はテスト段階にとどまっている。
■SMCファームウェア変更に伴う強制終了問題も修正
この起動画面の問題はLinuxに限ったものではなかった。米メディアのAppleInsiderによる初期検証では、別パーティションで古いバージョンのmacOSを実行している環境でも同様の起動障害が発生したことが確認されており、macOS 27 Beta 1におけるマルチOS環境全般のバグである可能性が示唆されている。Asahiチームはこの件を「FB22994760」としてAppleにバグ報告を提出した。
さらに、macOS 27に含まれるシステム管理コントローラー（SMC）のファームウェアアップデートにより、もう一つの問題が発生していた。Appleがバッテリー管理インターフェースの戻り値を32ビット整数から1バイトに変更したため、Asahi Linuxの電源管理ドライバーが充電状態や電圧、残り時間を誤認し、バッテリー故障と判断して緊急シャットダウンを引き起こす場合があったという。
この問題に対しては、Asahiのカーネルバージョン 7.0.12（およびそれ以降）にパッチがバックポートされ、新旧両方のSMCファームウェアに対応した。カーネルアップデートを適用する前にmacOS 27ベータ版を導入し、予期せぬシャットダウンが発生していたユーザーは、カーネルを7.0.12以降に更新することで解決できる。
プロジェクトチームは今回の件を受け、開発者向けベータ版を常用環境（プロダクションマシン）にインストールすべきではないと改めて注意を促している。macOSベータ版を通じて適用されるグローバルなファームウェアアップデートは実質的に元に戻せず、ダウングレードにはSecure Enclaveのデータを上書きする「DFU（Device Firmware Update）モード」での完全な初期化が必要になるためだ。チームは、こうした問題を一般ユーザーに影響が及ぶ前に検知するため、ベータテスト専用の検証機を用意して対応している。
■macOS 27のApple Silicon専用化とAsahi Linuxの役割
macOS 27は、Intelプロセッサ搭載Macのサポートを完全に打ち切り、Apple Silicon専用となった初めてのmacOSである。Intel Macという選択肢が消滅したことで、Apple製ハードウェア上でネイティブにLinuxを動作させる唯一の手段として、Asahi Linuxの存在感はさらに増している。同プロジェクトの成果は「Fedora Asahi Remix」に直接反映されるほか、Linuxカーネル本家（メインライン）へのアップストリーム活動を通じて、すべてのアーキテクチャのLinuxユーザーに還元される仕組みとなっている。
このような重要な位置づけにあるからこそ、今回のmacOS 27における起動障害が迅速に特定され、数週間で修正されたことの意味は大きい。Appleはブートローダー（iBoot）からAPFSのコンテナ検出ロジック、周辺機器のファームウェアに至るまで、起動チェーンをエンドツーエンドで制御している。Asahiのドキュメントが「macOSの挙動そのものが仕様である」と言及している通り、起動やファームウェアの挙動に関する事前ドキュメントはAppleから提供されない。そのため、新しいmacOSがリリースされるたびに、プロジェクト側で互換性の検証を独自に行う必要がある。
今回のmacOS 27の不具合が、意図的な排除や設計の根本的な変更ではなく、単なるメタデータフラグの欠落に起因するものだったことは、プロジェクトにとって不幸中の幸いだったと言える。修正方法はシンプルであり、ユーザーのデータが失われることもなかった。
■M3シリーズへの対応が急速に進展
Apple Siliconの「M3」シリーズへの対応も急速に進んでいる。M3のサポート状況トラッカーによると、現在、下流（downstream）のM3向けカーネルにおいて、PCIe、Wi-Fi、Bluetooth、NVMe、キーボード、トラックパッド、CPU動作周波数の切り替え、big.LITTLEタスクスケジューリング、SMCハードウェアセンサー、高音質なスピーカーおよびヘッドホンジャック出力が動作している。
これらの進捗の多くは、最小限の新規コード追加で実現した。これはAsahi Linuxの基本戦略が功を奏した結果である。AppleはM2の基本モデル以降、CPUの動作周波数切り替えの仕組みを変更しておらず、M1/M2向けの「cpufreq」ドライバーにM3のトポロジーを記述した「デバイスツリー」を追加するだけで動作した。オーディオサブシステムも同様に安定しており、I2SバスコントローラーやスピーカーアンプなどのチップはM1から変更されていないため、デバイスツリーと設定ファイルの調整だけで対応できたという。
CPUの周波数切り替えと適切なbig.LITTLEスケジューリングの実現は、バッテリー駆動時間に劇的な効果をもたらす。これが機能していない状態では、Linuxはすべてのタスクを高性能コア（Pコア）に割り当て、高効率コア（Eコア）はアイドル状態になってしまう。スケジューラーが適切に機能し、バックグラウンド処理や軽いタスクを高効率コアに割り当て、低負荷時に高性能コアのクロックを下げられるようになったことで、M3搭載MacでのLinux実行時の電力効率はmacOSの基準に近づきつつある。
なお、M3のGPUアクセラレーションは現時点では利用できず、Asahi Installerも一般ユーザー向けのM3マシンへのインストールにはまだ対応していない。しかしチームは、M3対応の進捗を「急速」と表現しており、初期のM1サポートにおけるアルファ版当時の状況に匹敵する段階に達しているとしている。
■Apple製を再利用せず、独自のビデオデコーダーファームウェアを開発した理由
Apple Siliconには、AVC（H.264）、HEVC（H.265）、VP9、AV1などの動画ストリームをハードウェアで処理する専用ブロック「Apple Video Decoder（AVD）」が搭載されている。これを活用することでCPU負荷を下げ、4K以上の動画再生時の画質向上やバッテリー持ち、発熱抑制に大きく貢献する。
しかし、AVDのファームウェア設計は他のハードウェアブロックとは異なっていた。多くのApple製ハードウェアは「RTKit」と呼ばれる標準化されたリアルタイムOSフレームワークを使用しているが、AVDはこれらを使用せず、独自のファームウェアを実行する「ARM Cortex-M3」マイクロコントローラーによって制御されている。このファームウェアはAppleのカーネル拡張（kext）内に格納されており、SoCのバリアントごとに異なるオフセット値でバンドルされていた。
この仕様は、Linuxカーネル本家への統合（アップストリーム化）を目指す上で大きな障害となった。macOSのアップデートごとにファームウェアのオフセット位置が変わる可能性があり、その都度Asahi側で対応を迫られるため、メンテナンスの負担が極めて大きくなるからである。
そこでAsahiチームは、よりエレガントな解決策を発見した。AVD上のCortex-M3は、リセットベクターから与えられたコードを署名検証なしで実行する仕様になっていた。これを利用し、新規メンバーの「sofus」氏が、完全にゼロから動作するカスタムファームウェアを書き上げた。このカスタムファームウェアは、割り込みハンドラーをインストールし、初期化時にApple製ファームウェアが適用するハードウェア調整値を再現するだけのシンプルな設計となっている。これにより、デコーダーの制御自体はLinuxのカーネルドライバーとユーザー空間から直接行えるようになり、ファームウェア自体をステートレス（状態を持たない構成）に保つことに成功した。
さらにsofus氏は、このファームウェア上で動作する、Linux標準のステートレスコーデックインターフェース「V4L2 Request API」に対応したドライバーを構築した。これにより、最大4K解像度の10ビットAVC/H.264動画のハードウェアデコードが可能となった。
このステートレス設計の意義は大きい。FirefoxやChromiumなどのブラウザがハードウェア動画再生支援を要求する際に使用する「VA-API」や、GPUアクセラレーションを用いたコーデック処理の標準規格「Vulkan Video」は、このV4L2レイヤーの上に構築できるためだ。現時点ではVP9、HEVC、AV1のデコードは未実装であり、一般ユーザー向けに提供するにはさらなる実機テストが必要だが、Cortex-M3のQEMUエミュレーターなどを駆使したリバースエンジニアリングによるアーキテクチャの基礎工事は完了したという。
ファームウェアを抽出して再利用するのではなく、独自の代替ファームウェアを開発するというこの手法は、今後カーネル拡張内にファームウェアが埋め込まれている他のハードウェアブロックに対しても適用される方針である。開発されたファームウェアとドライバーのソースコードは、GitHubの「avd-fw」リポジトリで公開されている。
■macOS 27ベータ版による起動障害が発生しているか確認する方法
2026年6月20日頃より前にmacOS 27デベロッパーベータをインストールし、起動ディスク選択画面にAsahi Linuxのパーティションが表示されなくなった場合、データは失われていないため、以下の手順で復旧が可能である。
macOSを起動してターミナルを開き、Asahi Installerを再実行する。メニューが表示されたら「Fix macOS 27 boot picker compatibility」を選択して実行する。処理が完了すれば、起動画面に再びAsahi Linuxが表示されるようになる。
また、使用しているLinuxカーネルが7.0.12未満の場合、予期せぬシャットダウンが発生していないか確認してほしい。macOS 27ベータ版によるSMCの仕様変更が原因で、バッテリー残量を誤認して緊急シャットダウンが誘発されている可能性がある。この問題は、Linux側でカーネルを7.0.12以降にアップデートすることで解決できる。
■注目ポイントQ&A
●macOS 27ベータ版をインストールした後にAsahi Linuxを修復するにはどうすればよいですか？
macOS上からAsahi Installerを再実行し、「Fix macOS 27 boot picker compatibility」オプションを選択してください。これにより、macOS 27で必須となったAPFSの起動可能ボリュームフラグが既存のコンテナに書き込まれます。この操作でデータが削除されたり再フォーマットされたりすることはありません。また、予期せぬシャットダウンが発生している場合は、Linuxのカーネルをバージョン7.0.12以降にアップデートしてください。
●なぜmacOS 27はAsahi Linuxを起動できなくしたのに、データは消去されなかったのですか？
パーティションが削除されたわけではなく、起動画面（ブートピッカー）での表示ロジックが変更されたためです。macOS 27の起動画面では、APFSコンテナのメタデータに特定の「起動可能ボリュームフラグ」が設定されていることが必須となりました。従来のAsahi Installerはこのフラグを書き込んでいなかったため、表示されなくなっていました。パーティションやファイルシステムは無傷で残っていたため、メタデータにフラグを追加するだけで元通りに表示されるようになります。
●独自開発されたAVDファームウェアは、Apple Silicon上の動画再生にどのようなメリットをもたらしますか？
オープンソースかつメインラインに統合可能な形で、ハードウェアアクセラレーションによる動画再生を実現する第一歩となります。このドライバーが一般向けに提供され、HEVCやAV1にも対応すれば、FirefoxやChromiumなどのブラウザでCPUに負荷をかけずに動画を再生できるようになります。これにより、特にファンレス設計やバッテリー容量に限りのあるMacBookモデルにおいて、動画再生時の消費電力と発熱を大幅に削減できます。
●2026年秋に予定されているmacOS 27の正式リリース時に、再びAsahi Linuxが起動しなくなる可能性はありますか？
Asahi Installer v0.8.3以降では、新規インストールおよび修復時にこのAPFS起動可能ボリュームフラグを自動的に書き込むため、今回の特定の変更によって再び起動できなくなることはありません。ただし、正式リリース時にAppleが起動チェーンに新たな変更を加えるかどうかは不明です。Asahiプロジェクトでは、ユーザーにOSアップデートを推奨する前に、新しいメジャーリリースごとに必ず互換性チェックを実施しています。
元記事: Asahi Linux Patches macOS 27 Boot Break, Builds Custom Firmware for Apple Video Decoder