あの角を曲がれば、かぼしー

「あのかぼ」のスピンオフサイト「ゼロかぼ」ができました。 詳しくはこちら>

OpenCore Legacy Patcher、Apple Siliconのサポートを開発中か Rosetta 2やARMへの対応を追加

Mac

OpenCore Legacy Patcher、Apple Siliconのサポートを開発中か Rosetta 2やARMへの対応を追加

OpenCore Legacy Patcher (OCLP)はサポートが終了Macに最新のmacOSインストールし、古いMacの有効活用を可能にするプロジェクトです。このOCLPはIntel CPUを搭載したMac を対象にしていましたが、Apple Siliconの対応追加を匂わせる変更が加えられました。

この記事ではOCLP加えられた変更について具体的なコードを確認しつつ、その詳細を分かりやすく解説していきます。

弊ブログ (あのかぼ)ではOpenCore Legacy Patcherを使用してサポートが終了した古いMacに最新のmacOSをインストールする方法について詳しく解説したガイドを公開しております。

目次

OpenCore Legacy PatcherがApple Siliconに対応？

OpenCore Legacy Patcher (OCLP)と言えば、最新のmacOSがインストール/アップグレードが出来なくなってしまったMacにmacOS Big Sur 以降の最新のmacOSをインストールできるようにするプロジェクトです。現在はIntel Macのみのサポートで、Apple MシリーズなどのApple Siliconを搭載したMacでは利用できません。

DRAMやCPU、GPUコアを統合したM1チップ

しかし、OpenCore Legacy PatcherのGitHubリポジトリのコミットを確認すると、Apple Siliconのサポートに向け動き始めているとも取れる変更が加えられています。

短期間のうちにOCLPに加えられた2回の変更の詳細

Apple Siliconをサポートするために加えられた変更は5月11日 (現地時間)に行われたコミット「Add backend support for Apple Silicon root patching」5月21日に行われたコミット「sys_patch_mount.py: Fix mount variable invocation」で確認できます。

この約10日間で行われた2つの変更はいずれもApple Siliconのルートパッチに関するものです。
(この間にOpenLegacyBoot.efiの取り扱いに関する変更も行われているので、Apple Siliconのサポートだけが行われていた訳ではないです。)

Apple Siliconにルートパッチを対応させるためのバックエンド

5月11日に行われたApple Silicon向けの最初のコミット「Add backend support for Apple Silicon root patching」は、Apple Siliconデバイスにおけるルートパッチの基盤を整えるためのものでした。このコミットのうちApple Silicon向けに加えられた変更点について詳しく見ていきます。

Rosetta 2のサポート

Rosetta 2は、Apple Siliconを搭載したMacでx86アプリケーション (Intelバイナリ)を実行するためのエミュレーションレイヤーです。これに対応するため、ルートボリュームのパッチ適用時にはRosetta 2の状態確認が必要となります。

5月11日に加えられた変更ではRosetta 2が有効な場合と無効な場合で、スナップショットの作成方法や管理方法を変化出来るようになりました。例えば、create_snapshotメソッドでは、Rosetta 2の状態に応じて異なる引数をblessコマンドに渡しています。

▼ sys_patch_mount.py内のSysPatchMountクラスにあるcreate_snapshot

    def create_snapshot(self) -> bool:
        """
        Create APFS snapshot of the root volume.
        """
        if self.xnu_major < os_data.os_data.big_sur.value:
            return True

        args = ["/usr/sbin/bless"]
        if platform.machine() == "arm64" or self.rosetta_status is True:
            args += ["--mount", "/System/Volumes/Update/mnt1", "--create-snapshot"]
        else:
            args += ["--folder", "/System/Volumes/Update/mnt1/System/Library/CoreServices", "--bootefi", "--create-snapshot"]


        result = subprocess_wrapper.run_as_root(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
        if result.returncode != 0:
            logging.error("Failed to create APFS snapshot")
            subprocess_wrapper.log(result)
            if "Can't use last-sealed-snapshot or create-snapshot on non system volume" in result.stdout.decode():
                logging.info("- This is an APFS bug with Monterey and newer! Perform a clean installation to ensure your APFS volume is built correctly")

            return False

        return True

ルートボリュームのマウント機能とAPFSスナップショットの作成とリバート

SysPatchMountクラスが導入され、ルートボリュームのマウントとアンマウントを扱うようになりました。これにより、APFSスナップショットの管理が可能となります。

この他、APFSスナップショットの作成とリバート機能の追加の為にcreate_snapshotとrevert_snapshotメソッドが追加され、ルートボリュームのAPFSスナップショットを作成および元に戻す機能サポートされました。これにより、パッチ適用後に問題が発生した場合でも元の状態に戻すことができます。

SysPatchMountクラスにはAPFSスナップショットの作成やリバートを扱う以下のようなメソッドが追加されました。

  • _mount_root_volume
    • ルートボリュームをマウントする。
  • _unmount_root_volume
    • ルートボリュームをアンマウントする。
  • create_snapshot
    • APFSスナップショットを作成する。
  • revert_snapshot
    • APFSスナップショットをリバートする。

変数呼び出しの修正

次のコミット「sys_patch_mount.py: Fix mount variable invocation」は、前のコミットで導入されたルートボリュームのマウントおよびスナップショット処理に関連する変数の呼び出しを修正するものでした。

アンマウントコマンドの修正

umountコマンドで、ハードコードされた"/"および"/System/Volumes/Update/mnt1"の代わりに、self.mount_pathを使用するように変更されました。これにより、環境に応じた正確なマウントポイントが使用されます。

▼ 元のコード (SysPatchMountクラスにある_unmount_root_volume)

        args = ["/sbin/umount"]

        if self.xnu_major == os_data.os_data.catalina.value:
            args += ["-uw", "/"]

        if self.xnu_major >= os_data.os_data.big_sur.value:
            args += ["/System/Volumes/Update/mnt1"]

▼ 修正後のコード (SysPatchMountクラスにある_unmount_root_volume)

        args = ["/sbin/umount"]

        if self.xnu_major == os_data.os_data.catalina.value:
            args += ["-uw", self.mount_path]

        if self.xnu_major >= os_data.os_data.big_sur.value:
            args += [self.mount_path]

スナップショット作成コマンドの修正

スナップショット作成時のblessコマンドでも、同様に動的に決定されるパスを使用するように変更されています。

▼ 元のコード (SysPatchMountクラスにあるcreate_snapshot)

        args = ["/usr/sbin/bless"]
        if platform.machine() == "arm64" or self.rosetta_status is True:
            args += ["--mount", "/System/Volumes/Update/mnt1", "--create-snapshot"]
        else:
            args += ["--folder", "/System/Volumes/Update/mnt1/System/Library/CoreServices", "--bootefi", "--create-snapshot"]

▼ 修正後のコード (SysPatchMountクラスにあるcreate_snapshot)

        args = ["/usr/sbin/bless"]
        if platform.machine() == "arm64" or self.rosetta_status is True:
            args += ["--mount", self.mount_path, "--create-snapshot"]
        else:
            args += ["--folder", f"{self.mount_path}/System/Library/CoreServices", "--bootefi", "--create-snapshot"]

スナップショットリバートコマンドの修正

スナップショットをリバートする際にも、動的に決定されるパスを使用するように変更されています。

スナップショットのリバートに関するコードでは、変数self.mount_locationからself.mount_pathへの変更が行われました。

▼ 元のコード (SysPatchMountクラスにあるrevert_snapshot)

       result = subprocess_wrapper.run_as_root(["/usr/sbin/bless", "--mount", self.mount_location, "--bootefi", "--last-sealed-snapshot"], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)

▼ 修正後のコード (SysPatchMountクラスにあるrevert_snapshot)

result = subprocess_wrapper.run_as_root(["/usr/sbin/bless", "--mount", self.mount_path, "--bootefi", "--last-sealed-snapshot"], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)

前2つのアンマウントコマンドやスナップショット作成コマンドと異なり、もともと変数が使用されていましたが、21日に行われたコミット「sys_patch_mount.py: Fix mount variable invocation」では変数self.mount_locationからself.mount_pathへ変更されました。

もともと使用されていたself.mount_locationは以前のコードで使用されていた変数で、マウント処理やスナップショットのリバート時に使用されていました。

変更後のコードで使用されているself.mount_pathは、SysPatchMountクラス内で動的に設定されるもので、前2つのアンマウントコマンドやスナップショット作成コマンドで使用されている変数と同じものです。

Apple Siliconのサポートに関しては変更履歴には記載がない

OpenCore Legacy Patcherの変更履歴を参照してもApple Siliconサポートや、ルートパッチに対応させるバックエンドの追加などの記載はありません。

1.5.0

  • Restructure project directories
    • Python:
      • Move logic into opencore_legacy_patcher directory
      • Use relative imports for local libraries
    • Documentation:
      • Move images to docs/images
    • Payloads:
      • Remove redundant/unused files bundled in payloads.dmg
  • Resolve unpatching Nvidia Web Drivers failing to clean up /Library/Extensions
  • Implement preflight code signature checks for macOS installer creation
    • Ensures validity of createinstallmedia binary before execution
  • Modularize AutoPkg’s pre/postinstall scripts
    • Adjusted to use functions for better readability
    • Implements ZSH shebang
    • Removes OS logging
  • Disable usage of OpenLegacyBoot.efi
    • Resolves boot issues on certain CSM-based Macs
  • Increment Binaries:
    • OpenCorePkg 1.0.0 – release

1.5.0 (和訳版)

  • プロジェクトディレクトリの再構成
    • Python:
      • ロジックを opencore_legacy_patcher ディレクトリに移動
      • ローカルライブラリに対して相対インポートを使用
    • ドキュメント:
      • 画像を docs/images に移動
    • ペイロード:
      • payloads.dmg にバンドルされている冗長な/未使用のファイルを削除
  • Nvidia Webドライバのアンパッチ時に /Library/Extensions のクリーンアップが失敗する問題を解決
  • macOSインストーラ作成のためのプレフライトコード署名チェックを実装
    • createinstallmedia バイナリの実行前に有効性を確認
  • AutoPkgのプレ/ポストインストールスクリプトのモジュール化
    • 読みやすさ向上のために関数を使用するよう調整
    • ZSHシェバングを実装
    • OSロギングを削除
  • OpenLegacyBoot.efiの使用を無効化
    • 一部のCSMベースのMacでのブート問題を解決
  • バイナリの更新:
    • OpenCorePkg 1.0.0 – リリース

変更履歴自体も5日前に更新があるものの、Apple Siliconに関する言及はないため、今後も継続的にApple Silicon関連の機能を追加した上で正式に発表されるものとみられます。

OCLPのApple Siliconを搭載したMacのフルサポートにはOpenCorePkgのARMサポートが不可欠

OpenCore Legacy Patcher自体はApple Siliconのサポートに向けたと思われる変更が加えられていますが、実際にOpenCore Legacy PatcherがApple SiliconをサポートするにはOCLPの重要なバックボーンであるOpenCorePkgがARMをサポートする必要があります。

ただし、現時点ではARMをサポートするOpenCoreの開発が活発という訳ではありません。
そもそもIntel Macのように(U)EFIをベースとした起動シーケンスからiBootをベースとしたiPhoneやiPadに近い起動シーケンスに代わっており従来のアプローチでは対応が難しい他、そもそもアーキテクチャ自体がARMである上に、Apple Siliconの仕様自体がApple独自に変更されているためHackintoshコミュニティーにとっては悩みの種になっています。

OpenCore Legacy Patcherを開発するDortaniaはOpenCoreを開発するAcidantheraに積極的に関与しており、ARMに関する開発も進むことが期待されます。(Dortaniaのプロジェクトリーダであるミコラ氏や主要メンバーであるDhinak G氏はAcidantheraのメンバー)

Apple SiliconはARMv8.4-AをベースとしたSoCではありますがApple独自の最適化とカスタマイズが施されており、前述の通りARMでのHackintoshという観点においては困難を極めます。そのため一筋縄ではいかないのは想像に難くありません。

OCLPについてもっと知りたい方は

「あのかぼ」ではOpenCore Legacy Patcherのガイドの他、OCLPの起動シーケンスやパッチの内容について解説したドキュメントも公開しております。もっとOCLPについて知りたいという方はぜひご一読ください。

まとめ

ここまでOpenCore Legacy PatcherのApple Silicon を搭載したMac のサポートが加わるかもしれない件の詳細を紹介してきました。

現時点までに加わった2つのコミットはいずれもApple Siliconを搭載したMacでルートパッチを「適用できるようにする機能」で、実際にMacに対し変更を加えるものではありません。ただ、従来Intel Macを対象に開発されてきたOpenCore Legacy PatcherがApple Siliconを搭載したMacを対象にした機能を開発していることは既にApple Siliconデバイスを利用しているユーザにとっては大変心強いものです。

次期macOS (執筆時点ではmacOS 15と仮定されています)の発表が6月に迫り、Intel Macを利用しているユーザにとっては、重大な転換点になる可能性があります。それは次期のmacOS はAppleが発売しているMacのすべてのモデルがApple Siliconへの移行が完了した初めてのリリースになることから、macOS 15 がIntel CPUをサポートしているのかが争点になります。

一方で、現時点ではApple Siliconを搭載したMacはどのモデルも最新のmacOS をサポートしていますが、将来的にサポートが切れた際にOCLPで最新のmacOS がインストールできるようになるかもしれません。

今後のOCLPの開発にもまだまだ目が離せません。

弊ブログ(あのかぼ)と姉妹メディア(おんかぼ)では引き続き、OpenCore Legacy Patcherの最新情報やmacOS Sonoma関連のニュースを紹介していきます。記事の更新については、かぼしーのTwitterアカウントや新着記事告知用のTwitterアカウントで紹介しますので、ぜひフォローいただけると幸いです。

また、現在OpenCore Legacy Patcher専門サイト「OCLP.net」でも執筆中です。ぜひ合わせてご覧ください。

Apple 2023 Mac mini M2 チップ搭載デスクトップコンピュータ: 8コアCPUと10コアGPU、8GB ユニファ...

Apple 2023 Mac mini M2 チップ搭載デスクトップコンピュータ: 8コアCPUと10コアGPU、8GB ユニファ…

AmazonYahoo

Amazonの情報を掲載しています