運用 on Boot macOS

macOS Sequoia 15.6.1 に更新

Tue, 26 Aug 2025 13:37:01 +0900

macOS Sequoia 15.6.1がリリース（2025/8/20）されていたので、15.6から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.63GBです。OCLPでパッチを当てているので、フルサイズになっているようです。

OCLPを外すと、678.2MBになりました。アップデートの内容は、セキュリティ修正のようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。ビルド番号は24G90でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.6から15.6.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.6 に更新

Thu, 07 Aug 2025 21:58:53 +0900

macOS Sequoia 15.6がリリース（2025/7/29）されていたので、15.5から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.63GBです。OCLPでパッチを当てているので、フルサイズになっています。

OCLPを外すと、1.43GBになりました。アップデートの内容は、バグとか脆弱性への対応のようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24G84でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.5から15.6にアップデートしました。今まで通り、安定して動作しています。

OpenCore 1.0.4 から1.0.5に更新

Thu, 07 Aug 2025 20:13:25 +0900

OpenCoreの1.0.5が公開 (2025年7月7日) されていたので1.0.4からアップデートしました。config.plistに追加された項目はありませんでしたので、1.0.4 のconfig.plistそのままでも動きます。

1.0.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

大きな変更は無いようですが、

Fixed kext injection compatibility issues with macOS 26

という項目があるので、macOS Tahoeに少し対応したのかもしれません。

OpenCore 1.0.5とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.5
OpenCore Legacy Patcher 2.3.2 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, RestrictEvents.kext, VirtualSMC.kext, WhateverGreen.kext がアップデートされてましたので、これも最新にしました。

EFIのバックアップを取る

何かあって起動しなくなると大変ですから、EFIのバックアップをとっておきます。EFIフォルダをどこかにコピーしておけば良いだけの簡単な作業です。Kext Updaterには、EFI Backupというボタンがありますからこれを押すと ~/Documents/EFI-Backup/EFI_Backup_2024.12.13-19-17.zipというような名前でバックアップしてくれるので、さらに簡単です。ただ、起動しなくなった場合に、このファイルにアクセスできる手段は用意しておく必要があります。通常はAPFSなので、EFIシェルやWindowsからはアクセスできません。

起動しなくなった場合に即座に対応したいならば、FAT32でフォーマットしたUSBメモリに、EFIという名前のフォルダを作り、起動に使っているEFIファイル類をコピーしておくと良いです。BIOSからこのUSBメモリを指定すれば、アップデート前と同様に起動します。私の場合は、iCloudでDocuments以下を同期してあるので、他のMacからすぐに読み出せます。

.efiファイルを差し替える

更新するために、今までと同様に、X64/EFIフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。

config.plistを作り直す

現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作ります。

この際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。

今回追加された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。

macOS Sequoia 15.5 に更新

Mon, 26 May 2025 01:37:09 +0900

macOS Sequoia 15.5がリリース（2025/5/13）されていたので、15.4.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.62GBです。OCLPでパッチを当てているので、フルサイズになっています。

OCLPを外すと、1.53GBになりました。Apple Intelligenceが売りのようです。でも、Apple IntelligenceはIntel Macでは動かないので、Hackintoshでも使えません。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24F74でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.4.1から15.5にアップデートしました。今まで通り、安定して動作しています。

Apple Intelligenceには未対応でした。例えば、Apple Silicon搭載MacだとインストールされるImage Playground.app（AIによる画像生成を試すアプリ）は、インストールされませんでした。Apple Intelligenceを使うためには、Apple Silicon搭載Macに買い換える必要があります。

macOS Sequoia 15.4.1 に更新

Wed, 23 Apr 2025 12:15:18 +0900

macOS Sequoia 15.4.1がリリース（2025/4/16）されていたので、15.4から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.58GBです。OCLPでパッチを当てているので、フルサイズになっています。

OCLPを外すと、842.1MBになりました。脆弱性に対応したセキュリティアップデートのようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24E263でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.4から15.4.1にアップデートしました。今まで通り、安定して動作しています。

OpenCore 1.0.3 から1.0.4に更新

Sat, 12 Apr 2025 21:53:08 +0900

OpenCoreの1.0.4が公開 (2025年3月4日) されていたので1.0.3からアップデートしました。config.plistに追加された項目は1件だけですが、デフォルトで対応しました。なので1.0.3 のconfig.plistそのままでも動きます。

1.0.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.4とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.4
OpenCore Legacy Patcher 2.3.2 (WiFi対応のため)

今回のタイミングでAppleALC.kext, VirtualSMC.kextがアップデートされてましたので、これも最新にしました。

EFIのバックアップを取る

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。

config.plistを作り直す

今回追加された項目は、以下でした。

Booter/Quirksに、ClearTaskSwitchBit が追加されました。古いmacOSで32bitカーネルが動作する場合に必要な機能らしいです。古いmacOSは使ってないので、デフォルトのまま、falseにしておきました。

デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動すると思います。

macOS Sequoia 15.4 に更新

Tue, 01 Apr 2025 22:53:51 +0900

macOS Sequoia 15.4がリリース（2025/3/31）されていたので、15.3.2から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

OCLPを外すと、3.34GBになりました。写真でメモリー動画が作れるようになったようです。AIでメール仕分けするとか、いろいろ便利になりそうです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ログインしようとすると、今までのアップデートとは違って、「次回から自動ダウンロードします」とか、「ようこそMacへ」などの画面が出ましたが、そのあとは、普通通りログインします。

ビルド番号は24E248でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.3.2から15.4にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.3.2 に更新

Wed, 12 Mar 2025 19:27:05 +0900

macOS Sequoia 15.3.2がリリース（2025/3/11）されていたので、15.3.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.22GBです。OCLPでパッチを当てているので、フルサイズになっています。そのせいか、説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。

OCLPを外すと、642.9MBになりました。アップデート内容は、セキュリティアップデートのようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D81でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.3.1から15.3.2にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.3.1 に更新

Fri, 21 Feb 2025 17:53:59 +0900

macOS Sequoia 15.3.1がリリース（2025/2/11）されていたので、15.3から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

OCLPを外すと、640MBになりました。アップデート内容は、セキュリティアップデートのようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D70でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.3から15.3.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.3 に更新

Wed, 05 Feb 2025 14:44:54 +0900

macOS Sequoia 15.3がリリース（2025/1/27）されていたので、15.2から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

OCLPを外すと、1.39GBになりました。説明は、前回のアップデートからの差分の内容になりました。15.3では、計算機に機能が追加されたようです。もちろん、これだけでなく、多数のアップデートがされているはずと思います。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D60でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

新機能を試す

アップデート内容に、「“計算機”で、等号をもう一度クリックすると、最後の数式の演算を繰り返すことができます」という項目がありましたので、試してみました。計算機を開いて、100×1.05=を計算します。

100×1.05=を入力

100万円を年利5%の定期預金に預けた1年後の預金額、の計算です。結果は105万円です。ここで=キーをさらに押したところ、最後のx1.05=の演算が繰り返されました。=キーを全部で10回押せば、複利計算されて、10年後の預金額、162.889万円になります。

100×1.05==========を入力

ちなみに、バージョン15.2の計算機では、=を複数回押しても、結果は変化しませんでした。

まとめ

macOS Sequoia 15.2から15.3にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.2 に更新

Fri, 13 Dec 2024 19:15:10 +0900

macOS Sequoia 15.2がリリース（2024/12/12）されていたので、15.1.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.25GBです。OCLPでパッチを当てているので、フルサイズになっています。説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。

OCLPを外すと、2.17GBになりました。説明は、前回のマイナーアップデートからの差分の内容になりました。15.2では、写真とSafariなどに機能が追加されたようです。

更新する

「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24C101でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

新機能を試す

天気

アップデート内容に、「メニューバーに“天気”を追加すると、現在の気象状況をMacのメニューバーで確認したり、クリックして詳しい天気予報に素早くアクセスしたりできます」という項目がありましたので、試してみました。「アップルマーク」「システム設定」「コントロールセンター・メニューバーのみ」の天気を「メニューバーに表示」にします。デフォルトは非表示でした。これで、以下のように、メニューバーから天気を確認できます。

株価

「“株価”の時間外（立会時間前）の株価で、市場が開く前にNASDAQとNYSEの銘柄を追跡できます」という機能も追加されたので確認しました。以下は、15.1.1での株価（上）と、15.2での株価（下）のスクショです。

日本時間で18時過ぎのスクショなので、NASDAQは立会時間前取引の時刻です。日本時間早朝に終了した立会時間取引の終値に加えて、立会前価格が実時間で表示されるようになりました。グラフ部分は、立会時間内の価格グラフだけで、今までと変わりません。

まとめ

macOS Sequoia 15.1.1から15.2にアップデートしました。今まで通り、安定して動作しています。

OpenCore 1.0.2 から1.0.3に更新

Fri, 13 Dec 2024 16:31:40 +0900

OpenCoreの1.0.3が公開 (2024年12月4日) されていたので1.0.2からアップデートしました。config.plistに追加された項目はありません。なので1.0.2 のconfig.plistそのままでも動きます。

1.0.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.3とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.1.1
OpenCore Legacy Patcher 2.2.0 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, WhateverGreen.kextがアップデートされてましたので、これも最新にしました。

EFIのバックアップを取る

起動しなくなった場合に即座に対応したいならば、FAT32でフォーマットしたUSBメモリに、EFIという名前のフォルダを作り、起動に使っているEFIファイル類をコピーしておくと良いです。BIOSからこのUSBメモリを指定すれば、アップデート前と同様に起動します。

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。

config.plistを作り直す

今回追加された項目はありませんでした。古いconfig.plistのままでも、変更なしで起動すると思います。

OpenCore 1.0.1 から1.0.2に更新

Wed, 27 Nov 2024 22:09:42 +0900

OpenCoreの1.0.2が公開 (2024年10月9日) されていたので1.0.1からアップデートしました。config.plistに追加された項目は1点だけで、デフォルトのままで問題ありません。なので1.0.1 のconfig.plistそのままでも動きます。

1.0.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.2とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.1.1
OpenCore Legacy Patcher 2.1.2 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, RestrictEvents.kext, VirtualSMC.kext, WhateverGreen.kextがアップデートされてましたので、これも最新にしました。

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

今回追加された項目は、以下でした。

UEFI/ReservedMemoryに、Unload が追加されました。array型の情報で、初期値は空です。すでに存在するファームウェアドライバをアンロードする項目とのことです。デフォルトのまま、空にしておきました。

大きな変更はありませんので、古いconfig.plistのままでも、変更なしで起動すると思います。

macOS Sequoia 15.1.1 に更新

Fri, 22 Nov 2024 23:51:53 +0900

macOS Sequoia 15.1.1がリリース（2024/11/19）されていたので、15.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。セキュリティアップデートとのことなので、機能は変わらないと思われます。

サイズは、macOSの本体とほぼ同じ14.53GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、651.1MBになりました。

「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24B91でした。

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.1から15.1.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.1 に更新

Tue, 29 Oct 2024 17:58:55 +0900

macOS Sequoia 15.1がリリース（2024/10/28）されていたので、15.0.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。iPhoneミラーリングでドラッグ&ドロップが可能になったようです。iPhoneミラーリングは、セキュリティチップのないHackintoshでは使えない機能ですが、実機のMacで使うととても便利です。

サイズは、macOSの本体とほぼ同じ14.53GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、1.883GBになりました。「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24B83でした。

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.0.1から15.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.0.1 に更新

Sat, 05 Oct 2024 20:22:15 +0900

macOS Sequoia 15.0.1がリリース（2024/10/3）されていたので、15.0から更新しました。バグ修正のアップデートということもあり、特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。アップデート項目が多数列挙されていますが、Sequoiaになっての新機能がまだ表示されているだけのようです。今回の更新目的は、バグ修正なので機能の変更は無いものと思われます。

Software Update

サイズは、macOSの本体とほぼ同じ14.45GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、774.8MBになりました。「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

Download

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24A348でした。

About This Mac

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.0から15.0.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia を自作PCにインストール

Tue, 17 Sep 2024 15:29:37 +0900

macOS 15.0 Sequoia が日本時間2024/9/17に公開されました。これを、ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600で構成した自作PCにインストールしました。OpenCore、kext類は最新です。Sonoma 14.6.1を起動している設定と全く同じ設定で動作しました。使用できないSequoiaの機能はあるかと思いますが、基本的に問題なく動作します。

OpenCoreの設定

OpenCoreの設定は、Sonomaを動かしていた時と同様で、全く変更していません。Wi-Fiに関する設定については、こちらをご覧ください。

SonomaでBroadcom Wi-Fiを有効にする

以下の作業で使ったOpenCoreの設定 (EFIのファイル類) を、こちらに置いておきました。参考になさってください。（シリアル番号などは適当に書いてありますのでこちらを参考にしてconfig.plistを書き換えてください）

Sequoiaインストーラを入手

macOSインストーラーを入手するために、ベータ版の時と同様にsoftwareupdateコマンドを使いました。Sequoia対応のMacのターミナルで、以下のコマンドを入力すると、Sequoiaがダウンロード可能なことがわかります。ちなみに、Sonomaの方も14.7が配布されているようでした。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia, Version: 15.0, Size: 14138558KiB, Build: 24A335, Deferred: NO
* Title: macOS Sonoma, Version: 14.7, Size: 13343514KiB, Build: 23H124, Deferred: NO
（以下略）

次に、同じくsoftwareupdateコマンドで、Version 15.0のダウンロードを指定すると、Sequoiaをダウンロードできました。公開日当日で混んでいるためか、時間がかかりました。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 5.0%

Installingの数値が100%に到達すると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、Install macOS インストール.appというインストーラが出来上がってました。

macOS Sequoia Installer

クリーンインストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.1です。このコンピュータには、以下の２個のSSD（他にも多数接続してます）が接続されてます。

Macintosh HD (OpenCore 1.0.1 とSonoma 14.6.1)
Sequoia (Sequoia Beta 8)

現在、Macintosh HDのOpenCoreで起動して、SequoiaのSequoia Beta 8を動かしています。Sequoia Beta 8から起動した状態で、Macintosh HDをフォーマットして、クリーンインストールすることにしました。

ちなみに、ユーザー用のディレクトリは、homeと名付けた別のボリュームに入れてます。システムだけがMacintosh HDに入っているので、これだけを消去しました。EFIもユーザデータも無事なはずです。

HDD構成

次に、Sequoia Beta 8で起動している状態で、先のInstall macOS インストール.appを開きます。

macOS Sequoia Installer

続けるボタンを押して、消去したばかりのMacintosh HDボリュームをインストール先に選択しました。これでクリーンインストールができるはずです。

インストールの準備が終わると、再起動を促す表示が現れます。この先2-3回ほど再起動し、最初はmacOS Installerというボリュームから起動し、次回以降はMacintosh HDから起動しました。EFIボリュームに残したOpenCoreは正しく機能していたようです。

動作確認

この後、無事Sequoiaが起動して、通常通り使用できました。

About This Mac

ユーザディレクトリを、元のhomeボリュームに戻したので、データも全部引き継がれました。実用的に使えてますので、Sonomaから完全移行することにします。

OCLPは2.0.1になってましたので、これでBroadcomのWi-Fi設定をしました。Wi-Fiも接続可能になりました。

OCLP 2.0.1

Sequoiaの目玉機能の一つだったiPhoneミラーリングは、動作しませんでした。iPhoneとBluetoothで接続できて、コード認証の画面までは進むのですが、その後、Wi-Fiで接続する段階で動作しなくなりました。T2チップ、もしくはApple Siliconが必要らしく、今後も無理そうです。

iPhone mirroring

まとめ

macOS 15.0 Sequoiaが公開されたので、ASRock Z690 Steel Legendで自作したPCにインストールしました。Sonomaの時に使用していたのと同じOpenCore設定で動作しました。EFIファイル類は以下で公開してますので、参考になさってください。

Sequoia

T2チップを利用した一部機能は動作しませんが、実用的には問題なく使用できてます。

OpenCore Legacy PatcherがSequoiaに対応

Sun, 15 Sep 2024 13:15:05 +0900

OpenCore Legacy Patcher (OCLP)の 2.0.0がリリースされました。Sequoiaのベータ版にインストールしたところ、SequoiaでもBroadcomのWi-Fiが使えることを確認しました。

Sonoma以降で使えなくなったBroadcomのWi-Fiは、OpenCore Legacy Patcher (OCLP) を使うと復活できます。詳細は以下の記事をご覧ください。

SonomaでBroadcom Wi-Fiを有効にする

OCLPがSequoiaに対応

SonomaのWi-Fi対応のために使っているOCLPから、アップデートの案内が出てました。Ver. 2.0.0になって、Sequoiaに対応したようです。

OpenCore Legacy Patcher update

そこで早速試してみることにします。

Sequoiaベータ版にインストール

ここからは、Sequoiaベータ版を起動して進めました。ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600を以下の設定で使ってます。

macOS Sequoia 15 Beta 8をインストール

Sequoiaベータ版は、メインで使っているSSDとは別のSSDにインストールしてあります。コンピュータのUEFIの起動は、SonomaがインストールされたメインのSSDで行い、OpenCoreの起動ボリューム選択で、Sequoia SSDを起動します。なので、OpenCoreの設定やkext類はSonomaを動かしている状態のままです。

次に、OCLPリリースページから、2.0.0をダウンロードします。

https://github.com/dortania/OpenCore-Legacy-Patcher/releases

ここから、OpenCore-Patcher.pkgをダウンロードしました。pkgファイルを開くと、インストーラが起動します。

OCLPインストーラ

インストール終了すると、アプリケーションフォルダの中にOCLPアプリができているので起動します。

OCLP 2.0.0

ここで、Post-Install Root Patchを選ぶと、Wi-Fi関係のパッチを当てられます。

Post-Install Root Patch

再起動するとWi-Fiが使えるようになってました。

Wi-Fi

まとめ

OCLPがアップデートされて2.0.0になり、Sequoiaに対応しました。そこでSequoiaベータ版で、動作を確認しました。OCLPを起動してボタンを押すだけでWi-Fiが動作するようになりました。SonomaとSequoiaの差は少ないようで、同じOpenCore設定で問題なく動作してます。OCLPのおかげでWi-Fiも動くようになったので、Sequoiaリリース日には、すぐに移行しようと考えてます。

macOS Sequoia 15 Beta 8をインストール

Fri, 30 Aug 2024 14:25:42 +0900

macOS Sequoia 15のDeveloper Beta 8が2024/8/29に公開されていました。ビルドは24A5331bです。前回のDeveloper Beta 7に引き続き、このDeveloper Beta 8も自作PCにインストールしてみました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.6.1を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 8インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Betaを選ぶとBeta 6が、Developer Betaを選ぶとBeta 8がダウンロードできるようになります。

Screenshot

softwareupdateコマンドで確認すると、どちらを選んでもビルド番号は24A5331bで、同じもののようです。以下では単にBeta 8と書くことにします。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14086413KiB, Build: 24A5331b, Deferred: NO
（以下略）

softwareupdateコマンドでVersion 15.0のダウンロードを指定すると、Beta 8をダウンロードできました。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 25.0%

Installingの数値が100%になると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、Install macOS Sequoia Beta.appというインストーラが出来上がってました。

Screenshot

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.1で、macOS 14.6.1で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。

Installer

この後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。

このSSDには、前回インストールしたBeta版が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールの準備が終わると、再起動を促す表示が現れます。

Restart Your Mac

この先3回再起動し、最初はmacOS Installerというボリュームから起動し、次回以降はインストール先に指定したボリュームから起動しました。

動作確認

この先、無事にmacOS Sequoiaが動作しました。前回同様、Radeon RX 6600のDP端子にも画像が出ました。日本語変換のインラインインタフェースも前回同様に正常動作しました。

About This Mac

これは仕方ないことですが、WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

WiFi

まとめ

macOS Sequoia Developer Beta 8を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。

macOS Sequoia 15 Beta 7をインストール

Sat, 24 Aug 2024 18:02:30 +0900

macOS Sequoia 15のDeveloper Beta 7が2024/8/21に公開されていました。ビルドは24A5327aです。前回のDeveloper Beta 6に引き続き、このDeveloper Beta 7も自作PCにインストールしてみました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.6.1を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 7インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Betaを選ぶとBeta 5が、Developer Betaを選ぶとBeta 7がダウンロードできるようになります。

Screenshot: Download Beta

softwareupdateコマンドで確認すると、どちらを選んでもビルド番号は24A5327aで、同じもののようです。以下では単にBeta 7と書くことにします。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14086413KiB, Build: 24A5327a, Deferred: NO
（以下略）

softwareupdateコマンドでVersion 15.0のダウンロードを指定すると、Beta 7をダウンロードできました。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 13.0%

Screenshot

インストールする

Installer

このSSDには、前回インストールしたBeta 6が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールの準備が終わると、再起動を促す表示が現れます。

Restart Your Mac

この先、2回再起動し、いずれもmacOS Installerというボリュームから起動しました。

動作確認

DPから映像が出る

この先、無事にmacOS Sequoiaが動作しました。今回から、Radeon RX 6600のDP端子に画像が出るようになりました！今までのようにHDMI端子に切り替える必要はありませんでした。

Screenshot

インラインでの日本語変換

日本語変換のインタフェースにも進展がありました。今までは、メモアプリなどの一部のアプリでしかインラインでの変換ができませんでした。Safariで文章を入力すると、確定するまで表示されない状態でした。これが改善されて、正常に日本語入力できるようになりました。

そのほか

WiFi

まとめ

macOS Sequoia Developer Beta 7を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。ディスプレイポートからの映像出力ができるようになり、日本語入力のインタフェースも完璧になりました。使い込んでいないので、動作しない機能があるのかもしれませんが、すぐに移行しても問題ない気もします。

OpenCore 1.0.0 から1.0.1に更新

Thu, 22 Aug 2024 11:50:56 +0900

OpenCoreの1.0.1が公開されていたので1.0.0からアップデートしました。config.plistに追加された項目はありません。なので1.0.0 のconfig.plistそのままでも動きます。

1.0.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。Sequoia対応に関しても記述はありませんが、手元の環境ではSequoiaベータ版が問題なく起動できているので、大きな問題は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.1とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.6.1
OpenCore Legacy Patcher 1.5.0 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, RestrictEvents.kext, VirtualSMC.kext, WhateverGreen.kextがアップデートされてましたので、これも最新にしました。

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

比較した結果、新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。

macOS Sequoia 15 Beta 6をインストール

Thu, 22 Aug 2024 10:49:44 +0900

macOS Sequoia 15のDeveloper Beta 6が2024/8/13に公開されていました。Public Beta 4に相当するベータ版のようです。前回のDeveloper Beta 4に引き続き、このDeveloper Beta 6も自作PCにインストールしてみました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.6.1を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 6インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Beta, Developer Beta, 15.1 Developer Betaの選択肢がありますが、どれを選んでも、この先でダウンロードされるベータ版は同じでした。

Screenshot: Download Beta

今回はPublic Betaを選んでみたところ、macOS Sequoia 15 Beta 5というアップデートが現れました。

Screenshot: Public Beta 5

Developer Betaを選ぶと、今度はmacOS Sequoia 15 Beta 7というアップデートが現れます。でもsoftwareupdateで調べたところ、どちらも同じビルド番号24A5320aでした。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14086413KiB, Build: 24A5320a, Deferred: NO
（以下略）

これはDeveloper Beta 6もしくはPublic Beta 4に相当するもののようです。Developer Beta 7 もしくはPublic Beta 5 は予告だけで、まだ用意されていないのかもしれません。以下ではDeveloper Beta 6を単にBeta 6と書くことにします。

softwareupdateコマンドでVersion 15.0を指定すると、Beta 6をダウンロードできます。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 13.0%

Installingの数値が100%になると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、Install macOS Sequoia Beta.appというインストーラが出来上がってました。どういうわけかアプリ名が英語に戻ってました。

Screenshot

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.6.1で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。これも英語表示に戻りました。

Installer

このSSDには、前回インストールしたBeta 4が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールの準備が終わると、再起動を促す表示（これも英語に戻りました）が現れます。

Restart Your Mac

この先、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況は今までのBeta版と同じでした。HDMI端子には映像が出ます。デフォルトの壁紙が、セコイアの森に変わってました。

About This Mac

WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

WiFi

まとめ

macOS Sequoia Developer Beta 6を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。壁紙がセコイアの森に変更されていました。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。

macOS Sonoma 14.6.1 に更新

Tue, 20 Aug 2024 21:43:36 +0900

macOS Sonoma 14.6.1がリリース（2024/8/8）されていたので、14.6から更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.64GBです。

Screenshot: software update

「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23G93でした。

Screenshot: About This Mac

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、無事Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.6から14.6.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sonoma 14.6 に更新

Sat, 03 Aug 2024 23:14:28 +0900

macOS Sonoma 14.6がリリース（2024/7/29）されていたので、14.5から更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.64GBです。

Update 14.6

「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23G80でした。

About this Mac.

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、無事Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.5から14.6にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15 Beta 4をインストール

Mon, 29 Jul 2024 12:51:03 +0900

macOS Sequoia 15のDeveloper Beta 4が2024/07/24に公開されていました。同時に公開されたPublic Beta 2と同じもののようです。Public Beta 1という最初のパブリックベータ版も2024/7/15に公開されていたのですが、これはDeveloper Beta 3とは違うバージョンでした。そこで、前回のDeveloper Beta 3に引き続き、Developer Beta 4も自作PCにインストールしたところ、動作しました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.5を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 4インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておきます。今まではDeveloper Betaの項目しかありませんでしたが、今回はPublic Betaの項目も現れていました。どちらを選ぶと良いかわからなかったので、最初は新しく現れたPublic Betaを選んでみました。

すると、macOS Sequoia 15 Beta 2というアップデートが現れます。これはPublic Beta 2という意味のようです。

Public Beta 2

次に今までと同じDeveloper Betaを選んでみると、macOS Sequoia 15 Beta 4が現れます。これはDeveloper Beta 4という意味のようです。

Developer Beta 4

それぞれのバージョンを、softwareupdateで調べたところ、どちらも同じビルド番号24A5298hでした。Public Beta 2とDeveloper Beta 4は同じもののようです。ややこしいので、ここでは単にBeta 4として紹介します。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14328272KiB, Build: 24A5298h, Deferred: NO
（以下略）

softwareupdateコマンドでVersion 15.0を指定すると、これをダウンロードできます。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 13.0%

Installingの数値が100%になると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、macOS Sequoiaベータ版インストール.appというインストーラが出来上がってました。サイズは少し増えて14.72GBです。

インストーラー

今までは、名称がInstall macOS Sequoia Beta.appだったものが、日本語になりました。だんだん日本語対応が進んでいるようです。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のmacOS Sequoiaベータ版インストール.appを開くと、インストーラウィンドウが現れました。今までは英語表示でしたが、これも日本語に変わってました。

インストーラー

この後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。ここの表示も日本語化されていました。

インストーラ

このSSDには、前回インストールしたBeta 3が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

再起動の案内も日本語化されてました。

installer

この先、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況はBeta 1と3と同じでした。HDMI端子には映像が出ます。

About this Mac

WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

まとめ

macOS Sequoia Beta 4を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。日本語表示される部分が増えて、日本語対応が進んでいる様子です。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。

macOS Sequoia 15 Beta 3をインストール

Mon, 15 Jul 2024 14:10:08 +0900

macOS Sequoia 15のBeta 3が2024/07/10に公開されていました。Beta 2も2024/6/24に公開されていたようです。そこで、Beta 1に引き続き、Beta 3も自作PCにインストールしたところ、動作しました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.5を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 3インストーラを入手

今回も、Beta 1と同様に、最初は以下のサイトのお世話になりました。

macOS Sequoia Full Installer Database. Download Directly from Apple!

ここには、https://swcdn.apple.com/というアップルのサイトのダウンロード用URLが紹介されています。ここにBeta 3インストーラへのリンクがありました。ダウンロードすると、InstallAssistant.pkgというファイルが出来上がります。

これを開きインストールすると、Install macOS Sequoia Beta.appというアプリが、「アプリケーション」の中に作られます。

フォーラムで教えていただいた内容によると、ターミナルからsoftwareupdateコマンドを使ってダウンロードすることも可能のようです。これも試してみました。

まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておきます。

Screenshot

次に、ターミナルからsoftwareupdate --list-full-installersコマンドを打ち、ベータ版がダウンロード可能なことを確認します。

% softwareupdate --list-full-installers
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14112733KiB, Build: 24A5289g, Deferred: NO
* Title: macOS Sonoma, Version: 14.5, Size: 13353373KiB, Build: 23F79, Deferred: NO
* Title: macOS Sonoma, Version: 14.4.1, Size: 13298513KiB, Build: 23E224, Deferred: NO
* Title: macOS Ventura, Version: 13.6.7, Size: 11924125KiB, Build: 22G720, Deferred: NO
* Title: macOS Ventura, Version: 13.6.6, Size: 11917983KiB, Build: 22G630, Deferred: NO
* Title: macOS Monterey, Version: 12.7.5, Size: 12116686KiB, Build: 21H1222, Deferred: NO
* Title: macOS Monterey, Version: 12.7.4, Size: 12117810KiB, Build: 21H1123, Deferred: NO
* Title: macOS Big Sur, Version: 11.7.10, Size: 12125478KiB, Build: 20G1427, Deferred: NO
* Title: macOS Catalina, Version: 10.15.7, Size: 8055650KiB, Build: 19H15, Deferred: NO
* Title: macOS Catalina, Version: 10.15.7, Size: 8055522KiB, Build: 19H2, Deferred: NO
* Title: macOS Catalina, Version: 10.15.6, Size: 8055450KiB, Build: 19G2021, Deferred: NO
* Title: macOS Mojave, Version: 10.14.6, Size: 5896894KiB, Build: 18G103, Deferred: NO
* Title: macOS High Sierra, Version: 10.13.6, Size: 5099306KiB, Build: 17G66, Deferred: NO

次に、softwareupdate --fetch-full-installer --full-installer-version 15.0コマンドで、バージョンを指定してダウンロードします。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Install finished successfully

この結果、アプリケーションフォルダにインストーラがダウンロードされました。

Sequoiaアイコン登場

「アプリケーション」の中に作られた、Install macOS Sequoia Beta.appのサイズは14.5GBと、Beta 1から少しだけ増えてました。何よりもアイコンが新しくなってます。Sequoiaのアイコンが決定したのかと思います。

Beta 3

「パッケージの内容」を見ると、

Beta 3

Contents/Resources の中に、ProductPageIcon.icnsというファイルが見つかりました。

Sequoia Icon file

これがSequoiaのアイコンのようです。これをプレビュー.appで開くと、複数サイズのアイコンPNGデータを得ることができます。アイコンのデザインはSonomaの方が凝っていて良かった気もします・・・

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。

インストーラを開くと、あとは通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。

このSSDには、前回インストールしたBeta 1が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールでは、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況はBeta 1の時と同じでした。HDMI端子には映像が出ます。

OpenCoreの最新版があれば、Sequoiaも問題ないようです。

WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

まとめ

macOS SequoiaのBeta 3を動かして、OpenCoreの最新版で動作することを確認しました。アイコンが、Sequoiaのものに更新されました。Sonomaを起動しているOpenCore設定と全く同じ設定で、動作します。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。

macOS Sequoia Beta 1を第13世代Intel CPUで動かす

Tue, 11 Jun 2024 20:00:36 +0900

2024/06/10のWWDC24キーノートでmacOS Sequoiaが発表され、ベータ版が無償公開されました。さっそく自作PCにインストールして動作することを確認しました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonomaを起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作するようで安心しました。

ベータ版インストーラを入手

開発ベータ版は無償で配布されています。開発ベータ版を入手するための方法はいくつかありますが、一番簡単なのは、「システム設定…」「一般」「ソフトウェアアップデート」で、「ベータアップデート」から「macOS Sequoia Developer Beta」を選択することです。

すると、ベータアップデートにmacOS Sequoia Developer Betaの項目が現れます。

ただ、この方式で続けると、起動中のmacOSをベータ版に入れ替えてアップデートされます。使用中のSSDではなくて、予備のSSDにインストールしたかったので、macOSのインストーラを入手したいと思いました。

インストーラ単体は、おそらくはdeveloper.apple.comからダウンロードできると思います。ただ、Sonomaの時はIntel用を入手できなかったので、これを試すことなく、前回と同様に、以下のサイトのお世話になりました。

macOS Sequoia Full Installer Database. Download Directly from Apple!

ここには、https://swcdn.apple.com/というアップルのサイトのダウンロード用URLが紹介されています。ダウンロードすると、InstallAssistant.pkgというファイルが出来上がります。

これを開くと、Install macOS 15 beta.appというアプリが、「アプリケーション」の中に作られます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のInstall macOS 15 beta.appを開くと、インストーラウィンドウが現れました。

アイコンはSonomaの流用です。Sonomaのbetaの時と同様、この後のバージョンアップでSequoiaのアイコンが採用されるはずです。

このSSDはフォーマットした直後なので、そのESPにOpenCoreなどが入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

画面が出ない

この後、インストールがほぼ終了し、グラフィックスカードに制御が切り替わるタイミングで、画面が真っ黒になりました。しばらく待っていたところボイスオーバーの案内がスピーカーから流れました。音が出るように用意しておくことは重要ですね。画面が出ていないだけで、インストールは成功しているようでした。

画面が出ない症状は、1年前にSonomaの開発ベータをインストールしたときにも発生していました。なので、同様に試したところ、グラフィックスカードのRadeon RX 6600のHDMI端子には映像が出ているようでした。今まではDP端子を接続していたのですが、そちらはブラックスクリーンになったようです。ということで、ディスプレイをHDMI端子に接続すれば、問題なくmacOSのインストールを進めることができました。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。OpenCoreの最新版があれば、Sequoiaも問題ないようです。

全コアが動作してます。

ただ、Sonomaの時と同様にWiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

まとめ

macOS Sequoiaの開発ベータ版を動かして、OpenCoreの最新版で動作することを確認しました。Sonomaを起動しているOpenCore設定と全く同じ設定で、動作します。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調に進みそうなので安心しました。

macOS Sonoma 14.5 に更新

Mon, 27 May 2024 01:09:13 +0900

macOS Sonoma 14.5がリリース（2024/5/13）されていたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.6GBです。

いつもはアップデートの説明が表示されるのに、今回は白紙でした。「今すぐ再起動」というボタンが表示されていて、すでにダウンロードは終了している様子です。なので今更ダウンロードサイズを節約する必要もなさそうなので、今回はOCLPのパッチを外さないまま続けました。「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23F79でした。

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、無事Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.4.1から14.5にアップデートしました。今まで通り、安定して動作しています。

OpenCore 0.9.9 から1.0.0に更新

Sun, 26 May 2024 23:37:00 +0900

OpenCoreの1.0.0が公開されていたので0.9.9からアップデートしました。config.plistに追加された項目はありません。なので0.9.9 のconfig.plistそのままでも動きます。

1.0.0をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。とはいえ、バージョンがとうとう1.0.0に到達しました。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.0とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.4.1
OpenCore Legacy Patcher 1.4.3 (WiFi対応のため)

今回のタイミングでAppleALC.kextがアップデートされてましたので、これも最新にしました。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

macOS Sonoma 14.4.1 に更新

Sat, 30 Mar 2024 18:21:00 +0900

macOS Sonoma 14.4.1がリリースされた（2024/3/25）ので、更新しました。一時はWi-Fiが動作しなくなってしまいましたが、kextを更新して解決しました。このほか、特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。Wi-Fiは、マザボのE key M.2ソケットに取り付けたBCM94360NGです。

追記：初稿ではWi-Fiが不調でしたが、kext入れ替えで復活しました。2024/03/31

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。マイナーな機能拡張と、バグ修正、セキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.6GBです。

今回も、差分だけのダウンロードをしたいと思い、OCLPのパッチを外しました。OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。なお、OCLPにも新しいバージョン1.4.2が来ていたので、アップデートしました。14.4.1に対応するためには、1.4.2を使ってくださいとのことでした。

この後、再起動するとWi-Fiが使えなくなってました。Wi-Fi用パッチを外したので当然の現象です。改めて、更新通知を確認すると、サイズが2.01GBになってました。少し前に話題になっていた、USBハブが認識されない問題が解決されているようです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23E224でした。

Wi-Fiが復活しない

この後、OCLPのPost-Install Root Patchを当て直しました。メッセージには、Modern Wirelessに対応するためのネットワークパッチが当てられると表示されています。

パッチを当てて、再起動しましたが、しかしながらWi-Fiは動作しませんでした。今までの様子と異なり、メニューバーのWi-Fiアイコンに!マークが出ています。

ちなみに使用しているWi-Fiモジュールは、マザーボードのE key M.2ソケットに取り付けたBCM94360NGです。

IOSkywalkFamily.kextを更新する

そこで、Wi-Fiを有効化した時の手順：

SonomaでBroadcom Wi-Fiを有効にする

を見直しました。その結果、追加していた2個のkext：

のうち、IOSkywalkFamily.kextが、3週間前に更新されていることがわかりました。Sonoma 14.4のベータに合わせて、更新されていたようです。使用中のkextを、最新のものに置き換えることで、無事、Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.3.1から14.4.1にアップデートしました。Broadcom社のWi-Fiが動作しない問題が発生しましたが、対応するkextを更新したところ解決しました。今まで通り、安定して動作しています。

OpenCore 0.9.8 から0.9.9に更新

Thu, 28 Mar 2024 11:40:40 +0900

OpenCoreの0.9.9が公開されていたので0.9.8からアップデートしました。config.plistに追加された項目はありません。なので0.9.8 のconfig.plistそのままでも動きます。

0.9.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。とうとう0.9.9まできました。次はいよいよ1.0.0なのでしょうか？

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.9とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.3.1
OpenCore Legacy Patcher 1.4.1 (WiFi対応のため)

今回のタイミングでkextのアップデートはありませんでした。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

macOS Sonoma 14.3.1 に更新

Fri, 09 Feb 2024 22:33:15 +0900

macOS Sonoma 14.3.1がリリースされた（2024/2/9）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。詳細情報をクリックしたところ、マイナーな機能拡張と、バグ修正、セキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.37GBです。

今回も、差分だけのダウンロードをしたいと思い、OCLPのパッチを外しました。OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。

この後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが526.5MBになってました。また、アップデートの内容がより具体的に説明されるようになりました。タイプ入力中のテキスト表示の不具合を直したようです。その不具合には遭遇してなかったので、よくわかりません。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23D60でした。

この後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。

まとめ

macOS Sonoma 14.3から14.3.1にアップデートしました。今回も、OCLPのパッチを一旦外すことで、差分でのアップデートを行いました。アップデート後に、再びOCLPのパッチを当てました。

OpenCore 0.9.7 から0.9.8に更新

Fri, 09 Feb 2024 21:33:37 +0900

OpenCoreの0.9.8が公開されていたので0.9.7からアップデートしました。config.plistに追加された項目はありません。なので0.9.7 のconfig.plistそのままでも動きます。

0.9.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.8とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.3
OpenCore Legacy Patcher 1.3.0 (WiFi対応のため)

今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.7の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。

macOS Sonoma 14.3 に更新

Tue, 23 Jan 2024 13:27:51 +0900

macOS Sonoma 14.3がリリースされた（2024/1/22）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

この後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが935.9MBになってました。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23D56でした。

この後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。

まとめ

macOS Sonoma 14.2.1から14.3にアップデートしました。今回も、OCLPのパッチを一旦外すことで、差分でのアップデートを行いました。アップデート後に、再びOCLPのパッチを当てました。

macOS Sonoma 14.2.1 に更新

Thu, 21 Dec 2023 17:10:58 +0900

macOS Sonoma 14.2.1がリリースされた（2023/12/19）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.36GBです。

前回のアップデートの記事のコメントで、アップデートのサイズがフルサイズなのは、パッチが当たっているからなので、OCLPのパッチを外すと差分でアップデートできると教えていただきました。今回はそれを試しました。それで、OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。

この後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが421.8MBになってました。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23C71でした。

この後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。

まとめ

macOS Sonoma 14.2から14.2.1にアップデートしました。OCLPでパッチを当てて以来、アップデーターがmacOS本体くらいのサイズだったのですが、パッチを一旦外すことで、差分でのアップデートになりました。再起動1回分の手間がかかりますが、ダウンロード時間が短くなります。今後も一旦パッチを外してからアップデート作業したいと思います。

macOS Sonoma 14.2 に更新

Tue, 12 Dec 2023 17:15:31 +0900

macOS Sonoma 14.2がリリースされた（2023/12/12）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。

詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.36GBです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23C64でした。

OCLPを当て直す

これでmacOS 14.2が起動しました。でもOCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

そこで、OCLPの新しいバージョン1.3.0を起動しました。

Post-Install Root Patchをクリックしてパッチを当てなおしたところ、Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.1.2から14.2にアップデートしました。アップデート通知画面でボタンクリックすることで、自動的にアップデートできました。またWi-Fiを有効化するために、アップデート後に再びOCLPを当てました。

OpenCore 0.9.5 から0.9.6に更新

Tue, 12 Dec 2023 17:03:41 +0900

OpenCoreの0.9.6が公開されていたので0.9.5からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.5 のconfig.plistそのままでも動きます。

0.9.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.6とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.2
OpenCore Legacy Patcher 1.3.0 (WiFi対応のため)

今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.5の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

Booter/QuirksにFixupAppleEfiImagesが追加されていました。bool型データで、デフォルトはfalseです。macOS 10.4から10.12のboot.efiへのパッチとのことです。最新macOSしか使わないので、デフォルトのままfalseにしておきました。

今まで動作していたのであれば、追加された項目はデフォルトで問題無いようですので、古いconfig.plistのままでも、変更なしで起動します。

macOS Sonoma 14.1.2 に更新

Tue, 05 Dec 2023 22:35:56 +0900

macOS Sonoma 14.1.2がリリースされた（2023/11/30）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

前回、更新通知が来るように設定しましたので、今回は、「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。

詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ12.89GBです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B92でした。

OCLPを当て直す

これでmacOS 14.1.2が起動しました。でもOCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

そこで、OCLPからPost-Installを実行したところ、新しいバージョン1.2.1の案内が表示されました。

Download and Installボタンをクリックして1.2.1をインストールしました。

Post-Install Root Patchをクリックしてパッチを当てなおしたところ、Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.1.1から14.1.2にアップデートしました。アップデートの通知画面から、ボタンクリックで自動的にアップデートしてくれました。またWi-Fiを有効化するために、アップデート後に再びOCLPを当てました。

macOS Sonoma 14.1.1 に更新

Wed, 08 Nov 2023 17:42:22 +0900

本日（2023/11/8）macOS Sonoma 14.1.1がリリースされたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知を有効にする

macOS Sonoma 14.1.1がリリースされたはずなのですが、Sonomaになって以来、「システム設定」「一般」「ソフトウェアアップデート」に更新の表示が出なくなってました。

その記事へのコメントで「RestrictEvents.kextを入れてsbvmmを設定すればアップデートが表示されますよ」と教えていただいたのでそれを試しました。RestrictEventsの設定については、こちらをご覧ください。

RestrictEvents.kextで更新通知を有効化する

その結果、アップデートの通知が来るようになりました。これで今まで通り、アップデートできそうです。

詳細情報をクリックしたところ、Sonomaそのものの紹介しか書いてありませんでした。0.0.1のマイナーアップデートなので、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ12.89GBです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B81でした。

OCLPを当て直す

これでmacOS 14.1.1が起動しました。しかし、OCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

そこで、OCLPからPost-Installを実行し、パッチを当て直しました。これでWi-Fiが復活しました。

まとめ

macOS Sonoma 14.1から14.1.1にアップデートしました。RestrictEvents.kextを使ったので、今まで通り「システム設定」にアップデートの通知が来るようになりました。Wi-Fiを有効化するために、アップデート後に再びOCLPを当てました。

RestrictEvents.kextで更新通知を有効化する

Wed, 08 Nov 2023 17:06:26 +0900

RestrictEvents.kextを使って、Sonomaの更新通知が来るように設定しました。またCPU種類が表示されるようにもしました。

RestrictEvents.kextを導入

Sonomaにしてから、macOSのアップデートの通知が来なくなったという記事を書きました。その記事へのコメントで「RestrictEvents.kextを入れてsbvmmを設定すればアップデートが表示されますよ」と教えていただきました。こちらで公開されているkextです。

GitHub - acidanthera/RestrictEvents

その説明によるとRestrictEventsは、ハードウェア互換性を確保するために、不要なプロセスをブロックしたり、機能を復活させるためのkextで、Lilu.kextの機能を利用しているとのことです。これをダウンロードして、EFI/OC/Kextsの中に入れました。また、config.plistのKernel/Addの中に、このkextのことを追記しました。Liluを利用するkextなので、Liluの記述より後に記入します。Xplistで編集した様子を、以下に示します。

次に、config.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82/boot-argsに、

revpatch=sbvmm,cpuname revcpu=1

を追加しました。このうち、

revpatch=sbvmm

の部分は、説明によると一部のモデルでネットからの更新を可能にさせる機能とのことです。VMM SBモデルというのが何に相当するのかは、探したものの不明でした。

また、以下の部分では、

revpatch=cpuname revcpu=1

システム情報でのCPUの表示をカスタマイズします。RestrictEvents.kextの効果は、以下で確認します。

ソフトウェア更新通知が来る

Sonomaになってから、ソフトウェア更新の通知が来なくなってました。それが復活しました。リンゴマークのメニューに「アップデート」の表示がされるようになりました。App Storeの更新も復活してます。

システム設定を開くと、Sonoma 14.1.1のアップデートが可能になってます。

CPUの種別が表示される

「このMacについて」や「システム情報」で、CPUの名前が表示されなくなってました。いつ頃からなのか不明なのですが、Macで使われていないCPUを使っているので、仕方ないかと思ってました。これが復活しました。

ターミナルからは、sysctlコマンドでCPU名を取得できていました。

% sysctl machdep.cpu.brand_string
machdep.cpu.brand_string: 13th Gen Intel(R) Core(TM) i9-13900KF

この情報が表示されるようになるようです。システム環境設定では、今までは、「プロセッサ名」がUnknownだったものが、

正しく表示されるようになりました。

「このMacについて」でも、以下のようにCPU名表示されるようになりました。

まとめ

RestrictEvents.kextを使い、Sonomaのアップデートの通知が来るようにしました。また、CPU種類の表示も復活させました。この他に、RestrictEvents.kextを使うことで、

MacBookAir と MacBookPro10,xで「システム情報」のメモリータブを表示させる、
MacPro7,1でPCI構成の警告を表示させない、
「初期化されていないディスク」との警告を表示させない、
コンテンツキャッシングを可能にする、
Ivy BridgeでCoreGraphicsがクラッシュする問題を解決する、

などの設定が可能とのことです。

macOS Sonoma 14.1 に更新

Thu, 26 Oct 2023 18:10:22 +0900

本日（2023/10/26）macOS Sonoma 14.1がリリースされたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

アップデートが来ない

macOS Sonoma 14.1がリリースされたのですが、「システム設定」「一般」「ソフトウェアアップデート」に表示はありません。

Sonomaになったためか、それともOCLPでパッチを当てたためなのか、アップデート案内が来なくなってしまったようです。

OCLPで14.1をダウンロード

OCLPには、macOSのダウンロード機能があったのでそれを使うことにしました。OCLPメインメニューの左下のCreate macOS Installerを選びます。

この中から、macOS 14.1 Sonomaのダウンロードが可能でした。

差分ではないので、12.9GBあり、ダウンロードに20分程度かかるようです。

ダウンロードが終わると、Applicationsにインストーラが保存されています。

これを開いて、macOSのバージョンアップをしました。

この後、自動的に再起動しました。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B74でした。

OCLPを当て直す

これでmacOS 14.1が起動しました。しかし、OCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

この状態は、OCLPにもわかっているようで、再度パッチを当てることを促すメッセージが出ました。

そこで、パッチを当て直しました。これでWi-Fiが復活しました。

まとめ

macOS Sonoma 14.0から14.1にアップデートしました。OCLPを使って以来初めてのマイナーアップデートなので、今までと少し違ってました。まずは、「システム設定」にアップデートの通知が来なくなってました。またアップデート後に、再びOCLPを当てる必要がありました。それ以外は、今までのマイナーアップデートと同じく、問題なくアップデートできて動作しました。

OpenCore Legacy PatcherがSonomaに対応

Tue, 03 Oct 2023 16:17:05 +0900

前回の記事では、Sonomaになって使えなくなったBroadcomのWi-Fiを、OpenCore Legacy Patcher (OCLP) のNightly Buildを使って対応させました。

SonomaでBroadcom Wi-Fiを有効にする

その後、OCLPが更新されてSonomaに正式対応したので、それを使って再びパッチ当てしました。

OCLPがSonomaに対応

OCLPが Ver. 1.0.0 になってSonomaに対応しました。前回の記事で使用した0.6.9を起動したところ、バージョンアップのお知らせが表示されました。

これで正式にSonomaに対応したようです。リリースページからダウンロードできます。

Releases · dortania/OpenCore-Legacy-Patcher

Download and installボタンを押すと更新されました。

起動すると1.0.0になってます。

Post-Install Root Patchを選ぶと、前回同様にパッチを当てられます。

メッセージを見ると、macOSのシステム部分にかなりパッチが当たっています。それだけ大変な作業のようです。

1.0.1に更新（追記）

2023年10月4日に、OCLPが1.0.1に更新されていました。

アップデートしてパッチし直しました。特に変化はありません。

まとめ

OCLPの公開版がアップデートされてSonoma対応になりました。Nightly版で、Broadcom Wi-Fi対応のパッチを当てていたので、公開版でパッチし直しました。Config.plistはすでに対応しているので、OCLPを起動してボタンを押すだけで終了します。Wi-Fiを動かし続けるために、これからもOCLPにお世話になります。

SonomaでBroadcom Wi-Fiを有効にする

Sun, 01 Oct 2023 22:15:06 +0900

SonomaでBroadcomのWi-Fiを使えるようにしました。iPhoneとのコピペ（ユニバーサルクリップボード）やAirDropが再び使えるようになりました。

SonomaでWi-Fiが使えない

Sonomaでは、マザーボードのM.2ソケットに取り付けたBroadcom Wi-Fiカード

が動作しませんでした。Bluetooth部分は動作します。これらのBroadcom Wi-Fiを搭載しているMacが全て、Sonomaのサポート対象から外れたためです。Venturaまでは動作し、Sonomaで動作しなくなったチップは以下です。

BCM94350 (BCM94352を含む)
BCM94360
BCM43602
BCM94331
BCM943224

Wi-Fiが使えなくなったマシンは、デスクトップ（Z690マザーボード、13900K、Radeon RX 6600）なので、有線LANがあれば一般的なネット利用には支障ありません。しかしWi-Fiが機能しないと、iPhoneとの連携機能（ユニバーサルクリップボードやHandoffなど）やAirDropが使えないので、なんとかしたいところです。

OCLPで対応する

OpenCore Legacy Patcher（以下ではOCLP）を使用して、Broadcomチップを有効にする方法が以下で説明されていました。

Preliminary support for macOS Sonoma by khronokernel · Pull Request #1077 · d…

OCLPは、新しいmacOSを、サポート対象外の古いMacにインストールするツールです。OpenCoreを利用しています。Macの機種を選択すると自動的に設定してくれるので便利です。Sonomaでサポート外になったBroadcomのWi-Fiを有効にするOCLPが、Nightly Build版で用意されています。公式版は10月2日とのことです。

このSonoma対応の最新版OCLPをHackintoshで使います。上記のページの「Hackintosh Note」という項目に説明があります。本来の使い方ではないので、OpenCoreの設定準備が多少必要です。ちなみにOpenCoreも最新版にすると良いとのことなので、Nightly Build 0.9.6にしました。

OCLPを使ってみる

まずは上記のページからOCLPのNightly Buildを入手しました。直接リンクを公開しないようにと書いてありますので、このページから探してください。Nightly.link: OpenCore-Patcher.app (Sonoma Development)と書いてあるリンクをクリックすると、OpenCore-Pacherのアプリがダウンロードされます。10月2日には公開版が出るそうなので、それまで待っても良いと思います。

実はOCLPを使うのは今回が初めてです。それで、とりあえずダウンロードしたアプリを起動してみました。開いたメインメニューに、いろいろなツールがあって便利そうです。Sonomaのダウンロードも、これを使えばきっと簡単でした。

この中の「Post-Install Root Patch」という項目で、Wi-Fiのパッチが当てられます。「Post-Install Root Patch」をクリックすると、以下のメッセージが現れました。

要するに、

あなたのマシンに対してできることはModern Wirelessのパッチです
でもセキュリティ設定がキツいのでパッチ当てられません

ということです。状況をとても的確に把握してくれているようです。Modern Wirelessというのは、今回のSonomaで使えなくなったBroadcomのチップです。OCLPのプロジェクトでは、Montereyで切り捨てられた古いWi-FiチップをLegacy Wirelessと呼んでいたので、それに対してSonomaで切り捨てられたチップをModernと呼んでいるようです。

OpenCoreの調整

そこで、まずはOpenCoreの設定を整えて、OCLPが動作するようにします。Hackintoshに対して行う先ほどの手順を参考にしました。ちなみに、古いMacに対して行う手順がこちらに説明されています。これも参考にしました。これらに従ってconfigとEFIを調整します。

1. Kextの追加

まずはkextを追加します。必要なkextは、以下の3個です。うち1個は、他のkext/Contents/PlugInsの中に含まれてますので、入手するkextは2個です。

IOSkywalkFamily.kext
IO80211FamilyLegacy.kext
- AirPortBrcmNIC.kext (IO80211FamilyLegacyに含まれてます)

ちなみに古いMac向けのガイドのほうには、このほかにも3個のkextを入れるように書かれてました。それを試みるとカーネルパニックになったり、暗黒画面になりました。上記の3個だけで良いようです。

2. config.plistの変更

次に、config.plistを変更します。まずは、上記の3個のkextが動作するように、Kernel/Addに以下を追加します。Xplistアプリで編集している様子です。

次に、macOSにあるIOSkywalk.kextを停止させます。このために、以下の項目をKernel/Blockに追加します。

さらに、Misc/Securityで、SecureBootModelを無効にします。

また、NVRAM/Addで、boot-argsにamfi=0x80 を追加し、csr-active-configを03080000に設定します。

NVRAM/Deleteに、csr-active-configを追加します。

config.plistの変更は以上です。csr関係の設定は、パッチ作業後は元に戻しても良いのかもしれません。詳しくはこちらの説明をみてください。

OCLPを起動

これでOCLPが使えるようになりました。メインメニューからPost-Install Root Patchを選ぶと、先ほどと違って、以下のように表示されます。

いよいよパッチが当てられるようになったようです。Start Root Patchingを選択すると、rootとして作業するかどうかの確認と、パスワードを求められます。

パスワードを入力すると、パッチ作業が開始されます。

パッチが終了したら、再起動です。

Wi-Fi動作を確認する

再起動したところ、無事、Wi-Fiが動作するようになりました。

Wi-Fiを接続したところ、iPhoneとのユニバーサルクリップボード、Handoff、AirDropなどが動作するようになりました。

まとめ

Sonomaになって使えなくなっていたWi-Fiが、OCLPによって復活しました。その結果iPhoneや他のMacとの連携が再び使えるようになりました。macOSのバージョンアップの時にはいろいろ試練がありますが、それを克服しているコミュニティの皆さんの努力に感謝です。

今回は、M.2 Wi-Fiカード BCM94360NGを使いましたが、も同じ手順で復活するはずです。

SonomaのUSBインストーラを作ってクリーンインストール

Fri, 29 Sep 2023 18:31:35 +0900

macOS Sonoma 14.0が公開されましたので、USBインストーラを作って、クリーンインストールしました。最新版のOpenCore (0.9.5) とkext類でVenturaが動く環境ならば、Sonomaが動作するはずです。

システム構成

日本時間2023/9/27に、macOS Sonoma 14.0 が配布されました。Venturaが配布されたのは去年の10月25日でしたので、例年より1月ほど早いです。インストール先のマシンは、以下で、Z690マザーボードに13900Kを搭載しています。グラフィックスはRadeon RX 6600です。ブートローダはOpenCore 0.9.5でkext類は最新にしてあります。

Raptor Lake-S 13900KFの32コアをmacOSで使う

直近まで使っていたmacOSはVentura 13.5.2 (22G91)です。現在、13.6が配布されていますが、それをスキップして14.0に移行しました。

アップデートできない

Venturaの「システム設定」に「ソフトウェアアップデートがあります」というメッセージが出ていました。これを選択すると、macOS Sonoma 14.0の説明が表示されます。

ここで「今すぐアップデート」を選ぶと、ダウンロードが開始します。でもしばらくすると、以下のようなメッセージが出て中断してしまいます。

Public Betaの時と同様な症状です。Public BetaはApple Silicon版との関係でエラーが出ているのかと思ったのですが、他の要因かもしれません。

裏口からダウンロード

それで結局、こちらのサイトのリンク情報からインストーラをダウンロードしました。ダウンロード先はhttps://swcdn.apple.com/というサーバで、Apple公式ソフトウェアアップデートが使うサイトのようです。

InstallAssistant.pkgというファイルがダウンロードされました。これを開くと、デフォルトで/Applicationsフォルダに、macOSインストーラが出来上がります。

ということで、めでたくmacOS Sonomaインストールを入手できました。

クリーンインストールする

現用のVenturaに上書きインストールしても良いかとは思いますが、せっかくの年に一度のメジャーアップデートです。現在の起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは、同じSSDの別のAPFSボリュームに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはなりません。そこで次の手順でアップデートを進めます。

USBメモリを用意してSonomaインストールUSBを作る
USBメモリのESPに現在のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、M.2 SSDを消去する
インストーラからSonomaをインストールする

1. SonomaインストールUSBを作る

インストーラ用のUSBメモリを用意します。必要な容量は13.5GBですが、今回は32GBのUSB 3.0メモリーを用意しました。このUSBメモリーをディスクユーティリティ.appを使って初期化します。USBメモリを選択して、消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。ここでAPFSを選んでも良さそうな気もしますが、以前のバージョンのcreateinstallmediaコマンドではエラーが出ました。今回は試していませんが、Mac OS拡張（ジャーナリング）にしておくのが無難です。

次に、SonomaインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもSonomaをインストールできるUSBメモリになります。ターミナルを使用して、Sonomaインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。（下の例は、インストーラが/Applicationsにある場合です）

$ cd /Applications/Install\ macOS\ Sonoma.app/Contents/Resources/
% sudo ./createinstallmedia --volume /Volumes/USB/
Password: 
Ready to start. 
To continue we need to erase the volume at /Volumes/USB. 
If you wish to continue type (Y) then press return: y 
Erasing disk: 0%... 10%... 20%... 30%... 100% 
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100% 
Making disk bootable... 
Copying boot files... 
Install media now available at "/Volumes/Install macOS Sonoma"

パスワード入力と、確認のyを押すと、いろいろ進捗して終了します。これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。

2. USBメモリのESPに現用のESPをコピーする

この先の操作でも、稼働しているESPは残るので、それから起動してUSBメモリを起動できるはずです。でも念のためにメモリでも起動できるようにしておきたいと思います。そこでインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。

それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ&ドロップすれば良いです。この先、Venturaの起動ボリュームは消去しますので、他にも必要なデータがありましたらバックアップしておきます。ホームディレクトリは別ボリュームですし、インストールしているソフトウェアの大半はクラウドから再度ダウンロードしても良いので、バックアップは適当です。

3. USBメモリーからインストーラを起動する

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにInstall macOS Sonomaというボリュームが見えるはずです。

ただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security, ScanPolicyのデフォルト設定が原因です。これのデフォルト値（Sample.plistに書いてある値も同じく）は、0x010F0103 (10進数では17760515) です。この設定のまま使っている場合、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。

まず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。
また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。

なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はXplistを使って変更している様子です。

これで起動項目にUSBメモリのインストーラが現れるようになります。Sonomaアイコンのボリュームが、USBメモリーです。このInstall macOS Sonomaを選択して起動します。

4. インストール先ボリュームを消去する

USBメモリから起動すると、下のようなメニューが現れます。

ここでディスクユーティリティを選んで、インストール先ボリュームを綺麗さっぱりフォーマットしました。インストール先のAPFSボリュームグループを選択し、名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。

ユーザのホームディレクトリは、上記のhomeという場所に置いています。Macintosh HDというボリュームは、macOS本体とアプリケーションが使ってます。なのでこちらを消去しても、大半のデータはそのまま残せます。

5. Sonomaをインストールする

Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Sonomaインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。この後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

何度かの再起動の後で、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。

インストール終了したあと、このMacについてを確認しました。

これで、BIOS起動設定を内蔵SSDにすれば、今まで通り起動します。上の手順では、APFSボリュームグループをフォーマットしてたのでESPの内容は無事でした。ドライブ全体をフォーマットするとESPの内容も消えてしまいます。その場合は、USBメモリのESPの内容を、内蔵SSDに書き戻しておきます。

まとめ

OpenCoreで起動しているZ690マシンにSonomaをクリーンインストールしました。Wi-Fi以外は今のところ問題なく動作しています。ベータ版の時から、日本語と英語の入力モードの切り替えが高速になりわかりやすくなったのは、すごく良いです。

追記：Venturaで使用できてたWi-Fiが使えなくなった問題に対しては、OCLPで対応可能です。詳しくはこちらをご覧ください。

SonomaでBroadcom Wi-Fiを有効にする

OpenCore 0.9.4 から0.9.5に更新

Wed, 13 Sep 2023 16:52:25 +0900

OpenCoreの0.9.5が公開されていたので0.9.4からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.4 のconfig.plistそのままでも動きます。

0.9.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.5とmacOS Venturaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.5.2

今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.4の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

UEFI/QuirksにShimRetainProtocolが追加されていました。boolデータで、デフォルトはfalseです。LinuxのセキュアなブートローダーShimという仕組みでOpenCoreを動かすためのものらしいです。使うことはないかと考え、デフォルトのままfalseにしておきました。

追加された項目はデフォルトで問題無いようですので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.5.2 に更新

Fri, 08 Sep 2023 20:34:55 +0900

macOS Ventura 13.5.2に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.5.2の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。セキュリティ修正とのことで、小さなバグ修正のようです。サイズは475MBです。機能に変更は無い様子です。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動は3回で、最初がmacOS Installerから、2回3回目は通常の起動ボリュームから起動しました。

ビルド番号は22G91でした。13.5.1と末尾1番違いです。問題なく動作しています。

macOS Sonoma 14 Public Beta 5をインストール

Sun, 03 Sep 2023 14:13:02 +0900

macOS Sonoma 14のPublic Beta 5が公開されていました。OpenCore 0.9.4と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。

Sonoma Public Beta 5が来た

米国時間の2023/8/31にSonomaのPublic Beta 5 にして、Dev Beta 7に相当するベータ版が無償配布されました。今回も今までと同様、developer.apple.comにはApple silicon版しかありませんでした。

「システム設定…」「一般」「ソフトウェアアップデート」にもPublic Beta 5の通知は来ていますが、ダウンロードを試みると、これも

前回同様に、インストールできないと言われます。

そこで、再びこちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ここからダウンロードしたPublic Beta 5のファイルはpkg形式です。

ダブルクリックして、適当なフォルダにインストールすると、その中にmacOS 14 public beta 5インストーラが出来上がります。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.4とmacOS 13.5.1で動作しています。

macOS Ventura 13.5 に更新

このmacOSの環境から、入手したインストーラを起動しました。

今回も、テスト用に用意した2.5インチSATA SSDをフォーマットして、これにインストールしました。最初の再起動では、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されました。それで自動的にインストール終了しました。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5337aでした。デフォルトの壁紙は引き続きSonoma (?)の葡萄畑ですが、ズームの比率が変わったように見えました。

まとめ

macOS SonomaのPublic Beta 5が公開されたのでダウンロードして動作確認しました（この記事を書きました）。WiFiが使えない状態は相変わらずですが、それ以外の動作は試した限り問題ありませんでした。

macOS Ventura 13.5.1 に更新

Sat, 26 Aug 2023 12:02:12 +0900

macOS Ventura 13.5.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.5.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。8月18日から配布されていたようです。「位置情報へのアクセス許可が表示されない問題の修正」とのことで、小さなバグ修正のようです。サイズは475.9MBです。機能に変更は無いようです。

ビルド番号は22G90でした。問題なく動作しています。

macOS Sonoma 14 Public Beta 4をインストール

Fri, 25 Aug 2023 21:23:24 +0900

macOS Sonoma 14のPublic Beta 4が公開されていました。OpenCore 0.9.4と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。

Sonoma Public Beta 4が来た

米国時間の2023/8/22にSonomaのPublic Beta 4 にして、Dev Beta 6に相当するベータ版が無償配布されました。前回はBeta 1をインストールしましたが、Beta 2とBeta 3は見逃してしまいました。それでBeta 4をインストールしてみることにしました。

今回も今までと同様、developer.apple.comにはApple silicon版しかありませんでした。

「システム設定…」「一般」「ソフトウェアアップデート」にもBeta 4の通知は来ていますが、ダウンロードを試みると、これも

前回同様に、インストールできないと言われます。

そこで、再びこちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ここからダウンロードしたPublic Beta 4のファイルはpkg形式です。

ダブルクリックして、適当なフォルダにインストールすると、その中にmacOS 14 public beta 4インストーラが出来上がります。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.4とmacOS 13.5で動作しています。

macOS Ventura 13.5 に更新

このmacOSの環境から、入手したインストーラを起動しました。

今回も、テスト用に用意した2.5インチSATA SSDをフォーマットして、これにインストールしました。再起動の様子を観察していなかったのですが、おそらく今までと同じく、最初の再起動では、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されたと思います。それで自動的にインストール終了しました。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5328bでした。デフォルトの壁紙が、カラフルな抽象模様から、おそらくはSonomaの葡萄畑に変わってました。

また、これは最初のベータ版から気づいていたのですが、文字入力の状態がカーソル位置に表示されるのが地味に便利です。英語キーボード派なので、Caps Lockを日本語・英数字の切り替えに使っています。時々、切り替え状態を間違えるのですが、Sonomaからは、カーソル位置に、「A」または「あ」のマークが現れて、どちらに切り替わったかを知らせてくれます。これだけでも早くSonomaに移行したいと思います。

まとめ

macOS SonomaのPublic Beta 4が公開されたのでダウンロードして動作確認しました。WiFiは使えないですが、それ以外の動作は試した限り問題ありませんでした。

OpenCore 0.9.3 から0.9.4に更新

Mon, 21 Aug 2023 21:19:06 +0900

OpenCoreの0.9.4が公開されていたので0.9.3からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.3 のconfig.plistそのままでも動きます。

0.9.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.4とmacOS Venturaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.5

今回のタイミングで、AppleALC.kext、Lilu.kext、WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.3の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

Misc/BootにInstanceIdentifierが追加されていました。stringデータで、デフォルトは空です。「OpenCoreのインスタンスを識別するためのIDを英数字のstringで指定する」ためのものらしいです。現在は、「.contentVisibilityファイルがOpenCoreのインスタンスを識別するために使用する」そうです。.contentVisibilityは、OpenCore 0.8.8で導入された機能で、ピッカーが表示するブート項目を調整する機能のようです。よく理解できていないのですが、ピッカーが表示する項目が煩雑または、少なすぎて困ることがなければ、使わないものと考えました。それでデフォルトのまま空にしておきました。

追加された項目はデフォルトで問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.5 に更新

Tue, 25 Jul 2023 12:56:57 +0900

macOS Ventura 13.5に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.5の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。メジャーなアップデートだけあって、サイズも1.04GBあります。とはいえ、内容はバグ修正とセキュリティーアップデートのようです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22G74でした。

バグ修正ということで、特に変化した点はありませんでした。例年のスケジュールでは、Sonomaが出るまで、あと13.6までのアップデートがありそうです。

macOS Sonoma 14 Public Beta 1をインストール

Thu, 13 Jul 2023 18:16:33 +0900

macOS Sonoma 14のPublic Betaがいよいよ公開されました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。

Sonoma Public Beta 1が来た

米国時間の2023/7/12にSonomaの最初のPublic Betaが無償配布されました。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。

「システム設定…」「一般」「ソフトウェアアップデート」にも通知は来ていますが、ダウンロードを試みると、これも

インストールできないと言われます。

機種の設定の関係なのか、それともこちらでも配布されているのがApple Silicon用だけなのかもしれません。そこで、前回と同じく、こちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ダウンロードしたPublic Beta 1のファイルはpkg形式です。これを適当なドライブにインストールすると、

その中にmacOS 14 public beta 1インストーラが入ってます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1 (c)で動作しています。

macOS Ventura 13.4.1 (c)に更新

このmacOSの環境から、入手したインストーラを起動しました。

今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。Beta Dev 3までは、3回再起動しましたが、今回は2回でした。最初は、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されます。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5286iでした。

GeekBenchする

GeekBench 6でベンチマークしてみました。シングルコア2900, マルチコア15750くらいでした。

シングルコアスコアはどのMacよりも高速で、

マルチコアスコアはM1 UltraのMac Studioに負けるくらいの性能でした。

まとめ

macOS SonomaのPublic Beta 1が公開されたのでダウンロードして動作確認しました。今まで通りWiFiは使えないですが、それ以外は、問題なく動作しました。

macOS Ventura 13.4.1 (c)に更新

Thu, 13 Jul 2023 16:33:10 +0900

macOS Ventura 13.4.1 (c)に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.4.1 (c)の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。緊急のセキュリティアップデートのようで、サイズが6.6MBと極小です。機能に変更は無いようです。少し前に、(a)などのバージョンが出たそうですが、不具合があって差し替えられて(c)になったようです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動は1回だけでした。ビルド番号は22F770829dでした。

MacOS Sonoma 14 Beta Dev 3に更新

Fri, 07 Jul 2023 22:23:23 +0900

Sonoma Beta Dev 3が出たので、Beta Dev 2からアップデートしました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードで問題なく動作します。

Sonoma Beta Dev 3が来た

米国時間の2023/7/5にSonomaのBeta Dev 3が無償配布されました。開発者向けベータのバージョン3です。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。

そこで、前回と同じく、こちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ダウンロードしたファイルはpkg形式です。これを適当なドライブにインストールすると、

その中にmacOS 14 beta Dev 3インストーラが入ってます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1で動作しています。

ASRock Z690 Steel LegendでmacOSを動かす

このmacOSの環境から、入手したインストーラを起動しました。今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。インストールでは、Beta Dev 2までの時と同じく3回再起動します。最初は、macOS Installerというボリュームが、2回目以降は、インストール先のボリュームが自動的に選択されてます。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。

まとめ

macOS SonomaのBeta Dev 3をダウンロードして動作確認しました。今まで通りWiFiは使えないですが、それ以外は、問題なく動作しました。

MacOS Sonoma 14 Beta Dev 2に更新

Sat, 24 Jun 2023 01:07:44 +0900

Sonoma Beta Dev 2が出たので、最初のBetaからアップデートしました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードで問題なく動作します。

Sonoma Beta 2が来た

米国時間の2023/6/21にSonomaのBeta Dev 2が無償配布されました。開発者向けベータのバージョン2です。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。

その中にmacOS 14 beta Dev 2インストーラが入ってます。今回はインストーラのみで、他のファイルはありませんでした。Beta Dev 1と違い、Sonomaのアイコンに変わってます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1で動作しています。

ASRock Z690 Steel LegendでmacOSを動かす

このmacOSの環境から、入手したインストーラを起動しました。今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。インストールでは、Beta Dev 1の時と同じく3回再起動します。最初は、macOS Installerというボリュームが、2回目以降は、インストール先のボリュームが自動的に選択されてます。

動作確認

Beta 1では、Radeon RX 6600のDPに映像が出ず、HDMI端子に映像が出てました。今回は、DPにも映像が出るようになってました。

WiFiが動作しない状況は変わってません。Broadcom搭載Macがサポート対象から外れたのでドライバが無くなったようです。それ以外は、問題なく動作します。

まとめ

macOS SonomaのBeta Dev 2を動作確認しました。グラフィックカードのDP出力が動くようになりました。WiFiは使えないですが、それ以外は、問題なく動作しました。

macOS Ventura 13.4.1に更新

Thu, 22 Jun 2023 13:56:45 +0900

macOS Ventura 13.4.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.4.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。セキュリティアップデートのようで、サイズが501.2MBと小さいです。機能に変更は無いようです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22F82でした。

OpenCore 0.9.2 から0.9.3に更新

Tue, 13 Jun 2023 17:18:39 +0900

OpenCoreの0.9.3が公開されていたので0.9.2からアップデートしました。config.plistに変更はありませんでしたので、0.9.2 のconfig.plistそのままでも動きます。

0.9.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。バグフィックスと機能追加がされているようですが、大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.2とmacOS Venturaで動作確認していた手元のマシンは以下です。今回のタイミングで、AppleALC.kext、Lilu.kext、WhateverGreen、VirtualSMC関連がアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.2の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.4

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

UEFI/OutputにConsoleFontが追加されていました。デフォルトは空です。OpenCoreの文字表示で使うフォントの指定のようです。多言語サポートしているEFIアプリ（例えばmemtest86）を使う場合に指定が必要な場合があるようです。通常は指定無しで良いようなので空白のままにしました。
UEFI/ProtocolOverridesにPciIoが追加されていました。デフォルトはfalseです。メモリ管理関係のパッチのようで、一部のUEFIドライバに関係するようです。特に該当しないようだったので、falseのままにしておきました。

追加された項目はデフォルトでも問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。

macOS Sonomaを第13世代Intel CPUで動かす

Thu, 08 Jun 2023 12:35:21 +0900

2023/06/05のWWDC23キーノートでmacOS Sonomaが発表され、ベータ版が公開されました。Z690マザーボードとIntel Core i9-13900の自作PCにインストールして動作することを確認しました。

開発ベータ版

例年、WWDCと同時に公開されるmacOSの開発ベータ版は、会費を払った開発者だけが対象でした。一般の人に配布されるのは、7月に入って公開されるパブリックベータ版からでした。しかし今年からは、開発ベータ版から無償で配布されています。

Apple、各OSの開発者向けβを誰でも無料でダウンロード可能に（Apple IDは必要）

ただ、developer.apple.comから試したところApple silicon版しか公開されていないようでした。実際にダウンロードしたところ、ファイルは14GBくらいのipswという形式で、Apple silicon用らしいです。

macOS Venturaのシステム設定・一般・ソフトウェアアップデートの、ベータアップデートのメニューの中にも、Sonomaが現れていました。これを選んだらインストーラを入手できるかと思い、試しました。

しかし、やはり対象では無いとのことでした。機種IDはiMacPro1,1にしていて、Sonomaの動作対象Macです。こちらでも、Apple silicon版のみが配布されているのかもしれません。

探したところ、こちらのサイトで、直接ダウンロードできるリンク先が紹介されていました。”macOS Sonoma Beta Full Installer”という項目のリンクです。https://swcdn.apple.com/というURLなので、ちゃんとしたAppleのサイトのようです。

ダウンロードしたファイルはpkg形式です。これを適当なドライブにインストールすると、

その中にmacOS 14 betaインストーラが入ってます。これ以外にもファイルやフォルダがありますが、必要なのはこれだけでした。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.2とmacOS 13.4で動作しています。

ASRock Z690 Steel LegendでmacOSを動かす

このmacOSの環境から、入手したインストーラを起動しました。

インストーラを開くと、あとは通常のmacOSのインストールと同様です。テスト用に2.5インチSATA SSDを用意しました。これをインストール先にします。

このSSDはフォーマットした直後なので、そのESPにOpenCoreなどが入っていません。なので、マザーボードのEFIの起動は今まで通りのmacOS 13.4が入っているSSDで行います。OpenCoreの選択メニューで、新しいSonomaのSSDを選択します。

インストールでは、3回ほど再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

画面が出ない

少し試したところ、グラフィックスカードのRadeon RX 6600のHDMI端子に映像が出ているようでした。今まではDP端子を接続していたのですが、そちらはブラックスクリーンになったようです。ということで、ディスプレイをHDMI端子に接続すれば、問題なくmacOSのインストールを進めることができました。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sonomaが動作しました。OpenCoreの最新版があれば、Sonomaも問題無いようです。

全コアが動作してます。

WiFiが動かない

有線LANもBluetoothも動作してますが、WiFiは動いていません。今となっては古いBroadcomのWiFiなので、ちょっと心配ですが、最初のベータ版なのでまだドライバが入ってないだけだと思いたいです。（追記：いただいたコメントによるとBroadcom搭載Macがサポート対象から外れたのでドライバが無くなったようです）

まとめ

macOS Sonomaの開発ベータ版を動かして、OpenCoreの最新版で動作することを確認しました。新しいmacOSへの対応も順調に進みそうなので安心しました。

macOS Ventura 13.4に更新

Fri, 19 May 2023 12:11:54 +0900

macOS Ventura 13.4に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.4の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは1.03GBです。「機能向上」の項目に、「再起動後にMacへのキーボードの接続に時間がかかるBluetoothの問題を修正」とあります。スリープ後のBluetooth復帰に時間がかかる場面があったので、もしかして効果があるかなと期待しました。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22F66でした。

スリープ復帰後のBluetoothへの接続は、スムーズになった気がしますが、気のせいかもしれません。もう少し様子を見ます。

OpenCore 0.9.1 から0.9.2に更新

Wed, 17 May 2023 11:39:50 +0900

OpenCoreの0.9.2が公開されていたので0.9.1からアップデートしました。config.plistに変更はありませんでしたので、0.9.1 のconfig.plistそのままでも動きます。

0.9.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。最近の更新に比べると変更点は多いようですが、大半はバグフィックスのようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.2とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextとLilu.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.1の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.3.1 (a)

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

Kernel/QuirksにDisableIoMapperMappingが追加されていました。デフォルトはfalseです。macOS 13.3（以降？）でのみ必要らしいです。またAMD cpuでは不要らしいです。特定の条件でVT-dを使う際、Wi-Fi, Ethernet, Thunderboltの互換性問題を解決するために必要な、メモリ管理に関する指定のようです。ニッチな問題のように思えるので、デフォルトのfalseでも良いかとも思いましたが、 sample.plistの値がtrueになっていたので、それに合わせてtrueにしました。デフォルトのfalseでも一見問題なく動作します。
UEFI/OutputにInitialModeが追加されていました。デフォルトはAutoで、sample.plistの値も同じなので、合わせてAutoにしておきました。UEFIのコンソールコントロールモードを選択するらしいです。Auto, Text, Graphicsが選べます。OpenCoreとmacOSはTextモードを前提にしているけど、グラフィックスも描画可能らしいです。効果はUEFIの実装によって異なるようです。

追加された項目はデフォルトでも問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.3.1 (a)に更新

Tue, 02 May 2023 23:22:00 +0900

macOS Ventura 13.3.1 (a)に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.3.1 (a)の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。いつものアップデートではなく、「緊急セキュリティ対応」(Rapid Security Response、RSR) というものらしいです。サイズは53.2MBでした。非常に小さいです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は1回で、通常のインストール先ボリュームからでした。ビルド番号は22E772610aでした。

macOS Ventura 13.3.1に更新

Sat, 08 Apr 2023 19:25:53 +0900

macOS Ventura 13.3.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.3.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは584.7MBでした。いつもよりかなり小さいです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22E261でした。

OpenCore 0.9.0 から0.9.1に更新

Sat, 08 Apr 2023 18:55:04 +0900

OpenCoreの0.9.1が公開されていたので0.9.0からアップデートしました。config.plistに変更はありませんでしたので、0.9.0 のconfig.plistそのままでも動きます。

0.9.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はほとんど無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.1とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.0の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.3

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

今回も、config.plistで変更された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.3に更新

Tue, 28 Mar 2023 12:44:42 +0900

macOS Ventura 13.3に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.3の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは2.24GBでした。13.2.1の時に比べて大きいです。

今回のアップデートで、「“写真”の“重複項目”アルバムで、iCloud共有写真ライブラリ内の重複する写真やビデオの検出にも対応」されました。iOSではすでに対応している機能のようですが、macOSからも重複解消機能が使えるようになりました。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22E252でした。

OpenCore 0.8.9 から0.9.0に更新

Tue, 28 Mar 2023 12:05:20 +0900

OpenCoreの0.9.0が公開されていたので0.8.9からアップデートしました。config.plistに変更はありませんでしたので、0.8.9 のconfig.plistそのままでも動きます。

0.9.0をダウンロードする

0.9になりました。1.0までもう少しですね。公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はほとんど無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.0とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, Lilu.kext, VirtualSMC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.9の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.2.1および13.3

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

今回、config.plistで変更された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。

OpenCore 0.8.8 から0.8.9に更新

Tue, 28 Feb 2023 19:10:39 +0900

OpenCoreの0.8.9が公開されていたので0.8.8からアップデートしました。config.plistに大きな変更はありませんでしたので、0.8.8 のconfig.plistそのままでも動きます。

0.8.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.9とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.8の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.2.1

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

config.plistで変更された項目は以下だけでした。

UEFI/QuirksにResizeUsePciRbIoという項目が追加されていました。メモリー確保に関連してCapability I/O Errorを出すシステム対策のようでした。デフォルトはfalseだったのでそのままfalseに設定しました。

結局は、デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.2.1に更新

Tue, 14 Feb 2023 18:36:22 +0900

macOS Ventura 13.2.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.2.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは547.6MBでした。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は、いつものアップデートより多くて4回でした。ただ4回目は、電源が一旦落ちての再起動だったので、手元の環境独自の事情があったのかもしれません。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22D68でした。

フォーラムで、macOS13.2からmacOS13.2.1へのアップデートで、PioneerのBDドライブが認識されるように戻ったという情報がありました。

macOS Ventura 13.2に更新

Thu, 26 Jan 2023 15:43:46 +0900

macOS Ventura 13.2に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.2の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは1.05GBでした。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。今回は再起動の回数が少なくて、最初の再起動もインストール先のボリュームでした。小さめのアップデートだったようです。ビルド番号は22D49でした。

今回のアップデートにより、HomePod miniが測定した室温・湿度をホーム.appに表示してくれるようになり、温度・湿度をトリガーにしたオートメーションが作れるようになりました。

OpenCore 0.8.7 から0.8.8に更新

Thu, 26 Jan 2023 15:31:53 +0900

OpenCoreの0.8.8が公開されていたので0.8.7からアップデートしました。config.plistに大きな変更はありませんでしたので、0.8.7 のconfig.plistそのままでも動きます。

0.8.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.8とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, Lilu.kext, WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.7の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.1

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

config.plistで変更された項目は以下だけでした。

Misc/BootにHibernateSkipsPickerという項目が追加されていました。macOSハイバーネーションから復帰した場合に、ピッカーを表示しないための設定です。デフォルトはfalseだったのでそのままfalseに設定しました。

結局は、デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.1に更新

Sat, 17 Dec 2022 20:43:56 +0900

macOS Ventura 13.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは1.18GBでした。

そのまま「今すぐインストール」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22C65でした。

OpenCore 0.8.6 から0.8.7に更新

Wed, 14 Dec 2022 22:34:41 +0900

OpenCoreの0.8.7が公開されていたので0.8.6からアップデートしました。config.plistに変更はありませんでしたので、0.8.6 のconfig.plistそのままで動きます。

0.8.7をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.7とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextとWhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.6の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.0.1

.efiファイルを差し替える

更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistは変更なし

結局は、config.plistの項目には変更ありませんでした。なので、古いconfig.plistのまま、変更なしでも問題なく起動します。

OpenCore 0.8.5 から0.8.6に更新

Thu, 10 Nov 2022 21:33:17 +0900

OpenCoreの0.8.6が公開されていたので0.8.5からアップデートしました。config.plistに大きな変更はありませんので、0.8.5 のconfig.plistそのままでも動くはずです。

0.8.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.6とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.5の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.0.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点は以下でした。

UEFI/AppleInput/Power/PointerDwellClickTimeoutが追加されていました。Sample.plistの値が0でしたのでそのまま使いました。
UEFI/AppleInput/Power/PointerDwellDoubleClickTimeoutが追加されていました。Sample.plistの値が0でしたのでそのまま使いました。
UEFI/AppleInput/Power/PointerDwellRadiusが追加されていました。Sample.plistの値が0でしたのでそのまま使いました。

PointerDwellRadiusの数値以内にポインタが止まっていたら、指定したタイムアウトでクリックやダブルクリックが発生するらしいです。0の場合は無効なので、デフォルトではこの機能はoffです。何のための機能なのかわかりませんが、問題なければoffで良いと思いました。いずれもデフォルトのままでokなので、古いconfig.plistのまま、変更なしでも問題なく起動するはずです。

macOS Ventura 13.0.1に更新

Thu, 10 Nov 2022 12:42:12 +0900

macOS Ventura 13.0.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。

Venturaの13.0.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは493.5MBでした。

そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A400でした。

先日13.0が出て、間をおかずに13.0.1が出たように思いますが、過去の例を見るとMontereyもBig Surも最初の公開バージョン自体が12.0.1, 11.0.1だったんですね。

CpuTopologyRebuildで13900KFのコア構成を調整する

Sat, 05 Nov 2022 16:10:24 +0900

前回アップグレードしたCore i9-13900KFは、その後もmacOS Ventura 13.0で順調に稼働してます。

Raptor Lake-S 13900KFの32コアをmacOSで使う

この記事へのコメントで、CpuTopologyRebuildというkextを作者の方から教えて頂きました。物理コアとハイパースレッド (HT) の構成をmacOSに伝えるkextです。Alder Lake-Sのために作られて、Raptor Lake-Sでは未検証とのことでしたが、試したところ正しく動作しました。13900K, KFは、Pコア8, HT 8, Eコア16の全32スレッド構成 (8P16E32T) ですが、これを

物理コア24, HT 8、全32スレッド (24C32T) または、
物理コア8, HT 24、全32スレッド (8C32T)

に見せることが可能でした。ベンチマークテストの結果、マルチコアのスコアはどの構成でも大差はありませんが、シングルコアのスコアは物理コア8 (8C32T) と設定した場合が高性能でした。

CpuTopologyRebuild.kext

今回試したkextは、以下のCpuTopologyRebuild.kextです。

GitHub - b00t0x/CpuTopologyRebuild

Core i9-13900は、Pコア8, HT 8, Eコア16の構成です。macOSがサポートしているインテルCPUには、PコアとEコアが混在するモデルはありません。なので、均一の物理コアとHTの組み合わせとして認識させることになります。OpenCoreそのままで使用すると、全部が物理コアとして扱われて、

物理コア32、全スレッド32 (32C32T)

としてmacOSから見えるようになります。ちょっと乱暴な気はしますが、性能もそこそこ良く、特に問題は発生していませんでした。これに対して、CpuTopologyRebuild.kextを使うと、

物理コア24, 全スレッド32 (24C32T)、または、
物理コア8, 全スレッド32 (8C32T)

のようにmacOSに見せることができました。このkextを有効にすると物理コアが24になり、さらにboot argに-ctrsmtを追加すると物理コアが8コアになります。以下に13900K, KFのコア構成とkextの設定を表で示します。


物理コア	全スレッド	kext	boot arg
32	32	なし	なし
24	32	あり	なし
8	32	あり	-ctrsmt

コア数を確認する

Geekbench 5の表示で確認すると、確かにコアの構成が変わってます。以下はそれぞれ、32コア、24コア、8コアに設定した場合の表示です。

さらに、sysctl -a | grep cpuした結果を、diffで比較しました。<で始まる行がkextなしで、>で始まる行がkextあり（-ctrsmtオプション付き）の項目です。OpenCoreデフォルトだと32コアなところが、このkextで8コアになっていることがわかります。

< hw.perflevel0.physicalcpu: 32
< hw.perflevel0.physicalcpu_max: 32 
> hw.perflevel0.physicalcpu: 8
> hw.perflevel0.physicalcpu_max: 8
< hw.perflevel0.cpusperl2: 1 
> hw.perflevel0.cpusperl2: 2
< hw.physicalcpu: 32
< hw.physicalcpu_max: 32 
> hw.physicalcpu: 8
> hw.physicalcpu_max: 8

Geekbench 5の比較

Geekbench 5のスコアを比較します。数回実施した平均値です。参考に、GeekbenchのサイトにあるM1 Ultraのスコアも加えました。13900は、M1 Ultraにはシングルで勝っているものの、マルチでは負けてます。

コア構成の比較では、マルチの差は1%以下で誤差に近いです。シングルの差は4%くらいあって、8C > 32C > 24Cの順番で、8Cが一番良いです。

Cinebench R23の比較

Cinebench R23でもベンチマークしました。マルチは数回の平均、シングルは2回の平均です。これもM1 Ultraと比較しましたが、こちらはシングル、マルチとも13900がM1 Ultraよりも高速でした。Intel CPUが得意とするベンチマークのようです。

コア構成の比較では、Geekbench 5と同様の傾向が見られました。マルチは32C > 8C > 24Cで、シングルは8C > 32C > 24Cの順番でした。マルチの差は、毎回の測定のばらつきよりも小さいので、誤差範囲かと思います。それでもGeekbenchと同様の傾向だったので、何か意味があるかもしれません。シングルもGeekbenchと同じ傾向でした。これも8Cが一番良い性能でした。

動作の観察

CpuTopologyRebuildの作者の方も考察されてますが、それと同じ結果が得られました。シングルコアの性能は、8C > 32C > 24Cの順に高性能でした。

アクティビティモニターで、Cinebenchシングルスコア測定中のCPUの負荷を観察しました。32個のスレッドの使用状況が棒グラフで表示されます。

まずは32Cの場合の様子です。シングルスコアのベンチマークなので、一度には一つのコアしか使われていないと思いますが、一定時間累積しての表示なのか、複数の棒グラフが反応してました。それを見ると、全部のコアが区別なく使用されているようです。

次は、24Cの場合の様子です。左半分の16本がPコアで、一つおきに本体とそのHTが表示されていると思われます。棒グラフを見ると、そのHTが選択から除外されている様子がわかります。PコアとEコア（おそらく右半分の16本）はあまり区別なく選択されてます。

最後は8Cの場合の様子です。Pコアの物理コア部分のみが選択されてます。右半分のEコアは選択から外れてました。

32Cのシングルコアベンチマークでは、PコアのHTが選択されることもあるので、スコアが下がるのではと予想してました。しかし24Cより好成績でした。想像ですが、HTが選択されても、対応する物理コアが動いていなければ、物理コアと同等の性能が出せるのかもしれません。その結果、作者の方の分析通り、Pコアが選択される確率の高い32Cの方が24Cよりも好成績になったのかと思われます。

ちなみに、マルチコアのベンチマーク時は、どのコア設定でも大差ありませんでした。CPU使用状況を見ると、ほぼどのスレッドもフルに稼働しています。重い作業をさせるベンチマークテストでは、スレッド優先順位が適切に設定されていても、結局は全てのスレッド総出で使用されるので、差が出ないのかと思いました。

まとめ

13900KFのコア数設定を調整するCpuTopologyRebuild.kextを使ってみました。物理コアとハイパースレッド (HT) の数をmacOSに適切に伝えるためのkextです。ベンチマークテストで比較した結果、argで-ctrsmtをつけてこのkextを使い、物理コア8に設定することで、より良い性能を得られました。素晴らしいkextを作っていただきありがとうございます。

macOS Ventura 13 RC 2に更新

Fri, 21 Oct 2022 13:52:53 +0900

macOS Ventura 13 RC 2に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

macOS Ventura 13.0という案内が「システム設定」「一般」「ソフトウェアアップデート」にまた来ていました。一昨日RCになったばかりだと思ったのですが、今度はRC 2のようです。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A380になってました。10月25日の正式リリースが近づき差し替えが頻繁になったのでしょうか。

macOS Ventura 13 RCに更新・正式版は10月25日

Wed, 19 Oct 2022 22:21:30 +0900

macOS Ventura 13 RCに更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

macOS Ventura 13.0という案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。今まであったBetaの文字が無くなってました。RC (Release Candidate) 版のようです。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号からは末尾bが無くなり、22A379になってました。正式版は10月25日に公開されるそうなので楽しみです。

macOS Ventura 13 Beta 9に更新

Thu, 13 Oct 2022 12:19:45 +0900

macOS Ventura 13 Beta 9に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

VenturaのPublic Beta 9の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5373bでした。開発者向けのBeta 11に相当するらしいです。正式版は今月中に公開されるそうなので楽しみです。

OpenCore 0.8.4 から0.8.5に更新

Sat, 08 Oct 2022 14:54:57 +0900

OpenCoreの0.8.5が公開されていたので0.8.4からアップデートしました。config.plistに追加された項目はありませんので、0.8.4 のconfig.plistそのままでも動くはずです。

0.8.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はいつもより少ない様子でした。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.5とmacOS 13 Public Beta 8で動作確認している手元のマシンは以下です。今回のタイミングでのkext類のアップデートはありませんでしたので、kext類は0.8.4の時のままです。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Ventura PB8

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点はありませんでした。変更なしで、問題なく起動しました。間もなくリリースされるmacOS 13も安定して動きそうです。

macOS Ventura 13 Beta 8に更新

Thu, 06 Oct 2022 11:09:30 +0900

macOS Ventura 13 Beta 8に更新しました。更新間隔が短くなってきたので、正式リリースが近くなったかなと感じます。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

VenturaのPublic Beta 8の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5365dでした。開発者向けのBeta 10に相当するらしいです。

macOS Ventura 13 Beta 7に更新

Tue, 04 Oct 2022 18:58:02 +0900

macOS Ventura 13 Beta 7に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

VenturaのPublic Beta 7の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5358eでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。デフォルトの壁紙がダイナミックになって、時刻に合わせて変化するようになりました。

macOS Ventura 13 Beta 6に更新

Wed, 28 Sep 2022 20:09:57 +0900

macOS Ventura 13 Beta 6に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。（配布された当初はBeta 8となってましたが、どうやら6だったようです。訂正しました）

VenturaのPublic Beta 6の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5352eでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。

OpenCore 0.8.4にしてmacOS Ventura 13 Beta 5に更新

Sat, 10 Sep 2022 16:38:37 +0900

OpenCoreの0.8.4が出て、macOS Ventura 13 Beta 5も出たので両方を更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

OpenCoreの0.8.4が公開されていたので0.8.3からアップデートしました。config.plistに追加・変更された項目はありませんので、0.8.3のconfig.plistそのままで動きます。

一方で、VenturaのPublic Beta 5の案内も「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5342fでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。

macOS Ventura 13 Beta 4をインストール

Sat, 27 Aug 2022 23:38:51 +0900

Ventura Public Betaのアップデート、Public Beta 4が出たので、Beta 3からアップデートしました。公開版OpenCore 0.8.3で問題なく動作します。

Ventura Public Beta 4が来た

昨夜（米国時間で2022/8/26）のうちに VenturaのPublic Beta 4が配布されていたようです。「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。Beta 3の時は、アップデートに失敗して全体をダウンロードし直しましたが、今回はちゃんとアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。

公開版OpenCore 0.8.3で問題なく動作します。ビルド番号は22A5331fでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。

Venturaのpowerd暴走を止める

Fri, 26 Aug 2022 11:48:52 +0900

macOS 13 Ventura beta 3 (22A5321d) を、ASRock Z690 Steel Legend, 12900Kの環境で常用していたのですが、最近になって、CPUファンがうるさく回転していることに気づきました。アクティビティモニタでCPU使用状況を調べると、powerdというプロセスが104%くらいのCPUを使ってます。CPU使用の棒グラフを見ると左の方のコアの負荷が高いです。HWMonitorで温度を調べると、CPU Core 1が最高で77度くらいになって赤字表示でした。CPU Heatsink, Proximityも77度くらいまで上がってました。下のスクショは対応直後で、下がって余熱が残っている状況です。

ventura powerdで検索したところすぐに解決策が見つかりました。こちらです。

MacOS Ventura powerd activity util… | Apple Developer Forums

ターミナルから、

% sudo pmset schedule cancelall

とすれば良いようです。このコマンドを発行したら、CPUファンはすぐに静かになり、CPU温度も低下して、全部のコアが30度台になりました。この問題はredditでも話題になっているようです。

pmsetコマンドは、電力管理の設定を変更するコマンドです。schedule cancelallは、起動・再起動・終了・スリープ・スリープ解除を行うスケジュールを全部キャンセルするという指定のようです。このコマンドを発行する前に、pmset -g schedすると、異常なスケジュールが設定されている様子を確認できるらしいです。スケジュールは、「システム環境設定」「省エネルギー」から、曜日を指定して設定できる機能です。もともと設定していないので、キャンセルしても問題無いです。

手元の環境では、これで解決していますが、また暴走が始まることもあるそうです。ベータ版の途中から発生した問題のようですので、今後改善されると思います。

macOS Ventura 13 Beta 3をインストール

Sat, 20 Aug 2022 10:52:36 +0900

Ventura Public Betaのアップデート、Public Beta 3が出たので、Beta 2からアップデートしました。公開版OpenCore 0.8.3で問題なく動作します。

Beta 3が来たけど更新できない

米国時間で2022/8/9に VenturaのPublic Beta 3が配布されていました。Developer Beta 5に相当するビルドらしいです。いつものように、Public Beta 2の、「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。

ただ、今回は「今すぐアップデート」ボタンを押したところ、一瞬でダウンロードが終わって「再起動」ボタンが現れるものの、再起動しません。手動で再起動してもインストール用ボリュームができていないようでした。準備が完璧じゃないのかと思い、しばらくの間放置していました。でも状況が変わらないようなので、gibMacOSを使ってPublic Beta 3のインストーラ本体をダウンロードすることにしました。

gibMacOSでダウンロードする

gibMacOSはアップルの公開サイトから入手できるmacOSを探してダウンロードしてくれるスクリプトです。corpnewtさんのgithubへ行って、gibMacOSの一式をzip形式でダウンロードしました。

GitHub - corpnewt/gibMacOS: Py2/py3 script that can download macOS components…

Python版やシェルスクリプト版などが入ってますが、今回は、シェルスクリプト版のgibMacOS.commandを使用しました。gibMacOSのディレクトリに移動したあと、以下のように起動します。

% ./gibMacOS.command

起動するとmacOSの公開版の一覧が出ます。Public Beta版も公開版として含まれていました。この番号（ここでは3番）を指定してダウンロードします。

3. macOS Ventura beta 13.0 (22A5321d)
 - 012-51393 - Added 2022-08-09 17:07:05 - 11.97 GB

ダウンロードされたファイル類は、gibMacOSディレクトリの中のmacOS Downloads/public/の中に保存されてます。

ここでInstallAssistant.pkgを開くと、インストーラが起動して、/ApplicationsフォルダにInstall macOS Ventura betaが出来上がります。これはインストール後に消えてしまいますので、必要ならばバックアップしておきます。

Ventura Beta 3をインストールする

Install macOS Ventura betaを起動すると、お馴染みのインストール画面になります。インストール先を指定して続けると、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームから再起動します。

OpenCore 0.8.3にしてあれば問題なく動作しました。ビルド番号は22A5321dでした。Beta 2と同様、安定しているのでメインで使用します。

OpenCore 0.8.3 (NB) から0.8.3に更新

Sat, 06 Aug 2022 15:44:51 +0900

OpenCoreの0.8.3が公開されていたので0.8.3 Nightly Buildからアップデートしました。0.8.3公開で、macOS 13対応が確立した印象です。config.plistに追加された項目はありませんので、0.8.2, 0.8.3 (NB) のconfig.plistそのままでも動くはずです。

0.8.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.3とmacOS 13 Public Beta 2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Ventura PB2

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点はありませんでした。変更なしで、問題なく起動しました。macOS 13 Public Betaは非常に安定しているので、このままメインで使い続ける予定です。秋の正式版リリースが楽しみです。

macOS Ventura 13 Beta 2をインストール

Sat, 30 Jul 2022 00:24:08 +0900

Ventura Public Betaのアップデート、Public Beta 2が出たので、Beta 1からアップデートしました。OpenCore 0.8.3で問題なく動作します。0.8.3はKext Updaterで入手したNightly Buildです。

Ventura Public Beta 2が来た

昨夜（米国時間で2022/7/28）のうちに VenturaのPublic Beta 2が配布されていました。Developer Beta 4に相当するビルドらしいです。Public Beta 1の、「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。

OpenCore 0.8.3にしてあれば問題なく動作するようです。ビルド番号は22A5311fでした。Beta 1と同様、安定しているのでメインで使用します。

Monterey 12.5 にアップデートする

Thu, 21 Jul 2022 23:15:30 +0900

macOS Monterey 12.5が配布されていましたので12.4からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.5の情報はまだありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。いつもはVentura public betaを動かしている関係でOpenCore 0.8.3にしてましたが問題ありません。0.8.2での起動もokです。kext類は最新です。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT

システム環境設定のソフトウェアアップデートに、12.5のアップデートの通知が来ていました。

アップデートは、TVとSafariの不具合に対応したものらしいです。「今すぐインストール」ボタンを押すと、2.2GBのファイルがダウンロードされます。

その後、自動的に4回再起動して、12.5に更新されました。前回同様、1回目の再起動にはmacOS Installerという名前のボリュームが現れ選択されていて、2回目以降はこのボリュームは消えて、通常の起動ボリューム（Macintosh HDという名前にしてます）が選択されました。

いつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.5が起動しました。ビルドは21G72です。

12.5が起動するESPのファイル一式はここに置いてあります。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

macOS Ventura 13 Beta をインストール

Tue, 12 Jul 2022 16:05:47 +0900

VenturaのPublic Betaをインストールしました。OpenCoreとkext類をnightly build版にアップデートしておけば、macOS 12.4を起動する設定のままで問題なくインストール、起動できました。

Ventura Public Betaが来た

昨夜（米国時間で2022/7/11）のうちに VenturaのPublic Betaが配布されていました。Apple Beta Software Program登録済みMacの「システム環境設定」「ソフトウェア・アップデート」に登場してました。容量は3.84GBだそうです。前回のMontereyパブリックベータの容量が11.73GBでしたので、4分の1です。今回のアップデートは小規模なようです。インストールしたマシンは、ASRock Z690 Steel Legend + 12900K + RX 6600 XT + OpenCore 0.8.2 + macOS Monterey 12.4で構成した自作PCです。

追記 (2022/7/20)：配布方式が変更されたようで、従来のメジャーアップデートと同じくインストーラをダウンロードできるようになりました。こちらをご覧ください。

macOS Ventura PBの導入用USBを作る

以下の説明は古い情報ですので取り消しておきます。

いつものメジャーアップグレードでは、「今すぐアップグレード」ボタンを押すとインストーラがダウンロードされて起動しますが、そこで中断可能でした。しかしVenturaのベータ版は、アップデートが自動的に進んで、現在のmacOSを書き換えてしまうらしいです。

【要注意】macOS Venturaベータ版のインストール前に絶対知っておくべき落とし穴【…

パブリックベータでも同様と思われたので、新しいSSDを用意して、macOS 12.4とOpenCore 0.8.2で起動するように設定しておきました。そしてSSDからソフトウェアアップデートしました。実際に、ボタンを押すと自動でアップデートが進んでしまいました。

再起動でループ

ダウンロードが終わると再起動します。いつものように、ターゲットのドライブ（ここではVenturaという名前をつけてます）以外に、インストール用のmacOS Installerという暫定ドライブができていて、これから起動しようとします。しかしこの先、再起動してしまい、それが無限に続きます。

そこでOpenCoreをnightly版に入れ替えました。Kext UpdaterからOpenCore 0.8.3をダウンロードします。そして現在のEFIパーティションのファイルを、nightly build版のものに置き換えました。

カーネルパニック

すると先に進んだのですが、今度はカーネルパニックになりました。

そこでkext類もnightly build版にしました。これもKext Updaterから取り寄せました。nightly buildsから使用中のkextを取り寄せます。これをEFIパーティションにあるものと差し替えます。

なおOpenCoreとkextのnightly buildは以下のサイトからも入手できます。コメントで教えていただきました。Kext Updaterで入手するものより新しいバージョンが手に入ります。古いバージョンも入手できるので元に戻す場合にも便利です。

Builds

Venturaが起動

この結果、インストールが進み、いつものアップデートと同じように合計3回再起動し、Venturaが起動しました。バージョンは、13.0 Beta (22A5295i)でした。（ベータ版はスクショ禁止なのでバージョン番号以外の部分をぼかしてあります）

というわけで、OpenCoreとkextを最新のnightly build版にしておけば、特に設定を変えることなくインストールできました。今のところ問題なく動作してます。このままメインコンピュータとして使い続けることにしました。

Metal 3対応

システム情報・ハードウェア・グラフィックス／ディスプレイを見ると、RX 6600 XTがMetal 3対応になってました。

AMD Radeon RX 6600 XT:

 チップセットの機種: AMD Radeon RX 6600 XT
 種類: GPU
 バス: PCIe
 PCIeレーン幅: x16
 VRAM（総量）: 8 GB
 製造元: AMD（0x1002）
 装置ID: 0x73ff
 リビジョンID: 0x00c1
 ROMリビジョン: 113-3E4480U-S6L
 Metal対応: Metal 3
 ディスプレイ:

ASRock Z690 SLを最新BIOS (8.01) に更新

Wed, 06 Jul 2022 22:59:31 +0900

ASRock Z690 Steel Legendで作ったmacOSマシンは安定して動いていたのですが、BIOSを8.01にアップデートしたら起動途中で止まるようになってしまいました。tonymacx86で紹介されていた修正で起動するようになりました。こちらのマシン構成です。（ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4です。）

ASROCK Z690 STEEL LEGENDのUSBを設定する

tonymacx86で、BIOSを最新版の8.01に上げると起動が止まることと、その解決策を教えてもらいました。BIOSのネットワーク経由アップデート機能を動かすと、6.03のままで最新と言われていたので気づかなかったのですが、サポートサイトで確認したら6月に最新版が2個も出てました。それで7を飛ばして8.01をUSBメモリにダウンロードして、BIOSの更新を試みました。今まで、BIOS更新しても何の問題もなかったのですが、今回は、tonymacx86で教えてもらったように、

Stuck on [EB|#LOG:EXITBS:START]

と言うメッセージが出て止まってしまいました。起動ドライブの選択をした後の、macOSの読み込みに取り掛かるくらいのタイミングです。

この問題は、config.plistで、

Booter -> Quirks -> SetupVirtualMap をTRUEにする

ことで解決するとのことです。その通り設定したら、起動するようになりました。OpenCore 0.8.2に上げたことでもありますので、またEFIをアップロードしておきました。ご利用ください。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

OpenCore 0.8.1から0.8.2に更新: Ventura祭に備える

Wed, 06 Jul 2022 00:34:40 +0900

OpenCoreの0.8.2が公開されていたので0.8.1からアップデートしました。今回のアップデートはmacOS 13対応の項目が多いです。config.plistに追加された項目はありませんので、0.8.1のconfig.plistそのままでも動くはずです。

0.8.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.2とmacOS 12.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点はありませんでした。変更なしで、問題なく起動しました。macOS 13に対応するための修正が施されたようで、間も無くリリースされるpublic betaが楽しみです。

「このMacについて」表示でCPUが不明なことへの対処

Fri, 17 Jun 2022 12:31:28 +0900

Intelの12900K CPUを搭載したメインマシンはとても安定しているのですが、「このMacについて」を表示するとプロセッサが不明だと表示されます。弊害はないのですが、見た目が悪いので、それっぽく表示されるように直しました。

プロセッサ表示なんて飾りです

「このMacについて」のプロセッサの表示は単なる飾りで、不明と表示されても何の問題もないらしいです。不明と表示されていてもsysctlコマンドで調べると、以下のように

% sysctl machdep.cpu.brand_string 
machdep.cpu.brand_string: 12th Gen Intel(R) Core(TM) i9-12900K

搭載CPUが正確に認識されていることがわかります。とはいえ、「不明」と表示されるのはみっともないので、それっぽい表示が出るように直すことにしました。対象のマシン構成は以下です。

ASRock Z690 Steel Legend
12900K
Radeon RX 6600 XT
macOS Monterey 12.4
OpenCore 0.8.1

デフォルトは自動検出

表示を直す方法はいくつかあるようですが、今回は、OpenCoreのconfig.plistの中の、PlatformInfo / Generic / ProcessorTypeの値を変更します。設定可能な値は、AppleのSMBIOSヘッダ定義ファイルを見てくださいとのことです。ProcessorTypeのデフォルトは0で、その場合、最もそれらしい値を自動的に提示するようです。大抵の場合は、デフォルトの自動設定で問題ありませんでした。

現在のマシンでも、自動設定でIntel Core i9プロセッサであると正しく自動認識されていると考えられます。それでも「不明」と表示されてしまうのは、Appleの想定外のコア数で使用していることが原因のようです。12900はPコアが8、そのHTが8、Eコアが8ありますが、OpenCoreの機能でこれらを24コアと認識させて使ってます。

24コアのCore i9プロセッサは実存しないので、不明と表示されるようです。

コアを減らしてみる

このことを確認するために、BIOS設定でコア数を減らしてみます。Appleの想定内のコア数ならば、正しく表示されるはずです。そこで下のようにEコアを無効にして起動させます。

するとPコアだけになるので、コア数が8、スレッド数が16になりました。

コア数が8のCore i9プロセッサは実存するので、「このMacについて」のプロセッサ表示が正しく行われるようになりました。

Xeonだと思わせる

飾りでしかない「このMacについて」表示のためにEコアを諦めるのは本末転倒ですので、BIOSでEコアを復活させて、24コア設定に戻します。これで「不明」の表示に戻ってしまいました。そこで今度は、CPU種別自動判定を停止して、24コアでも問題の無いプロセッサに手動で設定することにします。

AppleのSMBIOSヘッダ定義ファイルを見ると、0以外に使用できるProcessor Typeの値がわかります。今回、関係しそうな値は以下のようになってます。コメントの説明によると、Core i9は6/8/10コアが存在することになっていて、当然ですが24コアはありません。その代わりXeon Wならば24コアの構成があり得ることになってます。iMac Proに搭載されているCPUです。

//
 155// Apple Processor Type Information - Processor Types.
 156//
 157 enum {

 ...

 138// <0F01> 08 cores Intel Xeon W Intel Xeon W
 139// <0F01> 10 cores Intel Xeon W Intel Xeon W
 140// <0F01> 12 cores Intel Xeon W Intel Xeon W (10.15+)
 141// <0F01> 14 cores Intel Xeon W Intel Xeon W
 142// <0F01> 16 cores Intel Xeon W Intel Xeon W (10.15+)
 143// <0F01> 18 cores Intel Xeon W Intel Xeon W
 144// <0F01> 24 cores Intel Xeon W Intel Xeon W (10.15+)
 145// <0F01> 28 cores Intel Xeon W Intel Xeon W (10.15+)
 146// <1001> 06 cores Intel Core i9 Intel Core i9
 147// <1001> 08 cores Intel Core i9 Intel Core i9 (10.15+)
 148// <1001> 10 cores Intel Core i9 Intel Core i9 (10.15+)

 ...

 215 AppleProcessorTypeXeonW = 0x0F01, // iMacPro1,1
 216 
 217 AppleProcessorTypeCorei9Type1 = 0x1001, // may not be used
 218 AppleProcessorTypeCorei9Type5 = 0x1005, // SKL-X i9, most likely to be invalid!
 219 AppleProcessorTypeCorei9Type9 = 0x1009 // ideal value for Coffee Lake i9, need confirmation
 220 };
 221

今回のマシンは、PlatformInfo / GenericでiMac Proとして設定しています。なのでそれに搭載されているCPUであると偽装するのも自然かと思いました。そこで、PlatformInfo / Generic / ProcessorTypeの値を明示的にXeon Wの値、すなわち0x0F01、10進数で3841に設定することにしました。

この結果、「このMacについて」のプロセッサ表示がXeon Wになりました。コア数は24と表示されました。

「このMacについて」のCPU表示をXeon Wに変更しても、sysctlコマンドは引き続きCPU種類を正しく認識していました。

% sysctl machdep.cpu.brand_string 
machdep.cpu.brand_string: 12th Gen Intel(R) Core(TM) i9-12900K

OpenCore 0.8.0から0.8.1に更新

Wed, 15 Jun 2022 13:19:24 +0900

OpenCoreの0.8.1が公開されていたので0.8.0からアップデートしました。追加された項目はありませんので、0.8.0のconfig.plistでもそのままでも動くはずです。

0.8.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.1とmacOS 12.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi。これらに加えて、新しく追加されたResetNvramEntry.efiも入れておきました。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点は以下でした。

Misc/SecurityのAllowNvramResetが消えてました。今まではtrueに設定していました。これはOpenCoreの起動時のピッカーにNVRAMをリセットするアイコンを出してくれていた機能です。アイコンを出す機能は、Driversフォルダの中に入れるResetNvramEntry.efiが担うようになったようです。/UEFI/Drivers/の中で、ResetNvramEntry.efiに関係するItemのEnabledをtrueにしておくと、今まで通りReset NVRAMアイコンが出ます。
Misc/SecurityのAllowToggleSipが消えてました。今まではfalseに設定していました。これもNVRAMリセット機能と同様に、Driversフォルダの中にToggleSipEntry.efiを入れることで機能するように変更されたようです。今まで使用していなかったので対応しませんでしたが、必要ならば、同様に、ToggleSipEntry.efiをDriversフォルダに入れて、/UEFI/Drivers/の中で設定すれば良いと思います。
0.8.0の時と同様に、Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中に、#INFO (prev-lang:kbd)という項目ができていて、これの値 (String型) がen:252 (ABC), set 656e3a323532になってました。コメントアウトなので問題ないはずですが、以前にこれを残しておいたらブラックスクリーンになりました。消しておくと良いです。

以上の設定で、引き続き問題なく起動しました。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4で動かしているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

Monterey 12.4 にアップデートする

Tue, 17 May 2022 21:52:59 +0900

macOS Monterey 12.4が配布されていましたので12.3.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.4の情報はまだありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.8.0で起動していて、kext類は最新です。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT

システム環境設定のソフトウェアアップデートに、12.4のアップデートの通知が来ていました。

アップデートは、PodcastとStudio Displayの機能強化と不具合に対応したものらしいです。これだけ見るとあまり関係なさそうですが、バージョン番号が大きく上がるマイナーアップデートなので期待したいところです。「今すぐインストール」ボタンを押すと、2.29GBのファイルがダウンロードされます。

その後、自動的に4回再起動して、12.4に更新されました。今回の再起動過程では、1回目の再起動にはmacOS Installerという名前のボリュームが現れ選択されていて、2回目以降はこのボリュームは消えて、通常の起動ボリューム（Macintosh HDという名前にしてます）が選択されました。

いつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.4が起動しました。ビルドは21F79です。

特に問題なく動いています。使用しているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

ASROCK Z690 STEEL LEGENDのUSBを設定する

Mon, 02 May 2022 00:14:20 +0900

ASRock Z690 Steel Legendをメインで使うことにして、ケースに入れたので、USBの設定を見直しました。15個制限があるので、使用するポートを選別して調整する必要があります。これまでの経緯は以下をご覧ください。

メインマシンをASRock Z690 Steel Legendに移行

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

USBポートの調査（前回）

以前の記事で書きましたように、バックパネルにアサインされているポート類は、以下のように割り当てられてました。ポート数は合計で12本です。Ethernetコネクタの下の２個のUSBポートのHSとSSの数字が入れ替わってますが、この通りでした。

また、マザーボード上の内部コネクタに関しては、以下の2ヶ所を調べてありました。

マザーボード上のM.2 E keyソケットに接続されたUSBはHS14でした
また、マザーボード上のUSB Type-Cコネクタは、HS01とSS01でした

ちなみにマザーボードの電源を切った時に、ほとんどのUSBコネクタに5Vが供給されるのですが、PS/2コネクタの下のUSB3_1_2だけには電力供給されないことがわかりました。

USBポートの全調査（今回）

今回は、マザーボードの他の内部USBポートも全部調べました。前回作ったUSBPorts.kextを書き換えて、キーボード類が接続されているHS14以外を、未確認のポート番号に入れ替えました。これで再起動すれば、未確認のポートが機能します。次に内部コネクタに、以下のようなアダプタを取り付けて、USBメモリなどのデバイスを取り付けます。その時の挙動をHackintoolなどで調べることで、ポート番号とコネクタの関係を知ることができます。

その結果、以下のように配線されていることが判明しました。

以上をまとめると、以下のリストになります。

HS01:マザーボード上のUSB Type-Cコネクタ (F_USB32_TC_1)
HS02:バックパネルのEtherの下の上のType-A (USB3_3_4)
HS03:バックパネルのEtherの下の下のType-A (USB3_3_4)
HS04:バックパネルのPS/2下の下のType-A (USB3_1_2)
HS05:バックパネルのPS/2下の上のType-A (USB3_1_2)
HS06:バックパネルのType-C (USB31_TC_1)
HS07:バックパネルのType-Cの上のType-A (USB31_TA_1)
HS08:オンボード搭載ハブ(ASM107x) (**USB3_5_6,**USB3_7_8)
HS09:オンボードUSB2.0 (USB_3_4 のCPU反対側)
HS10:オンボードUSB2.0 (USB_3_4 のCPU側)
HS11:オンボードUSB2.0 (USB_1_2 のCPUの反対側)
HS12: オンボードUSB2.0 (USB_1_2 のCPU側)
HS13: ASRock LED Controller
HS14:マザーボード上のM.2 E keyソケット接続 (BCM94360NGがBTで使用）
HS15〜:（不明）
SS01:マザーボード上のUSB Type-Cコネクタ (F_USB32_TC_1)
SS02:バックパネルのEtherの下の下のType-A (USB3_3_4)
SS03:バックパネルのEtherの下の上のType-A (USB3_3_4)
SS04:バックパネルのPS/2下の下のType-A(USB3_1_2)
SS05:バックパネルのPS/2下の上のType-A(USB3_1_2)
SS06:バックパネルのType-C (USB31_TC_1)
SS07:バックパネルのType-Cの上のType-A (USB31_TA_1)
SS08:オンボード搭載ハブ(ASM107x) (**USB3_5-6,**USB3_7_8)
SS09〜SS15:（不明）

HS08とSS08には、ASMedia社のUSB 3.0ハブ用チップのASM107xが接続されていると、Hackintoolに表示されました。ASM107xはマザーボードに搭載されていて、ASRockのマニュアルに記されたボード上のUSB 3.0コネクタ、USB3_5_6とUSB3_7_8に接続されているようです。

HS13には、ASRock LED Controllerというデバイスが接続されていました。名前から推測するに、マザーボードの電飾LEDコントローラに接続されているようです。Windowsのアプリケーションから電飾の設定を行う際に使用されるのだと思います。macOSでは使えません。

利用状況に合わせて調整

発見されたUSBポートが全部利用できれば良いのですが、macOSには最大15口までの制限があります。なので、ここから使用するポートを15個選んでUSBPorts.kextに設定します。どのポートを使うかは、マシンの構成次第です。マザーボード上の内部ポートを一切使わなければ、バックパネルのポートだけを活かせば良いです。でも、PCケースや5.25インチ拡張ベイなどで内部ポートを使用するならば、調整する必要があります。

Bluetoothで使用するポート：HS14

現在の構成では、BCM94360NGをマザーボード上のM.2 E keyソケットに取り付けて、WiFiとApple Magic Keyboard/Trakpadを使用しています。設定不要で機能する便利な無線アダプタです。BCM94360NGのBluetoothチップがHS14にUSB接続されているので、HS14は必須です。

ケースで使用するポート：HS/SS08

PCケースにUSB3.0コネクタが2個あり、これをマザーボード上のUSB3_7_8と刻印された内部USB 3.0コネクタに接続しています。上記で説明したように、このコネクタはASM107xハブに接続されてます。なのでHS08, SS08は使用したいです。

拡張ベイで使用するポート：HS/SS06, 07, 08, HS12

5.25インチ拡張ベイに、USBハブ＋SDカードリーダーを取り付けてます。

これが、マザーボード上のUSB3_5_6とUSB_1_2、バックパネルのEthernet下Type-Aに接続されてます。なので、HS06, HS07, HS08, HS12, SS06, SS07, SS08は活かしたいです。

拡張スロットに引出すポート：HS01, SS01

マザーボード上の内部Type-Cコネクタは、延長ケーブル経由で拡張スロットに引き出しています。なのでHS01とSS01は活かしたいです。

使用を断念するポート：HS/SS05, SS04

以上のポートと、残りのバックパネルポートを全部活かそうとすると、18個になります。使用できるポート数が15なので、3個の使用を諦めないといけません。高機能・高性能なポート、例えばType-CやUSB 3 Gen2のポートは活用したいところです。除外するとしたら、普通のUSB 3ポートです。

そこで、PS/2コネクタの下の２個のType-Aコネクタのうち、上のポートは使用を諦めました。また、PS/2コネクタ下の下のポートは、USB 2.0専用とすることにしました。HS05, SS05, SS04を諦めたことになります。PS/2下のコネクタは、通常はマウス・キーボード用に使われることが多いと思います。ここがUSB 2.0になっているマザーボードも多いので、2.0専用にしました。また前述のように、このポートは電源offの時に5Vが給電されません。使いにくい場合もあります。

ということで、上記のリストで番号が太字になっているポートを使用することにしました。その内容になるよう、USBPorts.kextの中のinfo.plistを書き換えました。

作成したUSBPorts.kextをこちらに置いておきました。皆さんの使用状況に合わせて、この中のinfo.plistの内容を変更して使ってください。

まとめ

仮組みで使ってたZ690マシンをケースに入れたことで、マザーボード上の内部USBを使用することになりました。それらが使用できるように、USBPorts.kextを調整しました。macOSには15個制限があるので、一部のバックパネルUSBコネクタを諦めました。厄介な制約ですが、苦労して調整するのも楽しく思えてきました。

メインマシンをASRock Z690 Steel Legendに移行

Sun, 24 Apr 2022 18:09:33 +0900

Alder Lake-S 12900Kを取り付けたASRock Z690 Steel Legendをメインマシンとして使うことにしました。そこで、今まで使っていたASRock Z590 Extremeマザーボードと交換しました。

古いマシンのSSDが不調に

Z590 Comet Lake-S で動かすmacOSメインマシンは、長らく安定していて全く問題ありませんでした。なので、興味本位で作ってしまったZ690マシンは、ずっとバラック状態で、サブマシンとして使ってました。

そのZ590メインマシンが、ここ1~2ヶ月ほど不調でした。数回に一回くらいの頻度で起動しません。やり直せば問題なく起動して使えるので、BIOS不調かなくらいに思ってました。それがとうとう、ログインできなくなりました。パスワード入力画面は出るのですが、データが壊れていてログインできないという内容のダイアログが出て起動できなくなりました。別のドライブから起動してDisk First Aidをかけてみると、パーティション構成に問題があるとの診断です。使用していたのはかなり前から使っている2.5インチSATA SSDでした。おそらくはフォーマットし直して復旧できると思われます。データはクラウドとTimemachineでバックアップしてあるので復旧は容易です。でもまた壊れるかもしれません。少なくともSSDは交換した方が良さそうです。

それで良いきっかけができたと思い直して、メインマシンからZ590マザボを取り外して、Z690マザボに交換することにしました。

起動SSD交換

Z690マザーボードには、1TB容量のWDのM.2 SSDが取り付けてありました。これにOpenCore 0.8.0とmacOS Monterey 12.3.1が入れてあり、問題なく動いています。なので、マザーボード交換に伴い、起動ドライブもこのM.2 SSDに変更します。一方で、起動しなくなった古い2.5インチSATA SSDは、いつの間にかディスクユーティリティからも見えなくなってました。

CPUクーラー交換

Z690マザーボードで最初に組んだ当時は、Alder LakeのLGA 1700対応クーラー製品が出揃ってませんでした。それでいち早く対応したCorsairの簡易水冷クーラーを使用しました。

一方で、メインマシンのZ590マザーボードには、Noctuaの空冷クーラーをつけてました。ケースには水冷ラジエータを取り付ける場所が確保できなかったので、引き続きこの空冷クーラーを使うことにして、これに交換しました。

現在売られているクーラー製品にはLGA 1700のアダプタも付属しています。でも昔に買った製品だったので、対応アダプタが必要です。NoctuaのLGA 1700アダプタには、サイズ違いのMP78とMP83があります。また、通常モデル用の銀色とchromax.black用の黒色があります。なので、色違い・サイズ違いの以下に示す4種類があります。色は間違えても取り付けられますが、サイズは互換リストを見て確認する必要があります。今回はMP78の黒色を入手しました。

グラフィックスカード交換

今まで使用していたZ590にはRadeon RX 6600を取り付けてました。

一方で、Z690マザーボードにはRadeon RX 580がついていました。これも交換して、今まで通りRX 6600を使うことにしました。RX 6600を使う場合には、config.plistのboot-argsにagdpmod=pikeraを追加します。 RX 580では不要でした。その結果現在の設定は、以下のようになってます。

-v keepsyms=1 debug=0x100 -wegnoigpu agdpmod=pikera

ちなみに-wegnoigpuは、WhateverGreen.kextに、iGPUを使わないように指示するオプションです。Alder LakeのiGPUはmacOSでサポートされていないので、ここで念の為に指定しています。

拡張カード

昔ながらのケースに、複数のHDD、光学ドライブ、SATA拡張ベイなどを取り付けているので、SATAを8本使ってました。Z590 ExtremeにはSATAが6本しか搭載されていなかったので、SATA拡張用のPCIeカードを使用していました。Z690 Steel Legendは、なんとSATAが8本ついています。拡張スロットの本数も多く、拡張性の高いマザーボードだと思います。なので、SATA拡張カードは取り外すことにしました。

また、ほとんど使ってないのですが、IEEE 1394カードを取り付けてました。これは今まで通り使えるよう移行しました。

マザーボード交換

説明が前後しますが、CPUクーラや拡張カード類を取り付ける前に、マザーボードを交換しました。同じASRock製品で、世代が近いこともあり、ボード上のケースファンコネクタ、USBコネクタ、オーディオコネクタなどの内部コネクタの位置がよく似ています。それでケース内の配線をほとんど変更することなく、大体同じ場所に取り付けることができて、とても助かりました。USB 3.0コネクタなどは嵩張るので、取り付け方向が90度違うと配線の取り回しが面倒になりますが、それも一緒なので楽でした。

まとめ

起動SSDが不調になったのをきっかけに、メインマシンのマザーボードをZ690に交換しました。12900Kを使っているので、コアがたくさん見えて満足感があります。

Z590マシンは、同じComet Lake搭載のiMacに合わせて、機種IDをiMac20,1に設定してありました。Z690マシンは、対応するCPU搭載Macが存在しないので、汎用性の高いiMacPro1,1に設定しました。そのおかげで、SafariからAmazon Primeビデオが再生できるようになりました。iMac20,1は本来Apple T2チップを搭載している機種なので、これに設定すると再生できないようです。

今後普段使いする過程で、不具合など見つけて対応していきたいと思います。今のところ、ケースのコネクタに接続したUSBポートの一部が機能しない問題があります。USBの設定を見直したいです。

OpenCore 0.7.9から0.8.0に更新

Sun, 24 Apr 2022 00:04:00 +0900

OpenCoreの0.8.0が公開されていたので0.7.9からアップデートしました。新しい項目はデフォルトのままで問題なかったので、0.7.9のconfig.plistでもそのままでも動くはずです。

0.8.0をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.0とmacOS 12.3.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.3.1
ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.3.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。

config.plistの変更点は以下でした。

Kernel/QuirksにCustomPciSerialDeviceという項目が追加されていました。シリアルポートに関する設定のようです。シリアルポートはデバッグの時に使うのかな？今時のマザーボードなので、シリアルポートは搭載していないので、Sample.plistの初期設定のfalseのままにしておきました。
Kernel/QuirksにForceAquantiaEthernetという項目が追加されていました。Aquantia AQtion を使った 10GbE ネットワークカードをサポートしてくれます。このカードは、macOS 10.15.4以前ではネイティブにサポートされていたので、それを有効にする機能のようです。またこのカードを使うためには、DisableIoMapperをdisabledに、DMAR ACPI tableはdropしない設定にして、BIOSでVT-dはenabledに設定する必要があるようです。現状では10GbEカードは取り外して休眠状態なので、Sample.plistの初期設定のfalseのままにしておきました。そのうち試したいです。
Misc/DebugからSerialInitという項目が削除されていました。これもシリアルポートに関するもので、シリアルポートを初期化する機能だったようです。Serialという項目に移動したようです。config.plistから削除しておきました。
MiscにSerialという項目が追加されていました。中には、InitとOverrideというブール値を設定します。シリアルポートを初期化したり設定する機能のようです。Debugから移動したものと思われます。これらも、Sample.plistの初期設定のfalseのままにしておきました。
0.7.9の時と同様に、Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中に、#INFO (prev-lang:kbd)という項目ができていて、これの値 (String型) がen:252 (ABC), set 656e3a323532になってました。説明書にもない項目で、間違って残っているのかもしれません。これを残しておいたらブラックスクリーンになりました。消しておくと良いです。
Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中のSystemAudioVolumeDBの設定がSample.plistからは消えてました。説明書には残っているので、機能していると思います。音量のことだけと思うので、Sample.plistに合わせて無しのままにしておきました。

以上の設定で、引き続き問題なく起動しました。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.3.1で動かしているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

Monterey 12.3.1 にアップデートする

Sun, 03 Apr 2022 14:40:59 +0900

macOS Monterey 12.3.1が配布されていましたので12.3からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.3.1の情報はまだありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.9で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

システム環境設定のソフトウェアアップデートに、12.3.1のアップデートの通知が来ていました。

アップデートは、2018 Mac mini外部ディスプレイとBeatsヘッドフォンの不具合に対応したものらしいです。そのほか、バグ修正とセキュリティアップデートが含まれているようです。脆弱性にも対応しているようなので、アップデートを急いだ方が良いと思われます。「今すぐインストール」ボタンを押すと、自動的に3回再起動して、12.3.1に更新されました。いつものアップデートでは、起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されるのですが、今回は、macOS Installerという名前のボリュームが現れました。

いずれにしても、いつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.3.1が起動しました。ビルドは21E258です。

Z690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートできました。

Monterey 12.3 でユニバーサルコントロールを使う

Wed, 16 Mar 2022 18:29:26 +0900

macOS Monterey 12.3が配布されたので12.2.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.3の解説はありません）。ユニバーサルコントロールが使えました。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.9で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + BCM94360NG

システム環境設定のソフトウェアアップデートに、12.3のアップデートの通知が来ていました。

アップデートにより、

「ユニバーサルコントロール（ベータ）」が追加
「空間オーディオ」「絵文字」が改良
Podcastのエピソードが追加
Safariの翻訳がイタリア語と中国語に対応
ショートカットがリマインダーでのタグに対応
保存済みパスワードにメモを追加可能
バッテリ容量測定の精度改善
TVアプリと写真アプリのバグに対応

などが実現されるようです。中でも、ユニバーサルコントロールは目玉機能で、世間で注目されてます。Hackintoshで動くのかどうか、是非とも試したいところです。

早速アップデートしました。「今すぐインストール」ボタンを押すと、4.38GBのファイルがダウンロードされ、その後、自動的に3回再起動して、12.3に更新されました。いつもと同様に、再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。

再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.3が起動しました。ビルドは21E230です。

ユニバーサルコントロールを試す

早速、話題のユニバーサルコントロールを試しました。これを使うためには、システム環境設定のディスプレイから、ユニバーサルコントロール…ボタンを押して設定します。現れるチェックボックスを、とりあえず全部有効にします。

iPadを使う場合は、これも最新のiPadOS 15.4にアップデートしておきます。次に、iPadの「設定」を開き、「一般」から「AirPlayとHandoff」を開いて「カーソルとキーボード」をオンにしておきます。

他のマシンの用意ができたら、macOSのディスプレイから「ディスプレイを追加」を選びます。これで追加するマシンを選べます。以下の例では、中央が、今回12.3をインストールしたASRock Z590 Extreme + 10900Kマシンです。左がMacBookで、右がiPadです。

この配置の場合、ASRock Z590 Extreme に接続したトラックパッドのポインターを、画面左に持っていくとMacBookにポインターが移動します。画面右に持っていくとiPadに移動します。それぞれのマシンに移動した後、テキストが入力できる場所でクリックすると、そこにカーソルが現れ、キーボードから入力できるようになります。とても便利です。ASRock Z590 Extremeの機種設定はApple T2セキュリティチップ搭載機種のiMac20,1に設定しています。このことでユニバーサルコントロールが動かないのではと心配していましたが、全く問題ありませんでした。

Macとの連携は、今までも、画面共有をすればほぼ近い操作が可能なので、それほど大きな変化ではないかもしれないです。でも、iPadとの連携はすごいです。iPadでの文字入力が楽になるので、iPad用のキーボードを買う必要が無くなったかもしれないです。また、写真ファイルなどをドラッグ＆ドラッグすると、その写真を貼り付けられます。ファイルの移動も簡単にできます。今のところ連携できるのは、Mac同士、もしくはMacとiPadだけのようです。この先、MacとiPhoneが連携できたら、ますます便利になるのではと思いました。

OpenCore 0.7.8から0.7.9に更新

Tue, 15 Mar 2022 22:41:52 +0900

OpenCoreの0.7.9が公開されていたので0.7.8からアップデートしました。今回もほとんど更新されていないので、0.7.8のconfig.plistでもそのままでも動くはずです。

0.7.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.9とmacOS 12.2.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.2.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点は以下だけでした。大きな変更はありません。

Misc/DebugにLogModulesという項目が追加されていました。値はStringでSample.plistの値は*でした。ログをモジュールごとにフィルタする機能のようです。例えば+OCCPU,OCA,OCBとするとこれらのモジュールのログだけが表示・記録されるようです。全てを表示するデフォルト値の*にしておきました。
Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中に、#INFO (prev-lang:kbd)という項目ができていて、これの値 (String型) がen:252 (ABC), set 656e3a323532になってました。説明書にもない項目で、間違って残っているのかもしれません。これを残しておいたらブラックスクリーンになりました。消しておくと良いです。

Sample.plistを見る限りでは他に変更点はありませんでした。Differences.pdfを見ると、他にも多少の変更があるようですが、デフォルト値には関係のないようでした。

Monterey 12.2.1 にアップデートする

Fri, 11 Feb 2022 14:35:46 +0900

macOS Monterey 12.2.1が配布されたので12.2からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.2.1の解説はありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.8で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

システム環境設定のソフトウェアアップデートに、12.2.1のアップデートの通知が来ていました。

アップデート内容は、「Intelプロセッサを搭載したMacコンピュータでBluetooth周辺機器に接続しているとスリープ中にバッテリーを使い切ってしまうことがある問題」を修正したとあります。12.2からすぐのタイミングですし、急いでバグに対応したようです。

12.2で動いているMacBookシリーズをスリープさせると、その間も電池の消耗が進んで数時間で電池切れになってしまう症状がネットで話題になってました。インテルだけでなくM1でも同様な症状が発生すると言われてました。スタパ齋藤氏の記事によると

[スタパ齋藤のApple野郎] 寝てくれっ、M1 Mac mini、徹夜しないでくれっ!!!

M1 Mac miniで、Bluetoothがオンになっているとスリープからすぐに目覚めてしまうそうです。なので、スリープからすぐに目覚めてしまうことが問題のようです。スリープからすぐに目覚める現象は、hackintoshでしばしば遭遇しますが、実機でも発生するようです。ちなみに、手元のM1 MacBook Airで試したところでは、スリープ状態でバッテリーが消耗する現象は見られませんでした。色々複雑な条件のもとで発生する不具合なのかもしれないです。いずれにしてもそれが解決されることは嬉しいです。

なので、早速アップデートしました。「今すぐインストール」ボタンを押すと、自動的に3回ほど再起動して、12.2.1に更新されました。いつもと同様に、再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。

再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.2.1が起動しました。ビルドは21D62です。

Z690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートして全コア、全スレッドで機能しました。

OpenCore 0.7.7から0.7.8に更新

Tue, 08 Feb 2022 18:43:30 +0900

OpenCoreの0.7.8が公開されたので0.7.7からアップデートしました。今回はほとんど更新されていないので、0.7.7のconfig.plistがそのままでも動くはずです。

0.7.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.8とmacOS 12.2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.2
ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.2

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistに変更はありませんでした。ただ、

NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82にSystemAudioVolumeDBが0.7.7から追加されていたのですが、Sample.plistから無くなってました。マニュアルには記載がありますし、残していても警告は出ませんでしたのでそのまま残してあります。0.7.7のSample.plistの値がE2だったのでそのままです。

Monterey 12.2 にアップデートする

Thu, 27 Jan 2022 12:22:41 +0900

macOS Monterey 12.2が配布されたので12.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.2の解説はありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.7で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

システム環境設定のソフトウェアアップデートに、12.2のアップデートの通知が来ていました。

アップデート内容はバグ修正とセキュリティ改善で、新機能が増えたわけではないようです。「今すぐインストール」ボタンを押すと、1.94 GBのファイルがダウンロードされました。その後、インストールを開始すると、自動的に3回ほど再起動して、12.2に更新されました。再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。

再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.2が起動しました。ビルドは21D49です。

Z690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートして全コア、全スレッドで機能しました。

OpenCore 0.7.6から0.7.7に更新

Wed, 12 Jan 2022 23:38:04 +0900

OpenCoreの0.7.7が公開されたので0.7.6からアップデートしました。Alder Lakeへのサポートが充実しました。config.plistには大きな変更は無いので、0.7.6のconfig.plistがそのままでも動くはずです。

0.7.7をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.7とmacOS 12.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.1
ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更は以下でした。

NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82にSystemAudioVolumeDBが追加されていました。Sample.plistの値がE2だったのでそのまま使いました。
UEFI/AppleinputにPointerPollMask, PointerPollMax, PointerPollMinが追加されていました。ポインターの制御用のようです。Sample.plistのデフォルトのまま、それぞれ-1, 80, 10にしておきました。
UEFI/AudioのAudioOutがなくなって代わりにAudioOutMaskが追加されてました。デフォルトの1にしておきました。
UEFI/AudioのMinimumVolumeが無くなってDisconnectHdaに置き換わってました。デフォルトのままfalseにしておきました。
UEFI/AudioのVolumeAmplifierがなくなって代わりにMinimumGain, MinimumAssistGain, MinimumAudibleGainが追加されていました。それぞれデフォルトのまま-15, -30, -55にしておきました。

Alder Lakeサポート

Alder Lakeの非対称コアへのサポートが強化されました。スレッドをコアとみなすことで、例えば8個のPコア、8個のPコアハイパースレッド、8個のEコアのある12900Kの場合、24コアのCPUとして機能します。性能の違うコアを同じものとみなすために、Geekbenchのシングルコアスコアが10%くらいばらつきます。でもマルチコアスコアは高速になりました。

ASRock Z690 Steel Legendをスリープさせる

Sat, 18 Dec 2021 11:34:33 +0900

ASRock Z690 Steel Legendで、スリープからすぐ目覚めてしまう現象が発生してましたが、これを止めることができました。USB関係の問題でした。他のCPU世代の自作でもよく見かける現象ですので、参考になると思います。以下の記事の続きです。OSはMonterey 12.1です。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

スリープからすぐに目覚める問題

Appleメニューから、もしくは、無操作のタイムアウトからスリープに入ると、以下のような現象が発生してました。

スリープに入る
画面が暗くなる。でもCPUファンは動いている。
1分ほどそのままの後、画面が復帰してログイン画面に戻る。

という現象です。スリープ復帰後は、引き続き正常に使用できます。また、シャットダウンは正常に行えます。

いろいろ試してみたところ、バックパネルのUSB Type-Aコネクタに接続されたデバイス（接続していたのはキーボード用無線USBアダプタとUSBメモリーです）を全部外すと、スリープから目覚めなくなることがわかりました。何かがUSB Type-Aコネクタに挿さっていると、1分ほどでスリープから目覚めてしまいます。

また、バックパネルのUSB Type-Cに同じキーボードとUSBメモリを接続したところ、この場合は正常にスリープし、そのキーボードを押すと復帰します。Type-Cには直接接続できないので、この確認には、MacBookで使うType-Cハブを使いました。

さらには、マザーボード搭載のM.2 E KeyコネクタのUSBも問題ないようで、そこに取り付けたBCM94360NGにBluetooth接続するApple Magic Keyboardなどは問題を起こしません。接続していてもスリープに入りますし、キーを押すとスリープから復帰します。

どうも、バックパネルのType-Aコネクタが問題を起こしている様子です。

USBがスリープを阻害する問題は、hackintoshでよく経験します。昔の記事ですが、こちらではZ390ボードが目覚める原因がUSBハブでした。

USB機器がスリープを阻害することがあります

OpenCoreのバニラガイドを見ると、macOSのUSBドライバに不備があって、スリープ時の電力管理に問題があるらしいです。おそらく、Macの実機で動けば良いので、標準仕様を満たした設計にはなっていないのでしょう。それでパッチを当てて修正する手法が考えられているようです。まずはそれを試しました。

方法1：USB機能にパッチする

USB機器がスリープを邪魔しないようにするパッチがいくつか考えられています。tonymacx86のZ690ビルドのスレッド

で配布されているZ690用のEFIファイル類を見ると、二つの方法が試みられていました。一つは、

SSDT-USBW.amlを使い、
USBWakeFixup.kextを使う

方法です。上記のバニラガイドでも紹介されている方法です。USBデバイスがスリープを妨げることを防ぐための措置らしいです。でも効果がありませんでした。カスタマイズする必要があったのかもしれないです。

もう一つは、

SSDT-GPRW.amlを使い、
Method(GPRW,2,N)にパッチを当てる

方法です。パッチは、config.plistのACPI/Patchに、以下のように書いておきます。USBとBluetoothがスリープを妨げないようにする処置のようです。

生のplistの部分は、以下になります。

<dict>
 <key>Comment</key>
 <string>change Method(GPRW,2,N) to XPRW, pair with SSDT-GPRW.aml</string>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>R1BSVwI=</data>
 <key>Replace</key>
 <data>WFBSVwI=</data>
</dict>

こちらは機能しました。これはUSBデバイスをスリープ解除に使えなくする力技のパッチです。なので、どんなUSBデバイスが挿さっていても、スリープから目覚めなくなりましたが、一方で、USBキーボードやBluetoothキーボードを操作しても、スリープから復帰しなくなります。電源スイッチを押して初めて復帰します。電源スイッチが遠いとちょっと不便なので、なんとかしたいところです。

方法2：USBPorts.kextを書き換える

そこでこの方法を考えました。まずは気になったところが、Type-Aコネクタが使用されている時だけ、スリープから目覚めてしまうという現象です。Type-CやM.2コネクタのUSBデバイスは問題を起こしません。

USBコネクタの種類は、EFIの中で設定してmacOSに知らせています。現在使っている方法は、USBPorts.kextを作って、その中のInfo.plistで設定する方法です。

15個制限のためのUSBPorts.kextをHackintoolで作る

Hackintool.appを使う場合は、以下のようにしてConnectorの種類を設定します。

Connectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。それぞれの選択で、Info.plistのUsbConnectorキーに0, 3, 9, 10, 255が割り当てられます。hackintoolのソースによると、この5種類を含めて、以下の数値が用意されています。

kTypeA		= 0x00,	// Type ‘A’ connector
kMiniAB		= 0x01,	// Mini-AB connector
kExpressCard	= 0x02,	// ExpressCard
kUSB3StandardA	= 0x03,	// USB 3 Standard-A connector
kUSB3StandardB	= 0x04,	// USB 3 Standard-B connector
kUSB3MicroB	= 0x05,	// USB 3 Micro-B connector
kUSB3MicroAB	= 0x06,	// USB 3 Micro-AB connector
kUSB3PowerB	= 0x07,	// USB 3 Power-B connector
kTypeCUSB2Only	= 0x08, // Type C connector - USB2-only
// These only implement the USB2 signal pair, and do not implement the SS signal pairs
kTypeCSSSw	= 0x09, // Type C connector - USB2 and SS with Switch
// These implement the USB2 signal pair, and a Functional Switch with a physical
// Multiplexer that is used to dynamically connect one of the two receptacle SuperSpeed
// signal pairs to a single USB Host Controller port as function of the Type-C plug
// orientation.
kTypeCSS	= 0x0A, // Type C connector - USB2 and SS without Switch
// These implement the USB2 signal pair and a Functional Switch by connecting each
// receptacle SuperSpeed signal pair to a separate USB Host Controller port.
// 0x0B – 0xFE: Reserved
kInternal	= 0xFF	// Proprietary connector

どのコネクタに接続されていてもUSBはUSBなので関係ない気もしますが、macOSの中での電力制御の扱いが異なるようです。IORegistryExplorerなどでコネクタの情報を見ると、コネクタ種類の違いで電流関係のパラメータが異なっています。コネクタ設定の違いが、スリープ時の電流管理にも影響していて、意図しない復帰を誘発している可能性があるかと思います。実際に先の記事にも書きましたが、Bluetoothアダプタが接続するポートは、255に設定しないとスリープを妨げることがあるようです。

今回の不具合も、Type-Aに対するスリープ時の電力管理がうまく働かないのが原因とも考えられます。それで、Type-Aに設定していた部分：

を、以下のように、全てInternalに設定しました。

この結果、Type-AのコネクタにUSBデバイスを接続していても正しくスリープするようになりました。Internal (255) 以外の設定値のうち、一般的なUSB 2.0 (0)とTypeC+Sw (9)も試しましたが、それらでは解決しませんでした。上の実験でType-Cで正しくスリープ動作したのは、ハブのおかげだったのかも知れないです。

スリープ動作の確認

ということで、USBPorts.kextでコネクタをInternalに設定する方法で、問題はほぼ解決しました。以下のaml, kext, パッチ：

SSDT-USBW.aml
USBWakeFixup.kext
SSDT-GPRW.aml
Method(GPRW,2,N)パッチ

は、どれも不要でした。

この方法で正しくスリープに入り、CPUファンが停止した状態が何時間も継続します。その一方で、Bluetooth接続したApple Magic Keyboard, Magic Trackpad, LogicoolのBTマウスなどから目覚めさせることが可能です。また、Type-Cにハブ経由で接続したノーブランドのキーボードからも目覚めます。

ただ、Type-Aに直接接続した一部のキーボードなどから目覚めさせることができない問題があります。フォーラムで教えてもらった情報によると、スリープ復帰するマウスとしないマウスがあるようです。また、Magic KeyboardをUSB接続した状態だと、これからスリープ復帰できるようです。いずれにしてもBluetooth入力デバイスをメインに使っていく予定なので、このことはほとんど気になりません。

macOSの「システム環境設定・省エネルギー」のデフォルトでは、「ネットワークアクセスによるスリープ解除」が有効になっています。これを有効にしておくと、手元の環境では頻繁に目覚めてしまいます。色々な機器が接続されているので、アクセスが多いのかも知れないです。ネットワークがもっと静かな環境なら有効に設定しても良いのかも知れませんが、これを無効にしました。

一方で、「Power Napを有効にする」は、有効にしておいてもそれほど問題はありません。約1時間に1回ほど目覚める程度でした。それが気になるような環境でしたら、無効にしておくと良いと思います。

まとめ

スリープから自動的に目覚めてしまう現象に、USBPorts.kextの設定で対応しました。正しくスリープして、キーボードやポインティングデバイスの操作でスリープ復帰するようになりました。Z690は、性能が良くて安定しているので、すぐにメインマシンにしても良いくらいです。

Monterey 12.1 にアップデートする

Tue, 14 Dec 2021 18:46:50 +0900

macOS Monterey 12.1が配布されたので12.1 RC2からアップデートしました。問題なくアップデートできました。Radeon RX 6600が正式にサポートされました。アップデート情報は以下にあります（現時点では12.1の解説はありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下の2台です。いずれもOpenCore 0.7.6で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

ネットの情報によると、配布された12.1はビルド番号が21C52らしいです。すでにベータ版12.1を導入していて、そのベータ最終版のRC 2も同じ21C52でした。なので、システム環境設定のソフトウェアアップデートに、12.1の通知は来ませんでした。同じもののようですが、念のためにApp Storeに行き、Montereyのダウンロードをしました。

その結果、12.16GBのファイルがダウンロードされました。

ダウンロードされたmacOS Montereyインストール.appは、自動的に起動しました。インストール先を指定するとインストール開始されて、途中、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.1が起動しました。でもビルドは21C52のままで変わりませんでした。

Radeon RX 6600 XTが認識されています。正式サポートされて一安心です。

OpenCore 0.7.7でAlder Lake全コアに対応予定

Sat, 11 Dec 2021 00:34:15 +0900

Intelの新しい第12世代CPU Alder Lake-Sへの対応がOpenCore開発チームによって進捗しています。先の記事では、macOSでAlder Lake-SのEコアを半分まで稼働させる拡張機能であるCpuTopologySync.kextを紹介しました。昨日これが配布終了になり、その機能がOpenCore本体に組み込まれつつあることが明らかになりました。来月公開のOpenCore 0.7.7では全てのEコアが稼働するそうです。

その機能を先立って試すことも可能です。以下のコメント、

で、開発段階のOpenCore.efiが配布されています。これを、

現在のEFI/OC/OpenCore.efiと入れ替えて、
config.plistでKernel/Quirks/ProvideCurrentCpuInfoをtrueにする

ことで、macOSから全コアが利用可能になります。当然ですがBIOSで全コアを有効に設定しておく必要があります。上記のコメントの手順では、CPUFriend.kextとCPUFriendDataProvider.kextを使用して、CPUの周波数ベクターを設定するように書かれていますが、iMacPro1,1の機種IDでは不要でした。書き換えなくても性能は変わりませんでした。

これでGeekBench 5のマルチコアスコアが1000から2000くらい上昇します。明らかなシングルコア性能低下もありませんでした。GeekBenchのCPU情報によると、例えば12700Kは、

1 Processor 20 Cores

と表示されます。8 Pコア＋8 ハイパースレッド (HT) ＋4 Eコア＝20コアという計算だと思われます。 10900Kの場合は、

1 Processor 10 Cores, 20 Threads

のように、物理コアとスレッドが別々に表示されていました。OpenCoreでは、Alder Lake PコアのHTを物理コアとして扱うことで、HT可否コア混在の問題を解決している様子です。

来月のOpenCore 0.7.7へのバージョンアップにより、何事もなく全コアが使えるようになると思いますが、現時点でも簡単に試せて、効果絶大です。

OpenCore 0.7.5から0.7.6に更新

Tue, 07 Dec 2021 19:18:30 +0900

OpenCoreの0.7.6が公開されたので0.7.5からアップデートしました。大きな変更は無いので、0.7.5のconfig.plistそのままでも動くはずです。

0.7.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.6とmacOS 12.1 betaで動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.1 beta
ASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.1 beta

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目にほとんど変更はありませんでした。

UEFI/Output/にReconnectGraphicsOnConnectが追加されていました。デフォルト値がfalseで、この機能は無効になります。ファームウェアによっては「BiosVideo.efiを使う場合のように、代替のグラフィックスドライバを使うと良い場合がある」そうです。おそらくはEFIの画面のことと思います。またこれを使うにはConnectDriversを有効にする必要があるとのことです。関係なさそうだったので、デフォルトのfalseにしておきました。
UEFI/Output/にUIScaleが追加されていました。以前は、NVRAM/Add/4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14/で指定していた設定です。こちらに移動したようです。sample.plistには0とされています。これは変更なしという意味らしいです。後述するように、Z690マシンで表示が見にくかったので2にしました。
UEFI/Quirks/にEnableVmxが追加されていました。Configuration.pdfには説明がありません。sample.plistにだけ加わっています。0.7.6のアナウンスによると、仮想化関係の設定のようです。sample.plistに書かれている通りfalseにしておきました。

追加項目がデフォルトのままでも起動には問題ありません。なので0.7.5のconfig.plistをそのまま使っても問題ありません。これで、0.7.5から0.7.6に移行できました。

UIScaleを調整

今までは、sample.plistに倣って、UIScaleをNVRAM/Add/4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14で01に設定していました。今回、UEFI/Output/で設定するように変更されたようなので、値を見直しました。sample.plistでのお手本では0に設定されています。0は変更なし、1は1倍ピクセルのことのようです。

Z590マシンでは、ボリューム選択画面は小さく鮮明に表示されていました。でもZ690マシンでは、同じく小さく表示されるものの、表示が滲んで、文字が潰れていました。それでも我慢して使ってました。

UIScaleの設定を試したところ、0や1の設定では、このような滲んだ表示になるようです。4Kディスプレイに正しく対応できていないようでした。そこでUIScaleを2に設定したところ、綺麗に表示されるようになりました。表示サイズは2倍に大きくなりました。

Alder Lake対応

Alder Lakeのために更新された項目もあります。特にXCPM CPU power management ACPI tableが追加されたとのことです。Z690マシンで、これに関して特に変わった感じは分かりませんでした。もう少し調査します。

OpenCoreと同時にアップデートされたkext類も、Alder Lakeに対応しました。AppleALC.kextは1.6.7になりました。これで、ASRock Z690 Steel Legendに搭載されたALC897のデバイス番号に対応し、音が出るようになりました。またVirtualSMC.kextもアップデートされて、HMMonitorでCPU温度や消費電力が表示できるようになりました。

Alder Lake-SをmacOSで動かすハッキング

Mon, 06 Dec 2021 23:14:57 +0900

Intelの新しい第12世代CPU Alder Lake-Sが発売されてから1月あまり経ちました。海外のコミュニティを見ていると、新CPUをmacOSで使うためのハッキングが進捗しています。昨日（2021/12/05）あたりには12900Kの24スレッド中の、20スレッドまでをmacOSで使うkextが紹介されました。近いうちにAlder Lakeの全性能を引き出せるようになるのではと思います。

追記：OpenCore 0.7.6が公開されたので更新しました。

Comet Lakeに偽装する方法

こちらでも紹介しましたが、Alder Lake-SとZ690マザーボードの組み合わせで、macOSがかなり安定して動作しています。macOSで元々サポートされているComet Lake-Sと比べて、遜色のないくらい安定しています。M1 Maxを凌駕する性能でもあることから、早々にメインマシンにしても良いと考えているくらいです。

この手法では、Alder Lake-SをComet Lake-SとしてmacOSに認識させています。その場合、Alder Lakeから導入されたPコア/Eコアの構成は活用できず、一部のコアを使用できません。例えば、最上位モデルの12900Kの場合、P+E+ハイパースレッド(HT)で24スレッドが用意されているのに対して、Eコア、またはHTを除く、合計16スレッドしか使えません。表にまとめておきました。


12900K	Pコア	PコアHT	Eコア	合計TH	GB5 Multi スコア
本来の構成	8	8	8	24	?
macOS (8コア)	8	8	0	16	~13000+
macOS (16コア)	8	0	8	16	~13000-
CpuTopologySync (12コア)	8	8	4	20	~16000

それでもM1 Maxより良いベンチマークスコアが得られます。Geekbench 5のMulti-core Scoreでは13000くらいです。Geekbench 5ブラウザのサイトで検索すると、

12900k Acidanthera - Geekbench 5 CPU Search - Geekbench Browser

このページで、8コアもしくは16コアと表示されるのが、これらの結果です。8コアがPコア+HTの設定、16コアがPコア（HTなし）+Eコアの設定です。Eコアを使わない方が、多少良いスコアになるので、16コアの結果はほとんど見られなくなりました。

CpuTopologySync.kextを使う方法

~~昨日（2021/12/05）あたりに、~~acidentheraさんからCpuTopologySync.kextというkextを使った方法が公開されました。

GitHub - acidanthera/CpuTopologySync: Rebuild asymmetric CPU topology on macOS.

~~まだ開発中で制約がありますが、~~これを使うとEコアをさらに活用できます。正確には、Pコア＋PコアのHTに加えて、Eコアの半分までを使用できるようです。12900Kの場合、物理コアが12コア、HTが8スレッドで、合計20スレッドになります。残りの4スレッドは、アクティビティモニタには24スレッドのグラフが現れるものの、うち4スレッドが動作しないようです。

この理由は、CpuTopologySync.kextのコメントによると、XNU割り込みコントローラの仕様のためらしいです。

 After this only half of the efficient cores will be active.
The reason for this is the way XNU interrupt controller works.
cpu_topology_start_cpu will not start any CPU, which index is
outside machine_info.max_cpus, and max_cpus is equal to a total
number of _active_ CPUs.
* Trying to increase this value results in a stall, likely because
non-existent ("hyperthreaded" counterprarts of E-Cores) CPUs
do not come live.
* Trying to add non-existent CPUs after all E-Cores does not work
either as they are treated as physical cores on the die,
and thus result in the same asymmetric topology crash.

XNU割り込みコントローラがEコアのHTにアクセスしようとするらしいです。それでコアを半分に設定しておいて、HTへアクセスしようとしてもコアが足りるようにしているようです。

それでもEコアが働く効果により、Geekbench 5のマルチコアスコアが16000以上になるそうです。Geekenchブラウザで、コア数12となっているスコアがこれに相当します。シングルスレッド性能のバラツキや低下もなく、効率良く動いている様子です。kextを使用する以外に、

カーネルにパッチを当てる（config.plistにパッチの記載を追加する）
~~開発版~~最新版のLilu.kextを使う
Liluの直後にCpuTopologySync.kextを読み込む

などの作業・要件が必要です。etorixさんのポストに、この方法がコンパクトに書かれています。

全スレッドを使う方法

Geekbench 5 ブラウザを見ていると、24コアで動く12900Kのスコアが掲載されています。詳細を見ると、3 Processors, 24 Coresと書かれています。おそらくは、Pコア、HT、Eコアをそれぞれ仮想CPUに見立てて、24コアを使い切った構成だと考えられます。でも今のところ、CpuTopologySync.kextで12コア20スレッドにする場合と、ベンチマークスコアはあまり変わらないです。

まとめ

Alder Lake-SでmacOSを動かすハッキングは、ここ1ヶ月くらいでどんどん進捗しています。海外のフォーラムを見ていると、その成果に沸く様子が伝わってきて楽しいです。今のところCpuTopologySync.kextでEコアが半分になってしまう点など、まだまだ改善の余地はありそうです。今後のOpenCoreのリリースに合わせて、安定したバージョンが提供されていくと思われます。

NVIDIA GeForce KeplerをMontereyで動かす

Sat, 04 Dec 2021 00:10:33 +0900

NVIDIAのKeplerアーキテクチャは、macOSで長らくサポートされていましたが、とうとうMontereyからサポートされなくなりました。でもBig Sur以前のドライバをインストールすれば動きます。

Keplerが動かない

久しぶりに古いKeplerアーキテクチャのグラボ、GTX 770を使ってみたところ、macOSで動かなくなってました。低解像度で表示はされますが、グラフィックス加速が効いてなくて、動きがギクシャクします。試したのは、ASRock Z690 + Intel 12700K + macOS Monterey 12.0.1の構成です。調べたところMontereyからKeplerのサポートが終了しているようです。ちなみにこれまでmacOSで動くとされていたKeplerのグラボは、以下です。Montereyから、これらが動かなくなったようです。（正確にはMonterey beta 6まではドライバがあったらしいです）

GTX Titan (GK 110 Maxwell core)
GTX Titan Black (GK 110 Maxwell core)
GTX Titan Z
GTX 780/Ti
GTX 770
GTX 760/Ti
GT 740
GT 730 (GK208 variant)
GT 720
GT 710
GTX 690
GTX 680
GTX 670
GTX 660Ti
GTX 660(MUST BE RUNNING A GK 104 core, NOT GK 106)
GTX 650(GK 107 core)
GT 640(Kepler edition, GK 107/208 core)
GT 630(Kepler edition, GK 107/208 core)
Quadro 410
Quadro K420
Quadro K600
Quadro K2000/D
Quadro K4000/D
Quadro K4200
Quadro K5000
Quadro K5200
Quadro K6000

ちなみに、NVIDIA自体も2021年10月の最新ドライバでKeplerのサポートを終了したそうです。なのでmacOSのKeplerサポート終了は、仕方のないことでしょう。

NVIDIA、Kepler世代GPUやWindows 8.1以前のサポートを終了

kextが無い

なのでMontereyにはKeplerをサポートする拡張ファイルが無くなりました。Keplerは、macOSでサポートされていたNVIDIA唯一のアーキテクチャだったので、これでNVIDIA製品が完全にサポートされなくなりました。

kextが無くなったことを確認するために、macOS 11.2.1 Big Sur (20D74)の/S/L/Eの中身を調べてみました。NVDAで始まるファイルとして、以下が見つかります。

/System/Library/Extensions/NVDAGF100Hal.kext
/System/Library/Extensions/NVDAGK100Hal.kext
/System/Library/Extensions/NVDAResman.kext
/System/Library/Extensions/NVDAStartup.kext

同様にGeForceで始まるファイルとして以下がありました。

/System/Library/Extensions/GeForce.kext
/System/Library/Extensions/GeForceAIRPlugin.bundle
/System/Library/Extensions/GeForceGLDriver.bundle
/System/Library/Extensions/GeForceMTLDriver.bundle
/System/Library/Extensions/GeForceVADriver.bundle

一方で、macOS 12.0.1 Monterey (21A559)にはこれらが存在していません。

古いKextを使う

Kextが無くなってしまったのなら、古いmacOSから持って来れば良いです。ただ、システムに必須のディレクトリは保護されていて、手作業でkextを持ってくるのは面倒です。なので、それを自動化してくれるツールがありました。

Releases · chris1111/Geforce-Kepler-patcher

前述の9個のkextとbundleをインストールしてくれます。

ただし、システムファイル用のディレクトリに手を加えるのでSIP (System Integrity Protection) を無効にする必要があります。通常は、

csrutil status

で確認できるように、SIPが有効になってます。Macの実機だと、リカバリーモードで起動してcsrutilコマンドでSIPを解除するのですが、hackintoshならconfig.plistで変更できます。NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82/csr-active-configの値（大抵は00000000のはずです）をEF0F0000に変更します。この数値はGeforce Kepler patcherで指示されます。

Runボタンを押すと、インストールが開始されます。インストール先のボリュームを指定して、その中のDATAになっているAPFSのボリュームを指定するステップを経て、インストール終了です。

csr-active-configの値は、kext類をインストールした後もそのままにしておく必要があるようです。SIPを有効に戻してしまうと、起動しなくなりました。また起動ボリュームの名前が、Monterey-DISKに変更されます。

動きました

再起動すると、高解像度の画面で表示されていました。macOSで認識されているようです。Geekbench 5も動くようになりました。でもOpenCLのテストはなぜか途中で中断します。Metalのテストは最後まで動きます。スコアは以下のようでした。

古いGPUですからこんなものでしょうか。M1 Maxの1/10くらいです。

まとめ

NVIDIA GeForce KeplerはMontereyからサポート外になってました。古いmacOSのkextをインストールすることで使えるようになります。古いカードですのでそれなりの性能でした。

ASRock Z690 Steel Legendのオーディオを動かす

Wed, 01 Dec 2021 23:15:43 +0900

ASRock Z690 Steel Legendのオンボードオーディオが動きました。AppleALC.kextのGithubのページを見に行ったら、Z690用のパッチの当たったバージョンがありました。以下の記事の続きです。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

Kext Updaterから開発版を入手する

Kext類の公開前開発バージョンは、Kext Updaterからも入手できます。Kextmanagerを選んで、Nightly Buildsの項目を見ます。ここから入手可能な開発バージョンの中に、AppleALCがありました。

これでダウンロードしたところ1.6.7を入手できました。EFIにある1.6.6と差し替えます。ASRock Z690 Steel Legendに搭載されているコーデックはALC897です。このlayout-idは、12, 23, 66, 69のいずれかとのことです。

Supported codecs · acidanthera/AppleALC Wiki

大抵はどれでも動くのですが、やはり最初に試した12で動きました。

これで音が出るようになりました。

M1 Maxと10コア勝負したら負ける

Sat, 06 Nov 2021 20:39:48 +0900

M1 ProとM1 Maxを搭載したMacBook Proの性能がとても良いらしいです。それで、同じ10コアCPUを搭載した重量級自作マシンとM1 Maxを比較しました。ベンチマークソフトはmacOS 12.0.1上でのGeekbench 5です。結果はわかっていたことですが、負けてます。

比較対象：M1 Max

新型MacBook Proが手元にあるわけではないので、比較対象のM1 MaxスコアはGeekbenchにあるベンチマーク結果です。テンション低くてすみません。M1 MacBook Airで十分な性能ですし、それでも重いので、無印MacBookの復活を待っているところです。OSは、M1 MaxなのでmacOS Monterey 12.0.1のはずです。

Geekbench BrowserのCPUのページでMacBookPro18で検索すると、今回の新製品MacBook Proのスコアが出てきました。

MacBookPro18 - Geekbench 5 CPU Search - Geekbench Browser

18,1から18,4まであるようです。GPUのページでもMacBookPro18で検索しました。

MacBookPro18 - Geekbench 5 Compute Search - Geekbench Browser

新型MacBookProには14インチと16インチモデルがあり、それぞれバリエーションがあります。8コアCPU, 14コアGPUのProが選択が可能なのは、最下位14インチモデルだけです。Geekbenchの結果と照らし合わせると、MacBookPro18,3がこのモデルのようです。また、18,2には32コアGPUの結果のみがあり、18,1と18,4には24コアGPUの結果もあります。これから、32コアGPUのMaxのみを選べる16インチ最上位機種が18,2だと思われます。以上から、

MacBookPro18,3は14インチ最下位モデル
MacBookPro18,2は16インチ最上位モデル
MacBookPro18,1とMacBookPro18,4は中間モデル

と推測しました。番号の並びから18,1が16インチ下位モデル、18,4が14インチ上位モデルと思われますが、両者のCPU/GPU仕様に違いがないので、Geekbenchスコアからは判断できません。

今回の比較対象は、この中から最上位モデルのMacBookPro18,2にしました。Apple Storeで最小構成で見積もると、以下の構成で、税込419,800円です。

32GBメモリ
1TB SSD

比較対象：Intelマシン

最上位M1マシンの挑戦を受けるのは、現在使っているIntelマシンです。M1 Maxと同じ10コアCPUです。OSも同じくmacOS Monterey 12.0.1です。GPUはRX 5700XTです。

CPU: Intel Core i9-10900K (10コア20スレッド)
GPU: AMD Radeon RX 5700XT
ASRock Z590 Extreme
macOS Monterey 12.0.1, OpenCore 0.7.5

これをもとに、MacBook Proと同等の自作機を考えると、以下のような見積もりになると思います。RX 5700XTは新品での入手が困難なので、入手可能でほぼ同等性能と言われるRX 6600XTにしました。macOS 12.1からサポートされます。

M1 Max搭載MacBook Pro対…｜自作PC構成｜自作.com

合計価格は税込281,336円です。MacBook Proよりは安いですが、差額14万円くらいです。割合では3分の2くらいでしょうか。グラフィックスカードの高騰が痛いですね。ノートとデスクトップの違いがありますので、大きくて重くて持ち運べなくてバッテリ無しですが、画面は大きいです。

CPU性能比較

M1無印の時からCPU性能はとても良かったのですが、10コアになってさらに強力になってました。10コアとは言っても、フルスペックのコアは8コアだけなので、10コア全部がフルスペックのインテルCPUも頑張るのではと期待していたのですが、以下のような結果です。M1 Maxのスコアは、Geekbenchのサイトにある最近の測定値3点を選んで平均しました。10900Kのスコアも3回の平均です。

シングルでは、M1無印の頃から負けてましたが、それを引き継いだ性能なので、完敗です。コア数が増えたのでマルチも負けました。M1 Maxの方が、シングルで30％、マルチで15％高性能です。大きなCPUクーラーで冷却している10900Kと、ノート筐体のM1 Maxというハンディを考えると、圧倒的な性能差と言えます。

Geekbenchによると、このマルチ性能に勝てるIntel Macは、iMac Pro最上位（18コア）か、Mac Pro 16コアモデル以上だけのようです。

GPU性能比較

インテルのiGPUは、CPUチップの片隅に載せてもらったおまけのようなiGPUという印象でした。M1だって大したことないだろうと思ってました。比較相手の5700XTは、長さ30cm近い拡張カードに搭載された大きなチップのGPUです。電力も冷却も十分なので、圧勝かと思いました。しかし以下のように、Open CLのスコアは5700XTが17%ほど勝っているものの、Metalのスコアは2％負けてます。これもそれぞれ3回の平均です。2％は誤差と言えますが、数回測っても逆転するのは1〜2回程度でした。

Open CLでM1 Maxが負けているのは、多分AppleがOpen CLに力を入れていないからではないかと思います。一方で、Appleが提唱しているMetalに対しては十分な最適化が施されていて、M1のハードウェア性能をとことん引き出したスコアが出たのではないかと思います。ということで、Open CLでは勝てたけど、Metalでは僅差で負けという結果でした。RX 6900XTだとこの3倍近いスコアが出るとコメントで紹介されていましたので、6900XTなら圧勝できるかもしれません。

まとめ

Intelの10コアCPUと、M1 Maxを比較しました。M1はGeekbenchからもらってきたスコアなので、手抜きです。CPU性能はM1が良いです。Radeon RX 5700XTと比較したグラフィクス性能では、MetalスコアでM1 Maxが僅差で高性能でした。

OpenCore 0.7.4から0.7.5に更新

Tue, 02 Nov 2021 23:15:28 +0900

OpenCoreの0.7.5が公開されたので0.7.4からアップデートしました。大きな変更は無いので、0.7.4のconfig.plistがそのまま動きます。

0.7.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.5とmacOS 12.0.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon 5700 XT + macOS Monterey 12.0.1

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目にほとんど変更はありませんでした。

Booter/Quirks/にResizeAppleGpuBarsが追加されてました。デフォルト値が-1で、この機能は無効になります。BIOSでResizable BAR (Base Address Register)の設定を有効にすると、WindowsではRadeon RX 6000シリーズの性能が上がるらしいです。でもmacOSはこの機能をサポートしていなくて、有効にするとクラッシュする可能性があるとのことです。これに対応するQuirkです。BIOSで設定しない限りは問題なさそうなので、無効にすることとし、-1にしました。
UEFI/Quirks/にResizeGpuBarsが追加されていました。Resizable BARに関係した設定です。デフォルトの-1にして無効にしました。

追加項目はデフォルトのままにしましたので、0.7.4のconfig.plistをそのまま使っているのと同じです。これで、0.7.4から0.7.5に移行できました。

macOS 12.1からRadeon 6600XTが使える

Sat, 30 Oct 2021 19:03:25 +0900

AppleのmacOS 12.1 betaリリースノートによると、AMD Radeon RX 6600XTが使えるようになったとのことです。色々なサイトで話題になっていますが、元ネタは以下のようです。

Apple Developer Documentation

情報のまとめ

これによると「ディスプレイに関するmacOS Monterey 12.1 betaの新機能：AMD Radeon 6600XT GPUを搭載したグラフィックスカードが使用可能になります。」とのことです！

Redditのコメントには以下のような内容が書かれてました。

Radeon RX 6600無印も6600XTと同じくNavi 23なのでdevice IDを偽装すればたぶん動く
Radeon RX 6900XTの新しいバージョン（XTXHチップ）もdevice IDを0x73BFに偽装する必要があるけど動く
Radeon RX 6700XTはNavi 22であり、GPUチップが違うので引き続き動かないと考えられる

6700だけはなぜかmacOSでサポートされない様子です。次期Mac製品ラインナップに関係しているのかもしれません。ということで、macOS 12.1でサポートされるRadeon RX 6000シリーズは

Radeon RX 6900XT
Radeon RX 6800XT, 6800
Radeon RX 6600XT (6600無印も対応可能？)

ということになりそうです。

12.0と12.1のkext比較

グラフィックスドライバーは、/System/Library/Extensions にあると思われます。macOS 12.0とmacOS 12.1で、それらしい名前のファイルを探してみたところ、そのどちらにも、AMDRadeonX6000という名前で始まる.kextファイルが3個、同じく.bundleファイルが3個ありました。

内部的にはこれらはディレクトリです。その中のContents/Info.plistを比較したところ、.bundle/Contents/Info.plistの中身は、バージョンの記述の違いだけでした。一方で、.kext/Contents/Info.plistの中身には違いがありました。このため、6600XT対応のために内容が更新されたのは、以下の3個の.kextファイルだと思われます。

AMDRadeonX6000.kext
AMDRadeonX6000Framebuffer.kext
AMDRadeonX6000HWServices.kext

AMDRadeonX6000.kext

12.0と12.1でAMDRadeonX6000.kextのInfo.plistを比較すると、以下の行を含む内容が追加されていました。6600XTに搭載されたNavi 23のために対応した部分と思われます。

<key>AMDNavi23GraphicsAccelerator</key>
（略）
<key>IOClass</key>
<string>AMDRadeonX6000_AMDNavi23GraphicsAccelerator</string>

AMDRadeonX6000Framebuffer.kext

こちらにのInfo.plistも比較したところ、12.1版には、Navi23に対応して追加されたフレームバッファと思われる情報が書かれていました。

AMDRadeonX6000HWServices.kext

このContents/Info.plistの中に、IOPCIMatchというキーがあります。12.0の内容が以下だったのに対して、

<string>0x73101002 0x73121002 0x73181002 0x73191002 0x731A1002 0x731B1002 0x731F1002 0x73401002 0x73411002 0x73431002 0x73471002 0x734F1002 0x73601002 0x73A21002 0x73AB1002 0x73BF1002 0x73A31002</string>

12.1では以下のように変更されていました。

<string>0x73101002 0x73121002 0x73181002 0x73191002 0x731A1002 0x731B1002 0x731F1002 0x73401002 0x73411002 0x73431002 0x73471002 0x734F1002 0x73601002 0x73A21002 0x73AB1002 0x73BF1002 0x73A31002 0x73E31002 0x73FF1002</string>

これは、対応デバイスの情報だと思われます。8桁の16進数のうち、下4桁がベンダーIDで、1002はAMDのvendor IDです。上4桁がdevice IDです。

0x73E31002
0x73FF1002

の2機種が追加されています。実際の商品とデバイスIDの組み合わせのしっかりした情報は見つけられなかったですが、巷の情報では、以下の対応だそうです。

73E3: Radeon Pro W6600
73FF: RX 6600, 6600M, & 6600 XT

6600無印には対応している可能性があります。

MontereyのUSBインストーラを作ってクリーンインストール

Tue, 26 Oct 2021 12:20:35 +0900

macOS Monterey 12.0.1が配布されたので、Big Surからアップデートしました。最新版のOpenCore (0.7.4) とkext類でBig Surが動いていれば、通常の作業でアップデートできるようです。ここではクリーンインストールしました。

作業に使ったシステム構成

本日 (日本時間2021/10/26)、macOS Monterey 12.0.1 が正式配布されました。Big Surが配布されたのは去年11月13日でしたのでそれより早く、過去のスケジュールに少し戻りました。Big Surの最初のバージョンが11.0.1だったのと同様、Montereyも12.0.1が最初の配布バージョンになりました。インストール先のマシンは、以下で、Z590マザーボードに10900Kを搭載しています。グラフィックスはRadeon RX 5700XTです。ブートローダはOpenCore 0.7.4でkext類は最新にしてあります。

ASRock Z590マザーボードでmacOSを起動する

現在インストールされているmacOSはBig Sur 11.6 (20G165)です。起動ドライブはWDの1TB M.2 SSD, WDS100T2B0Cです。

アップデートの手順

上書きインストールすれば楽なのですが、せっかくの年に一度のメジャーアップデートです。現在のBig Sur起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは別ドライブに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはならないと考えました。そこで次の手順でアップデートを進めます。

Montereyインストーラをダウンロードする
USBメモリを用意してMontereyインストールUSBを作る
USBメモリのESPに現在のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、M.2 SSDを消去する
インストーラからMontereyをインストールする

1. Montereyインストーラをダウンロード

Big Surの環境から、「システム環境設定」「ソフトウェアアップデート」を開いて、Montereyをダウンロードします。12.13GBあるようです。

ちなみに、「ほかにもアップデートがあります。」の表示が出ています。これをクリックすると11.6.1が来ていました。Montereyをすぐインストールしないという人も、こちらは入れておいた方が良いと思いました。

ダウンロードするといつものように自動的にインストーラが開きます。ここで「続ける」ボタンを押せば上書きインストールが開始します。今回は、クリーンインストールするので、メニューバーから「インストーラを終了」を選び中断します。

2. MontereyインストールUSBを作る

インストーラ用のUSBメモリを用意します。必要な容量は15GB程度ですが、USBメモリの容量は多分32GBはあった方が良いです。今回は32GBのUSB 3.0メモリーを用意しました。このUSBメモリーをディスクユーティリティ.appを使って初期化します。USBメモリを選択して、消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここでAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。Mac OS拡張（ジャーナリング）を選んでおく必要があります。

次に、MontereyインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもMontereyをインストールできるUSBメモリになります。ターミナルを使用して、Montereyインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。

$ cd /Applications/Install\ macOS\ Monterey.app/Contents/Resources/
% sudo ./createinstallmedia --volume /Volumes/USB/
Password: Ready to start. 
To continue we need to erase the volume at /Volumes/USB. 
If you wish to continue type (Y) then press return: y 
Erasing disk: 0%... 10%... 20%... 30%... 100% 
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100% 
Making disk bootable... 
Copying boot files... 
Install media now available at "/Volumes/Install macOS Monterey"

3. USBメモリのESPに現用のESPをコピーする

こうして作成したインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ&ドロップすれば良いです。この先、M.2 SSDは消去しますので、他にも必要なデータがありましたらバックアップしておきます。

4. USBメモリーからインストーラを起動する

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにMontereyインストーラが見えるはずです。

ただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security Properties, ScanPolicyのデフォルト設定が原因です。これのデフォルト値は、0x010F0103 (10進数では17760515) です。この設定だと、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。

まず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。
また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。

なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はPlistEDPlusを使って変更している様子です。

これで起動項目にUSBメモリのインストーラが現れるようになります。Montereyアイコンのボリュームが、USBメモリーです。このInstall macOS Montereyを選択して起動します。

5. インストール先ボリュームを消去する

USBメモリから起動すると、下のようなメニューが現れます。

ここでディスクユーティリティを選んで、インストール先M.2 SSDを綺麗さっぱりフォーマットしました。インストール先のAPFSボリュームグループを選択し、名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。

6. Montereyをインストールする

Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Montereyインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。

この後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

次にリンゴマークと棒グラフの表示が出ます。

この後多分5~6分くらいで、また再起動しました。またmacOS Installerが選択されてます。

そして数分でまたまた再起動。今度は、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。

インストール終了したあと、このMacについてを確認すると、バージョンは12.0.1 (21A559) でした。リリース候補(RC)と同じビルドでした。

これでM.2 SSDから起動します。上の手順では、APFSボリュームグループをフォーマットしてたのでESPの内容は無事でした。ドライブ全体をフォーマットするとESPの内容も消えてしまいます。その場合は、USBメモリのESPの内容を、M.2 SSDの方に書き戻しておきます。

まとめ

OpenCoreで起動しているZ590マシンにMontereyをクリーンインストールしました。そのために、単体で起動してMontereyがインストールできるUSBメモリを作りました。いつものようにベータ版で予行演習していたこともありますが、スムーズにMontereyに移行できました。

OpenCore 0.7.3から0.7.4に更新

Sat, 09 Oct 2021 23:46:31 +0900

OpenCoreの0.7.4が公開されたので0.7.3からアップデートしました。大きな変更は無いので、0.7.3のconfig.plistがそのまま動くと思います。

0.7.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.4とmacOS 11.6で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。macOS 12 public beta (21A5543b) でも動作しました。

ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.6

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目に変更はありませんでした。ただし、

Misc/Security/SecureBootModelの設定をDefaultに変更しました。T2チップが乗っていないhackintoshでは、x86legacyに設定するのが良いというニュアンスの表現が、前バージョンの説明書に書いてありました。これに対して、今回のバージョンでは、macOS 12以降は機種に合わせた方が良いという追記がありました。DefaultにしておくとSMBIOSのボードIDの記述に合わせて設定してくれるそうです。（以前のバージョンではDefaultにしておくとx86legacyになってました）いずれにしてもDefaultにしておくのが良いようなので、そうしておきました。SMBIOSがしっかり設定できていないようならば、ここで機種を指定した方が良いかもしれません。

これで、0.7.3から0.7.4に移行できました。

HPの小型デスクトップEliteDesk (7: Windows 11を入れる)

Sat, 09 Oct 2021 16:53:58 +0900

Montereyがなかなか出ないので、Windows 11で遊びました。10で動いているHP EliteDesk 800 G2 DM (Core i5-6500T) を11にアップデートしました。CPUは11に非対応ですが、インストール用USBメモリを作ったらインストールできました。各種設定は、Windowsに慣れていないこともあっていつもながら大変でした。10から11で変わってさらに面倒になったところもありました。

Windows 11がインストールできない

HP EliteDesk 800 G2 DMは、macOSではiGPUが動作しなくて挫折して、Windows 10を入れていました。それでMacからはRemote DesktopでWindowsを使ったり、WSL機能で動かすUbuntuにsshしたりして使っていました。このマシンをWindows 11にアップデートして、設定をやり直しました。

このマシンは、普通のアップデートではWindows 11がインストールできません。CPUが非サポートの第6世代なので致し方ないことです。本来ならばサポート対象の第8世代以降のCPUが必要です。でも、USBメモリーにWindows 11のインストーラを作れば可能でした。インストーラ作りは、Windows 10の環境で作業しました。USBメモリは8GBあれば良いようです。

このUSBメモリで起動すると、Windowsインストーラが動きます。インストーラのメニューには、過去の設定を引き継いでアップデートする選択肢もありましたが、選択できませんでした。クリーンインストールしなければならないようです。これで特に問題なくWindows 11が動くようになりました。

以前、Windows 10を設定した時の様子を紹介しました。

HPの小型デスクトップEliteDesk (6: Windowsを入れる)

今回もこれに従って、11での各種設定をしていこうと考えました。ただ、色々細かいところが10とは違っていて、少し苦労しました。

WSL2が動かない

WindowsはmacOSと違って、UNIX的な機能や操作が使えなくて残念です。でもWSL (Windows Subsystem for Linux) を使えばLinux機能が動きます。WSLは、LinuxとWindowsが連携できるように結構頑張って作られています。ただ、ファイルシステムもコマンド体系も違うので、macOSのターミナル操作とGUI操作のような一体感は望めないです。

今まではWSLを使っていたのですが、Windows 11にしたことで、WSL2に移行することになります。WSL2になって、LinuxとWindowsがより統合されたのかと期待したのですが、どちらかというと溝が深まった印象でした。インストールの手間も少し増えました。

Windows 10でWSLを有効にしてUbuntuを起動するための準備作業は、かなりシンプルでした。

「コントロールパネル – プログラム – Windowsの機能の有効化または無効化」から「Linux用Windowsサブシステム」にチェックする
Microsoft StoreからUbuntu 20.04 LTSをダウンロードして起動する

この2ステップだけでした。今回も同様の作業をしてWSLを起動したところ、以下のように

WslRegisterDistribution failed with error: 0x800701bc
????? 0x800701bc WSL 2 ??????? ????? https://aka.ms/wsl2kernel

謎の文字化けエラーメッセージが出ます。???の部分は正確では無いです。日本語でエラーを出しているけど、表示に失敗しているようです。読める英語部分の文言で検索したところ、「https://aka.ms/wsl2kernelに行ってカーネルコンポーネントを更新しなさい」というエラーのようです。最新の（WSL2 Linux カーネル更新プログラム）パッケージをダウンロードします。後で分かったのですが、StoreにあるUbuntuはWSL用のもので、WSL2では動かないので、WSL2に対応したカーネルパッケージが必要なようです。

これを解決すると、次には、仮想マシンの機能を有効にしなさいというようなエラーメッセージが出ます。Windowsの機能の有効化または無効化の項目の2つ上に見えているHyper-Vの設定のことのようです。以前は、以下のように無効でも問題なく動いていました。

これを有効にしたところ、WSL2でUbuntuが無事起動しました。これも後で知ったのですが、WSL2からはLinuxがHyper-Vの仮想環境で動作するよう変更になったようです。

SSHサーバが動かない

Ubuntuには最初からsshサーバが入っています。通常のUbuntuならば、sshサーバを以下のコマンドで起動することができます。

sudo service ssh start

WSLの時はこのコマンドで、他のマシン、例えばMacからWindowsマシンのIPアドレスを指定して、WSLのUbuntuにssh接続できました。WSL2ではこれができませんでした。Ubuntuと、同じコンピュータ上のWindowsからも localhostにはssh接続できますが、WindowsマシンのIPアドレスを指定すると接続できません。

Ubuntuでifconfigすると、eth0に見慣れないIPアドレスが設定されています。WSLではWindowsのIPアドレスがそのままLinuxに設定されていたのですが、WSL2では仮想のアドレスが割り当てられるようになったそうです。なので、外部のマシンからWindowsのIPアドレスを指定してもWSLのLinux環境に接続できません。

WSL2になってから、Linuxは仮想環境で動くようになり、Windowsとは別のIPアドレスが割り当てられるようになったのが、原因のようです。

https://atmarkit.itmedia.co.jp/ait/articles/1909/09/news020.html より引用

Linuxカーネルにも仮想環境に対応したパッチが当てられているようです。上記で、Hyper-Vが必須になったり、Ubuntuのカーネルを差し替える必要があったのも、これが理由のようです。

https://atmarkit.itmedia.co.jp/ait/articles/1906/14/news019.html より引用

素人の見解なので的外れなのかもしれませんが、VMwareとかVirtualBoxなどの仮想化ソフトウェア製品やDockerなんかと代わり映えしない気がしてしまいました。Linux環境がもっとWindowsにガチガチに絡みついて、よりシームレスに一体化して欲しかった気がします。

話を戻しますと、外部からssh接続できない問題は、WindowsマシンのIPアドレスを指定しても、WSL2のLinux環境に接続できないことでした。WSL2は独立した仮想のネットワークに接続されているからです。さらに厄介なことに、WSL2がLinuxに割り当てるアドレスは、起動するたびに変化するらしいです。

色々検索したところ、解決策はあるようでした。以下で紹介されていました。Windows側から、Ubuntu側にポートフォワーディングする設定です。これで、sshの22番のアクセスが来たら、Ubuntuのアドレスの22番に送ります。

wsl2でsshサーバを起動し、外部からそこに接続 - Qiita

まずは、Ubuntu側に、自分のIPアドレスを取得して、Windows側のポートフォワード機能に登録するスクリプトを書きます。ホームディレクトリに適当な名前をつけて保存します。

#!/bin/bash

IP=`hostname -I`

netsh.exe interface portproxy delete v4tov4 listenport=22
netsh.exe interface portproxy add v4tov4 listenport=22 connectaddress=$IP

sc.exe config iphlpsvc start=auto
sc.exe start iphlpsvc

hostnameコマンドからIPアドレスを取得して変数IPに入れて、それを使ってWindowsのnetshとscコマンドで設定しています。次に、このファイル（例えば /home/bootmacos/port_f22.sh ）を、Windowsから起動するバッチファイルを書きます。ついでにsshdを起動しておく記述も加えておきます。

@echo off
WSL -u root -- service ssh start
WSL --exec /home/bootmacos/port_f22.sh

そして、Windowsを起動したときに、このバッチファイルが管理者として実行されるように設定します。コントロールパネル–>システムとセキュリティ–>Windowsツール–>タスクスケジューラに行き、ここで「スタートアップ時（システム起動時）に」「ログインしているかどうかにかかわらず実行する」設定で、バッチファイルを登録します。結構ややこしいです。Windows 10では「管理ツール」という名前だったのが11では「Windowsツール」に名前が変わっていたりしました。

これにより以下のように処理が行われます。

Windowsが起動するとバッチファイルが動く
バッチの中で、Linuxコマンドでsshdを起動する
バッチの中で、Linuxのシェルスクリプトを起動する
シェルスクリプトの中でIPアドレスを取得してWindowsコマンドでポートフォワードを設定する

となります。WindowsとLinuxを行ったり来たりしてややこしいです。参考にしたサイトでは、全部の作業をWindowsバッチファイルで行う方法も紹介されていましたが、試したところ動作が不安定でした。

sshdが起動するように設定するには、Linuxならコマンドひとつ、macOSだと「システム環境設定」「共有」で「リモートログイン」をクリックするだけです。sshdの設定は、WSLでも結構面倒だったのですが、WSL2ではさらに大変でした。でもこれで、今まで通り、電源を入れるだけで、ssh経由でUbuntuに接続できるようになりました。

Wake On LANが動かない

WOLの設定も、いつもながらややこしいです。でもこれは10の時から変更点はありませんでした。

このマシンには、IntelのI219-LMというネットワークアダプター(NIC)チップが使われています。Windows 11には標準でNICのドライバが入っているのですが、この標準ドライバではWOLが動作しません。IntelやHPのサイトからダウンロードしたドライバならWOL可能です。このことをすっかり忘れて、ネットを検索して試行錯誤してしまいました。最初から、自分の書いた記事をちゃんと読めば良かったです。

WOLに対応するドライバを探すために、チップセット名などで検索しました。そして以下のIntelのサイトからドライバをダウンロードしました。

Windows® 10 用インテル®・ネットワーク・アダプター・ドライバー

Windowsのデバイスマネージャからこのドライバを入れようとすると、「すでに最新ドライバが入ってます」と言われてインストールできませんでした。ダウンロードした一式に入っているインストーラでインストールしました。

この結果、デバイスマネージャの設定でWOLを有効できるようになります。以下のスクリーンショットでは、Wake On Magic Packetが有効になるように設定しています。このほか「電源の管理」タブでもWOL関連の設定がありますが、多分デフォルトでokです。

BIOSにもWOLに関係する設定があります。こちらは、既に設定済みなので、今回は作業不要でした。

以前、Homebridgeを導入したのですが、

HomebridgeにはWOLによりコンピュータ機器の電源を投入するプラグインがいくつか公開されています。その中から、Homebridge Wolというプラグインを使ってます。

GitHub - AlexGustafsson/homebridge-wol: A Wake on Lan plugin for Homebridge

これにより、HomeKitからWindowsマシンの電源を投入し、On/Offの状態を確認できました。下はMacのホーム.appの画面です。Siriにお願いしてWindowsの電源を入れることも可能です。

BIOSもアップデート

ついでにBIOSもアップデートしておきました。HP EliteDesk 800 G2 DMのBIOS画面に、ネットワークから最新BIOSをダウンロードして更新するメニューがあります。クリックするだけで最新版 (2021/4/16版のN21 02.53) になりました。

まとめ

暗黒画面問題で頓挫したHP EliteDeskは、とうとうWindows 11マシンになりました。10より画面が洗練されて、良くなった気がします。引き続き、このマシンにはディスプレイを接続せず、macOSからMicrosoft Remote Desktopとssh経由で使用する予定です。

BIG SUR 11.6にアップデートする

Tue, 14 Sep 2021 23:11:29 +0900

macOS Big Sur 11.6が配布されたので11.5.2からアップデートしました。通常の方法で、問題なくアップデートできました。アップデートしたのはZ590マザーボードのマシンです。OpenCore 0.7.3で起動していて、kext類は最新です。Montereyがまもなくリリースされると思われますので、これがBig Sur最終版になるのかもしれません。過去のアップデート情報は以下にあります（現時点では11.6の解説はありません）。

https://support.apple.com/ja-jp/HT211896

iMac20,1に設定してあるZ590マシンでは、11.5.2のシステム環境設定の「ソフトウェア・アップデート」に、11.6のアップデートがあらわれていました。「詳しい情報…」をクリックすると、簡単に「macOSのセキュリティが向上します」と説明されてます。

この画面から「今すぐインストール」ボタンを押してアップデートしました。その結果、2.64GBのアップデートファイルがダウンロードされ、複数回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.6が起動しました。ビルドは20G165になってました。

メインマシンをASRock Z590 Extremeに移行

Sun, 12 Sep 2021 22:32:01 +0900

ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けたマシンをメインマシンとして使うことにしました。そこで、今まで使っていたASUS Z390 ROG MAXIMUS XI HEROマザーボードと交換しました。

絶対動くはず

Z390 Coffee Lake-S Refreshで動かすmacOSは、とても安定していて全く問題ありませんでした。なのでZ590に移行する必要性はあまりありませんでした。単に、macOSが動く最後のインテルCPUになるかもしれないComet Lake-Sに移行したかっただけです。とはいえ、8コア16スレッドから10コア20スレッドになるのは、その性能が必要かどうかは別として、嬉しいところです。なので、Z590への移行を以前から計画してました。

移行のために、ASRock Z590 Extremeを検証台（いわゆる、まな板です）で動かして、動作確認してきました。こちらもZ390同様にとても堅牢で安定しています。数日起動し続けても問題ありません。Montereyベータ版も問題なく動作しているので、将来にわたって大丈夫そうです。

今回はいよいよ、検証台のASRock Z590 Extremeを取り外し、PCケースの中のZ390マザーボードと差し替えることにしました。どちらも快調に動いている構成のマザーボードを入れ替えるだけなので、問題は何もなく、すぐに絶対動くものだと思っていました。

一部のSATAが動かない

メインのマシンは、大型のタワーケースで、HDDやSSDをたくさん搭載しています。TimeMachineのバックアップ用大容量HDDや、Windows起動用のSSDなどです。光学ドライブも搭載してます。リムーバブルHDD/SSD用の5.25インチベイも取り付けてます。ASRock Z590 Extremeは、今時のマザーボードとしては珍しくSATAが6ポートあります。今までのASUS MAXIMUS XIと同じ数なので、移行は楽勝のはずでした。でも、6個のうち2個が動きません。

ちゃんとマニュアルを読んでおけばよかったのですが、ASRock Z590 Extremeマザーボードは、3番目のM.2ソケットを使うと、SATAの2個が使えなくなる仕様でした。M.2とSATAに排他的な制約があるのはなんとなく理解してましたが、SATA M.2 SSDを使った場合だけの制約だと勝手に解釈してました。PCIe接続のM.2 SSDを使用した場合でも、2個のSATAが使えなくなるようです。

ということで、M.2 SSDを2番目の（マザーボード中心の）ソケットに移動しました。今の所M.2 SSDは一個しか使ってないのでこれで良いですが、多数のM.2 SSDを使用する場合には、足りないSATAをPCIeカードで拡張しようと思います。

起動が遅い

マザーボードを入れ替えてすぐに気づいた問題は、新しいASRockマザーボードの起動に時間がかかることです。電源を入れるとASRockのロゴが瞬時に出るのですが、その状態が続き、1分くらいかかってOpenCoreの選択画面が表示されます。F2キーでBIOSメニューに入る場合も、同じだけの時間がかかります。この状況から見て、macOSの問題でも、OpenCoreの問題でもなく、ハードウェアかUEFIの問題と思われます。ASRockのロゴを出さないよう設定すると、起動進捗のコードが画面右下に表示されるのですが、この情報からは原因を推測できませんでした。

このマザーボードを検証台で動かしていた時には、起動に時間がかかる問題はありませんでした。PCケースへの引っ越しで新たに追加されたハードウェアが原因と思われます。起動時に少し待てば良いので、我慢できなくはないのですが、OpenCoreやkextの設定を試行錯誤して試す場合には、効率が悪いです。そこで一つ一つ外して起動の様子を観察することにしました。

SATAドライブ

まずはSATA接続のSSD/HDDを全て外しました。HDDの調子が悪くなると、起動時のチェックに問題が出て、時間がかかることがあるそうです。全部外して、検証台での動作と同じくM.2 SSDだけで起動しても、やはり起動時間が長いままでした。原因は他にあるようです。

メモリー

メモリーに問題がある場合もあるようです。でも今回は、検証台で使っていたメモリーをそのまま持ってきたので問題ないはずです。

USBデバイス

次に、USB関係を外しました。以下で紹介した5.25インチベイ取り付けのUSBハブ／カードリーダなどを取り付けてました。でもUSB関係の部品を外しても変化はありませんでした。

USB機器がスリープを阻害することがあります

PCIe拡張カード

今度はPCIeスロットに挿した拡張カード類です。無線カードは以下で紹介したように、BCM94360NGをM.2 key Eソケットに取り付けていて、PCIeスロットは使ってません。マザーボードに取り付けたまま持ってきたのでこれは問題ないはずです。

ASRock Z590 Extremeに無線モジュールを取り付ける

Thunderbolt 4カードも取り付けてます。これも検証台の時から使っていたので問題ないはずです。一応取り外しましたが、起動時間に変化はありませんでした。

macOS で Thunderbolt 4 を使う

引っ越しで追加になったカードは、IEEE 1394カードと、

IEEE 1394 (FireWire) を使う

SATA拡張カードです。

PCIe拡張カードでSATAを増設する

IEEE 1394は、全く使ってないのですが、大昔のiPodやSONYのビデオカメラが動いて面白いのでそのまま取り付けてます。古いカードなので怪しかったですが、取り外してみても変化ありませんでした。

SATA拡張カードが原因

最後にSATA拡張カードを取り外したところ、なんと、一瞬で起動するようになりました。上記の記事では紹介していませんでしたが、実は、HighPoint社の Rocket 640LというSATA拡張カードを取り付けていました。macOSの /Library/Extensions には、HighPoint関係のドライバーが入っているので、macOS標準で動作します。これが問題を起こして、起動に時間がかかっているようです。検索すると、価格コムのレビューが見つかりました。UEFIに対応してなくて、現行のマザーボードとの相性が悪いようです。Z390マザーボードの時は、起動時間の問題は発生しませんでしたが、これに接続したリムーバブルベイに取り付けたHDD/SSDから起動できなかったです。そこで、上記の記事でも紹介したASMedia ASM1061搭載の格安SATA拡張カードに差し替えたところ、問題なく起動しました。このカードもmacOS標準のままで動作します。

まとめ

起動時間が異様に長くなる現象は、自作PCではよくあるトラブルのようです。今回は使用していたPCIeカードが古かったのが原因でした。最小構成になるまで、一つ一つ部品を取り外して動作チェックする定番の方法で原因究明できました。

OpenCore 0.7.2から0.7.3に更新

Fri, 10 Sep 2021 18:01:51 +0900

OpenCoreの0.7.3が公開されたので0.7.2からアップデートしました。config.plistのUEFI/Driversの書き方が変更になったので対応が必要です。それ以外には大きな変更は無いので、0.7.2のconfig.plistがそのまま動くと思います。

0.7.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.3とmacOS 11.5.2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.5.2

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は、以下の2箇所でした。

UEFI/QuirksにForceOcWriteFlashという項目が追加されてました。OpenCoreのシステム変数をフラッシュメモリに書き込めるようにするようです。ThinkPad T430やT530で複数OSを起動する場合などに必要な設定のようです。関係なさそうなので、Default値のfalseにしておきました。
UEFI/Driversの書き方が変更になってました。Driversの中身は配列で、その要素はItem1, Item2, Item3 …という名前です。0.7.2以前はItem1などはstring型で、そこにOpenRuntime.efiとかOpenCanopy.efiとファイル名を書いていました。0.7.3からは、Item1などがdict型になり、Path (string型), Enabled (bool型), Arguments (string型)を書くことになりました。引数が書けるようになったようです。移行するには、Pathに従来通りのefiファイル名を書き、Enabledにtrueを設定すれば良いです。

下は0.7.2以前のUEFI/Driversの書き方です。

0.7.3からは以下のように変更になりました。

これで、0.7.2から0.7.3に移行できました。

BIG SUR 11.5.2にアップデートする

Tue, 17 Aug 2021 22:38:52 +0900

macOS Big Sur 11.5.2が配布されたので11.5.1からアップデートしました。通常の方法で、問題なくアップデートできました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.7.2で起動していて、kext類は最新です。11.5.2が配布されたのは、8月11日(PST)です。

https://support.apple.com/ja-jp/HT211896

更新内容は、簡単に「Macのバグ修正が含まれている」と説明されてます。

iMac20,1に設定してあるZ590マシンでは、11.5.1のシステム環境設定の「ソフトウェア・アップデート」に、11.5.2のアップデートがあらわれていました。そこから「今すぐインストール」ボタンを押してアップデートしました。その結果、2.54GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.5.2が起動しました。ビルドは20G95になってました。

iMac19,1に設定してあるZ390マシンには、システム環境設定には11.5.2のアップデートが現れていませんでした。11.5.1の時と同様で、Monterey betaを受け取るためにApple Beta Software Programに登録してある影響と思われます。今回も、App StoreからBig Surを選択したところ、11.5.2へのアップデートが来ました。この場合、フルサイズのOSがダウンロードされるようで、サイズが12.44GBありました。

OpenCore 0.7.1から0.7.2に更新

Wed, 04 Aug 2021 23:50:15 +0900

OpenCoreの0.7.2が公開されたので0.7.1からアップデートしました。大きな変更は無いです。Montereyの起動で問題になっていたSecure Boot modelのデフォルト設定が変更されて、Monterey起動に対応したようです。新OS対応が進捗している様子です。

0.7.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.2とmacOS 11.5.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.5.1
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.5.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は、以下の1箇所だけでした。

UEFI/AppleInputにGraphicsInputMirroringという項目が追加されていました。非Apple製のグラフィックUEFIアプリケーションにキーストロークが伝わらないことを改善したようです。例えば、WindowsのBitLockerを使う場合に影響が出るそうです。デフォルト値はfalseですが、説明書によるとtrueが推奨値らしいです。Sample.plistでもtrueになってました。macOSを使う限りはfalseでも問題なさそうですが、とりあえず推奨値のtrueに設定しておきました。

これで、0.7.1から0.7.2に移行できました。

SecureBootModelの設定

設定できる値

Apple Secure Bootの機能では、macOSを動かすMacのモデルでは無効な設定や、動かないmacOSバージョンのインストールを防ぐ働きをするようです。config.plistのMisc, Securityの中の SecureBootModelで、Macのモデル名の設定をします。ここで設定できる値は、OpenCoreのマニュアルによると以下です。

Default — Recent available model, currently set to x86legacy.
Disabled — No model, Secure Boot will be disabled.
j137 — iMacPro1,1 (December 2017). Minimum macOS 10.13.2 (17C2111)
j680 — MacBookPro15,1 (July 2018). Minimum macOS 10.13.6 (17G2112)
j132 — MacBookPro15,2 (July 2018). Minimum macOS 10.13.6 (17G2112)
j174 — Macmini8,1 (October 2018). Minimum macOS 10.14 (18A2063)
j140k — MacBookAir8,1 (October 2018). Minimum macOS 10.14.1 (18B2084)
j780 — MacBookPro15,3 (May 2019). Minimum macOS 10.14.5 (18F132)
j213 — MacBookPro15,4 (July 2019). Minimum macOS 10.14.5 (18F2058)
j140a — MacBookAir8,2 (July 2019). Minimum macOS 10.14.5 (18F2058)
j152f — MacBookPro16,1 (November 2019). Minimum macOS 10.15.1 (19B2093)
j160 — MacPro7,1 (December 2019). Minimum macOS 10.15.1 (19B88)
j230k — MacBookAir9,1 (March 2020). Minimum macOS 10.15.3 (19D2064)
j214k — MacBookPro16,2 (May 2020). Minimum macOS 10.15.4 (19E2269)
j223 — MacBookPro16,3 (May 2020). Minimum macOS 10.15.4 (19E2265)
j215 — MacBookPro16,4 (June 2020). Minimum macOS 10.15.5 (19F96)
j185 — iMac20,1 (August 2020). Minimum macOS 10.15.6 (19G2005)
j185f — iMac20,2 (August 2020). Minimum macOS 10.15.6 (19G2005)
x86legacy — Macs without T2 chip and VMs. Minimum macOS 11.0.1 (20B29)

このうちx86legacyはT2チップを搭載していないMacのための選択肢です。一方、jで始まる選択肢は、T2チップを搭載したMacに対応してます。以下のMacが該当します。

Apple T2 セキュリティチップ搭載モデルの Mac

自作PCには当然ながらT2チップを搭載していないので、x86legacyの設定が良さそうです。ただし、x86legacyに設定するとmacOS 11.0.1以降のみしか起動しません。古いmacOSを使いたい場合は、SystemProductNameで設定したモデル名がT2搭載ならば、jから始まる選択肢を設定しても良いかと思います。11.0.1より古いmacOSをT2未搭載モデルで使いたい場合は、SecureBootModelをDisabledに設定すると良いです。DisabledにするとApple Secure Boot自体が無効になります。

SecureBootModelをDefaultにすると、一番無難な選択肢を選んでくれるようです。OpenCore 0.7.1では、Defaultにするとj137、すなわちiMacPro1,1に設定されていました。OpenCore 0.7.2では、Defaultにするとx86legacyに設定されるよう変更されました。

Montereyインストールの注意事項

OpenCore 0.7.1でMontereyのパブリックベータ版をインストールする際には、config.plistのSecureBootModelをDisabledに設定する必要がありました。SecureBootModelをT2チップ搭載Macに設定すると、インストール途中で起動を繰り返す状態になり、先に進みません。インストールが終了した後ならば、T2チップ搭載Macとして設定しても起動するようです。0.7.1でDefaultと設定すると（iMacPro1,1と設定され）インストール途中で再起動が繰り返され、先に進まなくなりました。0.7.2ではx86legacyに設定されたため、Defaultの設定でもインストール可能になりました。Defaultではなく、x86legacyに設定しても同じことなのでMontereyのインストールは可能です。おそらくは0.7.1でもx86legacyに設定すればMontereyのインストールが可能だったのではと思います。

Z590とZ390の設定

iMac20,1に設定してあるASRock Z590 Extreme + 10900Kマシンは、機種名に合わせて j185に設定してみました。j185に設定すると、Montereyのインストールは失敗しますが、インストールされたMontereyは起動します。なのでMontereyをインストールするときだけはx86legacyに設定する必要があります。

iMac19,1に設定してあるもう一台のZ390マシンは、T2チップ未搭載なのでDefaultにしておきました。現行のmacOSしか使わない予定なのもDefaultにした理由です。もしもこのマシンでmacOS 11.0.1より前のmacOSを起動したい場合は、Disabledに設定する必要があると思います。

macOS Monterey 12 Beta をインストール

Mon, 02 Aug 2021 23:14:54 +0900

Public Beta Programで配布されているmacOS Monterey 12.0 Beta（21A5294g）をダウンロードして、ASRock Z590 + 10900K + OpenCore 0.7.1で構成した自作PCにインストールしました。config.plistでSecureBootModelを無効に設定する必要がありました。新機能のAirPlayレシーバーが動作することを確認しました。

ダウンロード

Big Surを動かしているZ590マシンをPublic Beta Programに登録したところ、システム環境設定のソフトウェアアップデートにMontereyが現れました。サイズは11.73GBでした。

1時間弱でダウンロードは終了し、ダウンロード後にインストーラが起動します。それは中断します。するとApplicationフォルダにInstall macOS Monterey beta.app（日本語名はmacOS Montereyベータ版インストール.app）というアプリケーションができています。

インストール用USBメモリを作る

次に32GB容量のUSBメモリを用意しました。これをGUID, Mac OS拡張（ジャーナリング）でフォーマットし、ここではusbという名前をつけました。ターミナルでInstall macOS Monterey beta.appの場所にcdします。この中のContents/Resourcesの中に

% cd /Applications/Install\ macOS\ Monterey\ beta.app
% cd Contents/Resources/

お馴染みのcreateinstallmediaコマンドがあります。オプションなしで起動すると、ヘルプが表示されます。

% ./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsはファームウェア関係のファイルをダウンロードする機能のようです。無効にしたところ、後の工程で失敗したので、有効にした方が良いようです。

% sudo ./createinstallmedia --volume /Volumes/usb --downloadassets

とタイプします。これで用意したusbメモリが初期化されて、そこにMontereyのインストーラが作られます。

インストール

Montereyを試すために、今まで使用していたBig Sur用のM.2 SSDに加えて、250GBのM.2 SSDを新たに追加しました。BIOS起動は、引き続きBig Sur用SSDのESPから行いました。ESP内のOpenCoreとkext類などは最新にしてあります。最新のOpenCore 0.7.1はMontereyにかなり対応しているようです。config.plistの設定は、Big Surと同じです。上で作成したインストール用USBメモリを挿して起動すると、OpenCoreの起動選択画面にUSBメモリのインストーラが現れました。

これを選択すると無事、インストーラが起動しました。インストーラの中でディスクユーティリティを起動して、新しく取り付けたM.2 SSDをGUID, APFSでフォーマットしておきます。次に、インストーラでMontereyのインストールを進めます。いつものようにUSBメモリからの作業が終了すると、再起動し、次にインストール先のSSDから起動します。

SecureBootModelを無効にする

ここまでは順調だったのですが、インストール先SSDからの起動途中で失敗して、再起動されるようになってしまいました。何度も何度も再起動が繰り返されます。USBインストーラを使わない方法（11.5の環境からMontereyインストーラを起動してSSDにインストール）を試みても、やはり再起動で失敗します。それで暫くつまづいていました。でも、これはよく知られた症状のようで、このサイトのフォーラムでも解決方法が紹介されています。灯台下暗しでした。（kgraphさん、ありがとうございました）

macOS Monterey

Montereyのインストール途中で再起動が繰り返される問題は、config.plistのMisc, Securityの中の SecureBootModelの設定をDisabledにすれば良いようです。今まではDefaultに設定していました。これで無事インストールが進み、Montereyが起動しました。起動のセキュリティが仕様変更されたか、もしくは厳しくなったようです。

追記：SecureBootModelがDefaultでも起動が可能

OpenCore 0.7.2からはSecureBootModelの設定がDefaultでも起動可能になったようです。以下をご覧ください。

OpenCore 0.7.1から0.7.2に更新

AirPlayレシーバーが動く

Montereyの新機能にAirPlayレシーバーがあります。Montereyの英語ページで「AirPlay to Mac」という名前で紹介されている機能です。ちなみに日本語ページでは「MacにAirPlayを」です。これで他のApple製品から音楽や動画をMacで再生できます。今まで、HomePodやAppleTVでできていた機能が、Macでも可能になりました。

MontereyでAirPlayレシーバーを動かすためには、本物のMacやM1のセキュリティチップが必要なのではという推測もありましたが、自作PCでも動きました。おそらくは他のiOS連携機能と同じく、無線モジュールが純正に近い必要があるのかもしれません。試したマシンでは、BCM94360NGを使用してます。

ASRock Z590 Extremeに無線モジュールを取り付ける

Montereyの「システム環境設定」から、「共有」を選ぶと選択肢の中に「AirPlayレシーバー」が新たに現れています。これを選択して、一番緩い設定の「すべての人」にAirPlayを許可しました。ベータ版の利用規定の関係でスクリーンショットは省略します。

これでiPhoneなどから動画などをhackintoshに映し出すことが可能になりました。また、MacBookなどから接続すれば、外部ディスプレイのようにも設定できます。画面のミラーリングもできるし、2番目のサブスクリーンにもなります。ただし、コンテンツ保護には元々対応させていなかったので、Amazon Primeビデオなどは表示できませんでした。WhateverGreen.kextなどの設定を頑張ってコンテンツ保護に対応すれば対処できるのかもしれません。YouTube動画などは問題なく表示されました。

BIG SUR 11.5.1にアップデートする

Sat, 31 Jul 2021 17:46:24 +0900

macOS Big Sur 11.5と11.5.1が配布されたので、遅ればせながら11.4からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.7.1で起動していて、kext類は最新です。

更新内容

7月21日に11.5のアップデートが配布されて、7月26日に11.5.1が配布されています。

11.5は、PodCast、Music、M1関連のバグ対応で、

11.5.1はセキュリティ関連のアップデートのようです。

11.5.1へアップデート

iMac20,1に設定してあるZ590マシンでは、11.4のシステム環境設定の「ソフトウェア・アップデート」に、11.5.1のアップデートがあらわれていました。そこから「今すぐインストール」ボタンを押してアップデートしました。その結果、2.93GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.5.1が起動しました。ビルドは20G80になってました。

11.5へアップデート

iMac19,1に設定してあるZ390マシンでは、11.4のシステム環境設定の「ソフトウェア・アップデート」に、11.5のアップデートがあらわれていました。11.5.1は来ていないようです。そこから「今すぐインストール」ボタンを押してアップデートしたところ、1回の再起動でアップデートされました。放置しておいたら、Big Sur 11.5が起動しました。ビルドは20G71になってました。このマシンにも11.5.1へのアップデートがそのうちに来るのではと思ってます。

追記：11.5.1へのアップデート

Z390マシンのアップデートがなかなか来ないので、結局App StoreからBig Surを選択したところ、11.5.1へのアップデートが来ました。自動的に再起動して、問題なくアップデートできました。自動でアップデートが来なかったのは、Monterey betaを受け取るためにApple Beta Software Programに登録してある影響だったのかもしれません。

OpenCore 0.7.0から0.7.1に更新

Sun, 18 Jul 2021 22:23:10 +0900

OpenCoreの0.7.1が公開されたので0.7.0からアップデートしました。config.plistの変更点は2箇所のみで、OpenCanopy関連の変更もありませんでした。macOS Montereyへの対応が進んだようです。

0.7.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。更新点には、macOS Montereyに対応した項目が多くありました。新OSに向けて準備が進んでいる様子で楽しみです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.1とmacOS 11.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.4
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は以下でした。

ACPI/QuirksにSyncTableIdsという項目が追加されていました。古いWindowsのライセンス関係に影響するSLICテーブルの互換性に関する項目のようです。特に問題を感じていないので、デフォルトのままfalseにしておきました。
Kernel/SchemeにCustomKernelという項目が追加されていました。ESPにカスタマイズカーネルのキャッシュを作ってくれる機能のようです。AtomやAMDのCPUの場合に必要となる可能性があるようです。手元のマシンでは当てはまらないのでデフォルトのままfalseにしておきました。

これで、0.7.0から0.7.1に移行できました。

OpenCore 0.6.9から0.7.0に更新

Sun, 13 Jun 2021 23:16:31 +0900

OpenCoreの0.7.0が公開されたので0.6.9からアップデートしました。config.plistの大きな変更点はありませんでした。またOpenCanopyが動かなくなりましたので、EFIのOC/Resourcesの中身を、配布されているものに差し替えました。

0.7.0をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.0とmacOS 11.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.4
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は以下のようでした。

Kernel/QuirksにProvideCurrentCpuInfoという項目が追加されていました。kernelに現在のCPU情報を提供するというフラグです。Microsoft Hyper-Vのためのパッチだそうです。デフォルトのままfalseにしておきました。
Misc/SecurityにAllowToggleSipという項目が追加されていました。OpenCoreピッカー（起動時の選択メニュー）でSIPをon/offできるようにするかどうかの選択肢です。元々SIPを無効にすることをOpenCoreでは推奨していないので、必要な場合のみ、一時的に使って下さいという記述がありました。なのでデフォルトのままfalseにしておきました。
NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82にForceDisplayRotationInEFIという項目が追加されていました。EFIの表示を回転できるようです。デフォルトの0度にしておきました。
UEFI/OutputにGopPassThroughという項目があります。0.6.9ではbool型でfalseを設定していたのですが、0.7.0ではこれがstring型になってました。on/offの他に、Appleという選択肢が可能になったためstring型になったようです。Appleの場合は、AppleFramebufferInfoを有効にしたプロトコルで提供すると書いてありました。今まで問題なかったので、デフォルトのままのDisabledにしておきました。
UEFI/ProtocolOverridesにAppleEg2Infoという項目が追加されていました。Apple EFI Graphics 2プロトコルをビルトインのバージョンに入れ替えるという機能らしいです。EFI画面の回転に関係するようです。デフォルトのままfalseにしておきました。
Misc/BootにあるPickerVariantの指定方法が変更になった様です。詳細は後述します。デフォルト値は今までと同じくAutoなので、そのままで良いです。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.9から0.7.0に移行できました。

Pickerアイコン指定方法が変更

前節の変更で起動はできましたが、0.6.6や0.6.8の時のようにOpenCanopyが動かなくなり、起動時の選択メニュー (Pickerメニュー）が文字だけのメニューに戻ってしまいました。そこで以前と同じく、以下から、Resources/Image, Font, Labelを取り寄せて交換したところ、動くようになりました。

GitHub - acidanthera/OcBinaryData

上記からダウンロードしたファイルを確認すると、Resources/Imageの中身にさらにディレクトリのある構造になってます。以前は、Imagesの中に直接アイコンファイルが置かれていました。今回からは、ESPのOCフォルダーにも、配布されている形のディレクトリ構造を保ってコピーすれば良いようでした。

コメントで教えていただいて気づいたのですが、Pickerに表示するアイコンの指定方法が変更になった様です。これを指定するパラメータはconfig.plistのMisc/BootにあるPickerVariantです。0.6.9までは、この値（文字列です）は、

Auto (デフォルト) 背景色に合わせて適切なアイコンが自動選択される
Default 通常の名前のアイコンファイルが選択される
Old Oldで始まる名前のアイコンが選択される
Modern Modernで始まる名前のアイコンが選択される
（それ以外の値）カスタムアイコンとしてサポートされていれば指定できる

という規則でした。ファイル名の最初の文字で区別する方式です。例えばHDDのアイコンなら、PickerVariantにDefaultを指定するとHardDrive.icnsという名前のファイルが使用されますが、Modernを指定するとModernHardDrive.icnsという名前のファイルが使用されます。

これに対して、0.7.0では、上で説明したようにディレクトリで分類されるようになりました。アイコンファイルは66個くらいあるので、名前だけで区別するのは面倒ということだと思います。なので0.7.0のPickerVariantは、

Auto 背景に合わせて自動的に選択される。
Default Imageの中のAcidanthera\GoldenGateを選択する。
Acidanthera\GoldenGate Imageの中のこのディレクトリを選択する。macOS 11スタイルのアイコンセット。
Acidanthera\Syrah Imageの中のこのディレクトリを選択する。macOS 10.10スタイルのアイコンセット。
Acidanthera\Chardonnay Imageの中のこのディレクトリを選択する。スタイルのアイコンセット。

特にこだわりがなければ、今まで通り、デフォルト値のAutoを指定しておけば良いと思います。

UEFI ShellをBIOSから起動する

Wed, 02 Jun 2021 23:54:14 +0900

EFI System Partition (ESP)の中のconfig.plistやkext類を変更して、macOSが起動しなくなってしまうことがあります。そんな時のためにUEFI shellを使えるようにしておくと復旧作業に役立ちます。CloverやOpenCoreにはUEFI shellを起動する機能がありますが、BIOSメニューから起動する方法をまとめました。

UEFI Shellで復旧する（おさらい）

UEFI shellを使えば、OSが起動する前段階のUEFIが制御している状態で、ファイルシステムの中身を編集できます。なのでOSの起動に失敗している場合に、その状況を治せる可能性があります。ただしUEFIから読み書きできるファイルシステムに限定されるので、APFSやHFS+の中身は見ることも書き換えることもできません。でも、通常FAT32でフォーマットされるESPは編集可能です。ESPの中のconfig.plistやkext類を変更して起動しなくなってしまった場合は、UEFI shellで編集できるので、システムを復旧させることが可能です。UEFI shellについては、過去の記事でも紹介しました。

起動しないマシンをUEFI Shellで救う

この記事では、CloverまたはBIOSからUEFI shellを起動して、ESPを復旧する方法を説明しました。OpenCoreでも、EFI/OC/ToolsにOpenShell.efiを入れておき、config.plistでこれを認識するよう設定すれば、OpenCoreの起動メニューからUEFI shellを起動できます。この先は、以前の記事のダイジェストになりますが、基本的には

OpenCoreを入れたESPの場所を探して、
shellコマンドで編集する

という作業を行います。UEFI shellの使い方は、こちらのサイトの説明が簡潔でわかりやすかったです。

UEFI Shell のコマンド - 一寸先は/dev/null

UEFIから見えるボリュームは、fs0:, fs1:, fs2: …のように名前がついています。shellコマンドから

ls fs0:

などと入力すれば、この例ではfs0:のルート部分が見えます。この内容を見ながら、OpenCoreが使っているESPの場所を探して行きます。接続されたボリュームの数が少なければ、fs0:かfs1:くらいでOpenCoreのESPが見つかりますが、多い場合は探すのが大変です。そんな時に、mapコマンドが便利です。mapとタイプすると（またはmap -bとすれば画面に合わせて表示が停止します）、例えば以下のような表示がされます。長いので…で省略してます。

> map
Mapping table
FS0: Alias(s):HD0c0a0b:;BLK1:
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x2,0x0)/USB(0x0,0x0)/HD(1,MBR,...
FS1: Alias(s):HD1a65535a1:;BLK3:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,...
FS2: Alias(s):HD1a65535a2:;BLK4:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(2,GPT,...
FS3: Alias(s):HD1a65535a4:;BLK6:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(4,GPT,...
FS4: Alias(s):HD1a65535a5:;BLK7:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(5,GPT,...
FS5: Alias(s):HD1b65535a1:;BLK9:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT,...
FS6: Alias(s):HD1c65535a1:;BLK12:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x2,0xFFFF,0x0)/HD(1,GPT,...
FS7: Alias(s):HD1d65535a1:;BLK15:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x3,0xFFFF,0x0)/HD(1,GPT,...
FS8: Alias(s):HD2b:;BLK20:
PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,...)/HD(1,GPT,...
...

これを見れば、探すべきドライブの見当をつけることができます。接続方式がUSB, SATA, NVMeと分類されています。またパーティションマップが、MBRなのかGPTなのかもわかります。このマシンでは、NVMeにOpenCoreのESPを入れているので、fs8:が探しているボリュームだとわかります。その場合、

fs8:

とタイプしてそのボリュームに移動します。Windowsでcドライブやdドライブに移動する方法と同じです。次に、cdコマンドでOCのディレクトリに移動して、

cd EFI\OC

ここでls, cd, cp, mv, cp, rm, edit, type (Unixのcatに相当)コマンドを駆使して、ファイルを操作します。ディレクトリの区切りが、macOSやLinuxと違い、Windows風の逆スラッシュになってます。config.plistのバックアップがあってそれがもしconfig_old.plistという名前なら、

mv config_old.plist config.plist

コマンドで元に戻せます。config.plistを変更する場合には、このように確実に動くバージョンを残しておくと、簡単に元に戻せるので楽です。config.plistを編集したい場合は、

edit config.plist

でエディタを起動します。このエディタでは、コントロールEでヘルプが表示されます。操作は簡単で、

Ctrl-G 行に移動。行番号の入力を促される
Ctrl-S ファイルを保存する
Ctrl-Q 終了する
Ctrl-F 検索する
Ctrl-R 検索・置換する
Ctrl-K 行をカットする
Ctrl-U 行をペーストする
Ctrl-O ファイルを開く
Ctrl-T ASCIIとUNICODEの切り替え
Ctrl-E ヘルプを開く
Ctrl-W ヘルプを閉じる

です。これで大体の編集は可能なので、config.plistを元に戻すことができます。config.plistを保存し、エディタを終了した後で、

exit

もしくは

reset

コマンドをタイプしてシェルを抜けます。resetコマンドはシステムがリセットされます。exitコマンドでは、OpenCore選択画面に戻ります。大体はexitコマンドでokですが、変更内容によっては変更が反映されないことがあります。resetの方がより確実です。

USBメモリーから起動する

UEFI shellはCloverやOpenCoreの選択画面から起動するだけでなく、UEFI環境でshellを直接起動することもできます。UEFI shellはHackintoshのためのツールではありませんので、こちらが本来の使い方です。

通常のUEFIマザーボードの起動ステップでは、FAT32でフォーマットされたドライブの中にある、EFI/Boot/bootx64.efiというファイルを実行しているようです。実際に、OpenCoreのESPにもEFI/BOOT/BOOTx64.efiというファイルがあります。WindowsをインストールしたドライブのESPにも、EFI/Boot/bootx64.efiというファイルがありました。ディレクトリ名やファイル名の大文字小文字はどちらでも良いようです。UEFI shellのプログラムにbootx64.efiという名前をつけて、このディレクトリにおけば良いようです。

そこで、まずはUSBメモリをFAT32でフォーマットします。パーティションマップはMBRでもGPTでも良いようですが、今回は単純にMBRで試しました。次にこのUSBメモリに、EFI/Boot/というディレクトリを作ります。この中に、OpenCoreで配布されている一式に含まれるOpenShell.efiをコピーして、これをbootx64.efiという名前に改名します。OpenShell.efiは、OpenCoreの起動メニューから動かすために、通常はEFI/OC/Tools/の中に入れているファイルです。その結果、USBメモリには、

EFI/Boot/bootx64.efi

のような位置と名前で、OpenShell.efiが入ります。このUSBメモリを挿したままコンピュータを起動し、BIOSメニューに入ると、Boot選択の画面に、以下のようにUSBメモリが現れるはずです。

ここでは、

UEFI: JetFlashTrabscend 4GB 8.07, Partition 1 (4.0GB)

という名前で見えています。小さなサイズのUSB 2.0のUSBメモリを使いました。このボリュームを選択して起動すれば、UEFI shellが起動します。使い道のない古いUSBメモリですが、UEFI shellを入れておけばいざというときに役立ちます。

BIOSメニューから起動する

マザーボードのBIOSメニューに、UEFI shellを起動する機能が提供されていることがあります。マザーボードメーカによって、事情が異なるようです。最近の状況を調べてみました。

MSIマザーボードの場合

以前の記事ではMSIのマザーボードの例を書いていました。MSIのマザーボードでは、独自にUEFI shellのソフトウェアを用意しているようで、BIOSメニューから選択するとそのshellが起動しました。なので、CloverやOpenCoreで用意したshellとは違うバージョンのshellが起動しました。現行のMSIマザーボードが手元に無いので確認できませんが、MSIのZ590マザーボードのマニュアルを見る限りでは、Settings/Save & Exit/Boot Overrideのメニューに、UEFI: Built-in EFI Shellという選択肢が健在のようですので、

引き続き内蔵のshellが起動できるようです。

ASUSマザーボードの場合

Z390 ROG MAXIMUS XI HEROでは、Exitメニューの中に、Launch EFI Shell from USB drivesという項目があります。USBメモリーのルートにUEFI shellのプログラムを、Shell.efiという名前で入れておけば、ここから起動できます。これ以外の名前ではダメなようです。

ただし、BIOS設定でCSMをenabledにしてレガシー起動を可能にしておく必要があります。

Shell.efiを置く場所は、UEFIが見ることのできるボリュームのルートならどこでも良いようです。USBメモリがFAT32でフォーマットされているなら、そのルートで良いです。でもHFS+やAPFSはUEFIから見えないのでダメです。ESP (EFIシステムパーティション）でもokです。また、BIOSメニューにはUSBメモリから起動とありますが、それ以外のドライブでも起動できます。なので、OpenCoreを起動しているESPのルートに、OpenCoreのToolsフォルダからUEFI shellを次のようにコピーしておくと良いと思います。もちろんファインダーのドラッグ&ドロップでもokです。

 % cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/Shell.efi

この作業をしておけば、ESPの内容をうっかり間違って設定してしまっても、UEFI shellを起動できます。

GIGABYTEマザーボードの場合

実を言うと最近はGIGABYTEマザーボードを使っていないので、良くわかりません。マザーボードメーカを、GIGABYTE –> MSI –> ASUS –> ASRockと遍歴してきたので、最近の事情に疎くて、UEFI shellがBIOSから起動できるかどうかわかりません。マニュアルを取り寄せて見た限りでは、BIOSメニューからUEFI shellを起動する機能に関しての記載が無いようです。もしかしたら起動できないのかもしれません。ご存知の方いらしたら情報よろしくです。

ASRockマザーボードの場合

ASRockの場合は、Exitメニューの中に、Launch EFI Shell from filesystem deviceという項目があります。これを選択すると、M.2, SATA, USBなどに接続されていてUEFIでアクセスできるファイルシステムのルートに置かれたshellプログラムを起動してくれます。ASUSの機能と全く同じです。なのでASRockでも、OpenCoreでは通常EFI/OC/Toolsに置かれるOpenShell.efiを、EFI直下にコピーして入れて置くと、このメニューからそれが起動します。

ASRockの場合は、シェルプログラムのファイル名はなんでも良いようで、例えばOpenShell.efiのままでも起動しました。OpenCore用に入れているOpenShell.efiを以下のコマンドのようにしてコピーしておくだけです。もちろんファインダーのドラッグ&ドロップでもokです。

 % cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/.

とはいえ、ASUSに合わせてShell.efiにしておいた方が混乱しなくて良いかもです。

各社UEFI shell機能のまとめ

各社のBIOS画面からのUEFI shell起動機能をまとめると

MSI: マザーボードに内蔵されているshellプログラムを起動する。
ASUS: EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名はShell.efiであること。
GIGABYTE: 不明。起動できないかもしれない。
ASRock: ASUSと同じく、EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名は任意のようで、OpenShell.efiなどでも起動。

となりました。MSI > ASRock = ASUS > GIGABYTEの順番に、利便性が良いと思います。ASUSとASRockの場合は、起動ボリュームのEFIにShell.efiとして入れておくと、いざという時に役立ちます。MSIは、shellプログラムがマザーボードに内蔵されているのでもっと安心です。

まとめ

Hackintoshの設定を変更して起動しなくなる経験は誰にでもあると思います。そんな時に便利なUEFI shell機能は、

OpenCoreやCloverの起動メニューから立ち上げる
起動ボリューム（USBメモリでも可）から立ち上げる
BIOSメニューから立ち上げる

などの方法で起動可能です。UEFI shell起動の方法と使い方を知っておくと、いざという時に対処できるかと思います。

macOS で Thunderbolt 4 を使う

Sun, 30 May 2021 20:49:50 +0900

ASRockのZ590 Extreme + 10900KマシンにThunderbolt 4増設カードを取り付けました。これにThunderbolt 3 SSDを接続して動作確認しました。macOS Big Sur 11.4とOpenCore 0.6.9の環境で動かしたところ、hot plugは機能しないものの外付けドライブとして認識されて、M1 MacBook Airと同程度の速度で使用できました。

HackintoshでThunderbolt

Thunderboltの状況について昔の記事で紹介しました。

ThunderboltとHackintosh

現在もあまり変わっていないように思います。hot plugが効かなくても良ければ、つまり起動時に識別されるドライブや機器を使うだけならば、簡単に使用することができます。でもそれ以上の設定を行う場合には、色々と試行錯誤が必要のようです。Thunderboltの初期の頃に、外付けドライブの動作を試したことがありましたが、その時もhot plugは効きませんでした。今回も外付けドライブがとりあえず使えることを目標にします。

Thunderboltの3と4

Thunderbolt 4は、ごく最近、500シリーズチップセットになってから登場した規格です。現行のIntel MacとM1 Macが採用しているのはThunderbolt 3で、4ではありません。なのでmacOSも3だけをサポートしていると考えて良いでしょう。

とはいえ、Thunderbolt 3と4の違いはほとんどありません。最大データ転送速度はどちらも40Gbpsです。Thunderbolt 3の電気特性や仕様にばらつきがあったところを整理したのがThunderbolt 4なのではと理解しています。例えば3では、40Gbpsを実現するケーブル長が0.8mのものもあったところが、4では2mとされてます。また、3では使用するPCIeが2レーンである場合もあったところが、4では4レーンのみになり、32GbpsのPCIe最大データ転送速度が確保されるようです。この結果、PCIe拡張ボックス、Display Port接続などで4レーンの速度が必ず使えるようになってます。

Thunderbolt 3用SSD

Thunderboltの機能を確かめるために、Thunderbolt 3 対応SSDを用意しました。具体的には、以下のThunderbolt 3用SSDケースを用意しました。

少し分厚い (15mm) ですが、革風のエンボス加工がしてあって質感は良いです。内部にはNVMeのM.2 SSDを装着することができ、ヒートシンクも付属しています。搭載されているThunderboltコントローラチップはIntel JHL6540です。

内蔵するSSDは価格コムで安かったPNYのNVMe Gen3 x 4の256GBにしました。今チェックしたら、倍近くに急騰している様子で、あまりお勧めではないかもしれません。パッケージには、読み取り1,700MB/s, 書き込み1,100MB/sと書いてありました。

M1 MacBook Airで動作確認

自作機で試す前に、ちゃんとしたMacでどのように認識されて、速度が出るのかを確認しました。起動しているMacBook Airに接続したところ、hot plugが効いて、Thunderbolt/USB4ハードウェアとして認識されました。

MacもSSDもThunderbolt 3なので、Thunderbolt 3として認識されています。最高速度は40Gbps x 1となってました。ただ、ディスクユーティリティ.appで情報を見るとPCIe接続になっているようです。装置ツリーバスの値を、Hackintool.appの情報と比較したところ、この場所にはPhison Electronics社のPS5013というチップが接続されていました。調べたところ、NVMe SSDをPCIeに接続するコントローラチップで、M.2 SSDに搭載されているチップのようです。

これをAPFSでフォーマットして、AmorphousDiskMarkで測定しました。以下のように、SSDのパッケージに書いてある通りの速度が出ています。

参考までにM1 MacBook Air内蔵のSSDはこの倍くらい高速です。

Thunderboltドライブは取り外し可能ドライブとして認識されています。取り外した後、再度接続すると再認識されてマウントされます。hot plugが完璧に動作していることを確認できました。

(おまけ) Z390のUSB Type Cで使ってみる

MacでのThunderbolt SSDの動作確認ができたので、いよいよhackintoshで試してみます。まずは、Thunderboltの無い自作PCに、Thunderbolt SSDを挿すとどうなるのかを確認しました。使用したのはASUSのZ390マザーボードです。バックパネルにUSB Type Cポートがついていますが、Thunderboltではありません。OpenCore 0.6.9 + macOS Big Sur 11.4の構成です。ここにThunderbolt SSDを接続したところ、しばらくして以下のような通知が出ました。

Thunderboltがついていないので当然の結果ですが、Thunderboltデバイスが接続されたということをmacOSが正しく把握していることが確認できました。

ASRockのTB 4カード

では、いよいよThunderboltハードウェアを搭載したhackintoshで試してみます。使用するマザーボードはASRockのZ590 Extremeです。最近になって。メーカのサイトによると、搭載されているコントローラはIntel JHL8540だそうです。

ASRock「Thunderbolt 4 AIC」製品情報

Thunderbolt 3でよく使われたチップはJHL6x40でファミリー名はAlpine Ridgeでした。JHL8540は、Maple Ridgeというファミリー名だそうです。macOSがサポートしているのはAlpine Ridgeと言われていて、Maple Ridgeがどの程度動くのか未知数です。

カードはPCIe x 4を使用するので、マザーボードの真ん中のPCIe x 16スロット (PCIE3) に挿しました。このソケットは、形状こそx16ですが、マニュアルによると実際にはx4で接続されるようです。ここはチップセット経由のPCIeで、大元のCPUとの接続がx4なので仕方ないですね。Thunderboltカードには十分な仕様です。

カードには、マザーボードに接続するケーブルが2本付属しています。1本はPCIE3ソケットにすぐ隣にあるThunderbolt AICコネクタへ接続します。5ピンでケーブルも太いので、おそらくは電源強化用ですね。Type CのPD (Power Delivery) に対応するための強化策だと思います。もう1本のケーブルは、マザーボード上のUSB 2.0ピンに接続します。Type CにはUSB 2.0を一本用意しないといけないので、その接続用だと思います。

カード背面には2個のType CコネクタとDisplay Portコネクタがついています。DPの方は入力用で、グラフィックスカードなどに接続します。Type Cコネクタにディスプレイを接続する場合に使用します。今回は接続しませんでした。

BIOS設定

次に、Thunderboltが動くようにBIOS設定します。BIOS設定のAdvanced –> Intel Thunderbolt –> Discrete Thunderbolt SupportをEnabledにします。デフォルトではDisabledになっています。

Thunderboltを有効にすると、

Thunderbolt Boot Support
Thunderbolt USB Support
Windows 10 Thunderbolt support

の項目が現れます。最初の2個は、接続したThunderboltまたはUSBドライブからbootするようにするかどうかの設定です。3番目はWindowsでの設定のようです。とりあえず全部Disabledで良いようです。

また、Thunderboltを有効にすると、自動的に PCI Express Native Controlという項目がEnabledに設定されます。この項目のデフォルト設定はDisabledです。何か必要な設定だと思いますので、そのままEnabledにしておきました。

自作PC+macOSでTBの動作確認

以上でインストールと設定は終了です。Thunderbolt端子に、先に紹介したThunderbolt M.2 SSDを接続し、OpenCore 0.6.9でmacOS Big Sur 11.4を起動させました。その結果、リムーバブルドライブとして認識されました。ただしhot plugは効いていないようで、起動時にSSDが接続されている場合しか認識されず、一旦アンマウントすると再接続しても認識されません。

ディスクユーティリティ.appで情報を調べると以下のようでした。実機のMacと同様に、SSDはPCI-Express経由で接続されたドライブとして見えています。

装置ツリーバスの値を、Hackintool.appの情報と比較したところ、実際のMacと同様に、この場所にはPhison Electronics社のPS5013が接続されていました。ここまでは、SSDが実機とほとんど同じように見えているのですが、システム情報のThunderboltの項目を見ると、ハードウェアが見つかりませんとの表示です。

この先、頑張れば、hot plugも効くように調整できるのかもしれません。でも、大昔にThunderboltを試した時も、同様にhot plugが効かず、Thunderboltハードウェアの認識もされませんでした。なので、hot plugの制約を乗り越えるのは難しいかもしれません。Thunderboltはそこまで必要と感じていないので、今回はここまでとしました。

最後に性能のチェックです。Z590マシンにこのSSDを取り付けた状態で、AmorphousDiskMarkで測定しました。なんとM1 MacBook Airの結果とほとんど同じ結果が出ました。ということで、hot plugは効かないものの、実際のMacでのThunderbolt 3接続と同等の性能が出ていることを確認できました。

(おまけ)TB 4 AICをUSBで使う

ASRockのThunderbolt 4 AICにUSB Type-CのUSB 3.1メモリを挿してみたところ、マウントされて認識されました。ThunderboltとしてだけではなくUSBとしても使えるようです。USBとして使う場合は、hot plugが効きました。

まとめ

ASRock Z590 Extremeマザーボードに、ASRockのThunderbolt 4 AICを追加して動作を確認しました。ソフトウェア環境はOpenCore 0.6.9とBig Sur 11.4です。Thunderbolt 3 SSDを接続したところ、hot plugは効かないものの実機のMacと同じ転送速度が達成されていることを確認しました。

BIG SUR 11.4にアップデートする (Navi 21対応)

Tue, 25 May 2021 15:40:28 +0900

macOS Big Sur 11.4が配布されたので、11.3.1からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.9で起動していて、kext類は最新です。AMD Radeonの最新GPUに対応したようです。

一般的更新内容

前回の11.3.1アップデートとは違い、今回はバージョン番号の差異が大きいアップデートです。「ソフトウェア・アップデート」画面の説明によると、Podcastのサブスクリプションとチャンネル追加がされたようです。また重要なバグ修正も含まれているようです。個人的には、プレビューのバグに対応してくれたのが嬉しいです。

AMD Navi 21に対応

またAMD 6800, 6800XT, 6900XTに対応したようです。このことはベータ版の時から話題になっていて、フォーラムでも動作を報告していただいていました。Apple Developerの11.4 Release Notesページにも以下のように書かれています。

You can now use graphics cards based on the AMD Navi RDNA2 architecture (6800, 6800XT and 6900XT). (73709953)

これを確認するために、11.3.1と11.4のグラフィックス関連kextを比較しました。

/System/Library/Extensions

には、AMDRadeonで始まるkextが多数あるのですが、その一部が、Big Sur 11.3.1ではバージョンが4.4.17だったものが、11.4では4.5.14になり、更新されています。その中から、

/System/Library/Extensions/AMDRadeonX6000.kext/Contents/Info.plist

の内容を比較しました。すると、Big Sur 11.3.1では、

AMDNavi10GraphicsAccelerator
AMDNavi12GraphicsAccelerator
AMDNavi14GraphicsAccelerator

というキーが用意されているのに対して、Big Sur 11.4では、

AMDNavi10GraphicsAccelerator
AMDNavi12GraphicsAccelerator
AMDNavi14GraphicsAccelerator
AMDNavi21GraphicsAccelerator

が用意されていて、Navi 21が追加されていました。Navi 21はRadeon RX 6800 / 6800XT / 6900XTに使われているGPUの名前だそうです。Apple Developerのアナウンスもそれに従った内容です。ちなみにRadeon RX 6700はNavi 22だそうなので、6700はmacOSの正式サポート対象ではないようです。

アップデート作業

システム環境設定の「ソフトウェア・アップデート」から「今すぐインストール」ボタンを押してアップデートしました。この後、3.06GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.4が起動しました。特に気づく変更点はありません。ビルドは20F71になってました。

OPENCORE 0.6.8から0.6.9に更新

Wed, 05 May 2021 13:19:01 +0900

OpenCoreの0.6.9が公開されたので0.6.8からアップデートしました。config.plistの変更点はほとんどありませんでした。UEFI/AppleInput/CustomDelaysがstring型からbool型に変更されたのが注意点です。

0.6.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.9とmacOS 11.3.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.3.1
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.3.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は以下のようでした。

UEFI/AppleInputのCustomDelaysという項目があります。0.6.8ではstring型でAutoを設定してたのですが、0.6.9ではbool型になってました。string型なのは不自然だったとのことです。UEFI/AppleInputではKeyInitialDelayとKeySubsequentDelayを設定するのですが、CustomDelaysがfalseの場合はこれを無視してデフォルト値にしてくれるとのことです。Sample.plistの設定でもfalseなので、falseに設定しておきました。
UEFI/QuirksにEnableVectorAccelerationという項目が追加されていました。SHA-512とSHA-384ハッシングアルゴリズムでAVXベクトルアクセラレーションを有効にするらしいです。デフォルトはfalseだけどsample.plistではtrueでした。性能が上がりそうな説明だったのでtrueにしてみました。
UEFI/QuirksにForgeUefiSupportという項目が追加されていました。UEFI 1.xファームウェアで、UEFI 2.xのサポートを部分的に可能にするという設定らしいです。forgeは確立するとか偽造するという意味なので、UEFI 2.xのふりをするという機能のようです。MacPro5,1でNVIDIA GOPオプションROMを使う場合などに有効とのことです。いずれも該当しないので、デフォルトのままfalseにしておきました。
UEFI/QuirksにReloadOptionRomsという項目が追加されていました。ForgeUefiSupportでUEFI 2.xファームウェアを有効にした後で、NVIDIA GOPオプションROMをリロードするような場合に使うとのことです。ForgeUefiSupportを使わないなら不要のようなので、デフォルトのままfalseにしておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.8から0.6.9に移行できました。

BIG SUR 11.3.1にアップデートする

Tue, 04 May 2021 14:00:06 +0900

macOS Big Sur 11.3.1が配布されたので、11.3からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.8で起動していて、kext類は最新です。OpenCore 0.6.9が公開されていますが、古いバージョンでも対応できました。

前回の11.3アップデートとは違い、今回はバージョン番号の差異が小さいアップデートです。名前も「セキュリティアップデート」です。具体的なアップデート内容は不明ですが、「macOS Big Sur 11.3.1を適用すると、重要なセキュリティアップデートが提供されます。このアップデートをすべてのユーザに推奨します。」と案内されています。11.3の公開から1週間しか経たないタイミングでのアップデートなので、緊急度の高い内容だったのかもしれません。追記：Appleサポートの情報によると、悪意のあるページでWebKit（webページのレンダリングエンジン）が不具合を起こさないよう対応したそうです。

システム環境設定の「ソフトウェア・アップデート」から「今すぐインストール」ボタンを押してアップデートしました。この後、2.4GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.3.1が起動しました。特に気づく変更点はありません。ビルドは20E241になってました。

AirTagを使う

Fri, 30 Apr 2021 16:38:01 +0900

AirTagを試してみました。iPhoneで登録して「探す.app」からAirTagの場所を知ることができます。Z390で作った自作macOSマシンでも、同様に「探す.app」でタグを探すことができました。ただ、UWBデバイスに対応したiPhoneならば、タグの位置と方向を頼りにタグの場所まで案内してもらえるのですが、Macではできません。電池容量の確認、検出できた場合の通知、紛失モードへの設定は可能です。

AirTag

AirTagが来ました。こんな感じに梱包されてます。

ボタン電池の接点を絶縁しているプラスチックフィルムを、矢印の方向に引き抜くと動作開始します。すぐにiPhoneに通知が来ますので、ペアリングして名前をつけておきます。

名前は自由に付けられますが、あらかじめ用意された名前もあります。用意されている名前は、カメラ、ジャケット、バックパック、ハンドバッグ、ヘッドフォン、鍵、財布、傘、自転車、手荷物です。AirTagで探すアイテムとして想定されているもののリストになっていると思いました。

iPhoneで探す

iPhoneで「探す.app」を立ち上げて、画面下の「持ち物を探す」ボタンを押します。iPhoneを探す機能と同じように、地図上にAirTagの位置が表示されます。AirTagがある場所に近づいて「探す」ボタンを押すと、AirTagの方向と距離を表示してくれます。これはUWBに対応したiPhoneだけの機能のようです。

Macで探す

Macでも「探す.app」を起動して試しました。Z390マザーボードの自作マシンで、macOS 11.3、OpenCore 0.6.8の構成です。「探す.app」に新しく用意された「持ち物を探す」タブを押すと、登録したAirTagの場所を知ることができます。（スクリーンショットは加工してあります）

ただ、MacはUWBデバイスに対応していないので、タグの方向と距離を知ることはできません。AirTagはSiriからも問い合わせできるそうなので、MacのSiriで試したところ、iPhoneなどを使ってくださいと言われました。

HomePodのSiriにお願いしたら、タグのスピーカーから音を鳴らしてくれました。

BIG SUR 11.3にアップデートする

Tue, 27 Apr 2021 20:54:36 +0900

macOS Big Sur 11.3が配布されたので、11.2.3からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.8で起動していて、kext類は最新です。

前回の11.2.3アップデートとは違い、今回は小数点以下第1位の大きめのアップデートです。機能も増えている様子で、「探す.app」がAirTagに対応したようです。また「このMacについて」メニューで保証内容が表示されるようになったとのことです。他にも多数の変更・改良点があるようです。

システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、5.71GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.3が起動しました。ビルドは20E232になってました。

探す.appがAirTagに対応したとのことでしたが、「持ち物を探す」タブは11.2.3から変化はありませんでした。AirTagを登録した段階で、新しい機能が有効になるのかもしれません。

「このMacについて」の「サービス」タブは変化してました。以前はリンクがあるだけだったのですが、状況が表示されます。存在しないシリアル番号を割り当ててあるためか、「推定有効期限切れ」という状態のようです。

Z590マザーボードのマシンにも、無効なシリアル番号を割り当ててあるのですが、表示が少し違っていました。設定したシリアル番号の製造週からまだ1年未満なので、1年保証が有効だという表示なのかと思います。

ASRock Z590 ExtremeのUSBを設定する

Sun, 25 Apr 2021 18:12:47 +0900

ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを動かしています。今回はmacOSのUSB個数制限に合わせてUSBポートの設定を行います。以下で調査した結果はASRock Z590 ExtremeのUSB構成ですが、姉妹製品のZ590 Steel Legendでもおそらく同じなのではと思います。

macOSのUSB個数制限

今までにも何度かご紹介していますが、macOSにはUSBコントローラごとにUSBポートの数が15個までという制限があります。ポートの識別に1バイトしか割り当てられていないのです。実際には0を除いて1から15までの数値でポートを識別しているようです。大抵のマザーボードには15個を超えるポートがありますが、何も対処しないとUSB2.0のポートから順番に15個だけのポートが有効になります。後回しになるUSB3.0のポートがほとんど使えない状態になります。この問題を解決するには、以下のような対処法があります。

USBInjectAll.kextを使い、15個の制限を無視するパッチを当てる。OpenCoreの場合、config.plistで、Kernel/Quirks/XhciPortLimitをtrueにする。
USBInjectAll.kextを使い、使用しないポートをブートオプションのuia_excludeで指定する。
USBInjectAll.kextを使い、使用するポートをSSDTで指定する。
使用するポートを列挙したkextを自作する。hackintool.appなどにkextを作るツールが用意されている。

このうち4番目が一番スマートですので、今回もこの手法で設定します。hackintool.appでkextを作る方法はこちらでも説明してありますのでご覧ください。

15個制限のためのUSBPorts.kextをHackintoolで作る

個数制限を一時的に無効にする

まずは使用したいポートを特定するために、一旦、全部のポートが見えるように、個数制限撤廃パッチを当てます。上で述べた選択肢の1番の手法です。まずは500シリーズチップセットに対応したUSBInjectAll.kextを以下から入手します。

https://gitee.com/softxing/OS-X-USB-Inject-All/releases/v0.7.7

次に、config.plistで、Kernel/Quirks/XhciPortLimitをtrueにします。この結果、全てのポートが見えるようになります。hackintool.appで調べると以下のようになります。14個のHS (USB2.0) と9個のSS (USB3.x) が見えていることがわかります。USRという項目は無視して良いです。

15個制限を無視するパッチをこのまま使い続ければ楽かもしれません。でもLocation IDの項目を見ると、0x14F00000の次の行で0x14000000に戻ってしまっていて、重複していることがわかります。区別のための変数が1バイトしかないためのようです。これが何らかの不具合を引き起こす可能性はあると思いますので、15個以内に制限した方が良いでしょう。

USBポートを特定する

使用するポートを選択する作業の前に、実際のUSBポートがどの名前 (HS01からSS09までの名前）に対応しているかを調べます。15個制限を外すパッチを当てた状態で、hackintool.appを見ながら、USBポートにデバイスを挿して確認します。

何も挿さない状態でも、上記の図のようにHS09, HS14, SS09に反応があります。このうちASM107xというのはAsmedia社のUSBハブ制御チップのことです。マザーボード上に搭載されているようです。BRCM20702 Hubというのは、こちら

ASRock Z590 Extremeに無線モジュールを取り付ける

で取り付けた無線モジュールBCM94360NGのBluetooth部分です。これはM.2 key Eソケットに取り付けてあるのですが、key EにはUSB 2.0のポートが来ていて、それが見えています。

hackintool.appを動かしたまま、バックパネルとマザーボード上のポートを1個ずつ使っていくと、割り当てがわかります。USB 2.0を調べるためには、無線キーボードのドングルを使いました。USB 3.0を調べるためには、3.1対応のUSBメモリを使いました。USBメモリは、挿すとマウントされるので、取り外す前にアンマウントする手間がかかりちょっと面倒です。USBメモリの代わりに、USB 3.0対応のUSBハブを使えば、もっと効率が上がったかもしれません。

マザーボード上のポートを調べるためには、内部コネクタを通常のコネクタに変換するアダプタを使いました。画像にAliExpressへのリンクを貼っておきます。お手軽な値段なので、一通り持っていると何かと便利だと思います。

調査結果

ASRock Z590 ExtremeのUSBポートを調べた結果を以下に示します。

HS01 マザーボード上の2.0ヘッダピン（縁側） USB_3_4
HS02 マザーボード上の2.0ヘッダピン（縁側） USB_3_4
HS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
HS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
HS05 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
HS06 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
HS07 バックパネルのType-A、PS/2上の2個のうち下 (2.0 USB_2)
HS08 バックパネルのType-A、PS/2上の2個のうち上 (2.0 USB_1)
HS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)
HS10 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
HS11 マザーボード上の2.0ヘッダピン（内側） USB_5_6
HS12 マザーボード上の2.0ヘッダピン（内側） USB_5_6
HS13 （不明）
HS14 M.2 key Eソケット (Bluetoothで使用)
SS01 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
SS02 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
SS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
SS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
SS05 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
SS06 （不明）
SS07 （不明）
SS08 （不明）
SS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)

不明のポートは、発見できていないか、または元々どこにも接続されていないだけかもしれません。USBで始まる番号・記号は、ASRockのマニュアルに記載されているポートの名前です。マニュアルのバックパネルの図にポート名を書き込むと以下になります。

またマザーボード上のUSBピンは、それぞれ以下の名前になります。

マザーボード上のUSB2.0ピンはチップセット直結なのに対して、USB3.xピンはUSBハブ経由なのが面白いところです。Gen2x2のコネクタは、裏表で、別のSSポートに割り当てられているかと思ったのですが、同じでした。

15個に制限する

以上のように全部で19個のポートがあります。15個に制限するには、4個を諦める必要があります。バックパネルは便利なので、全部活かしたいところです。性能重視ならば、マザーボード上のUSB2.0ヘッダ端子を無効にするのが良いと思います。無駄に贅沢に使われている気がしました。これで4個除外できるので全部で15個になります。

HS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
HS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
HS05 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
HS06 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
HS07 バックパネルのType-A、PS/2上の2個のうち下 (2.0 USB_2)
HS08 バックパネルのType-A、PS/2上の2個のうち上 (2.0 USB_1)
HS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)
HS10 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
HS14 M.2 key Eソケット (Bluetoothで使用)
SS01 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
SS02 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
SS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
SS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
SS05 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
SS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)

hackintool.appのUSB画面で、必要なポートだけを選択して、ファイル書き出しします。するとデスクトップ上にUSBPorts.kextが出来上がります。これを使えばUSBInjectAll.kextはもう不要です。USBPorts.kextをEFIに入れて、config.plistで15個制限を復活させて、起動し、hackintool.appで確認すると以下のようになりました。Commentに説明を書いておくと、後々便利かと思います。

この後、ウィンドウ下のExportボタンを押します。箱から矢印が外に向かっているアイコンの部分がExportボタンです。するとこの設定から、以下の5個のファイルをデスクトップに作ってくれます。

SSDT-EC-USBX.aml
SSDT-EC-USBX.dsl
SSDT-UIAC.aml
SSDT-UIAC.dsl
USBPorts.kext

amlとdslの拡張子のファイルはSSDTファイルです。冒頭で述べた「USBInjectAll.kextを使い、使用するポートをSSDTで指定する」方法で使用するファイルです。以前のガイドで作っていたSSDT-UIACは、ここではSSDT-EC-USBXとSSDT-UIACの2つに分割されています。統合すれば内容は同じものでした。なので、SSDT関係のファイルはUSBInjectAll.kextと一緒に使うものであると思います。

一方、ここで作られるUSBPorts.kextは、Info.plistだけを持ったインジェクタkextという種類のkextファイル（実際にはディレクトリ）です。ターミナルからディレクトリを辿る、もしくはファインダーからパッケージを開くと、

USBPorts.kext/Contents/Info.plist

というテキストファイルが見えます。この中に、上で設定した内容が、plist書式のテキストで書かれています。このkextだけを使用すれば、15個のUSBポートを正しく設定することができます。

ここで作成したUSBPorts.kextをここに置いておきます。ご利用ください。機種名がiMac20,1になっていますので、20,2を使っている人はkextの中のInfo.plistを編集して書き直してください。

今回の設定では、マザーボード上のUSB2.0を全部無効にしました。しかし、無線モジュールを、M.2ソケットではなく、PCIeスロットに挿す場合、USB接続が必要なので、マザーボード上のUSB2.0を1個有効にする必要があります。その場合は、M.2 key EソケットのHS14を除外することになると思います。

まとめ

ASRockのZ590 ExtremeのUSBポートの構成を調べてmacOSの15個制限に対応しました。ここで調べたポート名対応は、構成が似ているZ590 Steel Legendでも同じなのではと思います。また他のASRockマザーボードもこれと似た構成かと思われます。これでZ590マザーボードの設定は一通り完成しました。Z590で作るhackintoshはとても安定しているので、第10世代CPUと組み合わせてmacOSマシンを作るのに適しているかと思います。もしもこの先、iMacが第11世代に対応してくれた場合も、CPU交換で追いつけます。

ASRock Z590 Extremeに無線モジュールを取り付ける

Mon, 12 Apr 2021 18:39:56 +0900

ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを動かしています。今回はこれにmacOSでOOBで機能するWiFi-BluetoothモジュールBroadcomのBCM94360NGを取り付けました。このマザーボードはバックパネルにアンテナ取り付け穴が空いているので、アンテナ取り付けが楽です。

BCM94360NG

BCM94360NGはmacOSでそのまま機能する唯一のM.2用WiFi-Bluetoothモジュールです。お値段は少し高いですが、kext類なしでそのまま動いて、Apple IDやiPhone連携なども問題なく動くので、hackintoshするには定番の無線モジュールです。

今回使用しているASRock Z590 Extremeには、M.2 key Eソケットがついていて、この無線モジュールを取り付けて動かすことができます。ただし、ASUS, GIGABYTE, MSIの、Z490/Z590マザーボードのM.2 key Eソケットは、CNVi専用の場合が多く、動かない可能性があるので注意が必要です。ASRockは従来型のM.2 key E無線モジュールを引き続きサポートしてくれているのでありがたいです。

アンテナ取り付け穴

マザーボード上のM.2ソケットに、WiFiモジュールを取り付けた場合に悩むのが、アンテナ取り付け位置です。PCIeスロットにつけても良いのですが、拡張スロットをアンテナで塞いでしまうのがもったいないです。マザー上のM.2ソケットを使うなら、PCIeスロット以外の場所からアンテナを引き出したいところです。

WiFi搭載マザーボードは大体がバックパネルにアンテナが付いてます。そこで、自分でモジュールを取り付ける場合も、バックパネルにアンテナを取付けたいと考えました。M.2ソケットからの距離も近いので、配線の引き回しも楽です。

マザーボードによっては同じモデルで、WiFi搭載・非搭載バージョンが用意されています。例えばASRockのZ590 Steel Legendだと、

がありますし、今回使ったExtremeにも

[ASRock Z590 Extreme WiFi付き](https://www.asrock.com/MB/Intel/Z590 Extreme WiFi 6E/index.asp)

があります。WiFiなしの方が3300円くらい安いです。WiFiなしを買ってBCM94360NGを取り付けるなら、WiFiなしの方が無駄になりません。他のマザーボードメーカも、WiFiあり・なしのバージョンのあるモデルがあるのですが、ASRockの素晴らしいところは「WiFiなしのバージョンもバックパネルにアンテナ穴が開いている」という点です。部品共通化してコストダウンを図っているだけなのでしょうが、後からWiFiモジュールを取り付ける場合には、とてもありがたいです。実際に、WiFiなしのZ590 Extremeのバックパネルは、こんな感じにアンテナ穴が開いています。

無線モジュールとアンテナ取り付け

ということで早速ASRock Z590 ExtremeのM.2 key EソケットにBCM94360NGを取り付けました。ここからアンテナ線を配線します。アンテナ配線のM.2モジュール側は、U.FL MH4という規格です。またアンテナ側は、通常はRP-SMAという規格です。オスメス反対の組み合わせのSMAにしても良いのですが、通常のマザーボードのアンテナがRP-SMAになっているので、こちらの方が使い回せて便利です。アンテナとケーブルはAliExpressでもAmazonでも買えます。

M.2モジュールの近くの配線はこんな感じになりました。

バックパネルとそのカバー部分は、マザーボード裏側の4個のネジを外すと取り外せます。

アンテナをバックパネルに取付け、バックパネルを戻します。アンテナ穴が開いているおかげで、標準装備のWiFiアンテナみたいに綺麗に取付けられました。

まとめ

ASRockのZ590 ExtremeにM.2無線モジュールのBCM94360NGを取り付けました。このマザーボードはバックパネルにアンテナ穴が開いているので、アンテナを綺麗に取り付けることができました。

OPENCORE 0.6.7から0.6.8に更新

Fri, 09 Apr 2021 00:06:33 +0900

OpenCoreの0.6.8が公開されたので、出遅れましたが0.6.7からアップデートしました。config.plistの変更点はほとんどありませんでした。ただ0.6.6の時のようにOpenCanopyが動かなくなってしまいました。EFIのOC/Resourcesの中身を、こちらにあるFont, Image, Labelフォルダの中身に差し替えたところ、OpenCanopyも動くようになりました。

0.6.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。これを見ると、今回はOpenCanopy関係の更新項目が多いですね。Rocket Lake と Tiger Lake のCPU IDも追加されたようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.8とmacOS 11.2.3で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

変更点は以下のようでした。

Booter/QuirksにForceBooterSignatureが追加されていました。というようなことが書いてありましたので、デフォルトのfalseにしておきました。
UEFI/AppleInputという項目ができていました。AppleEventの詳細な設定が可能になったとのことです。Sample.plistの設定が推奨とのことなので、そのまま設定しておきました。
UEFI/ProtocolOverridesにAppleEventというのが追加されていました。AppleEventプロトコルをビルトインバージョンと入れ替えるかどうかの項目とのことです。VMやレガシーMacの設定でFileVault 2を使う場合に有効かもしれない、というようなことが書いてありましたので、関係ないと考えて、デフォルトのfalseにしておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.7から0.6.8に移行できました。

OpenCanopy関係のファイルを更新する

0.6.7の時のようにnvramのバージョン情報が更新されない問題はありませんでした。しかし0.6.6の時のようにOpenCanopyが動かなくなりました。そこでコメントで教えていただいて、以下から、Resources/Image, Font, Labelを取り寄せて交換したら動くようになりました。

GitHub - acidanthera/OcBinaryData

BIG SUR 11.2.3にアップデートする

Fri, 12 Mar 2021 20:27:47 +0900

macOS Big Sur 11.2.3が配布されたので、11.2.2からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.7で起動していて、kext類は最新です。

前回の11.2.2アップデートに引き続き、またマイナーなアップデートのようで、WebページのレンダリングをするWebKitの脆弱性を修正するもののようです。機能が拡充するわけではなさそうですが、バージョン番号を上げてまで配布するということは深刻な不具合なのかもしれないです。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、2.44GBのアップデートファイルがダウンロードされ、複数回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.2.3が起動してました。

特に気づく変更点はありません。ビルドは20D91になってました。

OPENCORE 0.6.6から0.6.7に更新

Fri, 12 Mar 2021 07:43:01 +0900

OpenCoreの0.6.7が公開されてかなり経ってしまいましたが、ようやく0.6.6からアップデートしました。config.plistの変更点はほとんどありませんでした。

0.6.7をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.7とmacOS 11.2.3で動作確認している手元のマシンは以下です。

ASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

変更点は以下のようでした。

UEFI/AudioにResetTrafficClassが追加されていました。レガシーHDAにおいてTCSEL (トラフィッククラスセレクトレジスター) をTC0にリセットすると書いてあります。AppleALCを使う場合はそちらで設定したほうが良い、というようなことが書いてありましたので、デフォルトのfalseにしておきました。
UEFI/Input/KeyMergeThresholdは機能しなくなったので削除されたようです。削除しておきました。
UEFI/Output/GopPassThroughという項目が追加されていました。UGAプロトコル上にGOP (グラフィックアウトプットプロトコル) を提供するとの説明です。ProvideConsoleGopの設定と関係があるようです。macOSのブートローダが必要とするグラフィックスと、マザーボードの内蔵グラフィックスの乖離を埋める一連の機能のようです。最近のiGPU付きCPUを使いながら、MacPro5,1の設定をする場合に関係するパラメータのようです。iMacで設定しているので不要かと思い、デフォルトのfalseにしておきました。
UEFI/Quirks/ActivateHpetSupportという項目が追加されていました。ICH6などを使った古いマザーボード設定でHPET (高精度イベントタイマー) を有効にできない場合に、それを可能にするオプションだそうです。ICH6は2003年頃のサウスブリッジチップです。古いマザボへの対応のようなので不要かと思い、デフォルトのfalseにしておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.6から0.6.7に移行できました。

バージョンが更新されない

0.6.7にアップデートしたものの、Kext UpdaterやHackintoolでチェックすると0.6.6のままだと言われて、0.6.7のダウンロードを推奨されました。これはnvramの更新ができていないためのようです。ターミナルから、

nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version

とタイプして、OpenCoreのバージョンを示す変数を取得すると、以下のように表示されてしまいました。

4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version	REL-066-2021-02-02

066の設定のままでした。この問題は、OpenCoreの起動画面でnvramをリセットする項目を選べば解決します。もしくは、ターミナルから

sudo nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version=""

とタイプして、この変数を削除してしまうことでも解決します。nvramコマンドでは、何も無い値を設定することで変数を削除できます。なので、この後にnvramコマンドで確認すると、

nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version': (iokit/common) data was not found

というように表示されて、この変数が消えていることがわかります。正しいopencore-version値は、次の再起動時に自動的に更新されます。再起動後にnvramコマンドを入力すれば、

4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version	REL-067-2021-03-01

と表示されるようになりました。Kext UpdaterやHackintoolもOpenCoreの新しいバージョンを認識するようになりました。

BIG SUR 11.2.2にアップデートする

Fri, 26 Feb 2021 23:25:35 +0900

macOS Big Sur 11.2.2が配布されたので、11.2.1からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.6で起動していて、kext類は最新です。

前回の11.2.1アップデートに引き続き、またマイナーなアップデートのようです。サードパーティUSB-Cハブやドックを接続したときに、2019年以降のMacBook Proと2020年以降のMacBook Airが破損することを防ぐ効果があるようです。デスクトップのhackintoshにはとことん無関係な気もしましたが、最新macOSではありますので、アップデートしました。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、2.17GBのアップデートファイルがダウンロードされ、2回、再起動しました。1回目のアップデートのOpenCore画面では、いつもの起動ボリュームにしているMacintosh HDというボリュームが2個見えてましたが、デフォルトで選択されているままでokでした。インストール後、何の問題もなくBig Sur 11.2.2が起動しました。

特に気づく変更点はありません。ビルドは20D80になってました。

AliExpressで売っている格安MagSafe製品

Sun, 14 Feb 2021 20:55:39 +0900

iPhone 12から登場したMagSafeは、便利で優れた機能なのですが、純正アダプタが高価です。そこでAliExpressで探したところ、多種類の互換品が安価に販売されていました。これならMagSafeを気軽に活用できます。

MagSafe

名前が昔のMacBook用MagSafeと同じで紛らわしいですが、ここでご紹介するMagSafeはiPhone 12から登場した磁石内蔵無線給電アダプタです。iPhone 8以降からQi規格に対応していたので、無線給電自体は可能でした。その給電コイル部分に磁石を内蔵したのがMagSafeです。iPhone 12側にも、受電コイルの場所に磁石が埋め込まれていて、ピッタリと位置合わせしてくっつきます。Apple以外にも同じアイディアを製品化していた会社があったとは思いますが、これでデファクトスタンダードになった点が進歩だと思います。

無線給電は便利なのですが、位置合わせが面倒でした。給電・受電コイルの位置がズレると給電効率が悪くなり、充電できないこともあります。Appleが純正の無線給電アダプタを製品化するという噂があったものの、中止になってました。ネットの情報では、コイルカップリングの不確実さが問題だったそうです。MagSafeでそれが解決されたので、無線給電アダプタ類を本格的に製品化することになったのかと思います。

磁石でくっつけるアイディアは良いのですが、磁力なので距離の二乗に反比例して弱くなります。なので、iPhone背面とMagSafeアダプタの間に保護ケースが挟まると、MagSafeアダプタはほとんどくっつかなくなってしまいます。これを解決するために、ケース背面部分に磁性体部品を組み込んだMagSafe対応ケースが用意されてます。この構造により、iPhone裏からケースの裏まで、磁力線が拡散する事なく導かれるので、MagSafeアダプタがしっかり付きます。

MagSafe充電器

磁石内蔵の給電コイルを、Apple Storeでは「MagSafe充電器」という製品名で売ってます。充電器という名前ですが、ACアダプタ部分は別売です。MagSafeは15Wの充電をするので、純正の20W USB-C電源アダプタと一緒に使うことが推奨されてます。丸いパーツの中には給電コイルの他に、Qi規格に基づいてiPhoneと電磁誘導で通信して、相手を確認してネゴシエーションして、適切な電力を供給するためのコンピュータチップも内蔵されているはずです。

Apple Storeの価格は税別4,800円です。純正ACアダプタを買うとしたら、さらに税別2,000円が必要です。便利なのでたくさん備えて色々な場所で使いたいのですが、この価格だとちょっと躊躇します。そこでMagSafe充電器の互換品を探してみました。Amazonでも互換品は見つかりますが割と高価で3,000円前後します。でもAliExpressでは送料込1,100円くらいで売ってます。20WのUSB-C ACアダプタをセットにしても送料込1,600円くらいです。いくつかを入手しましたが、どれも問題なく使用できました。純正品1個の価格で互換品が4個以上買えるので、色々な場所で気軽にMagSafeを使えると思います。

MagSafe対応ケース

MagSafeを使うなら、iPhoneの保護ケースもMagSafe対応にすべきです。非対応のケースでも給電できなくはないですが、前述のように磁力が弱まるのですぐに外れてしまいます。中に磁性体パーツが内蔵された対応ケースなら、ケース無しの場合と同様にしっかりと固定され、簡単には外れません。

iPhoneの純正ケースが高価なのは昔からのことです。MagSafe対応の純正ケースで一番高級なケースは、「MagSafe対応iPhone 12 | iPhone 12 Proレザーケース」で、税別6,800円です。AmazonにもAliExpressにも、非純正のMagSafe対応ケースが手頃な価格でたくさん販売されているので、そちらを試した方が良いと思います。純正品にはない特徴のある製品も多いです。例えば、画面保護ガラスがセットになった製品、ケースの角部分を強化して保護力を向上させた製品、ストラップ取り付け穴のある製品などがあります。

一方、AliExpressでは純正品そっくりのレザーケース、シリコーンケース、レザーウォレットも販売されています。同様の他の商品に比べて少し高価（とはいっても1,800円前後）な値付けになっていて、ロゴ付き (with logo) と書かれていることもあります。これらの製品は、実際にAppleロゴがついて、純正品と同じ紙ケースに入って販売されているようです。おそらくは、Appleが委託生産した余剰品が流出しているのではないかと思います。アパレル製品などでよく聞く話ですね。

MagSafeスタンド

MagSafe充電器をはめ込んで、iPhoneを充電しつつ支えるスタンドも多数販売されています。金型さえ用意すれば量産できるこのタイプの製品は、AliExpressのお得意分野です。例えば以下の製品は送料込みで1,030円くらいです。丸い部分にMagSafeのコイルをはめ込みます。それにより、iPhoneを当てるだけでしっかりと支え、同時に充電もしてくれます。角度調整できる点も便利でした。別途MagSafe充電器が必要です。

車載ホルダー

車のダッシュボードにiPhoneを取り付けるホルダーです。この手の製品は以前からたくさんあり、iPhoneにカーナビさせるときに便利です。以前は、iPhoneをバネで挟んだり、iPhoneに鉄板を貼って磁石で固定したりしてました。それがMagSafeになってスマートで便利になりました。iPhoneをそのまま当てるだけで固定できて、同時に充電も可能になります。

エアコン吹き出し口フィンに固定するタイプならば、両面テープでダッシュボードを汚す心配もありません。AliExpressならば送料込みで2,881円です。ちゃんと使えます。なお、Apple StoreではBelkinの製品が税別4,980円で売られてます。Apple純正MagSafe充電器に比べたら妥当な価格ですので、Apple Storeで買ってあげても良いかもです。

MagSafeデュアル充電パッド

iPhoneとApple Watchの両方を無線給電できるMagSafe充電器です。旅先で便利そうです。でも純正品は、税別14,800円と、高すぎな気がします。AliExpressなら送料込みで1,907円です。実際に入手したのは、下のリンク先の製品ではありませんでしたが、安っぽい感じでした。Apple Watch充電コイルがポップアップするヒンジ部分がすぐに壊れてしまいました。壊れた部分は接着剤で固定して、載せるだけで充電することにしました。以下の製品はちゃんとしているかもしれません。

まとめ

iPhoneの固定と充電が同時に可能なMagSafeは、iPhone 12の新機能の中で一番便利な機能なのではと思ってます。でも純正アダプタ類が高価なので、なかなか使いづらいです。互換品を使って活用したいと思います。

ThinkPad T460sの更新 (OpenCore 0.6.6 + macOS 11.2.1)

Thu, 11 Feb 2021 16:32:01 +0900

中古で入手して色々設定したThinkPad T460sですが、すっかり放置してました。久々に起動したらOpenCoreは0.5.7でmacOSは10.15.6でした。今回は、OpenCoreを0.6.6に、macOSを11.2.1にアップデートします。

T460sのGitHubから更新

あまり使う予定はないのですが、手持ちのマシンは最新にしておきたいという気持ちがあるので、アップデートを考えました。以前の記事、

ThinkPad T460s (6300U) にOpenCoreでCatalinaを導入

では、T460s用にチューンナップしたEFI一式を配布してくれているサイト

GitHub - simprecicchiani/ThinkPad-T460s-macOS-OpenCore: Bootloader configurat…

のEFIデータをそのまま使ってmacOSをインストールしました。今回は自前で頑張るかなと思ったのですが、上記のサイトを再び見てみたところ、活発に更新されていました。タイミングが良いことに、これを書いている13時間前にOC 0.6.6用のEFI一式が更新されていました。ここまで面倒を見てくださるのなら、活用しない手はないと思い、早速EFI一式をダウンロードしました。

基本的にはこれで問題なく0.6.6にアップデートできたのですが、以下の点で多少手をかけました。

起動音を止める

ジャーンという起動音を止めました。最近のMacで復活した起動音ですが、本物Macでも止めてます。今回、何度か起動を試みることになり、その度に大きな音で起動するので、止めました。

SecureBootModel

Catalinaが起動している状態から、githubで公開されているEFIに差し替えると、起動しなくなりました。

OCB: Apple Secure Boot prohibits this boot entry, enforcing!

というエラーが出ます。検索したところSecureBootModelをDisabledにすれば良いとわかりました。今まではDefaultに設定してありました。OpenCoreのマニュアルにもこのことは書いてありました。そこでこれをDisabledにしたところ、起動するようになりました。

ただその後、後述のようにBig Surをクリーンインストールしたところ、SecureBootModelをDefaultにしても問題なく起動するようになりました。なので、現在は元のデフォルト値である、Defaultに戻しました。

矢印アイコンを追加

EFIを入れ替えたところOpenCanopyが動かなくなってました。例の矢印アイコンが足りないのが原因でした。なのでそれを追加しました。ただ、現在githubで配布されている一式には矢印アイコンも入っているようです。

Big Surをクリーンインストール

これでOpenCore 0.6.6 + Catalinaで動くようになりました。そこで、次のステップとして、Big Surにアップデートしようとしました。すると、Big Surのインストーラが途中で止まってしまいました。なので、Big Surインストール用のUSBメモリを作り、これにEFI一式を入れました。そしてUSBメモリから起動して、内蔵SSDを消去してのクリーンインストールを行いました。その結果、Big Surがインストールできました。SecureBootModelもDefaultで動くようになりました。ファイルシステムに何らかの不整合があったのかもしれません。その後、11.2.1にアップデートしました。

Big Sur 11.2.1にアップデートする

Wed, 10 Feb 2021 17:42:55 +0900

macOS Big Sur 11.2.1が配布されたので、11.2からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.6で起動していて、kext類は最新です。

いつものマイナーアップデートのさらにマイナーなアップデートのようです。古いMacBook Proで充電できない問題が修正されているようです。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、アップデートファイルがダウンロードされ、3回、再起動しました。1回目のアップデートのOpenCore画面では、いつもの起動ボリュームにしているMacintosh HDというボリュームが2個見えてましたが、デフォルトで選択されているままでokでした。インストール後、何の問題もなくBig Sur 11.2.1が起動しました。

特に気づく変更点はありません。ビルドは20D74になってました。

OpenCore 0.6.5から0.6.6に更新

Wed, 03 Feb 2021 22:35:18 +0900

OpenCoreの0.6.6が公開されたので0.6.5からアップデートしました。config.plistの変更点はほとんどありませんでした。~~なぜかOpenCanopyが動かなくなってしまいましたが、機能としては問題ありません。~~/EFI/OC/Resources/ImageにLeft/Right.icnsファイルを追加するとOpenCanopyも動きました。

0.6.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.6とmacOS 11.2で動作確認している手元のマシンは以下です。

ASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580
ASUS Z490G + 10900K + Radeon RX 5700XT

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。でも今回は、Bootstrap.efiがフォルダーごと消えてました。以下はありません。

EFI/OC/Bootstrap/Bootstrap.efi

それ以外は前回と同様です。なので入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、比較しながら新しいconfig.plistを作りました。

変更点は以下のようでした。

Kernel/QuirksにSetApfsTrimTimeoutが追加されていました。SSDコントローラが行うtrimの作業のためのタイムアウトをmsで指定するようです。sample.plistでは-1になってました（多分何も設定しないという意味？）ので、そのまま-1にしておきました。
Misc/BootにLauncherOptionとLauncherPathが追加されていました。Windowsを使うときのNVRAM設定に関連するものかと思いました。sample.plistではそれぞれDisabledとDefaultになってました。今までも問題なかったので、sample.plistのままにしておきました。
Misc/SecurityからBootProtectが消えてました。0.6.5ではBootstrapという値が入れてありました。LauncherOption/LauncherPathがこの代わりになったのかと思われます。
PlatformInfoにUseRawUuidEncodingが追加されていました。SMBIOS UUIDをbig endianにするか、little endianにするかの設定のようです。sample.plistではfalseになってました。今更変えるとUUIDが変わってしまうのかと思ったので、そのままfalseにしておきました。
UEFI/QuirksにDisableSecurityPolicyが追加されていました。platform security policyを無効にするという意味らしいです。UEFI Secure Bootを有効にしているならこれは使うなと書いてありました。sample.plistではfalseになってましたので、そのままfalseにしておきました。

いずれも大きな変更ではなさそうです。

OpenCanopyが動かない

以上の設定で、0.6.5から0.6.6に移行できました。問題なく起動して動いているのですが、なぜかOpenCanopyが動かなくなりました。ピッカー画面が、シンプルなテキストメニューに戻ってしまいました。OpenCanopy周りが色々変わったというような記述がありましたので、何か設定を変更しなければならなかったのだと思います。見た目の問題なので、とりあえずこれで使って行きます。

OpenCanopyを動かす（追記）

コメントで教えていただいて調べたところ、/EFI/OC/Resources/Imageに

Left.icns/Right.icns
ModernLeft.icns/ModernRight.icns
OldLeft.icns/OldRight.icns

というファイルが必要になっているようです。それぞれ、Misc -> Boot -> PickerVariantを、Default、Modern、Oldに設定した時に使われるアイコンファイルです。これらをこちらから入手して追加したところ、OpenCanopyが動くようになりました。

Big Sur 11.2にアップデートする

Tue, 02 Feb 2021 22:02:22 +0900

macOS Big Sur 11.2が配布されたので、11.1からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.5で起動していて、kext類は最新です。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐアップデート」ボタンを押しました。

この後、アップデートファイルがダウンロードされ、2回、再起動しました。インストール後、何の問題もなくBig Sur 11.2が起動しました。

特に気づく変更点はありません。ビルドは20D64になってました。

RTL8125B搭載の2.5GbE PCIeカード

Thu, 28 Jan 2021 22:58:00 +0900

RealtekのRTL8125Bチップを搭載した2.5Gbps Ethernet PCIeカードを、macOSで動作確認しました。前回の記事で8125A搭載カードの動作確認しましたが、今回は改良版のBです。Aと比較すると、Bは発熱がほとんどありませんでした。

RTL8125A搭載カード

Realtekの2.5GbE用チップを搭載した2.5G BASE-TのEthernet拡張カードがmacOSで使用可能だったことを書きました。

2.5G BASE-T PCIe Ethernetカードを使う

この記事で紹介したカードは以下の製品です。AliExpressやAmazonで2,000円程度で販売されてます。

これをシステム情報で確認すると、チップ名はRealtek RTL8125Aとなってました。

RTL8125AとB

調べてみると、RTL8125には型番末尾がAのものとBのものの2種類があり、最初に出たのがAで、後継モデルがBのようです。Realtekのサイトによると「 (RTL8125Bは) 第２世代2.5G チップで、世界最小の消費電力（<700mW）と最小パッケージサイズ（6mmx6mm）の2.5Gイーサネット製品です。」というような説明があります。ネットの情報にも、末尾にBがついたRTL8125Bは、省電力改良版であるとの説明がありました。発熱が抑えられているようです。

RTL8125B搭載カード

どうやらAよりBの方が改良されているようです。B搭載カードは多少お高いのかなと思い検索したところ、同じかむしろ安いくらいでした。ということで改めて以下のカードを取り寄せて、macOSでの動作を確認することにしました。

RTL8125Aは熱い

8125Bに交換する前に、8125Aの様子を観察しました。小さな放熱板が取り付けられているのですが、それがかなり熱くなってました。熱いお風呂くらいに感じたので50度くらいかと思ったのですが、その後、触れた指先が2-3日ヒリヒリしてました。もっと高温だったのかもしれません。

RTL8125Bの動作確認

Bのチップに交換しても、正常に機能しました。RTL8125用のドライバー、LucyRTL8125Ethernet.kextで動作しました。

GitHub - Mieze/LucyRTL8125Ethernet: macOS driver for Realtek RTL8125

システム情報でチェックすると、RTL8125Bであることを確認できました。

前回と同様にiperf3コマンドで速度測定もしましたが、Aのチップと性能は同じでした。今回のカードには、上の写真でわかるように、少し大きめのヒートシンクが取り付けられてます。これに指で触れても、ほぼ常温でした。iperf3コマンドを何度も起動しましたが、発熱を感じることはありませんでした。発熱がかなり抑えられていて、低消費電力になっているようです。

実はRTL8125AのカードではWOLが全く効きませんでした。RTL8125Bに変えたところ、２回に１回くらいの割合で、WOLが機能しました。でも、これではWOLとして使えないと思いました。幸い、マザーボード搭載のI219VはWOLが効くので、LANからの起動にはこちらを使っていきます。

まとめ

RTL8125AのカードをBのカードに交換しました。性能は変わらないですが、チップの発熱が圧倒的に少なくなりました。同じくらいの価格で販売されているので、買うならRTL8125Bのチップが搭載されているカードが良いと思います。

「Hey Siri, マックをつけて」で電源を投入する

Wed, 13 Jan 2021 23:55:08 +0900

電源をoffにしたhackintoshをWake On LANの機能によって起動する記事を少し前に書きました。今回は、WOL機能をSiriから呼び出して「Hey Siri, マックをつけて」で電源投入できるようにしました。hackintoshに限らず大抵のコンピュータ（ただし本物のMacは除く）に使える手法です。

Siriでショートカット呼び出し

Apple製品に搭載されたSiriは、HomeKit対応デバイス（アクセサリ）に直接接続して、色々なコントロールをしてくれます。HomeKit対応デバイスには、照明器具とか学習リモコンとかデロンギのヒーターなどがあります。なのでWOLのマジックパケットを送出するコンピュータを、HomeKit対応サーバとして設定すれば、これをSiriから操作することも可能です。でも今回はこれはやりません。

HomePodとWatchは特定のiPhoneと紐付けられているので、SiriはそのiPhoneに登録したショートカットも実行できます。ショートカットとは、一連の操作を記録したiOS版バッチファイルのようなものです。macOSだとApple ScriptやAutomator.appのような存在です。なのでショートカットからWOLできるように設定すれば、これをSiriから起動することが可能です。今回は、iPhoneショートカットを利用する方法で、SiriからWOLします。

Siri (HomePod mini) --> iPhone short-cut --> WOL起動

iOS用にWOLを行ってくれる無料アプリにRemoteBoot WOLがあります。これもショートカットに対応しているので、RemoteBoot WOLを起動してWOLを実行するショートカットを作れます。これで設定しておけば、iPhoneのSiriならば音声でお願いしてWOLを起動させることが可能です。

Siri --> iPhone short-cut --> RemoteBoot WOL --> WOL

ただとても残念なことに、HomePod miniのSiriからこのショートカットを起動すると「コンパニオンデバイスで続きの操作を行う必要があります」と言われてしまい、この後iPhoneでの画面操作が必要になります。結局はiPhoneを使用することになるので、HomePodを使う意味がありません。そこで、「コンパニオンデバイス (iPhone) で続きの操作を行う必要」の無いショートカット作りを目指します。

全体の流れ

RemoteBoot WOLを利用したショートカットでは、その後のiPhone操作が必要になりました。もっと単純なショートカット、例えば単に特定のURLにアクセスするだけのショートカットならば、iPhoneでの操作は不要なのではと考えました。以下に示すように、実際にiPhone画面操作不要のショートカットが作れました。

そこでURLアクセスされるとWOLのマジックパケットを送出するNode.jsサーバを作ることにします。全体の流れは、Siriに「Hey Siri, マックをつけて」と音声でお願いすると、iPhoneのショートカットが起動して、Node.jsが動くサーバが反応し、WOLを発動させます。以下に順番を示します。

Siri --> iPhone short-cut --> Node.js --> WOL

なので以下のものが必要です。

Siriを動かすHomePod、Apple Watch、iPhoneなど
ショートカットを実行するiPhone
Node.jsが常時動いているサーバ (Raspberry Piなど)
WOLで起動するコンピュータ (hackintoshなど)
と4.が必要なのは当然ですね。HomePodを使う上でiPhoneは必須なので2.はあるはずです。HomePodはiPhoneの機能を呼び出す端末のような存在なので、動作中にもiPhoneが必要です。

3.に関して、今回はたまたまNode.jsを使いますが、他にも実現方法はたくさんあります。いずれにしてもSiriからの命令を受け付けるために待機するサーバが必要です。実際には、macOSマシンでも、Windowsでも、Linuxマシンでも良いです。Intel CPU搭載のQNAPのNASもNode.jsが提供されているので、それでも良いです。今回は、安価・省電力に実現するためにRaspberry Piを使いました。将来色々と活用したいところですが、今の所WOLのためだけのサーバなので、できる限り簡単なものにしたかったです。インストールしたLinux (Raspbian) もCUIだけです。

Node.jsを使う

Node.jsをインストールする

WebアクセスするとWOLのためのマジックパケットを送出するサーバをNode.jsを使って作ります。そのためにまずはNode.jsをインストールします。macOSならばHomebrewでインストールできます。

$ brew install nodejs
Updating Homebrew...

Raspberry PiやWindowsのWSLなどのLinux環境ならaptを使います。

$ sudo apt install nodejs

Node.jsでHello World!

Node.jsをインストールするとnodeコマンドが使えるようになります。Node.jsはサーバーサイドでのJavaScript実行環境です。って言われてもなんのことかピンと来なかったのですが、乱暴に言ってしまうと普通のプログラミングに使えるJava Scriptインタプリターです。pythonコマンドとかrubyコマンドと同じようにnodeコマンドでJava Scriptファイルを実行できます。例えば、hello.jsというテキストファイルに

console.log("Hello World!");

という1行のJavaScriptプログラムが書かれていた時、シェル環境からnodeコマンドを使うと

% node hello.js 
Hello World!

のように実行できます。nodeコマンドのパスを1行目に書いて、

#!/usr/local/bin/node
console.log("Hello World!");

のような内容のテキストファイルを作って、実行パーミッションを与えておけば、shellスクリプトファイルとして実行することもできます。

通常、Java Scriptはクライアント側のwebブラウザで実行するので、ファイルアクセスやハードウェアアクセスに制限があります。サーバ機能も書けません。一方で、nodeコマンドで実行すると、制限無しで普通のプログラミングができます。サーバーサイドの実行環境と言われる所以です。

Node.jsでWOL

Node.jsでは色々なパッケージをnpmコマンドでインストールしたり、削除したり、管理します。Wake on LANをサポートしてくれるパッケージもあります。その名もwake_on_lanです。これをインストールするには、

$ npm install wake_on_lan

とします。npmが無いと言われたら、homebrewやaptなどで

$ sudo apt install npm

というようにしてインストールします。これでWOLに関する機能が使えるようになります。WOLさせたいコンピュータのMACアドレスが例えば11:22:33:44:55:66の場合、

var wol = require('wake_on_lan');
wol.wake('11:22:33:44:55:66');

というプログラムでWOLを機能させることができます。

Node.jsでサーバーアプリ

nodeコマンドは、webサーバー側でJava Scriptを動かすコマンドですので、webサーバの機能もあります。そもそもNode.jsが作られた目的がサーバ機能だったようです。例えば、以下のようなJava Scriptプログラムを用意して、nodeコマンドで動かしておきます。

var http = require('http');
var server = http.createServer(function(req,res){
 res.write("Hello world!\n");
 res.end();
});

server.listen(8080);

このプログラムを起動しておいて、このコンピュータのアドレスのポート8080番にhttpアクセスすると（例えばhttp://192.168.xxx.xxx:8080にアクセスすると）、Hello world!の文字列を返します。curlコマンドでアクセスするとこんな結果になります。

$ curl http://192.168.xxx.xxx:8080
Hello world!

SafariでこのURLにアクセスすると以下のような表示になります。

このようにプログラミングすれば、特定のURLに対して、決められた処理を実行するプログラムが簡単に書けます。

URLアクセスでWOL

上で紹介したWOLのサンプルと、サーバアプリのサンプルを組み合わせると、特定のURLにアクセスした時にWOLするプログラムが書けます。例えば、

var http = require('http');
var wol = require('wake_on_lan');
var server = http.createServer(function(req,res){
	wol.wake('11:22:33:44:55:66');
	res.write("Wake on LAN.\n");
 res.end();
});

server.listen(8080);

というプログラムを起動しておきます。すると、他のコンピュータからこのコンピュータのアドレス、http://192.168.xxx.xxx:8080にアクセスすることで、WOLを発動させることができます。このときWOLが動いたことがわかるようにWake on LAN.と返答するようにしておきました。

Raspberry Piに固定IPアドレスを設定して、このプログラムを実行しておけば、Raspberry PiがWOLを発動するサーバになります。サーバとして動かしたい場合は、Raspberry Piからログオフしても動いていて欲しいので、

$ node hello_server.js &

というように最後に&をつけて実行します。これを終了するときはps -xコマンドでPIDを調べてkillします。動作が確認できたら、Raspberry Piの起動時に自動的に実行されるよう設定すると良いでしょう。ちなみに、

/etc/rc.localに書き込む
crontab -eの@reboot行に書く

などの方法があります。

iPhoneショートカットでWOLする

次に、上で作ったNode.js WebサーバにiPhoneからアクセスするショートカットを作ります。iOSにはショートカットというアプリが標準で入ってます。こんなアイコンのアプリです。

ショートカットは、macOSだとAutomator.appに相当するソフトで、iOS操作やプログラム実行を自動化するショートカットを作成します。ここでは、上で作ったWOLサーバにアクセスするショートカットを作り、それに「マックをつけて」という名前を付けます。ショートカット作成後に「ホーム画面に追加」という設定を行うと、iPhoneの画面にショートカットアイコンが現れます。

最初に、ショートカットアプリの中で、「すべてのショートカット」を閲覧すると、右上に+のボタンが現れます。これを押すと新規ショートカットが作れます。

ここでは、URLを指定して、それを開くという2個のアクションを追加します。まずは最初のアクションを追加します。

アクションの候補が出てくるので、検索窓にurlと打ち込んで、URL関連のアクションを検索します。

すると、「URL」というアクションがあるので選びます。URLを指定するアクションです。

ここで、WOLサーバのアドレスと、ポート番号を示すURLを指定しておきます。さらにその下の+ボタンを押して、次のアクションを追加します。

ここでは、「URLを開く」もしくは「URLの内容を取得」あたりのアクションが使えそうです。URLを開くは、実際にはSafariが起動します。これを試したところ、iPhoneでの操作が必要で、Siriには「コンパニオンデバイスで続きの操作を行う必要があります」と言われてしまいました。RemoteBoot WOLの場合と同じで、これでは元の木阿弥です。

一方で、「URLの内容を取得」アクションの方は、最初の起動で確認を求められるものの、以降はiPhoneの操作なしで実行できました。なので、こちらを選びます。

これで完成です。URLを指定して、その内容を取得する手順となりました。URLの内容には意味がなくて、アクセスさえしてくれれば良いのです。この後、名前をつけて保存します。この名前は、Siriに依頼する時の名前になります。「マックをつけて」にしました。

これで「マックをつけて」ショートカットが完成します。最初に起動すると、先に述べたように、アクセスの設定を求められます。ここでOKを押しておけば、以降は何もしなくても実行してくれるようになります。

Hey Siri, マックをつけて

これで、HomePod miniに「Hey Siri, マックをつけて」と話しかけてみます。iPhoneのショートカットが反応し、WOLサーバが応答し、hackintoshが起動するはずです。本物のMacだと電源遮断の状態からのWOLは出来ないらしいので、これはhackintoshならではの機能です。

iPhoneショートカットを呼び出す機能は、iPhoneと連携して動くHomePodとWatchのSiriでのみ可能です。macOSのSiriにお願いするとこんな返事が返ってきます。もしかしたらハンバーガー屋さんの方を探そうとしてくれているのかもしれません。

まとめ

HomePod miniに話しかけてhackintoshの電源を投入できるようになりました。そのために、Raspberry PiにNode.jsをインストールして、WOLを発動するサーバとし、これにアクセスするショートカットをiPhone上に作成しました。Siriからプログラムを起動させたい場合、以前はHomeKit互換のデバイスとして構築する必要がありました。今はショートカットが使えるので、楽になりました。

2012年のMac miniをServerにする

Sun, 10 Jan 2021 21:51:51 +0900

Mac mini Late 2012の中古に2.5 inch SSDと大容量HDDを内蔵してサーバマシンにしました。この世代のminiは、Big Sur以降は動きませんがメモリもストレージも拡張可能で、さらにM1 Mac miniが出て値下がり傾向にあり魅力的です。

Mac miniで自宅サーバ

ストレージをたくさん搭載できる自作hackintoshを自宅サーバにするのは良いアイディアだと思ったのですが、遠隔から再起動する時は不安です。ソフトウェアアップデートや設定変更などで起動しなくなると、マシンのところまで出向いて操作をしないといけません。その点、本物のMacなら安心です。ということで、安価で、ストレージをたくさん搭載できて、邪魔にならない中古Mac miniを探してました。

拡張性の高いmini

今話題のM1 Mac miniは高性能ですが、拡張性が貧弱です。いろいろ増設したいサーバには不向きだと思います。さらには、大したサーバではないので、安価な中古品が欲しいです。それで古いモデルを検討しました。最近の世代のMac miniを比較すると以下のようになります。


Mac mini	2020	2018	2014	2012	2011
CPU	M1	Coffee Lake	Haswell	Ivy Bridge	Sandy Bridge
macOS	Ventura	Ventura	Monterey	Catalina	High Sierra
メモリ交換	–	可能	–	可能	可能
HDD/SSD交換	–	–	可能(M.2, SATA)	可能(SATA x2)	可能(SATA x2)

2020と2018モデルは現行製品です。どちらかを買うならM1 Mac miniが断然良いです。CPU性能が良いですし、それ以上にiGPUが強化されています。サーバとして使うならiGPUはあまり関係無いですが。

2014モデルはMontereyまで対応してます。SSDソケットは独自仕様ですがM.2への変換ケーブルが安価に入手可能です。でも2014年モデルは、メモリ交換ができない点がとても残念です。4, 8, 16GBモデルが販売されましたが、流通している中古の大半が4GBで、8GB以上のモデルは見つけられても高価です。少しお金を足したらM1 Mac miniが買えてしまうくらいです。2014モデルがメモリ交換可能だったら、安価に16GB程度へ交換できたのにと思います。

2012年以前のモデルは拡張性に優れてました。メモリ・HDDのどちらも増設が簡単です。あの小さな筐体に2.5インチSATAドライブが2個も入ります。2012年までは、Mac mini Serverというモデルが併売されていて、これが2台のドライブに対応していました。非Serverモデルにも2個目のSATAコネクタがちゃんとはんだ付けされているので、Serverモデルのケーブル部品を取り寄せることで、安価にSATA増設できます。

Apple、macOS 10.14 MojaveとmacOS 10.15 Catalina向けに「セキュリティアップデート2020-007/-001」を公開し、High Sierraのサポートを終了。

ただ2011年モデルはHigh Sierraまでの対応で、すでにサポートが打ち切られています。2012年モデルも、Catalinaまでしかサポートされません。2011よりはマシですし、2011と2012で中古価格はそれほど違わないです。そこで2012年モデルを探すことにしました。Serverモデルが作られた最後の世代なので、サーバ向きかと思います。

探してみると、税・送料込み2万円台前半で中古Mac mini 2012が売られてます。中古のほぼ全てが、Serverではない通常のMac miniなので、SATAドライブは1個のみ搭載されてます。これにSATAドライブを増設して2個として、Mac mini Server 2012相当に作り変えることにしました。

ストレージ交換

久々にminiを手にすると、記憶以上にでかいと感じました。Intel NUCよりはるかに大きいですし、HP EliteDesk 800 G2 DMよりも一回り大きいです。NUCやEliteDeskに比べると、Mac miniは電源も内蔵していますし、2.5インチも2台入るので、ある程度大きくなるのは仕方ないです。

裏の丸いプラスチック蓋は少し回すと外れます。蓋を外した丸い穴から作業することになるので作業はなかなか大変です。HP EliteDesk 800 G2 DMのような普通のデザインならば、もっと簡単に分解できるはずです。オシャレな見た目の代わりに、メンテナンス性はよくないです。以下では、IFIXITから写真お借りして説明します。

蓋を外してすぐに見えるファンは簡単に外せます。ネジ3本で止まってます。またロジックボードに繋がっているコネクタは、上に持ち上げると外れます。一見するとスライドして外れそうな形をしてますが、違います。方向を間違えると壊れます。昔それで失敗したことがあります。

(引用元：IFIXIT)

次に、薄いプラスチックの黒いカバーを外します。これはファンが、ヒートパイプの熱を外気と一緒に吸い込まないためのカバーです。バックパネルに近いあたりでネジ1本で固定されてます。薄いので割れやすく注意が必要です。これがまた、なかなか外れません。少しずつ歪ませて、回転させて外します。コツを掴めば次からはもう少し楽に外せるかもしれません。

(引用元：IFIXIT)

次に、アンテナのついているメッシュ金属パネルを外します。最初にネジ4本を外します。その後、バックパネル側にスライドして外すのですが、これもとても難しいです。いろいろ動かしながら、多少歪ませながら、苦労して外します。アンテナケーブルがロジックボードに繋がってますが、HDDが邪魔で外せません。しばらくは繋がったままにします。

(引用元：IFIXIT)

この世代のminiには、上段と下段に合計2台の2.5 inchドライブを内蔵可能です。通常のminiには、HDDが「下段」に1個入ってます。ややこしいですが、写真は本体の裏から見ているので、手前が本体の下側になります。Mac mini Serverには、上段と下段に合計2台のHDDが入ってました。HDDは基板上に四角いコネクタが挿さってるので、プラスチックのヘラのようなもので持ち上げて外します。このコネクタからはそのままHDDに接続されているので、SATAコネクタだと思われます。隣に、使われてない空のSATAコネクタもあります。通常のminiにも2個目のドライブ用SATAコネクタを残してくれているのは、とてもありがたいです。

(引用元：IFIXIT)

ここまでくると、ロジックボードはネジを1本で筐体に固定された状態です。バックパネル近くにあるそのネジを外します。かなり長いネジです。そのあとは、コの字型の金具でロジックボードを後ろに1cmくらいスライドします。ロジックボードがバックパネルと一緒に出てきます。SATAケーブル、フロントパネルLED/リモコンへのケーブル、電源ケーブルがつながっているので、それ以上はスライドしません。ケーブルを外すのが面倒なので1cmスライドしたところで止めておきます。それでもHDDは外せます。

(引用元：IFIXIT)

HDDは空間にはまっているだけなので、斜めに傾けたり、押したり引いたりしているとなんとか外せます。HDDが外せると、Wi-Fiアンテナ端子へのアクセスも楽になるので、これも外しておくのが良いと思います。この後の作業でアンテナ線にダメージを与える心配がなくなります。

HDDを取り外すと、跡には2.5インチドライブが2個入る、巨大な空間が現れます。Mac mini Serverはここに2台のHDD/SSDが入ります。このminiにも、「上段」にSSDを、「下段」にHDDと、2台のドライブを入れることにしました。ただ、元々内蔵されている上段ドライブ用のSATAコネクタはありますが、上段用の部品はありません。それでAmazonで「上段ドライブ用ケーブル」を買います。交換に必要な全ての工具と取り付けねじ込みで、送料込み800円くらいと安いです。

この取り付けキットの取り付けネジで、上段ドライブをすでにある枠に取り付けられます。でも上段ドライブ用の枠に取り付けようとすると、このあと、いくつかのケーブルを外し、ロジックボードと電源を外す作業が必要です。面倒ですし、この先ドライブを変更したい時にもすぐにアクセスできることを考えて、上段のドライブも下段のドライブと同様に嵌め込むだけにしておきます。ただ、最近のSSDだと2012年代HDDに比べて薄過ぎて安定しません。そこで100円均一で売っている防振ジェルでスペースを埋めて、これにSSDを貼り付けておくことにしました。

こんな感じで収まります。ケーブルがコネクタの上に来るように位置調整しておきます。

上段のSSDと下段のHDDの間にも防振ジェルを挟んで、元の位置にHDDを嵌め込みました。中古品に内蔵されていたHDDはへたれている可能性があるので、新しいHDDに交換しました。

この後は、逆の手順で組み直します。最初は、ファンのコネクタがちゃんと挿さっていなかったので、回転しませんでした。お気をつけください。

動作確認

搭載されていたCPUを確認したところi7-3615QMという型番でした。

% sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz

Late 2012に3機種あった真ん中のグレードです。モバイル用のCPUですが、それでも4コア8スレッドなので、Zoomのバーチャル背景も動きます。Geekbench 5でのスコアは、マルチコアで2800くらいでした。

M1に比べたら0.4倍くらいの性能です。でも、普段使いには問題ないくらいキビキビ動きます。これくらい古いMacでもSSDに交換すれば実用的に使えますね。

まとめ

Mac mini Late 2012中古のストレージを増設してサーバマシンにしました。このモデルは拡張性があった古き良き時代のMacです。最新macOSは走りませんが、安く流通していますし、拡張してまだまだ使えると思いました。

2.5G BASE-T PCIe Ethernetカードを使う

Wed, 06 Jan 2021 18:12:52 +0900

RealtekのRTL8125チップを搭載した2.5Gbps Ethernet PCIeカードを、macOSが動く自作PCで使ってみました。ドライバにはLucyRTL8125Ethernet.kextを使います。2.5Gbpsの速度が出ていることを確認しました。安価なので1G超えLANを試すのに良いと思います。

RTL8125搭載2.5G PCIeカード

AmazonやAliExpressのページでRTL8125を検索すると、2.5G BASE-TのEthernet拡張カード製品が多数見つかります。RTL8125はRealtekの2.5GbE用のチップです。現在主流のZ490マザーボードの多くにはIntelのI225-Vが採用されていますが、一部の製品にはRTL8125が搭載されています。例えばGIGABYTEのマザーボードにはRTL8125が搭載されています。GIGABYTE関係者の方が「I225-VよりRTL8125の方が安定しているから採用している」と、YouTubeで宣伝してました。それくらいメジャーなチップなので、2.5Gbps PCIe拡張カードの多くがRTL8125を搭載しているようです。Amazonでの価格は2,000円〜4,000円くらいです。10Gbpsのカードに比べると安価なので、導入しやすいです。

価格以外にも、2.5Gbpsカードのメリットがあります。2.5Gbpsカードは10Gbpsに比べて速度が遅いので、カードエッジコネクタはPCIe x 1です。それに対して、高速な10GbpsカードではPCIe x 4になります。今回使用したマザーボード（ASUSのROG Maximus XI Hero Z390マザーボード）には3本のPCIe x 16スロットと3本のPCIe x 1スロットがあります。3本のPCIe x 16スロットのうち、CPU直結スロットはグラフィックスに、チップセット経由のスロットはSATAカード (PCIe x 4)で使ってしまっていました。CPU直結のPCIe x 16のスロットがもう一本空いてはいますが、それを使うとグラフィックスカードを挿しているPCIe x 16と帯域を分け合うことになり、どちらもx 8になってしまいます。LANのためにグラフィックスの性能が下がるのは避けたいと思いました。そうすると空いているスロットはPCIe x 1だけです。x 1スロットで使える2.5 Gカードは、現状に即した選択と思いました。

今回注目したのは、2.5Gカードとして最安値で販売されている以下の製品です。AmazonとAliExpressのどちらにも、同じ写真の製品が複数販売されています。扱っている店が違うだけで、おそらく全て同じ製品だと思われます。

Amazonだと送料込みで2300円程度ですが、AliExpressでは1900円程度です。差額は大差ないのですが、Amazonの納期は3週間以上で、AliExpressの方は1週間未満でした。価格と納期は時期により変化すると思いますが、現状ではAliExpressの方が優秀な様子でした。以下ではAliExpressから届いたカードを使ってみた報告です。

LucyRTL8125Ethernet.kext

実際のMacでは採用されていないチップなので、macOSにはドライバーが含まれていません。でもmacOSで動くRTL8125用のドライバー（kextファイル）が以下で公開されています。Kext Updater.appにも登録されているので、そちらからもダウンロード可能です。

GitHub - Mieze/LucyRTL8125Ethernet: macOS driver for Realtek RTL8125

ちなみにLucyというのは作者のMiezeさんの猫の名前のようです。

LucyRTL8125Ethernet.kextをOpenCoreのKextsフォルダに入れ、ProperTreeのスナップショット機能を使ってconfig.plistに登録したところ、このRTL8125カードは問題なく動作しました。ただしWake On Lanは効きませんでした。カードの販売サイトではWOL対応していると書いてあるので、おそらくはmacOSとの相性問題ではないかと思います。

システム情報で確認

動作したところでmacOSの「システム情報」を開くと、RTL8125Aを搭載したPCIeカードだと確認できました。ちなみに、もう一つ見えているEthernetカードは、ASUS Z390マザーボード上に実装された1G Base-TのI219です。

速度測定

速度が出ていることを確認するためにiperf3コマンドで速度測定しました。このカードを取り付けたASUS Z390マシンを、ASUS Z490マシンに接続しました。どちらのマシンも、OpenCore 0.6.4 + Big Sur 11.1の構成です。Z490には、Intel I225-Vが搭載されています。なので接続は以下のようになります。

Z390 (Big Sur) + RTL8125A <-----> Intel I225-V + Z490 (Big Sur)

また、今回の測定ではジャンボフレームをonに設定しました。なので前回の測定より性能が出ました。ジャンボフレームを有効にするには、システム環境設定の、ネットワーク、詳細、ハードウエアで構成を手動にします。手動で2.5Gに設定すると、相手は2.5G Base-T限定になり、1Gハブなどには接続できなくなります。

iPerf3のクライアント側の結果を以下に示します。2.5Gbpsの速度が達成されている様子がわかります。

% iperf3 -c 192.168.x.x
Connecting to host 192.168.x.x, port 5201
[ 5] local 192.168.x.x port 49642 connected to 192.168.x.x port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 295 MBytes 2.48 Gbits/sec
[ 5] 1.00-2.00 sec 297 MBytes 2.49 Gbits/sec
[ 5] 2.00-3.00 sec 295 MBytes 2.47 Gbits/sec
[ 5] 3.00-4.00 sec 295 MBytes 2.47 Gbits/sec
[ 5] 4.00-5.00 sec 294 MBytes 2.47 Gbits/sec
[ 5] 5.00-6.00 sec 296 MBytes 2.48 Gbits/sec
[ 5] 6.00-7.00 sec 295 MBytes 2.48 Gbits/sec
[ 5] 7.00-8.00 sec 293 MBytes 2.46 Gbits/sec
[ 5] 8.00-9.00 sec 294 MBytes 2.46 Gbits/sec
[ 5] 9.00-10.00 sec 295 MBytes 2.47 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 2.88 GBytes 2.47 Gbits/sec sender
[ 5] 0.00-10.00 sec 2.88 GBytes 2.47 Gbits/sec receiver

iperf Done.

OpenCore 0.6.4から0.6.5に更新

Tue, 05 Jan 2021 18:01:54 +0900

OpenCoreの0.6.5が公開されたので0.6.4からアップデートしました。config.plistの変更点はほとんどありませんでした。何も変更しなくても問題なく起動すると思われます。

0.6.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。前回と同様、入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Bootstrap/Bootstrap.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。ACPIに関しては、今回からパッケージにamlとdslのファイル一式が含まれるようになりました。こちらの表から必要なdslファイルを確認してコピーすれば良いので、ESP作成が楽になります。念のために、ACPIフォルダの中身を配布ファイルに差し替えておきました。

config.plistを更新する

変更点は以下のようでした。

Misc/BootにPickerVariantが追加されていました。OpenCoreの選択画面で表示するアイコンセットを指定する項目のようです。Auto, Default, Old, Modern,その他の値が選べるそうです。OldとModernは、アイコンのファイル名がOld, Modernで始まるアイコンを選んでくれるそうです。AutoはDefaultBackgroundカラーに合わせて自動的に選択、DefaultはOld, Modernの文字がないものを選んでくれます。これでアイコンを簡単に切り替えられるようです。EFIごとに設定を変えておけば、どのドライブから起動したかを判断しやすくなると思います。sample.plistではAutoになってましたので、そのままAutoにしておきました。
UEFI/AudioにSetupDelayが追加されていました。ミリ秒単位のディレイを指定します。ボリュームなどの設定をした後、ディレイが必要な場合に指定します。通常は0.5秒で良いようです。多分起動音を正しく出すための設定だと思われます。sample.plistでは0になってました。そのまま0にしておきました。
UEFI/QuirksからDeduplicateBootOrderの設定が消えてました。以前のconfig.plistではtrueにしていた項目です。BootOrderで重複しているエントリーを取り除いてくれる機能だったようです。不要になったので削除されたとのことです。config.plistからもサンプル通り削除しておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.4から0.6.5に移行できました。

HomePod miniをASUS Z390マザーボードのType-Cに接続する

Fri, 01 Jan 2021 23:07:01 +0900

HomePod miniにはType-Cのケーブルがついています。これをASUSマザーボードバックパネルのType-Cコネクタに接続したら、macOSのファインダーにHomePodが現れました。この状態でHomePodのメンテナンスが可能です。

HomePodをhackintoshに接続する

HomePodにはUSB Type-Cのケーブルが1本だけついてます。本体からは抜けないので、生えている感じです。電力供給専用だとばかり思っていたので、これを自作PCに接続したらどうなるかとは考えてませんでした。

ところで、最近HomePod miniの調子が時々良く無いです。iPhoneと連携する機能をリクエストすると

「接続で問題が起きています。iPhoneがこのHomePodと同じWi-Fiに接続されていることを確認してください。」

という返答をすることがあります。検索すると、そういう状況で困っている人は多くて、

Wi-Fiを2.4GHzにしたり、
HomePodを初期化したり、
iPhoneを再起動する

と一時的に治るようでした。その対処法の一つに、HomePodをMacにUSB接続して初期化する方法が書いてありました。

「そんなことが可能ならばhackintoshでも試したい」ということで、ASUS Z390 + 9900K + OpenCore 0.6.4 + Big Sur 11.1で構成した自作マシンのバックパネルType-Cコネクタに、HomePodを直結してみました。するとなんと、ファインダーにHomePodが現れました。

HomePodの上面LEDはオレンジ色で点滅します。これはオーディオ用パワーアンプを駆動するためには電力が不足していることを表しているらしいです。マザーボードのType-CコネクタにはUSB 3.1 PDの機能はなく、5V 2Aが出ているだけなので電力不足です。でも「HomePodを復元…」する機能は使えるようです。

システム情報で調べると、480Mbps接続しているようです。USB 2.0のHigh-Speedモードですので、おそらくは変換器経由でUSB 2.0/3.0 Type-Aコネクタに接続しても、同様にファインダーに現れるのではと思います。

HomePodを復元する

ファインダーウィンドウで唯一できることは、「HomePodを復元…」することのようです。試さないわけにはいかないです。これをクリックすると、こんなダイアログが出ます。

何かのメディアもデータを入れたつもりもないので、ためらうことなく、復元ボタンを押しました。

すると2.29GBの「HomePodソフトウェア・アップデート」のダウンロードが始まりました。おそらくはHomePodのOSがアップルのサーバからダウンロードされ、これによりHomePodがアップデートされるのだと思われます。

この後「ファームウェアが復元」されて、工場出荷時状態になりました。

おまけ：Apple TVも接続してみた

5年前のApple TV (2015) にもType-Cのポートがあったので、同じくZ390マザーボードに接続してみました。こちらもファインダーに現れて、復元とアップデートができました。ソフトウェアアップデートのサイズは2.85GBでした。USBの接続は、やはり480MbpsのHigh-Speedモードです。ちなみにApple TVにメンテナンス用USBポートがついているのは2015モデルまでで、2017モデルからは廃止されてます。またType-Cなのは2015モデルだけです。

まとめ

Big Surが動いている自作PCに、HomePod miniをUSB接続したら、ファインダー上に現れて、ソフトウェアのアップデートなどが可能でした。Type-Cケーブルは単なる電源用だと思っていたので意外でした。

Wake On LAN (WOL) を使ってmacOSの電源を入れる

Sat, 26 Dec 2020 20:49:22 +0900

電源を落としたmacOSコンピュータをWake On LAN (Ethernet経由) で起動するよう設定しました。本物のMacだと電源を落とした状態からのWOLは不可能らしいです。条件はありますが、hackintoshならば電源off状態からのWOLが可能です。

Wake On LAN機能

Wake On LAN (WOL) は、スリープ状態や電源offのコンピュータを、ネットワークからのコマンドで起動させる機能です。WOL設定されたマシンのMACアドレス宛に、マジックパケットというデータを送りつけることで、目覚めさせます。WinowsをインストールしたHP EliteDesk 800 G2 DMでは、電源offからのWOLが動きました。でも実機のMacでは、検索した限りでは、電源offからのWOLは不可能なようです。

WOLの設定は、どのコンピュータでも結構、困難を伴うようです。色々な要素が絡んでいて、不安定なことも多いようです。Hackintosh関係のサイトでも、WOLの設定が時々話題になりますが、大変そうでした。WOLが必要な状況にあるなら、常時電源onにしたサーバとして動かしておけば良いのにと思ってましたので、あまり興味はありませんでした。でも、手を出してみたら、停止していたコンピュータをネットワークから起動させる事が純粋に面白かったです。何かの目的のためにWOLするのではなく、人はWOLしたいからWOLしているのだと感じました。また、実機のMacでは出来ないことを達成するという要素も、hackintoshの醍醐味です。

WOLには以下のような要素が関係するようです。このうち一つでも不完全だとWOLしません。またOSやドライバーのバージョンが変わると動かないこともあるようです。前回紹介したWindowsの場合でも設定は面倒でした。

BIOSでの設定：電源off時にもEthernetポートに通電するよう設定。
OSでの設定：macOSではシステム環境設定でWOLを有効にする。
ネットワークドライバ：WOLをサポートしたkextを使う。
NIC：WOLをサポートしたLANアダプタが必要。

後半の2条件：ネットワークドライバとNICに関しては、相性の問題かもしれないです。同じチップを使ったアダプターカードでも、WOLが効く・効かないものがあるようです。またこれ以外にも、OSのバージョンが変わるなどの状況で、WOLが動かなくなったりします。WOLが動く条件が満たされると、電源がoffでもEthernetコネクタのLEDが点灯するようになります。Hubの接続モニターLEDも点灯します。LEDが点灯しない状態では、NICへの電源が遮断されているので、WOLは無理なようです。電源off状態のLEDを観察すれば、WOLできるかどうかがある程度判定できます。

ASUS Z390 + Big SurでWOL

今回設定したマシン構成は、ASUS ROG MAXIMUS XI HERO Z390 + OpenCore 0.6.4 + Big Sur 11.1です。WOLに使用したのは、このマザーボードに搭載されているIntel I219-VギガビットLANです。

BIOS設定

BIOSのAdvanced –> APM ConfigurationからPower On By PCI-EをEnabledに設定します。デフォルトはDisabledです。下の欄に、「オンボードLANコントローラやPCIeスロット上LANカードのwake-on-LAN機能を有効・無効にします」という説明が出てます。オンボードチップの場合も、PCIeスロット搭載カードの場合も、この項目でWOL設定できるようです。

macOSの設定

システム環境設定の省エネルギーで「ネットワークアクセスによるスリープ解除」にチェックを入れます。これはデフォルト設定です。実際のMacでは、この設定によりスリープからのWOLが可能になります。でも、電源offの場合はWOLしません。

WOL対応kextを使う

以上のBIOSとmacOSの設定を行っても、当初はWOLが効きませんでした。BIOSで設定した直後に、電源を落とすと、WOLが効きます。でも一度でもmacOSを起動すると、それ以降、WOLが効かなくなりました。macOSの動作で、WOLが無効化されているような振る舞いです。ということで、macOSではWOLできないと書きましたが、その記事のコメントで、まっくぷろさんから、WOL対応しているらしいIntelMausiEthernet.kextバージョンを教えていただきました。このkextを使うことで、安定してWOLが動作するようになりました。

GitHub - fischerscode/IntelMausiEthernet-WOL: OS X driver for Intel onboard LAN

WOLするアプリケーション

WOL状態で待機しているコンピュータは、そのMACアドレス宛にマジックパケットを送ると起動します。マジックパケットを送るには、先の記事でも紹介した簡単なPythonプログラムでokです。

#!/usr/bin/python
import socket
s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
s.sendto('\xFF'*6+'\x99\xAA\xBB\xCC\xDD\xEE'*16, ('192.168.xxx.255', 7))

最後の行が、目覚めさせたいコンピュータのNIC情報です。\x99\xAA\xBB\xCC\xDD\xEEの部分がMACアドレスで、192.168.xxx.255がIPアドレスです。IPアドレスの最後が255なので、ブロードキャストします。

Homebrewで導入できるコマンドのwakeonlanをコメントで教えてもらいました。これをインストールすると以下のようにMACアドレスを指定してWOLできました。wakeonlanの中身はperlのスクリプトのようです。

wakeonlan 99:AA:BB:CC:DD:EE

App Storeには、GUIで機種を登録したり、MACアドレスを自動検出できる有料アプリ・広告付きアプリが多数あります。でも、遠隔地からWOLすることを目的と考えたら、シンプルなPythonプログラムで十分かと思いました。また、WOLのためのiPhoneアプリも多数あります。RemoteBoot WOLは、無料でユーザも多いようです。Windows用やAndroid用にももちろん多数のアプリがありますし、Amazonのデバイス用にもあるようです。記事冒頭のアイコンをお借りしたアプリは、FireTVなどで動くようです。

まとめ

ASUS Z390マザーボード搭載のIntel I219-V経由で、Big Surが動くコンピュータのWOLを試みました。電源offの状態から電源を入れられました。このために、BIOSを設定し、WOLに対応したIntelMausiEthernet.kextを使いました。これで外出先から電源を入れることもできそうです。

10G BASE-T PCIe Ethernetカードを使う

Thu, 24 Dec 2020 18:38:17 +0900

10GbpsのPCIe Ethernetカードを使ってみました。iMac Pro (2017) で使われているAquantia AQC107というチップを搭載したカードです。ドライバーが元々のmacOSに含まれているのでkext不要で動きます。同じチップ搭載でも、簡単なパッチが必要な製品と、OOBで動く製品があるようです。

ASUSの10Gbps Ethernetカード

フォーラムで教えていただいたMorgonautさんのビデオで、ASUSの10 Gbps EthernetカードがCatalinaでOOB動作すると紹介されてました。

紹介されているのは、Aquantia AQC107という製品です。以下のように、送料込みで1.1万円くらいです。

このカードを、実はかなり前に買ったのですが、macOSで動かなくてお蔵入りになってました。「OOBで動くようになっていたのか」と思い、発掘して（なかなか見つかりませんでした）試してみました。結論から言うと、OOBでは動きませんでしたが、パッチを当てて動くようになりました。

Aquantiaチップ用パッチ（Big Sur版）

Aquantiaの10Gbps EthernetカードのためのBig Sur版のパッチが以下で紹介されていました。これを使いました。動かした環境はZ390 + 9900K + OpenCore 0.6.4 + Big Sur 11.1です。

AppleEthernetAquantiaAqtion.kextを以下のように書き換えれば良いようです。このkextは、

Kext: com.apple.driver.AppleEthernetAquantiaAqtion
Find: D4TAAgAA (16進数: 0f 84 c0 02 00 00 )
Replace: Zg8fRAAA (16進数: 66 0f 1f 44 00 00 )

このkextの実体は以下の場所にあります。

/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleEthernetAquantiaAqtion.kext

テキストエディタで作業するなら、OpenCoreのconfig.plistのKernel, Patchの項目に、次のdictを足せば良いです。

<dict>
 <key>Comment</key>
 <string>ASUS XG-C100C (Aquantia AQtion AQC-107)</string>
 <key>Count</key><integer>1</integer>
 <key>Enabled</key><true/>
 <key>Find</key>
 <data>YnVpbHQtaW4=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleEthernetAquantiaAqtion</string>
 <key>Replace</key>
 <data>YmJiYmJiYmI=</data>
</dict>

PlistEDPlusで作業するなら、以下のようにします。

このように追記したconfig.plistを保存して再起動したところ、10G bps Ethernetカードが動きました。今のところ特に不具合はありません。

iperf3で動作試験

Morgonautさんのビデオではiperf3というツールで速度測定してました。これはLinuxなどで一般的な測定ツールのようで、Homebrewからbrew install iperf3コマンドでインストールできました。iperf3コマンドを2台のコンピュータで動かし、それぞれをサーバーとクライアントにして、通信速度を計測するツールです。

今回、ASUSの10Gbpsカードを取り付けたのがZ390マザーボードです。測定の相方は、ASUS ROG STRIX Z490-GのマザーボードにmacOS Big Surをインストールしたコンピュータです。このマザーボードには2.5 GbpsのIntel I225-Vが搭載されています。1Gbps超えのハブを持っていないので、ASUSの10GbpsカードとZ490をEthernetケーブル（CAT 6Aで十分らしいです）で直結しました。

Z390 (Aquantia 10Gbps) <-----> (Intel 2.5Gbps) Z490

それぞれのマシンに手作業で適当なアドレスを割り当てておきます。まずは、Z490マシンでiperf3をサーバーモードで動かしました。

iperf3 -s

一方、10Gbpsカードが載ったZ390マシンでは、サーバアドレスを指定して、クライアントモードでiperf3を動かしました。

iperf3 -c 192.168.x.x

その結果、両方に同じ測定結果が表示されます。クライアント側の表示を以下に示します。

% iperf3 -c 192.168.x.x
Connecting to host 192.168.x.x, port 5201
[ 5] local 192.168.x.x port 49648 connected to 192.168.x.x port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 244 MBytes 2.05 Gbits/sec
[ 5] 1.00-2.00 sec 246 MBytes 2.06 Gbits/sec
[ 5] 2.00-3.00 sec 247 MBytes 2.07 Gbits/sec
[ 5] 3.00-4.00 sec 244 MBytes 2.05 Gbits/sec
[ 5] 4.00-5.00 sec 247 MBytes 2.07 Gbits/sec
[ 5] 5.00-6.00 sec 245 MBytes 2.05 Gbits/sec
[ 5] 6.00-7.00 sec 247 MBytes 2.07 Gbits/sec
[ 5] 7.00-8.00 sec 245 MBytes 2.05 Gbits/sec
[ 5] 8.00-9.00 sec 250 MBytes 2.10 Gbits/sec
[ 5] 9.00-10.00 sec 249 MBytes 2.09 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 2.41 GBytes 2.07 Gbits/sec sender
[ 5] 0.00-10.00 sec 2.41 GBytes 2.07 Gbits/sec receiver
iperf Done.

結果は2.07Gbpsと、2G以上の速度が出ていました。片方が2.5 Gbpsなので、それ以上は出ません。ネットの転送には色々オーバーヘッドがあるので、これくらい出ていれば十分だと思いました。また、今まで相方がいなかったので不明だったのですが、Z490の2.5Gオンボード有線LANが性能通りの速度で動いていることも確認できました。

OOBの10Gbpsカード

同じAquantiaのチップ搭載カードでも、Sonnetの製品ならばOOBで動くようです。以下のAmazonの販売ページにも、macOS対応と書かれてます。ASUSのカードより3,000円ほど高価です。今回はたまたま手元にASUSのカードがあったのでそれを試しましたが、この価格差ならば、パッチが不要なSonnetカードの方が良いと思います。（コメントいただいた情報によると、SequoiaではこのカードもOOB動作しないようです。 2025/09/15）

Big Sur 11.1にアップデートする

Fri, 18 Dec 2020 23:49:55 +0900

macOS Big Sur 11.1が配布されたので、11.0.1からアップデートしました。アップデートしたのは、Z390マザーボードとZ490マザーボードのマシンです。どちらもOpenCore 0.6.4で起動していて、kext類は最新です。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐアップデート」ボタンを押しました。

この後、3.27GBのアップデートファイルがダウンロードされ、再起動します。最初の再起動では、どういうわけか同じ名前の起動ボリュームが見えていました。どちらかがアップデーターのボリューム（従来だとBoot macOS Install from …というような名前でした）で、どちらかが古いmacOSだと思われます。デフォルトで起動ドライブになっていた左側を選択すると、インストールが進みました。

この後、2回ほど再起動をします。2回目以降の再起動時には、起動ボリュームは1個だけに戻っていました。インストール後、何の問題もなくBig Sur 11.1が起動しました。

特に気づく変更点はありません。ビルドは20C69になってました。

M1 MacBook Airの良いところ

Sat, 12 Dec 2020 01:08:40 +0900

普段使いのノートとして古いMacBook無印を使っていたところへ、M1 MacBook Airがやってきました。重いけど速くて使いやすくて気に入りました。使ってみて気づいたところを書き連ねます。

M1 Mac

M1搭載MacはMac mini, MacBook Air, MacBook Proと3機種出ました。ハードウエア更新がいつも後回しな印象のあるMac miniが、新CPU搭載ラインナップに加わっているのは嬉しかったです。ただ、こんなにスカスカなのに、一切拡張できないのは残念です。メモリーソケットとM.2ソケットをつけて、2.5インチSATAドライブを2台は搭載可能な感じです。

(出典：egpu.io)

それで注目なのはAirだと思いました。3機種とも同じCPU/GPUで、メモリとSSDの構成も同じです。一切拡張できない点も同じです。ならばM1の小型・省電力という特徴を生かした軽くてファンレスのAirが面白いと考えました。

キーボードが良い

Late 2019 MacBook Proからすでに改良されている点で、今更報告するほどのことではないかと思いますが・・・キーボードが良くなってました。MacBook無印のキーボードは、評判の悪いバタフライ型でした。薄いけど、沈み込みが少なく、ペチペチと安っぽい打鍵音がします。打ちにくさは慣れれば克服できるのですが、打鍵音がうるさいので、周囲に人が居る会議や公共の場で使いにくかったです。薄さを追求したMacBook無印には薄いバタフライ型が必要だったのかもしれないですが、厚いMacBook Proにも使われてました。評判が悪い上に、動作不良になることも多くて、2019年11月からのMacBookシリーズでは、元のシザー型のキーに戻りました。薄いキーを諦めた結果、MacBook無印は終了になってしまいました。

M1 MacBook Airも、改良されたキーを搭載しています。デスクトップ用のApple Magic Keyboardと同じキーになっているそうで、慣れ親しんだいつもの打鍵感覚を得られます。MacBook無印と比べると打鍵音がほとんどしないのがとてもありがたいです。ファンレスで動くM1チップならば、MacBook無印の筐体で薄型軽量なモデルを作って欲しかったと最初は考えていました。実際、無印に比べてAirはずっしりと重いのですが、このキーボードのためなら我慢しても良いと思えました。それくらいキーボードが良いです。

Touch IDが便利

これも目新しいことではないですが、Touch IDが便利でした。Windowsノートには指紋デバイスが、はるか昔から搭載されてました。MacBookシリーズにも2016年のTouch Barから搭載されてます。なので単に疎かっただけなのですが、使ってみたら便利でした。Apple Watchで認証するには、装着していないと使えません。指紋ならいつでも対応できます。デスクトップ向けのMagic KeyboardにもTouch IDをつけてくれたら良いのにと思いました。

CPUとGPUが速い

省電力で小型軽量マシン向けのCPUだと思われていたところが、ベンチマークのスコアが予想以上に高くて、評判になってます。ここでは、デスクトップの自作macOSマシンと、改めて比較しました。構成はASUS Z490-G + 10900K + RX-5700XT + OpenCore 0.6.4 + Big Surです。まずはGeekbench 5のCPUスコアの比較です。シングルコアはM1が優ってます。マルチコアの結果も、4+4物理コア対 10物理コア+10HTの対決にしては、M1は頑張っています。省電力物理コアは、インテルのHTによる仮想コアよりも仕事が出来る感じです。グラフィックスの性能は冷却もしっかり効いたdGPUに敵いませんが、IntelのiGPUに比べたら高性能です。


	M1 MacBook Air	自作 macOS
CPU	M1	10900K
GPU	M1	RX-5700XT
メモリ/SSD	8GB/256GB	32GB/250GB
CPU シングル	1,714	1,335
CPU マルチ	7,394	11,041
GPU OpenCL	16,701	66,296
GPU Metal	18,727	69,797

Cinebench R23も試しました。デフォルトでは10分間の試験をすることになってますが、時間がかかるので１回だけ走らせました。10分間テストを実施したらファンレスのMacBook Airはスコアが下がったかもしれません。アクティビティモニターによるCPU稼働率も一緒に示します。M1では、高性能コアも省電力コアもどちらもしっかり仕事をしている印象です。省電力コアが足を引っ張るような振る舞いは見られませんでした。

こちらは10900Kの様子です。

スコアは、以下のようです。GeekbenchのCPUマルチのスコアよりは差が開きました。でも、ローエンドMacに搭載された省電力CPUとしては、今までにない高性能です。


	M1 MacBook Air	自作 macOS
Cinebench R23	7,063	16,230

SSDの速度をAmorphousDiskMarkで測定しました。時間がかかるのでこれも最初の項目だけのテストです。M1 MacBook Airも自作PCもどちらも250GBなので、SSDの性能は同じようなものだと思います。後述するように、M1は接続がApple Fabricです。スコアは以下のようでした。

こちらはASUSマザーボード上のM.2ソケットに取り付けたWDの250GB SSDの速度です。M.2 SSDの方がWriteは遅かったですが、Readは同程度でした。接続方式の違いではなく、SSDの特性の違いと思われます。

iOSアプリが使える

M1チップのMacではiOSアプリが使えます。App Storeで検索するときに、「iPhone および iPad App」を選ぶとiOSのアプリが出てきます。これを見ると、iOSのアプリのかなりがM1 macOSで動作するようです。キャッシュレス決済アプリを入れておけば、スマホを忘れても、MacBookさえ持っていればコンビニで買い物ができます。画面上部のカメラも起動できるので、店頭QRコード支払いも可能なようです。このほかiPhoneで使っていたタイマーアプリ、Wi-Fi接続家電のリモコン、電卓などをダウンロードして使えました。

謎アーキテクチャの探索が楽しい

今回のMac新モデルで一番楽しい点は、Apple Siliconという新しいアーキテクチャを探索できるところです。謎なところをいくつか探ってみました。もし詳しい情報をご存知の方がいらしたら、教えていただければと思います。まずは、Z490マシンでmacOSのCPU名を調べるコマンドを打ち込むと、

% sysctl -n machdep.cpu.brand_string 
Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz

のように、詳しい名前やクロック数が表示されていました。M1 MacBook Airでこのコマンドを打つと、こんな表示になります。

% sysctl -n machdep.cpu.brand_string
Apple processor

そっけなくて、詳細な仕様を謎のままにしておきたいという意図を感じます。

unameコマンドでは、OSの名前を表示できます。インテル版のBig Surで実行すると以下のような表示が出ます。

% uname -a
Darwin chimney.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64

X86 64のためのリリースだと書いてあります。M1 MacBook Airでこのコマンドを打つと、以下のように表示されました。

% uname -a
Darwin air2020.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8101 arm64

ARM64アーキテクチャの、ARM64 T8101のためのリリースとのことです。T8101をネットで検索してみたら、iPhone 12シリーズに搭載されているApple A14 Bionic SoCの型番だそうです。M1チップは、A14に非常に近い仕様なのではと想像できます。

Z490マザーボードのM.2ソケットに取り付けたSSDをディスクユーティリティで見ると以下のようでした。名前の説明に「PCI-Express内蔵物理ディスク」となっていて、PCI-Express接続になってます。

M.2ソケットにはPCIeの配線がつながっていて、SSDはそれに接続しているので当然の表示です。一方、M1 MacBook AirのSSDを、同様にディスクユーティリティで調べてみます。すると、名前の説明が「Apple Fabric内蔵物理ディスク」になり、接続先がApple Fabricになってます。このSSDはPCI-Expressとは違った接続のようです。

「システム環境」のSSDの項目にもApple Fabricの記述があります。Appleのサイトの図によると、FabricとはCPU, GPU, メモリーなどが接続されている内部バスのようなものらしいです。ここにSSDが接続されているようです。PCIeは無くなってしまったのでしょうか？

HackintoolやIORegistryExplorerなどで調べると、一応はPCIeらしきものの一覧が出てきます。また、Display controllerとしてAMDのRadeon R7 370 / R9 270X/370XがPCIeの一覧に見えます。

でもどのDevice Pathも0番になっていて、怪しい感じです。Systemのタブを見ると、CPUは2.50GHzのVirtualAppleとなってます。

同様の情報は、MacCPUIDを動かしても得られました。やはりVirtualAppleという名前のCPUになってます。アーキテクチャはWestmereという太古のインテルCPUの設定です。おそらくは、Hackintoolに表示されている情報の、Intel Generationが???になっている部分を、Westmereと判断したのだと思います。

Hackintoolを動かす前にRosetta 2をインストールしてくださいというダイアログが出てました。なので、これらの情報は、Rosetta 2が提供しているフェイクな情報ではないかと思います。Intel版macOSアプリを動かすために、Apple SiliconアーキテクチャをIntelアーキテクチャに偽装しているとしたら、これはhackintoshに通じるテクニックだと思います。

まとめ

新しいM1 MacBook Airを使ってみました。今まで使っていたMacBook無印と比べると重量が重くなりましたが、動作は軽く、キーボード、Touch ID、iOSアプリが使えて便利です。Appleオリジナルの新しいCPUになったので、今までと違う内部情報が得られました。

OpenCore 0.6.3から0.6.4に更新

Wed, 09 Dec 2020 01:12:11 +0900

OpenCoreの0.6.4が公開されたので0.6.3からアップデートしました。config.plistの変更点は少ないですが、PlayChime項目がbool型からstring型に変更されてます。なので今までのconfig.plistではエラーが出るようです。

0.6.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Bootstrap/Bootstrap.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。

config.plistを更新する

現在のconfig.plistをconfig_063.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、比較しながら新しいconfig.plistを作りました。

気付いた変更点は以下です。

Booter/Patchが追加されていました。Itemが1個有りますが、sample.plistではenabled=falseなので機能はしていないようです。
Booter/QuirksにAllowRelocationBlockが追加されてます。これもfalseなので影響はないようです。「relocation blockからmacOSを起動する」という指定らしいです。カーネルを読み込むメモリが足りないときに使えるようです。起動に問題なければfalseで良いようです。
Misc/SecurityにBlacklistAppleUpdateが追加されてsample.plistではtrueになってます。デフォルトはfalseです。Apple周辺ファームウェアのアップデートを試みないように設定します。Big Surで、NVRAMでこれを設定できない場合のために設けられました。Big Surならtrueでも良いと思いました。
Misc/SecurityのBootProtectがsample.plistではNoneになってます。以前のsample.plistではBootstrapでした。bootloader persistence を提供する機能らしいです。新しいサンプルに従ってNoneを試したところ、一応起動するのですがESPがマウントできない問題が発生しました。再起動ではokでした。なのでBootstrapに戻しました。
UEFI/Audio/PlayChimeがstring型のAutoになってます。今まではbool型のfalseにしてましたが、それではエラーが出るようです。string型のAuto, Enabled, Disabledから選びます。起動音を使ってないのでDisabledにしました。

いずれも大きな変更ではなさそうです。でも、PlayChimeのフォーマットが変更されたことには、対応が必要です。以上の設定で、0.6.3から0.6.4に移行できました。

OpenCore用のミニマムなテーマ

Tue, 08 Dec 2020 00:54:18 +0900

OpenCore用のミニマムな起動画面アイコンが公開されてます。作者の方がredditで紹介してました。これを使う前に、まずはOpenCanopyの設定をしておきます。

OpenCoreの選択画面をグラフィカルにする

次に、以下のGithubのサイトからダウンロードして、アイコンファイルをEFI/OC/Resources/Imageにコピーして、同じ名前のアイコンを差し替えます。また、config.plistのMisc -> Boot -> PickerAttributesを1にしておいてくださいとのことです。デフォルトは0ですが、1にするとカスタムアイコンを読む設定になります。

GitHub - tekteq/opencanopy-minimal-theme: Minimal theme for OpenCanopy/OpenCore

OpenCanopyのデフォルトアイコンは、実機と同じデザインなので、できる限り本物のMacを再現したいという目的には合ってます。以下がOpenCanopyのアイコンで、

以下が実機Macでのボリューム選択画面の表示です。HDDの反射具合や支柱の太さが微妙に違いますが、ほぼ同じです。

リアリティを志向したオリジナルアイコンとはかなり違って、tekteqさんのアイコンはおしゃれな感じです。さらに、OpenCoreの起動画面に引き続き、macOSが表示するブート画面にも同じ形とサイズのAppleアイコンが表示されるので、一連の流れが美しいです。どっちもありかなと思いました。

HPの小型デスクトップEliteDesk (6: Windowsを入れる)

Sun, 06 Dec 2020 00:53:46 +0900

いろいろ頑張ってきたHP EliteDesk 800 G2 DM (Core i5-6500T)ですが、Windowsをインストールしました。Hackintoshとしては完敗です。macOSからはWindowsを画面共有で使います。sshでUbuntuも使います。電源が切れてても使えるようにWake On LANの設定もしました。

Microsoft Remote Desktop

最近はWindowsが絶対必要という場面が少なくなりましたが、世の中がWindows前提なので、たまにWindowsを使わざるを得ない時があります。Hackintoshなら、マルチブートにしておけば、同じマシンでWindowsが使えますが、切り替えが面倒です。VMware Fusion Player 12 が個人利用で無償になって、かなり快適でした。なので仮想環境でWindowsを使う手もあります。マルチブートに比べて性能は出ませんが、macOSとの切り替えが簡単です。今回は第3の選択肢として、Windowsマシンを別に用意して、これにリモートデスクトップする方法を試します。

そこで、macOSをインストールしようとして暗黒画面問題で挫折したHP EliteDesk 800 G2 DM

HPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)

にWindowsを入れて、ディスプレイ無しのリモートデスクトップサーバにします。macOSは諦めて、ただのWindowsマシンに戻すのですから、BootmacOSの路線からしたらダメダメな状況です。すみません。でもWindowsマシンが用意できれば、これにmacOS用のMicrosoft Remote Desktopで接続することでWindowsが使えます。Remote Desktopクライアントプログラムは、無償で配布されていて、使いやすいです。応答も素早いので、仮想マシンより快適な気がしました。

Remote Desktopを起動すると、接続先を選べるようになります。接続先のマシンを何個も登録できるインタフェースでした。職場の何台ものWindowsマシンを管理するような状況を想定しているのかもしれません。

HP EliteDesk 800 G2 DMは小型なのでiGPUで動きます。M1が話題になって貧弱さが際立っているインテルiGPUなので、このままディスプレイには接続しないで、ヘッドレスのリモートデスクトップサーバとして使おうと考えてます。小さなマシンなので、邪魔にならないです。

Windowsをインストール

まずはHP EliteDesk 800 G2 DMにWindowsをクリーンインストールします。macOSマシンにされていたところが、本来の姿に戻ることになります。でも元からあったWindowsは綺麗に全消去されているので、起動できるUSBメモリインストーラを作ります。そこで、Z390 + 9900K + OpenCore 0.6.3 + Big Sur の構成のマシン（機種IDはiMac19,1）で以下の作業をしました。Windowsインストール用のISOイメージファイルがダウンロードできるMicrosoftのサイトに行きました。

Windows 10 のディスクイメージ (ISO ファイル) のダウンロード

とりあえずダウンロードしてみたところ、Windowsのイメージファイルは6GBほどでした。12GB超えてるBig Surに比べて優しいですね。

これから頑張れば、インストール用USBメモリをmacOS環境でも作れないことはないです。でも結構難しい作業で、適当に試しても失敗ばかりでした。USBメモリをFAT32でフォーマットするのですが、コピーしなければならないファイルの一つが、FAT32の限界の2GBを超えているところがネックです。それを乗り越える技が複雑過ぎました。

結局、macOSで頑張るのは諦めて、Windowsでインストール用USBを作ることにしました。このマシンの、Big Surとは別のSSDにWindows 10が入っています。OpenCoreでWindows起動SSDを選択して起動し、上記のMicrosoftのサイトに接続しました。すると、ISOイメージファイル以外に、起動可能なUSBインストーラを作成するアプリケーション「Media Creation Tool」がダウンロードできるようになってます！。macOSからこのページを開いても、Media Creation Toolの選択肢は見えませんでした。Media Creation Toolは、macOSのcreateinstallmediaコマンドとよく似た名前で、同じような機能のプログラムです。ですが、Windows版の方が完成度高いです。CUIコマンドのmacOS版と違って、GUIで起動して、ISOイメージを自動でダウンロードして、そのままUSBメモリに書き込んでくれます。とても楽でした。

BIOSもアップデート

ついでにBIOSもアップデートしておきました。HP EliteDesk 800 G2 DMのBIOS画面に、ネットワークからダウンロードして更新するメニューがあります。クリックするだけで最新版 (2020/11/6版の02.51 Rev.A) になりました。以下はHPのサイトですが、ここからダウンロードする必要はありませんでした。

HP EliteDesk 800 35W G2 Mini PC ソフトウェア及びドライバーのダウンロード | HP…

デジタルライセンス

HP EliteDesk 800 G2 DMの筐体のどこを見てもWindowsのプロダクトキーが書いてありません。Windowsを買わないとダメなのか、全消去するんじゃなかったと少し後悔しました。ところが今やデジタルライセンスの時代だったんですね。このマシンの情報がすでにどこかのサーバに登録されているらしく、Windowsインストール作業最初のプロダクトキー入力をスキップしても、自動的に認証されてました。SSDもメモリもCPUも交換してしまっているので、BIOSのシリアル番号のようなもので個体識別しているようです。メーカー製PCにはWindows代が含まれているので当然の結果かもしれませんが、予想外でありがたかったです。ハードにOS代が含まれていることは、よく考えたらmacOSも同じです。

HP EliteDesk 800 G2 DMの中古価格は、Core i3モデルが1.5万円くらい、i5モデルでも2万円くらいです。一方で、マルチブートしたり、仮想環境を使ってWindows 10 Proを起動する場合には、パーツに紐付けたDSP版でも1.7万円くらい、通常版なら2万円以上のライセンス代が必要になります。そう考えると、デジタルライセンスが付いた上にCPUもメモリも手に入る中古のハードを買うのは、お得な手段なのではと思いました。

リモートデスクトップサーバを有効化

インストールしたWindows 10で最初に行った作業は、リモートデスクトップサーバをonにすることです。これでmacOSから作業ができます。設定する場所が「設定」だったり「コントロールパネル」だったり混乱します。

WSLを入れる

次に行った作業は、WSL (Windows Subsystem for Linux) を有効にすることです。

そして、Microsoft StoreからUbuntu 20.04 LTSをダウンロードしてインストールしました。WSLがあってLinuxが使えることは、macOSユーザから見てちょっと羨ましいです。

とはいえ、WindowsとLinuxではディレクトリ構成が違います。ディレクトリ階層の区切りも¥と／で違います。ファイルやフォルダをUbuntuのウィンドウにドラッグ&ドロップしても、Linuxが理解できるディレクトリ文字列になりません。macOSファインダとターミナルのような円滑な操作性ではなく、ぎくしゃくしている印象です。Windows上の仮想環境でLinuxを動かしているので仕方ないですが、もう少し統合してほしいと思いました。ネイティブに動いているmacOSのUNIX環境が、シームレスで使いやすいことを改めて実感しました。

Dropboxを入れる

One Driveの方がWindowsとの相性が良いのでしょうが、Dropboxを使ってます。One Driveは、昔試したことがありますが、macOSとの相性が悪かったです。One Driveでは、Windowsの規則で、ファイル名に使えない文字があります。例えば、CON, PRN, AUXという名前はファイル名・フォルダ名に使えません。また、” * : < > ? / \ |などの文字も使えません。Dropboxにはそのような制約はありません。自分で作るファイルなら命名に気をつければ良いのですが、例えばアプリケーションのパッケージの中に、たまたまこのような名前のファイル・フォルダがあると厄介です。これらがOne Driveにコピーする際に除外され、アプリケーションの内容が変わってしまいます。実際にそのような事例が発生しました。現在のOne Driveも同様な命名規則を引き継いでいるのかどうかわかりませんが、こういう理由で使用を避けてました。

SSHサーバを入れる

昔のWindowsでsshを使うのは面倒だった記憶がありました。でもWindows 10ではsshクライアントが標準で入っているようです。PowerShellから使えました。でもsshサーバ (sshd) はOpenSSHを自力でインストールする必要があります。

一方で、WSLのUbuntuには、あって当然なのですが、sshのクライアントとサーバが入っています。Ubuntuのsshサーバは、以下のコマンドで起動することができます。

sudo service ssh start

ということで、sshdを使うには、

Windowsのsshdを使う
Linux (WSL-Ubuntu)のsshdを使う

の2種類の選択肢があります。ここはすでにインストール済みのLinuxにしました。Windowsルートは手順が大変そうでしたが、Linuxルートにも罠がありました。普通のLinuxなら

sudo systemctl enable sshd.service

というような類のコマンドで、起動時に自動的にsshdが起動するように設定できました。でもWSLでは技術的な事情でsystemctlコマンドが動かないようです。なので、コンピュータを起動するたびごとに、

sudo service ssh start

のコマンドを発行する必要があります。これは自動化したいところです。ちょっと調べたところ、PowerShellからWSLのコマンドを発行する命令があるらしいです。その名もwslです。これを使って、

@echo off
wsl -u root -- service ssh start

というbatファイルを作ると、Windows環境から、–の後に書いたLinuxの命令がroot権限で出せるようです。batファイルなんて書くのはものすごく久々でした。

Windowsのbatファイルなので、これはWindowsで実行できます。なのでこのbatファイルを、Windowsが起動した直後に実行するよう設定すれば良いです。でもこの方法もかなり試行錯誤しました。結局は、コントロールパネル–>システムとセキュリティ–>管理ツール–>タスクスケジューラに行きついて、ここで「スタートアップ時（システム起動時）に」「ログインしているかどうかにかかわらず実行する」設定で、batファイルを登録すれば良いようでした。

sshdが起動するように設定するには、Linuxならコマンドひとつ、macOSだと「システム環境設定」「共有」で「リモートログイン」をクリックするだけです。Windows (WSL) だと深い階層の幾つもの設定が必要で大変でした。でもこの作業の結果、電源を入れるだけでLinuxのsshdが応答してくれる状態になるので、別のマシンからssh接続すればUbuntuのシェル環境が使えます。Windows環境が用意されただけでなく、いつでも試せるLinux環境も出来上がったので、ちょっと嬉しいです。

Wake On LANを設定

次にWake On LAN (WOL)を設定しました。これに関しては、Windowsは素晴らしい！です。WOLは、ネットワークの他のマシンから、スリープ中や電源切れているコンピュータを目覚めさせる機能です。そのために、相手のMACアドレスを指定して、マジックパケットという謎のパケットを送りつけます。マジックパケットを送るアプリケーションは多数ありますが、Pythonで書けばこんなプログラムで可能なようです。

#!/usr/bin/python
import socket
s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
s.sendto('\xFF'*6+'\x99\xAA\xBB\xCC\xDD\xEE'*16, ('192.168.xxx.255', 7))

最後の行に、目覚めさせたいコンピュータのNICの情報を書きます。\x99\xAA\xBB\xCC\xDD\xEEの部分がMACアドレスで、192.168.xxx.255がIPアドレスです。IPアドレスの最後が255なのは、ブロードキャストするためです。ここを機器のアドレス通りにしても、一応は起動するようです。でも今回のマシンで試したところ、offした後しばらくは起動しますが、時間が経つと失敗します。シャットダウンしてからしばらくすると、スリープモードが深まるのか、自分のIPアドレスがわからなくなるようです。255にしておけば、必ず成功します。

macOSでは、「システム環境設定」「省エネルギー」の「ネットワークアクセスによるスリープ解除」で、Wake On LANを有効にできます。以下は、「省エネルギー」のデフォルト設定ですが、デフォルトで有効になってます。このほかにもBIOSでWOLを有効にしておく設定が必要です。

Windowsの場合は、デバイスマネージャの中のいくつかの設定でWOLを有効にします。ここではWake On Magic Packetが有効であることを確認してますが、このほか「電源の管理」タブも関係があります。一般的にmacOSよりも設定箇所が多い傾向にあると感じますが、デフォルトのままで大丈夫でした。ちなみにネットワークアダプターのドライバを、上記のHPのサイトからダウンロードしないと、WOL関係の設定が現れなかったです。Windowsの標準ドライバーでは、最新に更新してもWOLの設定がありませんでした。このほかBIOSの設定も確認する必要があります。

幾つか試行錯誤しつつ設定したところ、macOS（前述のZ390マシン）でも、このWindowsでも、どちらもマジックパケットを送ってスリープから目覚めさせることができました。

macOSでは、スリープ状態に対してのみ、WOLが効くようでした。電源を落としてしまうとWOLは効かなくなります。少し検索しただけなのですが、ネットにもやっぱりそう書いてありました。もし、電源も入れられるようなWOL設定の情報ありましたら、教えていただければとても助かります。

一方、Windowsでは、なんと電源を切った状態でもWOLが効きます。電源の落ちたマシンにマジックパケットを送ると電源投入できました。これはちょっと素晴らしいです。

訂正：hackintoshなら電源を切った状態からのWOLが効きます。以下をご覧ください。

Wake On LAN (WOL) を使ってmacOSの電源を入れる

追記：Windows 10のWOL

その後、起動ディスクをM.2 SSDに変更しようとして、Windows 10のクリーンインストールを再度行いました。そうしたら電源offでのWOLが効かなくなりました。結局は、再びWOLが動くようにできたのですが、そのポイントをメモしておきます。

LANのドライバーは最新にします。Windowsに最初に入っている、または更新からダウンロードできるIntel LANドライバーにはWOLの設定項目がありません。HPのサイトからダウンロードするとWOLの設定があります。これがないとsleepからのWOLもできないです。
「高速スタートアップ」をoffにします。これがOnだとシャットダウンからのWOLができなかったです。
スリープ中やシャットダウン時に、LANコネクタのLEDが点灯していることが重要です。これが消灯している状態だと如何なるパケットも受け付けないようで、WOLもしません。
BIOSでシャットダウン時にS5に移行するよう設定すると、WOLしません。Off状態ではLANコネクタのLEDも点灯しません。デフォルトはS5ではないので、注意すべき点ではないですが。

WOLはいろいろとややこしいです。シャットダウンしないと、機能しているかどうかを確認できないので、結果がなかなかわからないこともあり、手間がかかります。そこを設定するところが達成感を得られて楽しいところです。

まとめ

暗黒画面問題で頓挫したHP EliteDeskは、結局のところWindowsマシンとして復活しました。ディスプレイは接続せず、macOSからMicrosoft Remote Desktopで使用します。Windowsのデジタルライセンスが効いていたので無償でした。さらにWSL、SSHサーバ、Wake on LANなどを設定しました。このプライベートネットワークには、ルータのVPN機能を使ってL2TP over IPSecでインターネットから入れるようにしてあります。なので

外出先からVPNで接続する
Pythonプログラムでマジックパケットを送る
電源が切れているHP EliteDeskが起動する
sshまたはRemote Desktopで接続する

という手順で、世界中どこからでも、このWindowsマシン（Ubuntu付き）をmacOSから利用できるようになりました。今後は、電源が切れている自作Z390 macOSマシンも、外部から起動して使えるように考えたいです。

M1 Mac miniと自作PCのコスパ勝負

Fri, 04 Dec 2020 21:56:45 +0900

M1 Mac miniが予想以上に高性能なので話題になってます。価格も安いので、自作する意味は無くなったのでしょうか。自作機とコストパフォーマンスを比較しました。

M1 Mac miniのスコア

Geekbench Browserによると、M1 Mac miniのCPUスコアは

Single 1,700
Multi 7,500

くらいのようです。発売前の予想以上に性能が高いので評判になってます。特にシングルの性能が高いです。一方で内蔵GPU (iGPU) は、

OpenCL 19,500
Metal 22,000

くらいのようです。どちらも同程度の値なので、以下ではOpenCLで比較します。

M1相当の自作パーツ

最近のOpenCoreベースのhackintoshは、Geekbenchにスコアを上げるとAcidantheraというキーワードが入ります。そのキーワードで検索しました。現行CPUの中で、マルチで7,500が出るものを探すと、10700あたりになります。10700は概ね以下のスコアでした。

Single 1,200
Multi 8,500

M1と比較するとシングルで負けてマルチで勝ってます。マルチは9000超える結果も多数登録されてますが、シングルで負けているので、10700あたりがM1に相当する性能かと考えました。一つグレードを下げて、10600の結果を探すと、マルチが7000未満になるので、こちらは明らかにM1に劣ってしまいます。

一方で、OpenCL, Metalで2万台のスコアを出す結果を探してみると、RX-560を搭載したマシンが、大体25,000程度のスコアでした。ということで、M1搭載Mac miniと同等の性能を出すマシンを自作するためには、CPUに10700を、GPUにRX-560を選択すれば良いことになります。

mini最小構成で比較

M1 Mac miniの最小構成ではメモリが8GBで、SSDが256GBです。デスクトップマシンとしては少ないです。でも世間の評価を見ていると、メモリの効率が良くなったので8GBでも困らないという説もあります。SSDも少ないですが、クラウドストレージが一般的なのでこれでも実用性があるのかもしれないです。最小構成の価格は、税込で80,080円です。

これに対して、10700 + RX-560の構成で、いくらで自作できるのか調べてみました。kakaku.comの価格で計算してくれるサイトがありました。

ここで現行製品で見積もってみます。RX-560は既に販売されてなくて中古しかないようです。RX-570なら販売されてました。中古価格で見積もっては不公平だと思うので、RX-570に変更しました。こちらはGeekbenchで調べるとスコアが4万くらいなので、性能はM1 iGPUの倍になります。他の部品は、安めのものを選びました。その結果、

【CPU】インテル Core i7 10700 ¥38,272
【CPUクーラー】サイズ 虎徹 MarkII SCKTT-2000 ¥3,938
【メモリ】Corsair CMK16GX4M2A2666C16 [DDR4 PC4-21300 8GB 1枚] ¥3,290
【マザーボード】ASRock H470 Phantom Gaming 4 ¥12,882
【ビデオカード】MSI Radeon RX 570 8GT OCV1 [PCIExp 8GB] ¥15,734
【SSD】ADATA XPG SX6000 Lite ASX6000LNP-256GT-C ¥3,980
【ケース】Thermaltake CA-1J5-00M6WN-01 ¥4,117
【電源】玄人志向 KRPW-BK650W/85+ ¥6,264
【Wi-Fi/Bluetooth】Fenvi T919 ¥5,100
【合計】¥ 93,677

となりました。Wi-Fi/Bluetoothカードは、上記の見積もりサイトには当然ながらありませんので、を追加しました。コストと性能をまとめると以下になります。


	M1 Mac mini	自作 macOS
CPU	M1	10700
GPU	M1	RX-570
メモリ/SSD	8GB/256GB	8GB/256GB
CPU シングル	1,700	1,200
CPU マルチ	7,500	8,500
GPU OpenCL	19,500	40,000
税込価格	80,080	93,677

改めてM1 Mac miniのお買い得度がわかります。miniはメモリもSSDも拡張できないという欠点があります。SSDは外付けするという手がありますが、メモリは増強できません。でも純正Macなので、hackintoshの苦労（たのしみ？）が不要という大きなメリットがあります。この構成ならばMac miniを買った方が良いですね。

mini最大構成で比較

次に、Mac miniをオプション全部盛りの条件で比較します。とは言っても、メモリを16GBにしてSSDを2TBにできるだけです。SSDは個人的には1TBもあれば十分なのですが、動画編集などされる方は、これくらい必要なのかもしれません。価格は税込190,080円になります。

自作する場合も計算しなおします。メモリを16GBにして、SSDを2TBすると、以下になります。

【CPU】インテル Core i7 10700 ¥38,272
【CPUクーラー】サイズ 虎徹 MarkII SCKTT-2000 ¥3,938
【メモリ】Corsair CMK16GX4M2A2666C16 [DDR4 PC4-21300 8GB 2枚組] ¥6,573
【マザーボード】ASRock H470 Phantom Gaming 4 ¥12,882
【ビデオカード】MSI Radeon RX 570 8GT OCV1 [PCIExp 8GB] ¥15,734
【SSD】WESTERN DIGITAL WD Blue SN550 NVMe WDS200T2B0C ¥26,379
【ケース】Thermaltake CA-1J5-00M6WN-01 ¥4,117
【電源】玄人志向 KRPW-BK650W/85+ ¥6,264
【Wi-Fi/Bluetooth】Fenvi T919 ¥5,100
【合計】¥ 119,359

こちらも表にまとめると以下になります。


	M1 Mac mini	自作 macOS
CPU	M1	10700
GPU	M1	RX-570
メモリ/SSD	16GB/2TB	16GB/2TB
CPU シングル	1,700	1,200
CPU マルチ	7,500	8,500
GPU OpenCL	19,500	40,000
税込価格	190,080	119,359

AppleのBTOでメモリ/SSDを追加すると割高ですね。自作との差額は7万円強になります。SSDを1TBにすれば、差額は縮まって5.5万円くらいです。純正か自作かどちらを選ぶか微妙になってきます。将来のアップグレードの可能性があるという点で、自作を選ぶ選択肢もありかと思います。

こだわりのパーツで自作

ここまで考えた自作構成は、M1のiGPUに合わせて、かなり控えめの構成です。こだわりのパーツで作ってみようと思ったら、この構成にはならないように思います。ある程度予算には配慮しつつも、こんな自作をしてみたいという構成を考えてみました。

【CPU】インテル Core i9 10900K BOX ¥58,376
【CPUクーラー】サイズ 虎徹 MarkII SCKTT-2000 ¥3,938
【メモリ】Corsair CMK16GX4M2A2666C16 [DDR4 PC4-21300 8GB 2枚組] ¥6,573
【マザーボード】ASUS ROG STRIX Z490-F GAMING ¥25,278
【ビデオカード】MSI Radeon RX 5700 XT GAMING X [PCIExp 8GB] ¥41,000
【SSD】crucial P1 CT1000P1SSD8JP ¥11,248
【ケース】Thermaltake CA-1J5-00M6WN-01 ¥4,117
【電源】玄人志向 KRPW-BK650W/85+ ¥6,264
【Wi-Fi/Bluetooth】Fenvi T919 ¥5,100
【合計】¥ 161,894

SSDは1TBで十分と考えました。CPUは一般向けIntel CPU最強の10900Kです。グラフィックスも、macOS対応モデル中最強クラスの5700XTです。マザーボードも良いものにしたいと考えました。良いマザーボードは高い部品が使われていて、手に持った感じがずっしりしていて良いです。でも、こだわったわりには、先ほどのリストから4万円くらいしか価格上昇してないです。

この構成を、同等のメモリ/SSD構成のMac miniと比較すると以下のようになります。


	M1 Mac mini	自作 macOS
CPU	M1	10900K
GPU	M1	RX-5700XT
メモリ/SSD	16GB/1TB	16GB/1TB
CPU シングル	1,700	1,300
CPU マルチ	7,500	11,000
GPU OpenCL	19,500	69,200
税込価格	146,080	161,894

同じメモリ/SSD構成のMac miniと比べて、自作機は1.5万円くらい割高ですが、性能はとても良いです。この性能が必要かどうかは別として、自己満足できる数値だと思います。

まとめ

新Mac miniと自作macOSマシンを、コストパフォーマンス比較してみました。miniはコスパが高いので、実用的な性能のマシンを安く作りたいという動機でhackintoshする意味は無くなったかもしれません。hackintoshする動機の一つに、「Mac miniとMac Proの中間のディスプレイ無しデスクトップマシンが欲しい」という理由がありました。今回登場したM1 Mac miniのおかげで、その希望を叶える純正選択肢ができたと思います。

とはいえ、上位iMacに相当する性能には到達していません。インテルのiGPUに比べたらM1のiGPUは別格の性能ですが、RadeonシリーズのdGPUには劣ってます。またメモリ, SSD, PCIeなどの拡張性はありません。自作には、好きな部品を選んで、拡張や組み合わせを楽しむ余地が残っていると思います。自作PCの歴史を振り返ると、メーカ製品に比べてコスパが良いという理由で、Windowsマシンの自作が流行した時代がありました。今は、そういう動機の一般人は撤退して、楽しいから自作するという人（と、最近はゲーマーの人かな）だけが自作界隈に居る状態だと思います。hackintoshもそうなったのかもしれません。macOSがインテルプラットフォームから完全撤退するまでの間は、自作を楽しんでいきたいと考えてます。

VMware Fusion Player 12を使う

Thu, 03 Dec 2020 21:34:52 +0900

無償で個人利用できるようになったVMware Fusion 12 Playerを使ってみました。無償ライセンスを入手するのが手間でしたが、インストールは簡単で素早く、機能も動作も満足のいくものでした。

無償になったPlayer版

VirtualBoxを使う記事、

HackintoshでVirtualBoxを使う

のコメントで、VMware Fusion 12 Playerが無償になったことを教えていただきました。こちらの記事が詳しいです。

個人なら無償インテルMac用仮想環境アプリ「VMware Fusion Player 12」レビュー (…

VMware Fusion 12はBig Surに対応したバージョンらしいですが、そのスタンダード版に当たるPlayer用のライセンスキーが、今回、個人利用者に対して無償で配布されることになったそうです。ということで現状のmacOSで利用できるVMアプリケーションは以下のようになりました。

Parallels（有料）
VMWare Fusion（個人利用は無料）
VirtualBox（無料）

VMwareの有料版も、かなり昔に使っていた記憶があります。有料なだけあって、Parallelsと同様に使いやすく性能が良かったです。それで早速、ASCIIの記事を参考に無償ライセンスキーと本体を入手しました。ASCIIの記事にあるように、入手場所は、webページの中のわかりにくい場所にあります。またユーザ登録が必要です。大昔に有料版を使っていた時に登録してあったのか（すっかり忘れてましたが）アカウントが残ってました。

ダウンロードして動かす

次にVMwareのサイトから本体をダウンロードします。インストールが終了するとこんなウィンドウが出ます。使用したマシンの構成はハードウェアがASUS Z390マザーボード + 9900Kで、ソフトウェアがOpenCore 0.6.3 + macOS Big Sur 11.0.1です。

VMware Fusionを起動すると、ライセンスキーを聞かれるので、サイトで入手した番号を入力します。

このウィンドウにも、無償ライセンスキーを取得するリンクのボタンがあります。先にソフトウェア本体をダウンロードして、その後に、ライセンスキーを取得に行くのがわかりやすかったかもしれないです。ライセンスキーを入れると、無事、受け付けてくれました。

この後、起動用のイメージファイルを選択する画面になります。Windows 10のisoファイルがあったので、それを選択しました。すると、特に設定の必要もなく、稼働ボリュームのイメージファイルが作られて、インストールが始まり、Windowsが起動しました。10分ちょっとくらいで終わってしまった感じで、速かったです。Windowsをアップデートしたりなどして、多少使った後の稼働ボリュームのファイルは20GB程度でした。今後さらに使用を続けていくと、必要に応じてサイズが大きくなっていくのだと思います。

まとめ

VMware Fusion 12が無償で利用できるようになっていたことを知り、インストールしました。ゲストOSとしてWindows 10をインストールしたところ、キビキビと動いていて快適です。VirtualBoxと比べて、元々が有償ソフトウェアなためか、高速に動く気がしました。以前から無償で利用できたVirtualBoxにはお世話になりましたが、Fusionをしばらく使ってみようと思いました。

HomePod miniを使う

Sun, 29 Nov 2020 00:19:43 +0900

HomePod miniを使ってみました。macOSからはAirPlayのスピーカーとして使えます。またHome.appからアラームの設定ができます。HomeKitのホームハブとして使えるそうですが、そちらは試せてません。

HomePod mini

Amazon EchoやGoogle Homeに比べて、Appleのスマートスピーカは高価なHomePod無印が1機種だけしかなく、普及に力を入れているという様子がありませんでした。でもHomePod miniが出て、競争力が付いたと思います。Echoは、安いのでいくつか使用してますが、結構便利です。でもAppleのエコシステムで生きているので、カレンダーやメッセージにアクセスできなくて物足りなく思ってました。今回、手頃な価格でコンパクトなHomePod miniが出たので、ようやく試せました。

設定

箱から出して、電源に接続して、iPhoneを近づけると、iPhoneに設定画面が現れます。このあとは数個の選択肢を設定していくだけです。

この辺りは、iOSを所有している会社の製品だけあって、手間要らずです。自社のアプリをダウンロードさせたり、起動させたりする手間が不要なだけでも有利です。Wi-Fiなどの設定も、Amazon Echoに比べたら格段に容易でした。てっぺんのLEDの点滅をiPhoneで撮影して、デバイスをペアリングする手法もスマートです。その結果、Wi-FiもBluetoothもApple IDも全てが、気づかないうちに設定終了してました。逆に言うと、iPhoneが無いと使い始めることもできないデバイスです。

このあと、Z390 + 9900KにOpenCore 0.6.3 + Big Sur 11.0.1の構成のmacOSマシンから何ができるのか試しました。無線ユニットは、純正Macと同じBCM94360CDです。

Hackintoshのパーツ選び【その4：無線編】

HomePod miniとの通信でBluetoothなども使っているのかなと思ったのですが、以下で紹介するAirPlayもHome.appも有線LANだけで動きました。BluetoothとWi-Fiをoffにしても同様に動きます。

AirPlayスピーカー

まずはサウンドです。デフォルトの選択肢からオフィスを選んであったのですが、その名前でAirPlayデバイスとして見えてます。これを選択するだけで、すぐに音が出ました。Bluetoothのペアリングは、簡単そうで失敗することも多いのですが、こちらは手間要らず機能します。キーボードの音量キーも操作可能でした。HDMIやUSBオーディオだとキーボードの音量キーが効かないことも多いので、これは助かります。

すでに色々な人が音質が良いとレビューしてますが、評判通り、音質はそこそこ良いです。ステレオスピーカーと比較すると、HomePod miniはモノラルなので、広がりに欠けるのは仕方ないです。ちなみに、2台のHomePod miniを用意すると、iPhoneからはステレオになります。でもmacOSのAirPlayではモノラルのスピーカーが2個に増えただけになってしまうらしいです。macOSで使う限り、1台だけ買えば良いようです。

しばらく使ってみると、いくつか不具合に気づきました。まず、YouTubeで動画を止めたり動かしたりしていると、HomePod miniの設定音量とずれてしまうことがありました。また、macOS警告音の「サウンドエフェクトの再生装置」として、システム環境設定の選択肢にHomePod miniが現れることもあれば、現れないこともあります。バグのような感じなので、そのうち直してくれるかもしれません。

もう一点、気になったところは、遅延が大きい場合があることです。サウンドエフェクトの再生装置として現れる場合、通知音のサンプルをクリックしてから1~2秒くらい遅れて音が出ます。MusicやQuickTime Playerなどで音楽の再生・停止ボタンを押すと、2秒くらいしてから反応します。動画再生・停止でも遅延します。でも映像も遅延するので、音との同期がズレる現象はないのです。いずれの場合も、マザーボードのサウンドチップでは瞬時に応答するので、AirPlayが原因だと思われます。何処かのバッファメモリが一杯、または空っぽになるまで、操作結果が反映されない感じです。遠隔会議ではこの遅延のために対話が成り立ちません。いろいろ謎の遅延ですが、これもそのうち直してくれるのかもしれないです。

ホーム.app

ホーム.appを開いてみました。オフィスという場所に、HomePod miniが見えてました。名前は変更できます。いくつかの設定も変更できます。でもできることは、アラームを設定する程度の事でした。macOSから操作するよりも、Siriに音声でお願いしたほうが楽そうです。

純正環境との比較

AirPlayの遅延などに関しては、hackintosh環境なので、不具合が起こっても当然だったのかもしれません。それで純正Mac, iPhone環境ではどうなのかを確認しました。

純正Macとの比較

Big Sur 11.0.1が動いている本物のMacBookからこのHomePod miniに接続して確認しました。警告音のデバイスに現れない、2秒くらい遅延するという状況は、同様に発生しました。hackintoshの問題ではないようです。

iPhoneとの比較

iPhoneから接続すると、Musicアプリでも、一般のアプリ（例えばSafariで見るYoutubeサイトの動画）でも、遅延はありませんでした。

AirPlay 2.0

先の説明で、macOSのAirPlayではHomePodはステレオにならないと書きました。正確には、macOSでも、Music.appからだけはステレオになるそうです。

調べたところ、初代HomePodが発表された2017年に同時に、AirPlay 2.0が発表されて、そこで複数スピーカーの同期ストリーミングがサポートされたのだそうです。これにより2台のHomePodでのステレオ再生がサポートされたのだと思われます。この時に、遅延の問題も改善されたのでは無いかと思いました。それで、iOSは全面的にAirPlay 2.0に対応しているので、遅延が発生しないけど、macOSではMusic.appだけが2.0に対応しているので、Music.appを使う時だけは、ステレオにもなるし、遅延も発生しないということかと思いました。

実はmacOSのMusic.appでも、設定によっては2秒の遅延が発生します。純正Macでも同様です。Music.appのAirPlayアイコンから、HomePod miniを選択すると、遅延は発生しません。「オフィス」というのがHomePod miniです。

でもここで「コンピュータ」を選んで、macOSの「システム環境設定」「サウンド」からAirPlayデバイスを選ぶと遅延が発生します。前者は、

Music.app ---> ( AirPlay 2.0 ) ---> HomePod mini

という接続になっていて、ステレオになって遅延も発生しないけど、後者は、

Music.app ---> macOS ---> ( AirPlay ) ---> HomePod mini

というようにmacOSを経由した設定で、この場合、古いAirPlay無印が使用されて、その結果遅延が発生するということかと推測できます。macOSのMusic.appは自前でAirPlay 2.0を実装しているのか、それとも2.0を提供するmacOSの未公開APIがあってそれを使用しているのかと思われます。

まとめ

HomePod miniが自作マシンのmacOSから使えることを確認しました。AirPlay接続のスピーカーとして使えて、さらにホーム.appにはデバイスとして現れます。ただ遅延が大きいので、コンピュータ用スピーカーには向いてませんでした。常設のSiriデバイスとして使っていきます。

OpenCoreのpicker画面を設定する

Tue, 24 Nov 2020 18:43:49 +0900

OpenCore 0.6.3のSample.plistを真似て作ったconfig.plistでは、ブート時のpicker選択画面で、macOSのUSBインストーラやWindowsドライブが現れませんでした。これを治しました。またpicker画面で使える便利な機能も設定しました。

デフォルト設定のpicker

OpenCoreが起動する際に、箇条書きやアイコンで現れる選択肢のことをpickerというのだそうです。Cloverの時は起動ボリュームが現れましたが、OpenCoreではツールのアイコンも一緒に現れるので、pickerと呼ぶのが適切なのかと思いました。

最近、このpicker画面にWindowsが入ったSSDが現れなくなっているのに気づきました。でもWindowsの使用頻度がほとんど皆無なので放置してました。その後、Big Surをクリーンインストールしようとしたときに、USBメモリーに入れたBig Surインストーラもpicker画面に現れませんでした。それで対応することにしました。OpenCoreのデフォルト設定では、WindowsもUSBメモリもpickerとして現れないようです。実際の例で示します。以下は、

macOSの入ったM.2 SSD
Windowsの入ったSATA SSD
Big Surインストーラが入ったUSBメモリ

が接続されたZ390マシンが起動した直後のpicker画面です。config.plistのほとんどの項目は、Sample.plistに記述のデフォルト状態です。上記の3個のボリュームに相当するpickerが現れて欲しいところですが、このうちの1個、macOSの入ったM.2 SSD (Macintosh HDという名前）しか現れません。Recovery はそのSSDに入っている復旧用ボリュームです。ほかに、UEFI ShellとNVRAMリセットのpickerが見えてます。

ScanPolicyを設定する

pickerを変更する方法の一つが、config.plistのMisc –> Security –> ScanPolicyという整数値を変更する方法です。これは起動選択のボリュームをスキャンする際のセキュリティ方針を決める項目のようです。得体の知れないボリュームから起動することは、セキュリティとして良く無いので、起動対象ボリュームの種類を決めておきましょうという項目のようです。

ScanPolicy = 0

ScanPolicyには、どのファイルシステムとどのデバイスを対象とするかをビットで設定します。詳細はOpenCoreのマニュアルに書いてあります。

• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.
• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported. Known device types are prefixed with OC_SCAN_ALLOW_DEVICE_.
• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.
• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.
• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.
• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.
• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.
• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.
• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition
as defined by the Boot Loader Specification.
• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.
• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.
• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.
• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.
• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.
• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.
• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.
• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.
• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus
(e.g. VIRTIO).

LSB 2ビットは、ファイルシステムとデバイスを限定するかどうかのビットで、0にしておけば全てのボリュームが現れるようになります。なのでScanPolicyを0に設定してしまえば、全てのボリュームが現れます。下の例は、同上のマシンでScanPolicyを0にした時のpickerの様子です。WindowsとUSBインストーラ（丸いBig Surアイコン）が追加されました。

左端に現れているオレンジ色のEFIというpickerは、USBメモリのESPです。OpenCoreが入ってます。これを選択すると、「すでにOpenCoreで起動している」というような内容のメッセージが出るだけです。Cloverの入ったESPが他のドライブにあると、それも現れます。ESPの内容がCloverの場合はCloverに切り替わります。起動できるESPがある場合に、それが現れてしまうのは、ちょっと煩雑な感じがします。でも、実際のMacでも、オプションキーで起動すると、同様に起動可能なESPがpicker画面に出現します。実機と同じ仕様と思えば納得できます。

ScanPolicy = 19859203

ScanPolicy = 0で全く困らないのですし、そう設定するように指示するガイドページもあります。実際OC Gen-Xが自動生成するconfig.plistも0に設定してます。ただ、せっかくセキュリティの機能が用意されているのに、無視するのももったいない気がします。正しく必要なものだけ設定したいと考えました。

ScanPolicyのデフォルト値は17760515です。ScanPolicyの設定そのものをconfig.plistから削除するとこのデフォルト値になります。Sample.plistでもこの値が設定されています。このデフォルト値では、

ファイルシステムはAPFSのみ
デバイスはSATA, SAS, NVMe, SCSI

を対象とする設定です。APFSのみなので、Windowsはもちろん、HFS+だったBig SurインストーラUSBも現れないわけです。さらには、デバイスでは、USB, DVD, FireWire, SDカード, PCIバスが除外されています。Big SurインストーラUSBはデバイスとしても除外されていました。そこで、このデフォルト値に追加して、

ファイルシステムにHFS+とEFI System Partition (ESP) を追加する
デバイスにUSBを追加する

ような設定にしました。それが10進数で19859203になります。ファイルシステムの選択肢にNTFSのビットがあったので、Windowsならそれだろうと考えたのですが、違ってました。ブートローダーがESPにある関係か、NTFSビットを立ててもWindowsのpickerは現れませんでした。ESPビットを設定する必要があるようです。ScanPolicyを19859203に設定すると、（上の写真と同じですが）以下のようになりました。

ビットの計算をする

皆さんはビットを立てたり、外したりするのにどうやって計算されてます？今回は手軽で便利なmacOS標準搭載の「計算機」を使いました。「計算機」はメニューの「表示」「プログラマ」を選ぶと16進数、8進数などを扱えます。入力や結果はコピペできるので便利です。

今回の計算は以下のようにして行いました。まずは、ScanPolicyのデフォルト値の、17760515をコピーします。計算機を10進数に切り替えて、ペーストします。その後、16進数に切り替えると、0x010F0103であることがわかります。ビットがわかりやすいです。

ここで、スキャン対象のファイルシステムにHFS+とESPを追加して、対象デバイスにUSBを追加します。それぞれのビットは、OpenCoreのマニュアルによると、以下です。

HFS+ : 0x200
ESP : 0x400
USB : 0x200000

なので、合計で0x200600のビットを立てれば良いわけです。そこで「計算機」で「OR」を押した後、0x200600を入力して、イコールを押します。出てきた結果は16進数で0x12F0703になります。10進数に切り替えれば、設定すべき10進数、19859203が得られます。これもコピーしてProperTreeまたはPlistEDPlusにペーストすれば良いです。

「計算機」にはRPN（逆ポーランド記法）で操作するモードもあるので、マニアックな人も満足できると思います。

おまけ1: 表示pickerを減らす

Pickerがこれくらい並んでも（USBメモリーが挿さってなければ2個減りますし）適切に賑わっていて良いと思いました。でも、efiツールをたくさんインストールしている場合は、それが右端に追加されるので、煩雑だと感じることもあるようです。

そこで、使用頻度の低いpickerを非表示にするオプションがあるようです。config.plistのMisc –> Boot –> HideAuxiliaryです。デフォルトではfalseですが、これをtrueにすると、写真のpickerのうち、Recovery, Reset NVRAMが非表示になります。また、Misc –> Toolsで追加しているefiツールItemの中のAuxiliaryをtrueにしているツールも非表示になります。現在はOpenShell.efiを追加してありますので、HideAuxiliaryをtrueにした上で、さらにOpenShell.efiの設定でAuxiliaryをtrueにしました。その結果、表示されるpickerが以下のように減りました。

ここでスペースキーを押すと、非表示にしていたpickerが元通りに表示されます。

おまけ2: -vを一時的に有効にする

Misc –> Boot –> PollAppleHotKeysをtrueにすると（デフォルトではfalseです）picker画面でApple標準のホットキーがいくつか使えるようになります。使用可能になるキーは以下です。

CMD+C+MINUS — disable board compatibility checking.
CMD+K — boot release kernel, similar to kcsuffix=release.
CMD+S — single user mode.
CMD+S+MINUS — disable KASLR slide, requires disabled SIP.
CMD+V — verbose mode.
Shift — safe mode.

ありがたいのはコマンド + vです（vは小文字でok）。ブートオプションには-vを付けずに、シンプルなリンゴマークだけで通常は起動していて、ちょっと動作が怪しい時だけ、コマンド + vでverbose modeに入れるようになります。Cloverだと起動画面からオプションを一時的に切り替えることができたので、同じように運用できます。

まとめ

ScanPolicyをデフォルト値から変更して、WindowsやUSBインストーラがpickerに現れるよう設定しました。また、HideAuxiliaryとPollAppleHotKeysもデフォルト値から変更しました。

Intel NUC D54250 (i5-4250U) にBig Sur 11.0.1を入れる

Mon, 23 Nov 2020 13:08:34 +0900

Haswell世代Core i5-4250U搭載Intel NUCにBig Sur 11.0.1をクリーンインストールしました。もともと11.0.1 RCを動かしていたので問題なく起動しました。サポート対象中の最弱マシン相当仕様ですがキビキビ動きます。

Intel NUC D54250

Intel NUCは、ノートPC用CPUを搭載したデスクトップです。MacBook Airからディスプレイを外してデスクトップにしたような仕様です。低消費電力なので電源を入れっぱなしの家庭用サーバに向いていると思います。

Intel NUC D54250, 4250U

10月に、これにOpenCoreを入れて、Big Sur Beta 9をインストールしました。その後、11.0.1 RCを入れてます。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

今回は、これに公開版のBig Sur 11.0.1をクリーンインストールしました。11.0.1 RCが問題なく動いている状態だったので、動いて当然の作業です。

構成は以下です。

Intel NUC D54250WYKH (2.5 inchドライブを内蔵できる背の高いモデルです。ちなみに兄弟モデルにはWYK, WYBがあります。WYKは2.5 inchの入らない薄型。WYBは基板だけです。)
CPUはIntel(R) Core(TM) i5-4250U CPU @ 1.30GHz
BIOSは2019年9月2日版のWYLPT10H-86A.0054
グラフィックスはIntel HD Graphics 5000 (ごく稀にアーティファクトが出ます)
mSATAソケットにが付いています。
2.5インチドライブベイには2TB HDDが付いています。
無線カードはです。WiFiはOOBですがBluetoothには追加のkextが必要です。
機種IDは4250Uが搭載されているMacBookAir6,2にしました。

ESPの設定

ブートに必要なESPの中身は、以下のように設定してあります。まず、ブートローダは、OpenCore 0.6.3です。

ACPIフォルダの中は以下です。

SSDT-PLUG.aml
SSDT-EC-DESKTOP.aml

Kextフォルダの中は以下です。SMC….kextはハードウェアモニター用なのでなくても良いです。Brcm….kextはBluetoothを使うために入れました。これらが無くてもWi-FiはOOBで動きます。

WhateverGreen.kext
VirtualSMC.kext
SMCSuperIO.kext (HWモニター用)
SMCProcessor.kext (HWモニター用)
Lilu.kext
IntelMausi.kext
AppleALC.kext
BrcmPatchRAM3.kext (Bluetoothが必要な場合)
BrcmFirmwareData.kext (Bluetoothが必要な場合)
BrcmBluetoothInjector.kext (Bluetoothが必要な場合)

Driversフォルダの中身は以下です。

VBoxHfs.efi (HFS+で起動しなければ不要)
OpenRuntime.efi
OpenCanopy.efi (OpenCore起動画面でアイコン出さなければ不要)

Config.plistの設定

config.plistの内容は、Haswell用ガイドのページに従って設定してあります。DevicePropertiesの箇所には、

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>AwAiDQ==</data>
 </dict>

を加えました。Intel HD Graphics 5000を表示用に使用する設定です。また、

<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

も加えました。オーディオのレイアウトIDを1番に設定する記述です。また、デフォルトではExposeSensitiveDataが6だったのを7にしました。NUCには搭載されるUSB数が元々少ないので、15個制限対策は不要です。実機のMacと同様ですね。

以前の記事で、

Misc – Security – SecureBootModel を Disabled にする

必要があると書きましたが、OpenCore 0.6.3からは、デフォルトのDefaultのままで起動します。

Big Surを入れる

前述のように、このNUCは

mSATA SSD (Big Sur 11.0.1 RC)
2.5 inch HDD (Catalina最終版)

を搭載してます。mSATA SSDにはBig Sur 11.0.1 RCを入れてました。また、2.5 inch HDDには緊急用ブートのために小さなパーティションが切ってあって、そこにはCatalina最終版が入っています。

今回は、mSATA SSDにBig Sur公開版をクリーンインストールしようとしました。そこで、HDDのCatalinaで起動して、mSATAをまっさらにフォーマットし直しました。そしてCatalinaからBig Surインストーラを起動して、mSATA SSDにインストールしました。

インストール過程の最初の再起動で、BIOSの警告が出ました。

特に設定はおかしくなってませんでしたし、この先は、警告が出ることはありませんでしたので、このまま続けました。今までのBig Surインストール作業と同様に、最初の2-3回の起動では、macOS Installerという名前のドライブから再起動します。

でも進捗すると、フォーマット時に設定したドライブの名前になってます。

その後、また２回ほど再起動して、設定画面に入りました。

MacBookAir6,1と6,2は、Big Surが動く最古のMacで、4250UはBig Surが公式対応する最弱のCPUと言えます。ギリギリのスペックですが、Big Surは充分にキビキビ動きました。とはいえ、Geekbench 5で、シングル600, マルチ1200と遅いです。これと比較すると、新しいM1のシングル1600, マルチ7200というスコアはすごいですね。

まとめ

Haswell版Intel NUCにも、OpenCore 0.6.3とBig Sur公開版をクリーンインストールしました。Big Surがサポート対象とする最弱Macに相当するスペックですが、問題なく動きました。

マイナンバーカードを読む

Sun, 22 Nov 2020 17:52:04 +0900

公的個人認証サービス対応ICカードリーダーが600円で売られてました。USB接続の接触型ICカードリーダーで、マイナンバーカードが読めます。自作macOSマシンでも使えてマイナポータルにログインできました。

マイナンバーカード対応リーダー

「Hackintoshで確定申告」という記事を、何年も前に書きました。この時使うのが、マイナンバーカードを読み取るための「公的個人認証サービス対応ICカードリーダ」です。今まで、SCR3310-NTTComというカードリーダを使用してました。ずっと以前に販売終了になった古代の製品ですが、秋葉原のジャンク屋さんに山積みされていたのを、使う当てもなく買ったものでした。こういう衝動買いは、大体は無駄に終わるのですが、この物件に関してはとても役に立ってます。

今は後継機種が販売されているようですが結構な価格です。実はマイナンバーカードは非接触型ICカードでもあるらしくNFCリーダやスマートフォンでも読めるようです。後継機種のカードリーダーも非接触型らしく、それもあって高価なようです。接触型なら端子だけで済むところを、無線送受信機とアンテナが必要なので高くなるのは仕方ないです。

デジタル庁もできることですし、これから利用する機会も増えそうなので、カードリーダーを買い足そうと考えました。AliExpressで探したら、接触型ICカードリーダーは送料込みで7ドルくらいでした。

Amazon.co.jpで探したら、ほぼ同じものらしい製品が送料無料で600円でした。今は少し値上がりしてましたがそれでも700円程度です。

ならばということで、信頼と安心のAmazonで手配しました。これをBig Surをインストールした自作マシンに接続すると、システム情報に現れました。動きそうです。

ここに書かれているEMV Smartcard Readerという名前のEMVは、ICチップ搭載クレジットカードの標準規格の名前だそうです。Europay, Master Card, Visaの頭文字らしいです。マイナンバーカードもEMV規格に合わせて作られているようです。考えてみれば、日本のマイナンバーカードにしか使えないガラパゴスなリーダーだったら、ネットで格安で売られているわけがないですよね。試してみたところ、クレジットカードを挿しても反応しますので、本来はPOS端末用などの用途で販売されているのかと思われます。

公的個人認証サービス

マイナンバーカードがあるとどうして確定申告がオンラインでできるのか、謎だったので、総務省のページに行って勉強してきました。

総務省｜マイナンバー制度とマイナンバーカード｜公的個人認証サービスによる電子…

ちなみに冒頭のキャラクタはマイキーくんと言って総務省の職員の方がデザインされたようです。JPKI (Japanese Public Key Infrastructure) の頭文字が入っているそうです。

このページに書いてあることによると、マイナンバーカードのメモリーには2個の証明書と2個の秘密鍵が記録してあるようです。秘密鍵は公開鍵暗号方式で使う鍵です。公開鍵暗号方式では、データを秘密鍵で暗号化して、公開鍵で解読します。秘密鍵を持っている人だけがその暗号化データを作れたことを証明できます。証明書と秘密鍵は、マイナンバーカードを作るときに要望すると書き込んでくれます。お役所でカードを作ってもらうときに、よく分からないけど無料だったので、とりあえず書き込んでもらった記憶があります。

マイナンバーカードに入っている秘密鍵は取り出すことができないように作られているそうです。一方で、2個の証明書は取り出せて、以下の用途に使われます。

署名用電子証明書：確定申告提出書類など、お役所に提出する書類の署名用証明書。公開鍵などの情報の他に、氏名、住所、性別、生年月日の情報（4基本情報）が書いてあります。
利用者証明用電子証明書：マイナポータル（マイナンバーカードを使った電子手続きのポータルサイト）などのサイトにログインするときに使う利用者証明書。公開鍵やシリアル番号などが書かれていますが、4基本情報は書かれていません。

総務省のサイトの説明を読む限りでは、以下のような手順で使用するようです。マイナポータルにログインするときは、おそらくはサーバ側から乱数のようなデータが送られてきて、それを秘密鍵で暗号化して、利用者証明用電子証明書と一緒に送り返すのかと思います。確定申告申請書に関しては、提出書類そのものを秘密鍵で暗号化して、署名用電子証明書と一緒に送り返すという説明が書いてありました。書類そのものを暗号化するのではなくて、書類は平文のままで、書類のハッシュ値を暗号化しているのかなと思わないでもないです。

秘密鍵の秘密

おおよその仕組みは把握できたのですが、秘密鍵の扱いが疑問でした。証明書を使用する際にはパスワード（英数字6~16桁または数字4桁）が必要です。その時に秘密鍵も読み出せるのかとも想像したのですが、それでは簡単に秘密鍵が漏洩してしまいます。総務省のページにも、秘密鍵はカードからは出てこないと説明してあります。そうすると暗号化できるのはカードの中の人（CPU）だけですが、NFCアンテナからの微小な電力でも動くカードで暗号化などできるのでしょうか。

検索していたら、「マイナンバーカードを使ってSSHする」という記事が見つかりました。

マイナンバーカードでSSHする - AAA Blog

マイナンバーカードにアクセスするためのプロトコルは、なんと未公開らしいです。（少し古い記事なので今は違うのかもしれません）どうりで謎だったわけです。ただ世界標準に準拠しているので、ハッキングできているようです。この記事によると、カードの中には、以下のようなディレクトリで機能が管理されているようです。APはアプリケーションの略らしいです。MFはメインフレームの略です（rootってくらいの意味かな）。

公的個人認証APが、公開鍵暗号方式を担っているディレクトリです。署名xxxというユニットが、確定申告などで使う4基本情報を含んだ証明書による認証を担当して、認証xxxというユニットが、マイナポータルへのログインなどで使う、個人情報（4基本情報）を含まない認証を担当してます。

この記事によると、標準的なカードドライバを元にしたオープンソースアプリで、プロトコルに即した数バイトのデータをマイナンバーカードとやり取りすることで、秘密鍵による暗号化ができるそうです。認証xxxユニットを使う手順をまとめると以下です。

とあるバイト列をカードに送信して公的個人認証APを選択する
同様に認証用PIN (IEF0018) を選択する
4桁の暗証番号をASCIIコードで送る
認証用鍵 (IEF0017) を選択する
暗号化してほしいデータ（ハッシュ値など）を送る
その結果、カードから署名データが返送される

これで最終的には、暗号化されたデータと公開鍵が得られるのだと思われます。ということで、なんと、マイナンバーカードが暗号化をしてくれているようです。それなら秘密鍵が外に出ることはないですね。冒頭のタイトルを「マイナンバーカードを読む」としましたが、実はもっと高度な処理をしていたようです。この記事によると、秘密鍵を内部に保持して、外に出さずに内部で暗号化できるデバイスは、まだまだ高価らしいです。それを国民全員に無料で配布しているのですから、もっと活用できるようにすべきだとのことでした。

マイナポータルにログインする

冒頭で紹介した格安カードリーダーを使ってマイナポータルにログインを試みました。

マイナポータルは政府が運営しているオンラインサービスで、マイナンバーカードを使った電子手続きのポータルサイトです。ここにログインするには、マイナンバーカードが必要です。おそらくはSSHのログインと同様に、サーバーからタイムスタンプのような乱数が送られてくるので、それをマイナンバーカードの中のチップが暗号化して、公開鍵を含んだ証明書と一緒に送り返すのだと思われます。

Big Surをクリーンインストールした後なので、前回インストールしたSafari拡張機能が消えてました。ログインをしようとしたら、Safari機能拡張のダウンロードとインストールを求められました。

OKボタンを押すと、Safari拡張機能がダウンロードされます。これを、Safariの「環境設定…」から有効にすると、この先に進みます。ちなみに、マイナンバーカードを使ういろいろなサイトで、それぞれ別々の拡張機能のダウンロードを求められます。一本化して簡素化しようとする動きはあるようですが、まだまだややこしいです。

公的個人認証サービスとは | 公的個人認証サービスポータルサイト

Safari拡張機能を有効にすると、カードリーダーが認識されて、マイナンバーカードをセットするよう促されました。600円のカードリーダーが正しく動いているようです！

マイナンバーカードをセットすると、4桁数字のパスワード入力を求められます。このパスワードを使ってマイナカードに指示すると、マイナカードが、サーバーから送られた既知のデータを暗号化し、公開鍵を含む「利用者証明用電子証明書」と一緒に返してくれるのだと思います。

これで無事ログインできました。

まとめ

Amazonで安価に売られているマイナンバー読み取りカードリーダーは、マイナポータルのログインに使えました。まだ試していませんが、他の公的個人認証サービスでも、おそらく問題なく使えると思います。マイナンバーカードの公的個人認証サービスは、無料で使える電子実印みたいな機能なので、お役所のサイトだけでなく、もっと色々な場面で使えるようになれば良いと思います。

Big SurでAFPファイルサーバ機能が廃止されました

Fri, 20 Nov 2020 23:18:52 +0900

以前から予告があったのですが、Big SurからとうとうAFPファイルサーバ機能が無くなっていました。SMBだけになったようです。AFPサーバへ接続するクライアント機能はBig Surになってもまだ動いていました。

AFP

AFP (Apple Filing Protocol または AppleTalk Filing Protocol) は、ファイル共有機能を実現するプロトコルの一つです。これにより、ネットワーク上のサーバにあるファイルを、手元のハードディスクにあるかのように扱うことが可能になります。元々AppleTalk用に開発されたのですが、TCP/IP上で動くように移植されて、今も使われてます。macOSの新ファイルシステムであるAPFSと紛らわしい名前ですが、別物です。AFPの仲間には、老舗のNFS (Network File System) とか、Windowsでお馴染みのSMB (Server Message Block) があります。

最近のmacOSの「システム環境設定」「共有」では、標準でAFPとSMBのサーバー機能がサポートされていました。なので、面倒な手続き無しでどちらのサーバも設定できました。でも、AppleはどうやらAFPから手を引きたいと考えているようで、しばらく前から「AFPをやめてSMBを使ってください」と言ってました。HFS+に代わってAPFSがmacOSの主流のファイルシステムになっても、AFPサーバではAPFSをサポートしてませんでした。なのでAPFSボリュームは、AFP方式でのファイル共有に使えませんでした。

Catalinaのファイル共有

Catalinaでは、「システム環境設定」「共有」からファイル共有の設定をすると、デフォルトではSMB方式のサーバとして機能するようになってました。AFPファイルサーバの設定も可能でしたが、「オプション…」ボタンを押してからようやく選択できるようになってました。できればAFPは使って欲しくないというメッセージが読み取れる設定画面でした。

Big Surのファイル共有

Big Surになって確認したところ、ファイル共有設定のオプションボタンを押しても、AFPの選択ができなくなってました。選択できるのはSMBだけです。

ちなみに、Big SurになってもAFPクライアント機能は健在です。AFPで立ち上げているファイルサーバに、Big Surから接続することができました。でもこれもそのうち廃止されるのかもしれないですね。

Big SurでTime MachineがAPFS対応する

Mon, 16 Nov 2020 17:19:52 +0900

Time Machine用に大容量HDDを搭載できるのは自作hackintoshの大きなメリットです。そのTime MachineがBig SurになってAPFSに対応したようです。APFSになると色々メリットがあるので、現用のTime Machineも移行しました。

Time MachineとAPFS

Time Machineによる自動バックアップ機能がOS標準なことは、macOSの大きなメリットだと思います。うっかり削除したり、書き換えてしまったファイルを、Time Machineに何度も救われてます。Macに安い大容量HDDを内蔵すれば、安価に高速にバックアップできます。お手軽なマシンでそれが可能なのが自作PCです。

そのTime Machineが、Big SurになってようやくAPFSに対応しました。今までのTime Machineは、古いHFS+ファイルシステムを使っていました。Time Machineでは、特定時間ごとの全ファイルのスナップショットをバックアップします。１回目は、全てのファイルをバックアップコピーしますが、２回目以降は、差分だけを記録します。でもTime Machineのドライブをファインダーで見ると、あたかも毎回の記録が全て揃っているように見えます。Time Machineが頑張ってそのように見せているのです。

この機能は、APFSで導入されたクローン機能と似ています。あるファイルをクローン機能で複写すると、物理的なデータは一つしかないけど、それを2個に見せてくれます。片方のコピーに変更が加わると、その変更分だけを記録します。おそらくは、Time MachineのコードがAPFSの開発にも役立っていたのではないかと思います。逆に、APFSに備わったクローン機能をTime Machineで使えば、よりシンプルに効率よく実現できるはずです。ファイルシステムの機能ならば色々な場面で動作チェックされますから、バグが減って、堅牢になって、さらには最適化が進んで高速化すると期待できます。でもAPFSが実用化されても、今までTime MachineはHFS+を使ってました。移行に手こずっていたのかもしれません。でもようやくBig Surで対応しました。

APFS対応の確認

Time MachineがAPFS対応したことの確認をしました。Time Machineは、今までのHFS+のバックアップファイルも、サポートします。でも、新しいバックアップディスクを作る場合は、APFSになるようです。まずは、500GBの2.5インチHDDを用意して、HFS+でフォーマットしました。先の記事で紹介したリムーバブルHDDラックに入れてあるので、オレンジ色のリムーバブルディスクに見えてます。

ファイダーにも、オレンジのアイコンで、New Diskという名前で見えてます。

diskutilコマンドでチェックすると、確かにHFS+になってます。全体が一つのHFSボリュームです。

/dev/disk8 (external, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *500.1 GB disk8
 1: EFI ⁨EFI⁩ 209.7 MB disk8s1
 2: Apple_HFS ⁨New Disk⁩ 499.8 GB disk8s2

この後、「システム環境設定」「Time Machine」から、「ディスクを選択」ボタンを押し、このドライブをTime Machine用に設定します。

ここで消去を選ぶと、Time Machine用のHDDとして再度フォーマットされます。HDDの名前は同じですが、アイコンがTime Machine用に変わりました。

diskutilコマンドで調べると、

/dev/disk8 (external, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *500.1 GB disk8
 1: EFI ⁨EFI⁩ 209.7 MB disk8s1
 2: Apple_APFS ⁨Container disk9⁩ 499.8 GB disk8s2

/dev/disk9 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +499.8 GB disk9
 Physical Store disk8s2
 1: APFS Volume ⁨New Disk⁩ 692.2 KB disk9s2

となってます。論理的な入れ物であるコンテナができて、その中にAPFSボリュームができてます。ボリュームの名前は、HFS+のボリュームの名前のNew Diskを引き継いでいます。このように、HFS+からAPFSにファイルシステムが変更されました。この後は、今までと同じように、Time Machineを利用できます。なお、ディスクユーティリティで確認すると、APFS（大文字、小文字を区別）になっていました。

APFSの利点

APFS化されたことで、堅牢になって高速化される可能性はあります。利便性も上がります。APFSのボリュームになったので、サイズが柔軟に変更できます。一台のHDDを丸ごとTime Machineに割り当てる場合は、悩む必要はないのですが、パーティションに分けて、一つのパーティションをTime Machine用に使う場合は、サイズの決定が難しかったです。Time Machineには大容量のHDDを割り当てるので、パーティションを分けて、その一つをデータ置き場にしようとか、別の一つにはバックアップのmacOSを入れておこうなどと考えることが多いです。

HFS+のパーティションの場合、パーティションの大きさを、フォーマット時に決める必要があり、それ以降変更することがほとんど不可能でした。なので、運用してみるとサイズが足りなかったり、大きすぎたので勿体無かったりします。APFSボリュームならば、可変サイズなので必要に応じて記録領域が伸縮します。後から別のボリュームを追加することも可能です。

ボリュームを追加する

すでにTime Machine用に設定してしまったこのHDDに、新たにデータを書き込んでおくボリュームを追加してみます。HFS+だと実現できなかった手順です。ディスクユーティリティで、コンテナを選び、上の+ボタンを選択します。これでAPFSボリュームを追加できます。dataという名前のボリュームを追加しました。

ついでなので、macOSというボリュームも追加しておきます。その結果、

/dev/disk10 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +499.8 GB disk10
 Physical Store disk9s2
 1: APFS Volume ⁨New Disk⁩ 84.8 GB disk10s2
 2: APFS Volume ⁨data⁩ 999.4 KB disk10s1
 3: APFS Volume ⁨macOS⁩ 991.2 KB disk10s3

こんな感じに3個のボリュームが出来上がりました。macOSには、本体macOSが壊れた時のために、Big Surをインストールしてみます。インストーラを立ち上げて、このボリュームを選択します。

これでBig Surもインストールできて、起動できるようになります。macOSがインストールされた後のコンテナを見ると、

/dev/disk10 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +499.8 GB disk10
 Physical Store disk0s2
 1: APFS Volume ⁨data⁩ 1.1 MB disk10s1
 2: APFS Volume ⁨New Disk⁩ 84.8 GB disk10s2
 3: APFS Volume ⁨macOS - Data⁩ 20.4 GB disk10s3
 4: APFS Volume ⁨macOS⁩ 14.9 GB disk10s5
 5: APFS Volume ⁨Preboot⁩ 282.1 MB disk10s6
 6: APFS Volume ⁨Recovery⁩ 655.5 MB disk10s7
 7: APFS Volume ⁨VM⁩ 1.1 MB disk10s8

手動で作成した、New Disk, data, macOSの3個のボリュームに加えて、macOSインストーラが作成した、macOS – Data, Preboot, Recovery, VMのボリュームが作られています。

まとめ

Time MachineがAPFSに対応したことを確認しました。Time Machine用のディスクを新たに作ると、APFSになります。APFSになったおかげで、Time Machineのデータはそのまま残しつつ、後からボリュームを追加したり、macOSをインストールしたりできるようになりました。ということで、今使っているTime Machineドライブも消去して、APFSに移行することにしました。

Big SurでRadeon RX 5700 XTのスコアが大幅に改善

Sun, 15 Nov 2020 16:46:58 +0900

Big SurになってRadeon RX 5700 XTのGeekbench 5のスコアが格段に改善されました。RX 580と比較するとOpenCLもMetalも1.6倍くらい高いスコアでした。

Geekbench 5ベンチ結果

Catalina (10.15.5および10.15.6)とBig Sur (11.0.1) で、RX 580とRX 5700 XTのOpenCL/Metalスコアを計測しました。いずれもOpenCLとMetalのベンチマークを交互にそれぞれ３回測定し、その結果を平均したものです。測定に使用した本体は、ほぼZ490マザーボードに10900Kの構成ですが、Big SurでのRX 580の測定だけはZ390 + 9900Kの構成です。

Catalinaのスコアは以前の記事などで計測したものです。Catalinaだと、RX 5700 XTはRX 580に比べて同程度か、場合によっては劣っていることもありました。特にMetalの性能が弱い感じでした。本来なら古くて安価なRX 580よりも性能が高いはずなのですが、macOSのドライバの作り込みが不足しているようでした。

Big Surのパブリックベータが出ると状況は変わります。ベータのバージョンが進むたびに、RX 5700 XTのスコアが少しずつ改善されていきました。そして公開版11.0.1では、最後のベータ版からさらに改良されたようで、RX 580に圧倒的な差をつけてます。一方でRX 580は、Catalinaの頃とスコアがほとんど変わっていません。

ちなみに話題のM1のiGPUは、OpenCLが19000くらいのようです。Intel UHD Graphics 630が5000くらいでしたから、iGPUとしては頑張ってますが、ちゃんとしたグラフィックスカードには及ばないようです。

macOSでグラフィックス性能を求めるなら、RX 5700 XTが1番の選択肢と思います。また、他のNaviアーキテクチャのRX 5000シリーズも性能改善されているのではないかと思われます。RX 5000シリーズを使うためには、

WhateverGreen.kext (グラフィックス関係のパッチ集)
Lilu.kext (パッチを当てる機能を提供するkext)

を入れ、CloverやOpenCoreのブートオプションに、WhateverGreenに指示するオプションである、

agdpmod=pikera

を追加します。

Vega 64も性能向上

コメントでyoshiiさんから教えていただいた情報によるとVega 64でも17% ~ 19%くらい改善しているようです。

MacOS 10.15　54050(OpenCL)/52086(Metal)
MacOS 11　64061(OpenCL)/60921(Metal)

Big Surをクリーンインストールする (OpenCore + Z390)

Sat, 14 Nov 2020 19:24:47 +0900

メインで使っているZ390マシンにmacOS Big Sur 11.0.1をクリーンインストールしました。macOSの本体とユーザディレクトリを別のSSDに分けて入れてありました。そこで、前回作成したインストール用USBを起動し、macOS本体が入っているSSDだけを初期化し、Big Surをインストールしました。

システムの構成

Big Sur公開初日にZ490マシンにクリーンインストールしました。

Big Surをクリーンインストールする (OpenCore + Z490)

2日目の今日は、メインで使用しているZ390マシンにもクリーンインストールします。こちらのマシンです。現在は、OpenCore 0.6.3とCatalinaの最新版が動いています。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

Z490の方は、ほとんどデータがなかったので、クリーンインストールも簡単でした。でもこちらのマシンは、いろいろデータが入っています。Dropbox、iCloud, Timemachineなどでバックアップされているので、最悪、全部消えても困りませんが、できれば残しておきたいです。

幸いなことに、macOSの本体と、ホームディレクトリを別のSSDに置いていました。diskutil listコマンドで見ると、以下のようになってます。（TimemachineやWindowsなどのドライブも接続されているのですが省略しました。なので、番号が飛んでます）

% diskutil list
/dev/disk1 (internal, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *250.1 GB disk1
 1: EFI EFI 209.7 MB disk1s1
 2: Apple_APFS Container disk6 249.8 GB disk1s2

/dev/disk4 (internal, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *960.2 GB disk4
 1: EFI EFI 209.7 MB disk4s1
 2: Apple_APFS Container disk7 960.0 GB disk4s2

/dev/disk6 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +249.8 GB disk6
 Physical Store disk1s2
 1: APFS Volume Mojave 56.6 GB disk6s1
 2: APFS Volume Preboot 127.3 MB disk6s2
 3: APFS Volume Recovery 1.0 GB disk6s3
 4: APFS Volume VM 2.1 GB disk6s4
 5: APFS Volume Macintosh HD - Data 139.8 GB disk6s5
 6: APFS Volume Macintosh HD 12.2 GB disk6s6

/dev/disk7 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +960.0 GB disk7
 Physical Store disk4s2
 1: APFS Volume home 830.7 GB disk7s2
 2: APFS Volume Preboot 20.5 KB disk7s3
 3: APFS Volume Recovery 20.5 KB disk7s4
 4: APFS Volume VM 2.1 GB disk7s5

物理ディスクは

disk1 (250GBのM.2 SSD) と
disk4 (960GBのSATA SSD)

です。

disk1 (250GB SSD) には、APFSコンテナである
- disk6が作られていて、現用のCatalinaの論理ボリューム (Macintosh HD – DataとMacintosh HD) と、先代のMojaveの論理ボリュームがあります。
disk4 (960GB SSD) には、APFSコンテナである
- disk7が作られていて、homeという論理ボリュームがあります。ここには、ホームディレクトリのデータを置いてあります。

つまり、disk1および6がある250GB SSDには、macOS本体と、後から追加したドライバーやアプリケーション類が入っています。最近はパッケージで買うアプリケーションは皆無になりましたので、いずれもネットから再ダウンロードすれば良いものです。なので、250GB SSDの論理ボリュームは全部消去しても困らないと考えました。また、250GB SSDのESPには、OpenCore類が一式入っています。これは残しても良いのですが、サイズは小さいので、バックアップしていてから、SSD全体を削除して、その後復活させることにしました。

USBインストーラを起動

昨日の記事で作ったUSBインストーラを使います。まずは、このUSBメモリのESPの部分に、現在使用しているdisk1のEFIをコピーしておきます。これでUSBメモリから起動できます。disk1から起動することも可能ですが、これから消去する予定なので、ここでバックアップしておきます。

これでBIOSでUSBインストーラを指定して起動できます。昨日のZ490へのインストールの時は復旧（Revoery）画面が日本語でしたが、今回はなぜか英語画面でした。

クリーンインストールする

まずはDisk Utilityを選んで、250GB SSDを綺麗に全消去します。

ここでEraseボタンを押したら元には戻れません。ひたすら進むだけです。Disk Utilityを終了して、最初の画面に戻り、Install macOS Big Surを選びます。

さらに、インストール先に、先ほどフォーマットしたボリュームを選び、インストールを開始します。

この先は、前回と同じく、数回ほど再起動しつつ、インストールが進んでいきます。インストールが一通り終了すると、国選択の画面になります。

この後、いくつかの設定をすればインストール完了です。

USBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。

ホームディレクトリを復活

インストール直後は、インストール先の/Users以下にホームディレクトリがあります。クリーンインストールしたので中身は空です。そこで、今まで使っていた2.5インチSSDの場所にあるディレクトリに、ホームディレクトリを移動します。「システム環境設定」「ユーザとグループ」で「変更するにはカギをクリックします。」を選び、自分のユーザアカウントの上で右クリックして、「詳細オプション…」を選べば、ホームディレクトリを元の場所に戻せます。これで再起動すれば、Catalinaで使っていたファイルが全て使えます。

まとめ

OpenCoreで起動しているZ390マシンにBig Surをクリーンインストールしました。ホームディレクトリをmacOSとは別のSSDに入れてありましたので、それを残しつつ作業しました。

Big Surをクリーンインストールする (OpenCore + Z490)

Fri, 13 Nov 2020 23:56:37 +0900

macOS Big Sur 11.0.1の配布が開始されました。早速、Catalinaからアップデートしました。最新版のOpenCore (0.6.3) とkext類でCatalinaが動いていれば、通常の作業でアップデートできるようです。

システムの構成

本日 (日本時間2020/11/13)、macOS Big Sur 11.0.1 の配布が開始されました。過去のメジャーアップデートのナンバリング方式から、最初に出るのは11.0だと思ってましたが、今回は最初から11.0.1でした。インストール先のマシンは、こちらです。Z490マザーボードに10900Kを搭載しています。グラフィックスはRadeon RX 5700XTです。

ASUS ROG STRIX Z490-G, 10900K

このマザーボードに取り付けたWestern Digitalの250GB M.2 SSD, WD BLACK SN750 NVMeにクリーンインストールしました。SSDには、OpenCore 0.6.3と最新のkext類が入っていて、Catalina 10.15.7が動いています。diskutil listコマンドで見ると以下のようになっています。

% diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *250.1 GB disk0
1: EFI ⁨EFI⁩ 209.7 MB disk0s1
2: Apple_APFS ⁨Container disk1⁩ 249.8 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +249.8 GB disk1
 Physical Store disk0s2
1: APFS Volume ⁨Macintosh HD - Data⁩ 32.6 GB disk1s1
2: APFS Volume ⁨Preboot⁩ 83.6 MB disk1s2
3: APFS Volume ⁨Recovery⁩ 528.9 MB disk1s3
4: APFS Volume ⁨VM⁩ 2.1 GB disk1s4
5: APFS Volume ⁨Macintosh HD⁩ 11.2 GB disk1s5

disk0s1がESPです。disk0s2にAPFSコンテナが作られていて、この中に論理ディスクdisk1があり、その中にCatalina一式が入っています。Macintosh HDがシステムの中核部分で、簡単には書き換えられないよう保護されています。Macintosh HD – Data⁩がその他のシステムとユーザのデータです。PrebootはFileVault用のボリューム、Recoveryはリカバリーモードで起動するためのボリューム、VMは仮想メモリー用のボリュームです。

アップデートの手順

せっかくのメジャーアップデートなので、現在のM.2 SSDは綺麗さっぱりと全消去して、クリーンインストールしようと思います。なので次の手順でアップデートを進めます。

disk1のCatalinaでBig Surインストーラをダウンロードする
USBメモリを用意してBig SurインストールUSBを作る
USBメモリのESPにdisk1のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、disk1を消去する
インストーラからBig Surをdisk1にインストールする

1. Big Surインストーラをダウンロード

Catalinaを起動して、「システム環境設定」「ソフトウェアアップデート」を開いて、Big Surをダウンロードします。12.18GBあるようです。公開直後はネットが混み合ってダウンロード困難だったらしいですが、30分くらいでダウンロードできました。

ダウンロードするといつものように自動的にインストーラが開きます。ここではインストールしないので、インストーラは一旦終了します。

2. Big SurインストールUSBを作る

インストーラ用のUSBメモリを用意します。32GBはあった方が良いです。今回は32GBのUSB 3.0メモリーを用意しました。起動速度がとても遅くなってしまいますがUSB 2.0メモリーの方が確実です。今回は設定済みのESPがあるので問題ありませんが、未知のマザーボードの場合、USBの15個制限の影響で、USB 3.0ポートがUSB 2.0として動いてしまうことがあります。その場合、BIOS起動時は3.0だったポートが、macOSに制御が切り替わった途端に2.0に変貌してしまうので、起動作業が止まってしまうのです。（config.plistで15個制限を外しておくという方法もありますが）

USBメモリをHFS+で初期化する

次に、USBメモリーをディスクユーティリティ.appを使って初期化します。ディスクユーティリティ.appのデフォルトではボリュームのみが表示されますので、まずは、メニューバーの表示から「すべてのデバイスを表示」を選んでおきます。

こうすると、USBメモリ製品名が入ったデバイス名がウィンドウ左側リストに現れますので、これを選択します。今回はJetFlash Transcendという製品名を選択しています。次に消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここでAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。Mac OS拡張（ジャーナリング）を選んでおく必要があります。

次に、Big SurインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもBig SurをインストールできるUSBメモリになります。ターミナルを使用して、Big Surインストーラの中のContents/Resourcesに移動して、lsするとcreateinstallmediaというファイルが見つかるはずです。

$ cd /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/
$ ls create*
createinstallmedia

これを使用して、macOSインストールUSBメモリを作成します。とりあえず起動すると、ヘルプ情報が表示されます。

$ ./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsオプションは、起動用USBメモリを作成する場合に、最新ファームウェアやApple T2チップ用ファームウェアをダウンロードする機能のようです。Hackintoshでは不要な機能なので使わないでおきます。–volumeオプションでは、先ほど作成したUSBメモリへのパスを書いておきます。ということで、以下のコマンドを入力します。

% sudo ./createinstallmedia --volume /Volumes/USB/

sudoしているのでパスワードを求められます。その後、確認を求められるのでyを押します。そうするといろいろ進捗して終了します。

Password:
Ready to start.
To continue we need to erase the volume at /Volumes/USB.
If you wish to continue type (Y) then press return: y
Erasing disk: 0%... 10%... 20%... 30%... 100%
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100%
Making disk bootable...
Copying boot files...
Install media now available at "/Volumes/Install macOS Big Sur"

これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。

3. USBメモリのESPにdisk1のESPをコピーする

4. USBメモリーからインストーラを起動する

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにBig Surインストーラが見えるはずです。

まず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。
また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。

なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はProperTreeを使って変更している様子です。

これで起動項目にUSBメモリのインストーラが現れるようになります。Big Surアイコンのボリュームが、USBメモリーです。このInstall macOS Big Surを選択して起動します。

5. インストール先ボリュームを消去する

USBメモリから起動すると、復旧 (Recovery) というアプリケーションが起動します。

Time Machineから復元する、macOS Big Surインストールする、Safari (を開く)、ディスクユーティリティ（を開く）、の選択が可能になります。この他、メニューバーの「ユーティリティ」から、「起動セキュリティユーティリティ」と「ターミナル」が選べます。「起動セキュリティユーティリティ」は、Apple T2チップ用の機能と思われます。hackintoshでは関係ないです。

今回はクリーンインストールを目指すので、Catalinaが入っているdisk 1を消去します。ディスクユーティリティを開き、全てのドライブを表示するようにし、Catalinaが入っているドライブを選択して、消去します。

名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。

6. Big Surをインストールする

Disk Utilityを閉じると、またRecoveryのメニューに戻ります。次にInstall macOS Big Surを選択します。するとおなじみのBig Surインストーラが起動します。後は、いつものようにインストールを進めていくだけです。

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。（ここでもう一つ見えているアイコンはUSBメモリです）

17分くらいでインストールできるそうです。

でも17分も経たないうちに（多分5~6分）、再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

次は30分程度のようです。

この後、30分も経たないうちに（これも多分5~6分くらい）また再起動しました。またmacOS Installerが選択されてます。

そして数分でまたまた再起動。今度は、インストール先ドライブにつけた名前 (Macintosh HD) の選択肢が現れ、選択されています。これで起動します。

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。

あとはいつものように、設定を行なっていくだけです。

インストール終了したあと、このMacについてを確認すると、バージョンは11.0.1 (20B29) でした。Geekbenchブラウザに出回っている情報によると、M1搭載MacBook Airなどと同じOSが搭載されているようです。

USBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。

まとめ

OpenCoreで起動しているZ490マシンにBig Surをクリーンインストールしました。そのために、単体で起動してBig SurがインストールできるUSBメモリを作りました。以前のバージョンの場合と手順は同じです。ベータ版で予行演習していたこともありますが、スムーズにBig Surに移行できました。

macOS Big Sur 11.0.1 RC 2をインストール

Thu, 12 Nov 2020 00:42:55 +0900

macOS Big Sur 11.0.1 RC 2 (Release Candidate 2) が、パブリックベータとして公開されたので、11.0.1 RCからアップデートしました。ビルド番号は20B28です。システム環境設定のソフトウェア・アップデートから簡単にアップデートできました。Big Surの公式リリースの2日前に配布されたということは、最初のBig Surはこれではなくて、順当に11.0なのかもしれません。いずれにしても11.0.1もすぐに出そうです。

11.0.1 RC 2にアップデートする

前回の記事で11.0.1 RCを入れたZ490マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0.1 RCをインストール

のソフトウェアアップデートにmacOS Big Sur 11.0.1 RC 2の案内が来ていました。ネット上のニュースでは開発者向けに公開されたと書かれていましたが、Public Betaとしても公開されたようです。

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.3
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、3.22GBのファイルがダウンロードされ、その後、3回くらい再起動してインストールが終了し、macOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、20B28になっていることを確認できます。RC 2 になって、Betaという文字が消えてますし、ビルド番号もクリックしないと現れなくなりました。公開を見越したバージョンになっていると思いました。

ちなみに発表されたばかりのMacBook Airに搭載されるBig Surは、Geekbenchブラウザによると20B29のようです。

Apple Payでお買い物する

Sun, 08 Nov 2020 00:18:18 +0900

Apple Storeのページの買い物を、macOSからApple Payで手続きしました。iPhoneで認証する必要があり、また何回か試行錯誤しましたが支払いできました。

使用したマシン構成

Apple Storeサイトで買い物をしようとしたら「Apple Payで注文手続きを行う」というボタンがありました。これで支払いができるのかどうか、試してみました。

使用したハードウェアは、ASUSのZ390マザーボード、9900K、Radeon RX580の構成です。マザーボードのPCIeスロットに、Broadcom BCM94360CDを搭載したWiFi/Bluetoothカードを取り付けています。macOSはCatalina 10.15.7で、OpenCore 0.6.3でブートしています。機種IDはiMac19,1に設定してあります。

Apple Pay使用可能なMac

Apple Payは、Suicaやクレジットカードなどを紐付けたiPhone/Watchで、非接触で支払いができる機能です。用途が限定されますがMacでも使えることになってます。Macの場合、web上で支払いができます。対象は2012年以降に発売されたMacです。iMac19,1は問題ないですし、BCM94360CDも2013年モデルから採用されているので大丈夫と思いました。

また、Apple Payのサイトには、「Touch IDを搭載したMacBook AirとMacBook Proではワンタッチで支払いが完了。」と書いてあります。指紋認証機能が未搭載のMacでは、ワンタッチでは完了しないという意味に読み取れます。そのようなMacでは本人認証にiPhoneを使用するようです。

iPhoneを接続する

「Apple Payで注文手続きを行う」ボタンをクリックしたところ、iPhoneをBluetooth接続するように指示されました。指紋認証があるMacだと、もしかしたらiPhoneは不要なのかもしれません。

そこで、iPhoneを動作させて近くに持ってきたのですが、Bluetooth接続に失敗しているようです。最近のBluetoothでは、ペアリング画面が表示されている時だけ、ペアリングのための情報をブロードキャストするらしいです。ということで、iPhoneの「設定」「Bluetooth」画面を開きました。Bluetoothはすでにオンになってましたが、この画面を開くことでペアリングが可能になるようです。次のステップに進みました。

クレジットカードで支払う

iPhoneに接続できると、次に支払いカードの選択画面になります。カードの請求先を選択することもできます。

と同時に、iPhoneにもApple Payの画面が現れて、右ボタンダブルクリックで承認できるようになってます。ここでiPhoneで承認すれば、支払い処理が終了するようでした。

ただ、最初のうちは、「請求先住所が無効です」とか「このカードはウェブ支払いに使えません（この通りの文言では無かったです）」というようなメッセージが出て、処理が進みませんでした。

iPhone側では、WalletアプリでApple Payで使うクレジットカードを登録します。この情報を確認したところ請求先住所が未登録でした。Macの画面でも請求先を指定できるのですが、iPhone側でも登録する必要があるのかもしれません。また、MasterCard系のクレジットカードではなかなか処理が進みませんでしたが、JCB系のカードに切り替えたらすんなり進みました。ということで、何回か試行錯誤した結果、結局は支払いに成功しました。失敗したケースでは、カードの設定か手続きが不十分だったように思います。JCB系のカードではすぐに承認されたので、Hackintoshだからダメだったという様子ではないです。

ということで無事、Apple Payでお買い物ができました。ちなみに買ったのは、HomePod miniです。最近は、近所のファミリーマートで受け取りができるんですね。これはありがたいです。

macOS Big Sur 11.0.1 RCをインストール

Fri, 06 Nov 2020 22:50:14 +0900

macOS Big Sur 11.0.1 RC (Release Candidate) が、パブリックベータとして本日公開されたので、11.0.1 Betaからアップデートしました。ビルド番号は20B5022aです。システム環境設定のソフトウェア・アップデートから簡単にアップデートできました。RCは、問題がなければこのまま正式リリースになるバージョンです。11.0が出ることなく、最初のBig Surは11.0.1になるのかもしれません。

11.0.1 RCにアップデートする

前回の記事で11.0.1 Betaを入れたZ490マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0.1 Betaをインストール

のソフトウェアアップデートにmacOS Big Sur 11.0.1 RCの案内が来ていました。ネット上の多数のニュースでは開発者向けに公開されたと書かれていましたが、Public Betaとしても公開されたようです。（パブリックベータ版のスクリーンショットは公開してはいけないらしいので、前回同様に加工しました。）

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.3
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、2.8GBのファイルがダウンロードされ、その後、2回再起動してインストールが終了しました。その後、macOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、20B5022aになっていることを確認できます。

Intel NUCもアップデート

以下で、HaswellベースのIntel NUCにBeta 9とBeta 10をインストールした記事を書きました。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

さらに11.0.1 Betaにしていました。このマシンにも11.0.1 RCのアップデートのお知らせが来ていたので、アップデートしたところ、問題なく起動しました。これもOpenCoreは0.6.3です。

OpenCore 0.6.2から0.6.3に更新

Tue, 03 Nov 2020 19:35:58 +0900

OpenCoreの0.6.3が公開されたので0.6.2からアップデートしました。差分は少ないので新しくなったファイルを差し替えるだけで移行できると思います。Big Surがいつ公開されてもこれで大丈夫と思います。

0.6.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

.efiファイルを差し替える

前回のアップデートからは古いIA32アーキテクチャ用バイナリーが追加されましたが、今回も同様です。最近のCPU/macOSを使うならIA32フォルダは無視して、X64の方のフォルダの中身を、現用のファイルと入れ替えれば良いです。

前回0.6.1から0.6.2へアップデートした時と同じ作業を行いました。現在0.6.2が動いている状態ですので、現在のESPに含まれる.efiファイルを、0.6.3のものに差し替えます。以下のスクリーンキャプチャは前回のアップデートのものですが、同じなので流用します。まずはBOOTの中のBOOTx64.efiを差し替えます。

次に、OC直下のOpenCore.efiです。

また、OC/Bootstrap/の中のBootstrap.efiも差し替えます。

OC/Driversの中のうち、現在使用しているものだけを差し替えました。手元のマシンでは、OpenCanopy.efiとOpenRuntime.efiだけを使っているので、それを差し替えました。OpenRuntime.efiが一番重要ですね。

OC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。

PlistEDPlusを使ってみる

今回、config.plistを編集するにあたり、Mifjpnさんのサイトで紹介されていたPlistEDPlusというXMLエディタを使ってみました。

Releases · ic005k/PlistEDPlus

ミニマムなデザインのProperTreeと比べて、アイコンが並んでいて賑やかです。タブでファイルを切り替えられるので、新旧のconfig.plistを切り替えて比較するのが楽でした。下は、0.6.2のconfig.plistと、OpenCore 0.6.3に付属してきたSample.plist（をコピーしてconfig063.plistという名前に改名したファイル）を開いているところです。

一般的なXMLエディタなので、ProperTreeにあるKexts, ACPI, Toolsフォルダをスキャンしてその記述を追加してくれるようなOpenCoreに特化した機能はありません。でも今回は前バージョンで動いているconfig.plistがあるので、その機能は使いません。

0.6.3での変更点

今回アップデートしたマシンは、Coffee Lake-S + CatalinaとComet Lake-S + Big Sur 11.0.1 Betaです。Change logを見たところ、この環境で対処すべき項目は見つかりませんでした。すでに0.6.2で問題なく動いているなら、config.plistがそのまま使えて、変更は不要なようです。

PlatformInfoの中にメモリを設定する項目が追加されてます。特に、Memory Propertiesという一連の項目ができました。メモリーのデータ幅、ECCの有無、DIMMなのかSODIMMなのか、最大容量、DDR2,3,4などの指定ができるようです。「このMacについて」でメモリ情報が正しく現れない場合や、ECC付きなどの特殊なメモリを使う場合に必要なのかもしれません。Sample.plistにもMemory Propertiesは設定されてないので、設定が必要な場合はあまりないと思われます。

UEFIのOutput PropertiesにForceResolutionという項目ができました。Intel GMAや第1世代のIntel HD Graphics向けのようです。KernelのQuirksの中にForceSecureBootSchemeができたくらいです。説明を見ると仮想マシン向けの設定です。いずれも今回の環境には関係ありませんでした。

Big Sur Beta 10以降では、SecureBootModelをDisabledにしないとカーネルパニックする現象がありました。これが0.6.3で改善されたようです。11.0.1 RCで試したところ、SecureBootModelのデフォルト値であるDefaultのままで、問題なく起動しました。

Config.plistはこちら

OpenCoreに付属のSample.plistに、0.6.2で使用していたconfig.plistの内容を反映させました。新しく追加された項目は、全てデフォルト値のままです。その結果、ASUS Z390 ROG MAXIMUS XI + 9900K + RX580の構成のconfig.plistはこのようになりました。

config.plist for ASUS Z390 OC060 - Pastebin.com

ASUS Z490G + 10900K + RX5700XTの構成のconfig.plistは以下です。

config.plist for ASUS Z390 OC060 - Pastebin.com

いずれもPlatformInfoの項目は未記入ですので、macserialなどを使って生成してください。

macOS Big Sur 11.0.1 Betaをインストール

Fri, 30 Oct 2020 18:49:45 +0900

Big Sur 11.0.1 Betaがパブリックベータとして本日公開されたので、11.0 Beta 10からアップデートしました。ビルド番号は20B5012dです。簡単にアップデートできました。今までのPBではmacOSインストーラが起動したのですが、今回は単に1回再起動しただけでした。11.0正式版が出ない状況で11.0.1 Betaが出るのは珍しいことかと思います。11.0正式版リリースは近いと思いました。

11.0.1 Betaにアップデートする

前回の記事で入れた11.0 Beta 10マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0 Beta 9 をインストール

のソフトウェアアップデートにmacOS Big Sur 11.0.1 Betaの案内が来ていました。（ベータ版のスクリーンショットは公開してはいけないらしいので、前回同様に加工しましたw）

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.2
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、「アップデートするには、Macを再起動する必要があります。」というメッセージが出ます。ここで再起動を選択すると、アップデートが始まります。

再起動の後、ダウンロードが始まり、しばらくしてmacOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、11.0.1になっていることを確認できます。

ちなみに、ベータ版一般の注意なのですが、デフォルトで「Mac解析を共有する」設定になっています。Hackintoshの不具合情報をアップルに送付しても、どちらにとっても無意味なことですので、システム環境設定–>セキュリティとプライバシー–>解析と改善を選んで無効にしておきましょう。

5700XTのMetal性能が微増

このマシン (Z490 + 10900K) にはRadeon 5700XTを取り付けてあります。その性能をGeekbench 5で測定しました。下のグラフはCatalina 10.15.6、Big Sur Beta 6、Beta 9、Beta 10、11.0.1 Betaでの比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

Betaが出るたびに改良されてきた5700XTのスコアは、今回はほぼ据え置きのようです。ただ、Metalに関しては、測定ばらつき以上に微増していて、まだまだ改良されているようです。macOS開発チームの5700XTへの愛が垣間見える気がしました。

Intel NUCもアップデート

以下で、HaswellベースのIntel NUCにBeta 9とBeta 10をインストールした記事を書きました。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

このマシンも11.0.1にアップデートしてみました。問題なく起動しました。

macOS Big Sur 11.0 Beta 10 をインストール

Sat, 17 Oct 2020 17:04:59 +0900

Beta 10がパブリックベータとして昨日公開されたので、Beta 9からアップデートしました。ビルド番号は20A5395gです。RX 5700XTの性能が更に向上しました。Beta 10を起動させるために、config.plistのSecureBootModelをDisabledに設定する必要がありました。

Beta 10をダウンロードする

前回の記事で入れたBeta 9マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0 Beta 9 をインストール

のソフトウェアアップデートにmacOS Big Sur Betaの案内が来ていました。（ベータ版のスクリーンショットは公開してはいけないらしいので、詳細がわからないように加工しましたw）

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.2
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、「このシステムでアップグレードするには、フルインストーラが必要です。」というメッセージが出ます。

アップデートできないのかなと思って、諦めてOKボタンを押したら、親切なことに、「macOS Big Sur Beta 11.0をダウンロードしてもよろしいですか？」というダイアログが出ました。

ダウンロードボタンを押したら、12.21GBのフルインストーラーがダウンロードされました。

Beta 10をインストールする

ダウンロード後に、いつもと同じようにBig Surのインストーラが起動します。

そのままインストールを続けました。途中で2回、再起動しました。再起動の時の一時的なボリューム名は、「macOS Installer」になり、わかりやすくなりました。

**（追記）**以下の、起動に失敗する問題はOpenCore 0.6.3で修正されたようです。SecureBootModelはデフォルトのDefaultのままで起動します。

この後、インストールが終了したらしい状態になりましたが、起動しなくなりました。カーネルパニックが発生しているのか、メモリーパニックという表示で再起動を繰り返すようになってしまいました。

~~フォーラムで、須磨の辰五郎さん、Mifjpnさんから、~~

~~Misc – Security – ExposeSensitiveData を 3 にする~~
~~Misc – Security – DmgLoading を Any にする~~
~~Misc – Security – SecureBootModel を Disabled にする~~
~~NVRAM – Add – csr-active-config を 00000000 にする~~

の4点に気をつけるとBeta 10が起動すると教えていただきました。このうち1.と4.は対応済みでした（1.は7にしてます）。また、DmgLoadingはデフォルトのSignedでも大丈夫でした。ということで、

~~Misc – Security – SecureBootModel を Disabled にする~~

~~だけを対応したところ、無事、Beta 10が起動しました。~~

5700XTの性能がまたまた向上

このマシン (Z490 + 10900K) にはRadeon 5700XTを取り付けてあります。その性能をGeekbench 5で測定しました。下のグラフはCatalina 10.15.6、Big Sur Beta 6、Beta 9、Beta 10での比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

これを見ると、5700XTの性能がまたまた向上した様子です。OpenCLもMetalもどちらも、明らかにRX 580のスコアを上回ってます。これからは、5×00シリーズの時代なのかもしれません（もう生産終了らしいですが）。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

Mon, 12 Oct 2020 00:29:02 +0900

昔作った、Haswell世代Core i5-4250U搭載Intel NUCをOpenCoreとBig Sur (Beta 9) にアップデートしました。Ivy Bridge搭載初代NUCの代わりに省電力サーバとして使いたいと考えてます。

Intel NUC D54250

Intel NUCは、ノートPC用CPUを搭載したデスクトップです。低消費電力なので電源を入れっぱなしの家庭用サーバに向いていると思います。今までは、サーバとしてIvy Bridge搭載の初代NUCを使っていました。でもBig Surでサポートされなくなるので、Haswell搭載のD54250に更新することにしました。D54250には、すでにMojaveを入れてあったのですが長らく放置してました。押し入れから引っ張り出して、CloverからOpenCoreに差し替えて、Big Surに備えることにしました。

Intel NUC D54250, 4250U

Intel NUC D54250が搭載するCore i5-4250Uは、MacBookAir6,1, 6,2で使用されているCPUで、macOSとの互換性が高く安定しています。Big Surでもサポートされます。D54250には2種類のケースがあり、末尾がWYKのモデルは薄型筐体で、WYKHは2.5インチドライブを内蔵できる厚型モデルです。古いので探せば安価に入手可能です。WYKHはドスパラで一時期税込3万円未満で売られていましたし、現在は中古店で2万円くらい、オークションでは1万円前後で入手可能なようです。

ハードウェアの構成をまとめると以下です。

Intel NUC D54250WYKH (WYKHの他にWYK, WYBがあります。WYKは2.5inchの入らない薄型。WYBは基板だけです。)
CPUはIntel(R) Core(TM) i5-4250U CPU @ 1.30GHz
グラフィックスはIntel HD Graphics 5000 (稀にアーティファクトが出ます)
無線カードはです。WiFiはOOBです。Bluetoothは後で説明するようにkextが必要です。

シリアル番号にこだわる

昔に割り当てたシリアル番号には、今から見るといろいろ疑問なところがあったので、変更しました。まず機種IDは、4250Uが搭載されているMacBookAir6,2にしました。6,1でもほぼ同じなので、どちらでも良いです。OpenCoreの一式に入っているmacserialコマンドで機種を指定すると、シリアル番号とボードシリアル番号の候補が出ます。

 % ./macserial --model MacBookAir6,2
C02L20YVF5V7 | C02328501GUFD47JA
C02NLHYMF5V7 | C02443100J9FD471M
C02NNLZBF5V7 | C02445802GUFD47JA
C02MT0WEF5V7 | C02423500GUFD47AD
C02KGYYNF5V7 | C02312301QXFD471M
C02P3QYNF5V7 | C025022004NFD47FB
C02ND4Y8F5V7 | C02437303QXFD478C
C02M20CTF5V7 | C024011304NFD471H
C02NMFYJF5V7 | C02444501CDFD47UE
C02MNSZ6F5V7 | C02418301J9FD47AD

この中から一つを選べば良いのですが、念のためにその一つの詳細を調べてみます。

% ./macserial --info C02P3QYNF5V7
Country: C02 - China (Quanta Computer)
Year: P - 2015
Week: 3 - 3 (15.01.2015-21.01.2015)
Line: QYN - 2742 (copy 1)
Model: F5V7 - MacBookAir6,2
SystemModel: MacBook Air (13-inch, Mid 2013)
Valid: Possibly

製造週が2015年の第3週になってます。MacBookAir6,1, 6,2は2013年6月から2015年3月まで製造されたのですが、2014年4月に4250Uから4260Uにマイナーアップグレードされています。なので同じMacBookAir6,2用のシリアルでも、できれば2013年6月から2014年4月までの番号にしたいところです。ということで、macserialで製造年を2013、製造週を30に指定し、シリアル生成します。

./macserial --model MacBookAir6,2 --year 2013 --week 30
C02L40WPF5V7 | C02330701QXFD471M
C02L4LYLF5V7 | C023303064NFD471M
C02L4YYTF5V7 | C023309024NFD47FB
C02L4BZFF5V7 | C02330102GUFD47FB
C02L40S8F5V7 | C023303064NFD471M
C02L4XZEF5V7 | C02330101QXFD47UE
C02L4TY0F5V7 | C02330405CDFD47AD
C02L40ENF5V7 | C02330403GUFD471F
C02L4069F5V7 | C02330102GUFD47FB
C02L40FQF5V7 | C023303064NFD471M

このうちの一つを–infoオプションで調べてみると、2013年の30週（2013年7月23日から2013年7月29日）でした。発売されて1ヶ月後くらいなので妥当な製造日だと思います。

シリアル番号の特定の4桁部分、上の例では、F5V7とFD47は機種特有の番号です。macserialのソースコードを見ると、他にも多数の選択肢があるのですが、オプションで指定しないとこの番号しか生成されません。このF5V7が4250U搭載の2013年版MacBookAirなのかどうかは、すぐに調べる方法がなさそうでした。ただ、Appleのサイトでシリアル番号が有効かどうかを調べたところ、たまたま実機と同じシリアル番号が見つかりました。（実機と合致する番号は使ってはいけないです）

これから、F5V7はMid 2013の4250U搭載モデルの番号と考えて良いと思いました。

BIOSをアップデートする

このNUCでは起動時に時々「CMOSのチェックサムがおかしい」というメッセージがBIOS起動画面に出ました。ボタン電池を外して放置しても出てくるので、BIOSが壊れかけている疑惑もありました。なので、この際、アップデートすることにしました。現在のBIOSは、昔メンテナンスした時にアップデートしたWYLPT10H-86A.0045というバージョンでした。

インテルのサイトで調べたところ、2019年9月2日に最新のBIOSが出ていて、それは、WYLPT10H-86A.0054でした。早速ダウンロードして、USBメモリーに入れて、BIOS起動画面からアップデートしました。

https://downloadcenter.intel.com/ja/download/29075/BIOS-WYLPT10H-?product=76977

NUCのBIOSアップデートにはちょっとした注意点があります。アップデートが一段落すると、画面に、「正常にアップデートされました」という表示が出て、そのまま動かなくなります。Ivy BridgeモデルのNUC BIOSをアップデートした時に、しばらく放置しても何の変化もなかったので、ここでリセットすれば良いのかと思い電源を切ったことがありました。すると2度と起動しなくなりました。（このNUCをしばらく放置していたら起動するようになってました。理由は不明ですが、バックアップされていた設定が消えて起動できるようになったのかもしれません。）なので重要なことは、「正常にアップデートされました」という表示が出ても、自動的に再起動されるまで辛抱強く待つということです。2〜3分くらい待たされる感じがします。

OpenCore 0.6.2を入れる

シリアル番号をより正しいものに変更し、BIOSを最新にアップデートした後、入っているCloverも最近のもの (5122) に入れ替え、macOSも最新の10.15.7 (19H2) にアップデートしました。問題なく稼働しているのですが、Big Surへの移行準備のために、ブートローダをOpenCoreに入れ替えることにしました。

まずはダウンロードしたOpenCore 0.6.2のX64フォルダにあるEFIフォルダを、ESPにコピーします。次に以下のガイドに従って、設定を進めます。

Desktop Haswell and Broadwell | OpenCore Install Guide

ACPIフォルダの中には、以下の二点が必要です。

SSDT-PLUG.aml
SSDT-EC-DESKTOP.aml

CPU毎に必要なamlのリストは以下でまとめられています。

What SSDTs do each platform need | Getting Started With ACPI

ここで必要とされているデスクトップ用SSDT-EC.amlはこちらのサイトからダウンロードしました。そこでのファイル名がSSDT-EC-DESKTOP.amlとなってましたので、名前をそのまま使うことにしました。

Kextフォルダの中は、今回は以下にしました。

WhateverGreen.kext
VirtualSMC.kext
SMCSuperIO.kext
SMCProcessor.kext
Lilu.kext
IntelMausi.kext
AppleALC.kext

SMC….kextはハードウェアモニター用なのでなくても良いです。

config.plistの内容は、上記のガイドのページに従って設定しました。説明を読めば、どれが必要か判断できると思います。DevicePropertiesの箇所には、

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>AwAiDQ==</data>
 </dict>

を加えました。Intel HD Graphics 5000を表示用に使用する設定です。また、

<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

も加えました。オーディオのレイアウトIDを1番に設定する記述です。Pci(0x1b,0x0)のPci番号は、Hackintoolを使って、そのPciタブからPCIデバイス一覧を見て、このIOReg NameにHDEFとある行を探して、HDオーディオデバイスを特定しました。

レイアウト番号はとりあえず1番からテストしようとしたら、1番で正解でした。前面のヘッドフォン端子から音が出ることを確認しました。

Sample.plistの初期設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトではExposeSensitiveDataが6だったので7にしました。

このNUCには、前面にUSB 2.0端子が2個、背面にUSB 3.0端子が2個あります。また内部のmini PCIeソケットには、USB 2.0が1個あります。さらに、ケースに配線の余裕が無いので使うことはないですが、基板上にUSBコネクタがいくつかあります。ただ、それらを全部加えても15個のようです。なのでconfig.plistのXhciPortLimitで15個制限を外したり、15個制限に対応するkextを作ったりする必要は無いです。

Big Sur beta 9を入れる

Big Surベータ9を入れました。MacBookAir6,1と6,2は、Big Surが動く最古のMacです。また4250UはBig Surが公式対応する最弱のCPUと言えます。ギリギリのスペックでしたが、インストールは、インストーラを起動するだけで簡単でした。インストール途中の再起動では、macOS Installerというドライブが現れて選択されていました。インストール後の動作も問題ありませんでした。ベータ9は安定していて充分にキビキビ動くので、完成度は高いと思います。

Geekbenchをしてみたところシングル600, マルチ1200台程度でした。遅いですね。Apple Silicon搭載Mac miniが800/2900くらいと言われてますので、完全に負けてます。（追記：Apple Silicon搭載Mac miniが発売された後、スコアが明らかになりました。1680/7400くらいのようです。圧倒的に負けてました。）

ちなみに同じ4250U搭載のMacBook Air Mid 2013のスコアも大体同程度です。妥当な結果のようです。

Bluetoothを使う

NUCのmini PCIeソケットに、無線カードを挿しています。WiFiとBluetoothの機能のあるカードです。このうちWiFiはOOBで設定不要で動きます。Bluetoothを動かすためには以下のkextが必要でした。

BrcmPatchRAM3.kext
BrcmFirmwareData.kext
BrcmBluetoothInjector.kext

これらはKext-Updater.appからダウンロードしました。メイン画面のKextmanagerボタンをクリックして、次の画面でBrcmPatchRamを選びます。

すると8個のkextがダウンロードされます。このうち太字の3個を使ったわけです。

BrcmBluetoothInjector.kext
BrcmFirmwareData.kext
BrcmFirmwareRepo.kext
BrcmNonPatchRAM.kext
BrcmNonPatchRAM2.kext
BrcmPatchRAM.kext
BrcmPatchRAM2.kext
BrcmPatchRAM3.kext

無線カードのファームウェアにパッチを当てるもののようです。初期の頃は、このうちBrcmFirmwareData.kextとBrcmPatchRAM.kextを使用するのが一般的だったようです。ファームウェアのデータkextとパッチしてくれるkextという組み合わせかと思います。その後Catalinaの頃のガイドでは、BrcmPatchRAM2.kextとBrcmFirmwareData.kextに加えて、BrcmBluetoothInjector.kextも必要になったと書かれていました。今回ダウンロードしたら、さらにBrcmPatchRAM3.kextという新しそうな名前のkextがありました。ということで、上記の3個のkextを使うことにしました。この結果、システム環境設定からBluetoothが見えて、アップル純正キーボード・トラックパッドでの動作を確認しました。

Big Sur beta 10を入れる

追記です。その後、Big Surベータ10を入れました。ベータ9からのアップデートはインストーラを起動するだけです。ただ、config.plistで、

Misc – Security – SecureBootModel を Disabled にする

ように変更しました。これをしないと多分起動しないようです。詳しくはこちらをご覧ください。

macOS Big Sur 11.0 Beta 10 をインストール

OpenCore 0.6.1から0.6.2に更新

Tue, 06 Oct 2020 21:39:32 +0900

OpenCoreの0.6.2が公開されたので0.6.1からアップデートしました。0.0.1の違いなので新しくなったファイルを差し替えただけで移行できました。

0.6.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

IA32というフォルダができている

今回から、IA32アーキテクチャ用のバイナリーも入っています。Intelの古い32ビットアーキテクチャです。古いハードウェアやmacOSのサポートのために32ビット版も配布されるようになったそうです（まっくぷろさん、解説ありがとうございました）。最近のCPU/macOSを使うならIA32フォルダは無視して、X64の方のフォルダの中身を使うことになると思います。

EFIファイルを差し替える

前回0.6.0から0.6.1へアップデートした時と同じ作業を行いました。現在0.6.1が動いている状態でしたら、現在のESPに含まれる.efiファイルを、0.6.2のものと差し替えることでアップデートできます。具体的には以下のファイルです。まずはBOOTの中のBOOTx64.efiです。

次に、OC直下のOpenCore.efiです。

また、OC/Bootstrap/の中のBootstrap.efiも差し替えます。

OC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。

変更点

今回アップデートしたマシンは、Coffee Lake-S + CatalinaとComet Lake-S + Big Surです。Change logを見たところ、このような環境では、対処すべき項目はほとんど見つかりませんでした。すでに0.6.1で問題なく動いているなら、config.plistがそのまま使えて、変更は不要なようです。

PlatformInfoの中にSystemMemoryStatusという項目ができました。デフォルトは自動ですが、メモリーが交換可能か、はんだ付けされてて交換不可能かを設定するようです。また、Processor Typeという項目もできました。デフォルトは0で、その場合、自動的に設定されるようです。自動認識されない場合はここで手動設定するようです。

macserialなどで使用される機種情報のうち、iMac20,1などの最新機種の細かい情報がアップデートされたようです。BIOSのバージョンとか日付が実際のものに近づいたようです。iMac20,1を使っているのでこれはありがたいです。更新された部分は、OpenCoreの中で自動的に構成してくれる部分なので、config.plistの設定には影響ありません。macserialが生成してくれるシリアル番号などにも変更はありません。iMac20,2のボードシリアル番号の機種ID部分は相変わらず不明で0000になっているようです。iMac20,2にアクセスできるなら貢献できるチャンスかもしれないです。

% ./macserial --model iMac20,2 --num 5
C02DW05T046M | C02052600QX00008C
C02DF4YW046M | C02038130GU0000AD
C02DQ2YH046M | C02047701QX00001H
C02D76Y9046M | C02033902QX0000UE
C02DL0K8046M | C02043101CD00001M

いずれにせよ、Comet Lake-Sの自作機でiMac20,2を選ぶことのメリットは特にありませんので、iMac20,1を選んでおくのが良いと思います。

DummyPowerManagement の場所が変更されたようです。手元の環境では使っていなかったので気づきませんでした。コメントで教えていただきました。config.plistの中のこの設定が、Kernel > Emulate Propertiesに移動しています。このフラグでPower managementをoffにしている場合は、config.plistを更新する必要があります。

Config.plistはこちら

その後、OpenCoreに付属のSample.plistを見ながら、新しく追加された項目も含んだconfig.plistを作り直しました。ASUS Z390 ROG MAXIMUS XI + 9900K + RX580の構成のconfig.plistはこのようになりました。

config.plist for ASUS Z390 OC060 - Pastebin.com

一方、ASUS Z490G + 10900K + RX5700XTの構成のconfig.plistは以下です。

config.plist for ASUS Z490 10900K OC062 - Pastebin.com

いずれもPlatformInfoの項目は未記入ですので、macserialなどを使って生成してください。

accountsdが暴走してCPU使用率700％

Mon, 05 Oct 2020 22:17:00 +0900

Catalina 10.15.7が動いているZ390 + 9900Kマシンで、ポインターが虹色円盤になり動作不能に陥りました。先日のアップデートの副作用のようで、再起動したら治りました。10.15.7 Comboアップデートを当てておきました。再発しないかどうか様子見します。

症状

突然、Catalina 10.15.7が動いているマシンで、ポインターが虹色円盤になり、文字入力がほとんど動かなくなり、ほぼ動作不能に陥りました。いわゆるSpinning wheel of deathです。アクティビティモニターで調べてみると、accountsdというデーモンがしきりに稼働していて、このデーモンだけでCPU使用率が700%近くになってました。マシンはこちらで作成したZ390 + 9900Kの構成です。

macOS Catalina 10.15.7 (19H2)
ASUS ROG MAXIMUS XI HERO (Z390)
9900K
OpenCore 0.6.1
kext類は最新

とりあえず再起動したところ治りました。スクリーンショットを撮っておけば良かったですが忘れてました。Hackintoshしている弱みで、トラブルがあるとついついhackintoshの動作と設定を疑ってしまうのですが、どうやら最近話題になっているアップデートの副作用のようです。フォーラムでまっくぷろさんに紹介されているのを見て気づきました。ネットで紹介されている症状とほぼ同じでした。

対策？

ネットの情報では、10.15.7 Comboアップデートを当てると効果があるようです。古い設定を捨ててくれるのかもしれないです。ということで、AppleのサイトからComboアップデートをダウンロードして、インストールしておきました。ビルド番号は19H2と変わらないです。再発するかどうか様子見します。

Download macOS Catalina 10.15.7 Combo Update

macOS Big Sur 11.0 Beta 9 をインストール

Fri, 02 Oct 2020 17:52:06 +0900

Beta 9がパブリックベータとして公開されたので、Beta 6からアップデートしました。ビルド番号は20A5384cです。Radeon 5700XTの性能がかなり向上しました。Z490, 10900K, OpenCore 0.6.1の環境で快適に動作しています。

インストール手順

前回の記事で入れたBeta 6マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0 Beta 6 をインストール

のソフトウェアアップデートにmacOS Big Sur Betaの案内が来ていました。

このMac用のアップデートがあります
・macOS Big Sur Beta 9 11.0

という表示です。Beta 6からBeta 9に飛んだのは、パブリックベータだからだと思います（もしかしたら途中のアップデータに気づかなかったのかもしれませんが）。

早速「今すぐアップデート」ボタンを押したのですが、ダウンロードが開始した後で、「インターネットの接続を確認してください」というようなエラーが出て進まなくなりました。夢日記で紹介されている状況とおそらく同じだと思います。さらに、別のCatalinaマシンもベータテスターに登録しているので、こちらでもダウンロードを試みましたが、やはりネットが不調というメッセージで止まります。

サーバが不調なのかと思い、一晩待ちましたがやはり同じエラーでした。そこで、ベータテストのサイトからmacOSPublicBetaAccessUtility.pkgをダウンロードし直して、インストールし直したところアップデートが進みました。自動的に何回か再起動して、問題なくアップデートが完了しました。一方のCatalinaマシンも、macOSPublicBetaAccessUtility.pkgを入れ直すことでダウンロードが成功しました。原因は不明ですが、何らかのアクションをすると改善するようです。

インストールが終わったBig Sur Beta 9はとても快適です。この分ならメイン環境として使っても良いと思いました。OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.1
kext類は一般公開されている最新のもの
機種設定はiMac20,1

5700XTの性能がさらに向上

このマシン (Z490 + 10900K) にはRadeon 5700XTを取り付けてあります。Beta 6の時と同様に、その性能をGeekbench 5で測定しました。下のグラフはCatalina 10.15.6、Big Sur Beta 6、Beta 9との比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

Radeon 5700XTの性能がかなり改善されています。Beta 6では、RX 580と比較して、OpenCLでは優っているもののMetalで負けていました。Beta 9ではBeta 6より2~3割改善されて、OpenCLもMetalもどちらもRX 580のスコアを上回りました。5700XTの性能をようやく引き出せるようになったようです。

OpenCore 0.6.0から0.6.1に更新

Thu, 10 Sep 2020 22:23:35 +0900

OpenCoreの0.6.1が公開されたので0.6.0からアップデートしました。Big Surに対応してComet Lakeに対応したところが大きな変更点かと思います。0.0.1の違いなので新しくなったファイルを差し替えただけで移行できました。

0.6.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

EFIファイルを差し替える

現在0.6.0が動いている状態でしたら、0.6.1に含まれる.efiファイルを、0.6.0のものと差し替えることでアップデートできます。具体的には以下のファイルです。まずはBOOTの中のBOOTx64.efiです。

次に、OC直下のOpenCore.efiです。

また、OC/Bootstrap/の中のBootstrap.efiも差し替えます。

OC/Driversの中のうち、現在使用しているものだけを差し替えました。手元のマシンでは、OpenCanopy.efiとOpenRuntime.efiだけを使っているので、それを差し替えました。

OC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。OpenCoreに付属している差分を説明するファイルや、インストールガイドのページを見ても、書き換えるべきconfig.plistの項目はなかったように思います。

iMac20,1に対応

0.6.1で最新のComet Lake-S CPUを搭載したiMac20に対応しました。最新パーツで組む場合にはありがたいところです。付属しているmacserialコマンドでも、iMac20,1と20,2のシリアル番号とボードシリアル番号の対を生成できるようになっています。

% ./macserial --model iMac20,1 --num 5
C02D1KZGPN5T | C02027600GUPHCD1F
C02DP1Z3PN5T | C02046104GUPHCD1H
C02CFNYTPN5T | C02011401GUPHCDA8
C02D6PZWPN5T | C02032200QXPHCDAD
C02D36YPPN5T | C02029101CDPHCDAD
% ./macserial --model iMac20,2 --num 5
C02DW05T046M | C02052600QX00008C
C02DF4YW046M | C02038130GU0000AD
C02DQ2YH046M | C02047701QX00001H
C02D76Y9046M | C02033902QX0000UE
C02DL0K8046M | C02043101CD00001M

ただし、iMac20,2は、ボードシリアル番号の機種IDの部分が更新されていなくて0000になってます。実機を調べてきた人がいないためです。Comet Lake-Sの自作機でiMac20,2を選ぶことのメリットは特にありませんので、iMac20,1を選んでおくのが良いと思います。

macOS Big Sur 11.0 Beta 6 をインストール

Wed, 09 Sep 2020 22:40:47 +0900

Beta 6が公開されたのでアップデートしました。ビルド番号は20A5364eです。Beta 5では起動で失敗していたComet Lake-Sで、Beta 6は動きました！また、Catalinaに比較してRadeon 5700XTの性能が向上していることを確認しました。

インストール手順

前回の記事では、createinstallmediaコマンドを使ってインストール用USBメモリを作成し、それで起動してSSDにインストールしました。今回はUSBメモリを作るのが面倒だったので、真っ新な2.5インチSATA SSD（今回は250GB）をCatalinaマシンに接続し、フォーマットし、macOS Big Surベータ版インストール.appから直接インストールしました。

このSSDを、Catalinaマシンに接続したまま、Catalinaが入っているESPの中のOpenCoreで起動します。そして起動ボリューム選択画面で、Big SurをインストールしたこのSSDを選択して起動しました。Beta 5に引き続き、Prebootという分かりにくい名前で現れています。Prebootの右に見えるMacintosh HDというドライブは、いつも起動しているCatalinaのボリュームです。

Z490で動きました

前回の記事でBeta 5が既に動作していたZ390上のCoffee Lake-Sマシンでは、Beta 6も引き続き問題なく起動しました。一方で、Beta 5が動かなかったZ490上のComet Lake-Sでも、Beta 6ならば起動しました。このマシンです。

ASUS ROG STRIX Z490-G, 10900K

ESPの構成は以下です。config.plistも、Catalina 10.15.6を起動させている状態のそのままです。

OpenCore 0.6.1
kext類は一般公開されている最新のもの
機種設定はiMac20,1

OpenCore 0.6.1はGitHubで公開されているソースからビルドしたものです。iMac20,1の機種設定・シリアル番号が使用したかったので0.6.1にしてあります。0.6.1が必須というわけではありません。（追記：この記事を書いている間に0.6.1は公開版として出てました。）Z390マシンでは公開版の0.6.0でも動いています。Z490マシンでBeta 5を試みた時には、OpenCoreが動いてすぐに

[EB|#LOG:EXITBS:START]

という表示で止まってしまい、起動しませんでした。このメッセージで止まることへの対策を色々試みたのですが、解決しませんでした。それがBeta 6にしたら、何の問題もなく起動しました。Beta 6はComet Lake-S搭載のiMac 2020に対応したという話をコメントで教えていただきました。Hackintoshなのが原因ではなく、もともと今回でComet Lake-Sに対応したということだったのかもしれません。

5700XTの性能が向上

このComet Lake-Sマシン (CPUは10900K) にはRadeon 5700XTを取り付けてあります。その性能を測定しました。下のグラフはCatalina 10.15.6とBig Sur Beta 6との比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

Radeon 5700XTは、RX 580と比較して、OpenCLでは優っているもののMetalで負けているという状態でした。その傾向は変わらないのですが、Big Surになってそれぞれ10%程度性能が向上しているようです。

macOS Big Sur 11.0 Beta 5 をインストール

Sat, 05 Sep 2020 19:23:54 +0900

ようやくBig Surを入れました。Public Beta Programで現在配布されているBig Sur 11 beta 5 (20A5354i) です。Catalinaを動かしているZ390マシンの、OpenCoreとその設定が入っているESPから起動して、すんなり動きました。この記事もBig Surで書いてます。この調子ならBig Surへのアップデートも順調に行えるように思います。

ダウンロード

Catalinaを動かしているZ390マシンをPublic Beta Programに登録し、システム環境設定のソフトウェアアップデートからダウンロードしました。デベロッパー向けにはbeta 6 (20A5364e)が既に出ているようですが、Public Betaはbeta 5のようです。ダウンロード後にインストーラが起動しますが、それは中断します。ApplicationフォルダにmacOS Big Surベータ版インストールというアプリケーションができています。

インストール用USBメモリを作る

次に32GB容量のUSBメモリを用意しました。これをフォーマットし、ここではusbという名前をつけました。ターミナルでmacOS Big Surベータ版インストールの場所にcdします。この中のContents/Resourcesの中に

% cd /Applications/Install\ macOS\ Big\ Sur\ Beta.app/
% cd Contents/Resources/

お馴染みのcreateinstallmediaコマンドがあります。オプションなしで起動すると、ヘルプが表示されます。

% ./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsを指定すると、インストール途中でネットにアクセスする必要がないような説明がされているので、これは使うことにします。そこで、

% sudo ./createinstallmedia --volume /Volumes/usb --downloadassets

とタイプします。これで用意したusbメモリが初期化されて、そこにBig Surのインストーラが作られます。

USBメモリから起動する

実際のMacなら、このUSBメモリで起動して、インストールをすることができます。Macでの動作を確認しました。インストール途中で再起動するときに、中間のボリュームの名前がいつもと違って「EFI」というように表示されて違和感がありました。この後で行ったhackintoshへのインストールでも後述のように、名前がおかしかったです。ベータ版なので、後に改善されると思います。

USBメモリを起動したhackintoshは、こちらで紹介したZ390マザーボードの構成です。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ESPの構成は以下です。通常は最新版のCatalinaを起動させています。

OpenCore 0.6.0 (一般公開されている最新バージョンです)
kext類は一般公開されている最新のもの
機種設定はiMac19,1

このESPから起動し、OpenCoreのメニューからBig Surインストール用USBメモリを選ぶと、インストーラが起動しました。

SSDを用意してインストール

インストール用に、余っていた64GBの2.5インチSSDを用意しました。これをUSB接続のHDDケースに入れて、USB接続しました。Big Surインストール用USBメモリで起動すると、そこからDisk Utilityを起動できるので、これを使ってSSDをAPFSでフォーマットします。フォーマットが終わったらインストーラプログラムに戻って、SSDにインストールをします。

インストール途中で再起動を求められます。NVRAMが機能していれば再起動時に選択すべきドライブがデフォルトで選択されているのですが、場合によってはOpenCoreやCloverの起動ボリューム選択画面で選択する必要があります。

最初の再起動では、macOS Installerというボリュームが見えたので、それを選択しました。これでインストールが正しく進みました。今まではBoot macOS Install from xxxxというような名前のボリュームを選ぶことになったので、少し違った様子です。

次の再起動では、さらに悩みました。Prebootというボリュームが見えていて、これを選択するのが正しかったです。従来は、PrebootはFileVaultのログイン用に使うボリュームだと思っていたのですが、今回は違うようです。

ボリュームの名前に関しては、前述のように実機でも同じようにわかりにくい不具合（実機ではEFIという名前になってました）があります。公開バージョンになれば改善されると思います。Mifjpnさんのブログに、再起動時に選択肢が現れない場合への対処法や、Prebootから改名する方法などが紹介されています。

インストール後のBig Sur起動ディスクの容量は40.05GBでした。64GB SSDで十分でした。今回使用した64GB SSDは骨董品なので180MB/sくらいしか読み取り速度が出ないのですが、最近だとこれより高速な64 GB USBメモリーが1,000円台で買えるのですね。

Big Surで起動

Prebootから起動すると、いつものような設定画面を経て、Big Surが起動します。デフォルト壁紙が、今までの写真から、カラフルな絵に変わって、新鮮な感じです。少し操作を試しましたが、特に問題はないようです。サクサクといつものように動作します。この調子ならば、例年のようにスムーズにバージョンアップが出来そうです。

おまけ：Z490では苦戦中

こうして動かしたSSDを、Z490のマシン

ASUS ROG STRIX Z490-G, 10900K

で動かそうとしたのですが、こちらは、OpenCoreが動いてすぐに

[EB|#LOG:EXITBS:START]

という表示で止まってしまい、起動しません。Catalinaは問題なく起動するのですが、なぜかBig Surだと起動しません。こちらのトラブル対策を試してはいるのですがまだ解決していません。メモリーマップが変わったのかなとは思ってます。

追記：Beta 6になったらZ490マシンで動くようになりました。

macOS Big Sur 11.0 Beta 6 をインストール

自作PCにiMac20,1のシリアル番号を設定する

Sun, 23 Aug 2020 00:49:27 +0900

Comet Lake-S搭載自作PCの機種IDを、iMac 2020に合わせてiMac20,1に設定しました。iMac 2020が発売されたばかりなので、現バージョンのOpenCoreとmacserialがiMac20,1に未対応です。そこでGitHubから最新版を入手して、MLB情報を追加して、ビルドしました。

OpenCoreをビルドする

先の記事で紹介したように、第10世代Comet Lake-S搭載のマシンは、iMac 2020に合わせてiMac20,1に設定するのが良いと思います。最新のmacOS 10.15.6 (19G2021)は、iMac20,1に対応しています。でも現在のOpenCore 0.6.0は、iMac 2020が発売される前のバージョンなのでiMac20,1に対応していません。

OpenCoreは現在0.6.1の開発が進んでいて、GitHubでソースコード一式を入手できます。後で詳しく説明しますが、0.6.1ではiMac20,1, 20,2の機種IDに対応しつつあります。なのでこれをビルドすれば、対応したOpenCoreを入手できます。

GitHub - acidanthera/OpenCorePkg: OpenCore bootloader

OpenCoreのビルドはやったことがなかったのですが、いつもコメントを書いていただいているMifjpnさんのサイトの記事を見て、試してみました。最初はいくつかのツールをダウンロードすることになりましたが、基本的には自動で簡単にビルドできました。

デイリービルドの日々・・・Big Sur Betaが終わるまで

ビルドした結果は、こちらに置いておきました。後で説明するiMac20,1対応のmacserialも含まれています。

OpenCore-0.6.1-RELEASE.zip

これでiMac20,1に対応したmacserialとOpenCoreが得られます。そこで、macserialでiMac20,1のシリアル番号を生成して、これをconfig.plistに書き込み、OpenCore 0.6.1を使えば、iMac 2020に相当するマシンになります。

ここから先は、ソースコードの細かい話ですので、興味の無い方は、「IDを生成する」の節まで飛ばしてください。

macserialとOpenCore

Hackintoshのconfig.plistに書くべきシステムシリアル番号、ボードシリアル番号 (MLB) などを自動生成してくれるツールにmacserialがあります。以前の記事でも紹介しました。macserialのソースコードは、今は同じacidantheraさんが管理するOpenCoreのソースに組み込まれています。以前のmacserialの部分は、OpenCoreのUtilitiesディレクトリに収められています。

macserialは、機種ID、シリアル番号の規則、MLBの規則などの様々なMacの機種情報を把握した上で、シリアル番号などを自動生成しています。Macの機種情報は、従来はmacserialのヘッダファイルに手作業で書き込まれていました。しかし今は、OpenCoreのAppleModelsというディレクトリの中で、MacBook, iMacなどの種類ごとにテキストファイルで書き込まれています。機種情報は、macserialだけでなくOpenCoreパッケージの他のプログラムでも利用されています。なので、config.plistに個体特有の機種情報を書くだけで、それ以外の機種共通の情報、例えばBoard IDやファームウェアバージョンなどは、自動的に用意されるのです。

iMacの情報は、AppleModels/DataBase/iMacの中にあります。最初、OpenCore 0.6.1のGitHubを見ていたときには、iMac20,1, iMac20,2の情報はDataBaseの中にありませんでした。しかし、最近になって有志の方が書き込んでくれたようで、IM201.yaml, IM202.yamlという2個のファイルが作られています。そこで、現時点でOpenCore 0.6.1をビルドすると、iMac 2020に対応したOpenCoreが得られます。またターミナルでmacserialのディレクトリに移動してmakeコマンドを打ち込めば、macserialもビルドできます。

macserialを使ってみる

この記事を書いている時点で配布されているmacserialを使ってみると、生成されるiMac20,1, 20,2のMLBが不完全でした。例えば、iMac20,1のシリアルとMLBを生成すると、以下のようになります。

% ./macserial --model iMac20,1
C02C68ZDPN5T | C02005101QX00008C
C02D90GAPN5T | C02035401J900008C
C02CRFZPPN5T | C020213034N0000AD
C02C9MZFPN5T | C02008108QX00001H
C02DK0K5PN5T | C02042501GU0000UE
C02CK0A6PN5T | C02015130CD0000CB
C02CK6Y6PN5T | C02015902J90000JC
C02D1MYSPN5T | C02027501QX00001M
C02D2CYVPN5T | C02028101GU00001F
C02C5VZKPN5T | C020041304N0000JC

シリアル番号は正しく生成されているようですが、MLBの方は下6桁から下3桁の4文字が0になっています。シリアル番号を紹介する記事で説明したように、本来ならばここにはiMac20,1特有のボードコード(AppleBoardCode)が書かれるべき場所です。AppleBoardCodeが0なのは、前述のIMAC201.yamlに記載が無く、仮の値として0000が書き込まれているからです。

MLBを見つけてくる

シリアル番号とMLBを生成するためには、実機のiMacの番号を見つけて、それから機種固有のコードを知る必要があります。上の例で、シリアルに共通しているのはPN5Tという下4桁の部分で、これが機種固有のAppleModelCodeです。シリアル番号は、以前の記事でも紹介したように、ネットを探すとわりと簡単に見つかります。「このMacについて」にシリアル番号が表示されるからです。これに対してMLBは簡単には表示されません。なのでGitHubに機種情報を書いてくださった方も、ネットからわかる範囲でDataBaseを用意してくれたので、生成されるMLBの一部が0000になってしまっています。

ということで酷暑の中、iMac 2020が展示されているお店を巡ってMLBを調べてきました。大都会のアップルストアに行ければ良かったのですが、近場の量販店に置いてあったのはどこも10500搭載モデルが1台だけでした。つまりiMac20,1だけでした。そのMLBを調べた結果、いずれの展示品iMacのMLBも、AppleBoardCodeの部分はPHCDでした。ちなみに、シリアルのAppleModelCodeはどれもPN5Tでした。貴重な情報を得られたので、お礼に買い物もしてきました。

macserialをビルドする

このAppleBoardCodeを

OpenCore/AppleModels/DataBase/iMac/IM201.yaml

に書き込みます。以下のようになります。

# Note, first model code is used by macserial
AppleModelCode:
- "PN5T"
- "PN5Y"
- "PN5X"
- "PN5W"
- "PN5V"
- "PN78"
- "PN7D"
- "PN77"
- "PN7C"
# Note, first board code is used by macserial
AppleBoardCode:
- "PHCD"

ちなみに現時点でAppleModelCodeは9個登録されています。9個あっても、コメントにあるように、シリアル番号生成には最初の1個だけが使用されます。なので、特定のAppleModelCodeを使いたかったら、それを最上位に移動しておくと良いです。この後、

OpenCore/AppleModels/update_generated.py

を実行します。このコマンドでmacserialの機種情報ヘッダファイル、modelinfo_autogen.hが更新されます。README.mdにあるように、yamlを解釈するPythonライブラリであるpyyamlを事前にインストールしておく必要があります。

この後、OpenCore全体をビルドすればmacserialもビルドされてiMac20,1対応になります。macserialだけをビルドするのであれば、ターミナルで

OpenCore/Utilities/macserial

に移動し、

make

とタイプすると、macserialをビルドできます。makeするための条件を満たすために、

touch macserial.c

としてソースファイルの日付を更新しておく必要があるかもしれないです。

IDを生成する

こうしてビルドした新macserialを使えば、以下のようにAppleBoardCodeがPHCDのMLBを生成してくれます。これをconfig.plistに書き込めば良いです。

% ./macserial --model iMac20,1 --week 30
C02D4SZ5PN5T | C02030100GUPHCDAD
C02D409PPN5T | C02030500J9PHCD1F
C02D4LZGPN5T | C02030130J9PHCDCB
C02D4GYUPN5T | C02030100CDPHCD8C
C02D4BZ8PN5T | C02030404GUPHCD8C
C02D4DYJPN5T | C02030403CDPHCDJA
C02D47YYPN5T | C02030600GUPHCDA8
C02D4EY9PN5T | C02030303GUPHCDA8
C02D40JYPN5T | C02030100GUPHCDAD
C02D40QHPN5T | C020304054NPHCDAD

ちなみに、上記ではmacserialのweekオプションを使って製造週を30週に指定しています。これを指定しないと、例えば2020年1月製造とか、2020年10月製造のシリアルが生成されてしまいます。iMac 2020が未発売時点の製造日や、未来の製造日は避けたいです。30週は、2020年7月22日から28日なので、この記事の時点で妥当な値です。

OpenCore 0.6.1に反映されました

この記事を書いている間に、今回紹介したAppleBoardCode情報がOpenCore 0.6.1に反映されました。GitHubに出してあったpull requestをvit9696さんが受理してくれました。たったの4文字だけですがOpenCoreに貢献できて嬉しいです。

まとめ

iMac20,1のMLBを街で探して、OpenCoreのソースに反映しました。これでiMac20,1のシリアル番号と完全なMLBが作れるようになります。これらをconfig.plistに書き込み、OpenCore 0.6.1とmacOS 10.15.6 (19G2021) でComet Lake-S自作機を動かしていますが、今のところ問題はありません。

第10世代自作PCの機種IDはiMac20,1が良い

Sat, 22 Aug 2020 12:34:43 +0900

第10世代CPU, Comet Lake-Sで自作したら、機種IDはiMac20,1にするのが良いと思います。iMac 2020に搭載されるComet Lake-S CPUの全てに適用されるIDだからです。ただ、Radeon RX 5700 XTなどを使用する場合は、類似GPUを搭載するiMac20,2の方が性能を引き出せる可能性も無いとは言えません。でも、実測したところ性能に違いはありませんでした。

iMac 2020には2種類の機種IDがある

前回の記事で紹介しましたように、iMac 2020には、iMac20,1とiMac20,2の2種類の機種IDがあります。ここでは、Comet Lake-Sの自作PCでmacOSマシンを作る場合、そのどちらを使用したら良いかをさらに考えてみます。

iMac20,1とiMac20,2の違い

とりあえずは全てのComet Lake-Sモデルが対象になっているiMac20,1にしておくのが良いと思われます。特に10500や10600などを使う場合はiMac20,1にすべきでしょう。また多くの人がiMac20,1に設定すると思われるので、iMac20,1にしておけば、トラブル解決情報も容易に得られると思います。

ただ、iMac20,2はRadeon Pro 5700とPro 5700 XT搭載モデルなので、よく似た型番のRadeon RX 5700とRX 5700 XT搭載グラフィックスカードを使用する場合だけに関しては、iMac20,2の方が適切なのかもしれない、とも考えられます。もしかしたらiMac20,2にした方が、5700 (XT)のグラフィックス性能がより引き出せるのかもしれません。そこで今回は、RX 5700 XT搭載マシンで、性能差を検証しました。

iMac20,1と20,2でベンチマーク

機種IDをiMac20,1もしくはiMac20,2に設定するためには、それぞれのシリアル番号などを正しく生成して、対応したmacOSとOpenCoreを使用するのが良いです。この話題については次の記事で紹介します。

今回のベンチマークで使用したマシンは、こちらで紹介したものを基にして、さらにCPU, macOSとOpenCore, kext類をアップデートしてあります。

ASUS ROG STRIX Z490-G GAMING (WiFi)
Intel Core i9 10900K
macOS 10.15.6 (19G2021)
OpenCore 0.6.1
Radeon RX 5700 XT (ASUSのリファレンスファン)

このマシンの機種IDをiMac20,1とiMac20,2に設定して、それぞれでGeekbench 5のOpenCLとMetalのテストを5回ずつ実施しました。その平均を以下に示します。相変わらずしょぼいスコアで、同じ条件のRX 580に負けているのではと思いますが、今回はモデルIDの違いだけに注目します。

その結果、iMac20,1とiMac20,2では差がないことが判明しました。むしろiMac20,1の方が多少良いくらいです。ただ、個々のスコアを見ると、それぞれ逆転しているスコアもあり、違いは誤差範囲かと思われます。

まとめ

Radeon RX 5700 (XT)を使用した場合、iMac20,2に設定した方が性能を引き出せるのかどうかを検証しました。その結果、iMac20,1との差はありませんでした。第10世代で自作するなら、どの構成でも、機種IDはiMac20,1にすれば良いと思います。

iMac20,1とiMac20,2の違い

Tue, 18 Aug 2020 23:43:32 +0900

Comet Lake-S搭載のiMac 2020には、iMac20,1とiMac20,2という2種類のModel IDが存在します。Geekbench Browserなどからの類推によると、どうやらRadeon Pro 5300と5500 XTを搭載したモデルがiMac20,1で、5700と5700 XTを搭載したモデルがiMac20,2のようです。

CPUが違う？

こちらで、iMac20,1と20,2の違いが議論されていました。Geekbench Browserで確認すると、iMac20,1に搭載されるCPUは以下の4種類があり、iMac 2020に搭載されてる全てのCPUを網羅しています。

10500
10600
10700K
10910

一方でiMac20,2に搭載されるCPUは以下の2種類だけです。

10700K
10910

なので10700Kと10910搭載iMacには、iMac20,1と20,2の2種類のハードウェアが存在することがわかります。その違いが性能差に現れるかどうかをGeekbench Browserで検索して調べてみました。すると、同じCPUでCPU Resultsを比較すると、若干iMac20,2の方が高いような気もしますが、逆転している結果もあります。たとえば、10910を搭載したiMac20,1と20,2を検索して比較すると、スコア10,000超えはなぜか全て20,2ですが、それ以下のスコアでは両方のIDが入り乱れて競っています。Model IDによるCPU性能の違いはあまり無いようです。

GPUが違う。

一方でMetalとOpenCLのスコアを比較すると、iMac20,2がiMac20,1を明らかに上回っています。たとえばOpenCLで比較すると、20,1のスコアは36,000から50,000くらいなのに対して、20,2は44,000から61,000くらいです。このことからModel IDの違いは、GPUの違いなのではと言われています。つまり、iMac20,1は、

Radeon Pro 5300
Radeon Pro 5500 XT

を搭載していて、iMac20,2は

Radeon Pro 5700
Radeon Pro 5700 XT

を搭載しているようです。

仕様で確認

Appleの仕様ページをもとにすると、この結果から以下のように分類できます。これから10500, 10600搭載のiMacは必ずiMac20,1であることが確認できます。10700K搭載iMacは、搭載GPUの違いによってiMac20,1とiMac20,2の両方の可能性があります。また10910へは、どのGPU搭載モデルからもアップグレード可能なので、これにも両方のModel IDが存在します。

どちらのIDを使うべきか

この推測が正しいとしたら、自作PCにはどちらのIDを割り当てるべきでしょうか。

まず、10500や10600で組む場合には、おそらくiMac20,1が良いと思います。そのまま、将来10700Kや10900Kなどにアップグレードする場合も、iMac20,1を使い続けて良いはずです。

一方、10700Kや10900Kなどで組む場合には、20,1でも20,2でもどちらでも良いと思います。グラフィックスカードに、Radeon RX 5700や5700 XTを搭載する場合には、もしかしたら20,2の方が良いのかもしれません。ただ、Radeon ProはApple専用の特別版（クロック低下版）で、市販のRadeon RXとは同一ではありません。なのでこだわる必要はそれほど無いかもしれないです。MacRumorsの議論にあるように、20,2はおそらくは、高性能GPUのために電源、冷却機構などのハードウェアを対応させた程度の上位バージョンで、macOSとしての対応は変わらないのではないかと思います。

ということで、自作PCに対しては、iMac20,1を割り当てておけば良いと思います。

iMac 2020シリアル番号の仕組み

Sat, 08 Aug 2020 18:51:08 +0900

ネット上にある開封動画から、iMac 2020のシリアル番号のフォーマットを解析しました。以下の記事のこの部分に追記しました。

第10世代CPU搭載iMac登場

ロジックボードのシリアル番号 (MLB) を生成するには、MLBの下6-3桁 (AppleBoardCode) が必要のようです。こればかりは実機で調べてこないとわからないかな。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

Thu, 06 Aug 2020 21:56:56 +0900

OpenCore 0.6.0が出たので、ASUSのZ490マザーボードのオーディオを再設定しました。OpenCore 0.6.0とAppleALC.kext 1.5.1がZ490マザーボードに対応したことから、PCI IDを偽装しなくても動くようになりました。

今までの設定

前回は、OpenCore 0.5.9を使ってZ490マザーボード搭載コーデックを動かしました。特別な設定不要で音が出たASUSの先代Z390マザーボードには、ASUSの仕様書によると、オーディオユニットにはSupremeFX S1220という名前が付けられています。Hackintoolなどで調べるとコーデックはRealtekのALC1220のようです。Z490マザーボードになって、これがSupremeFX S1220Aになってました。HackintoolではRealtek ALCS1220Aになっています。SやAが追加されていますが数字部分は同じなのであまり変わらないと思ったのでしたが、デバイスIDを偽装する設定を行わないと、音が出ませんでした。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

ここに書きましたように、kextに、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を入れ、さらにconfig.plistでデバイスIDを指定し、レイアウトIDを7に指定する必要がありました。

<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
<dict>
 <key>device-id</key>
 <data>cKEAAA==</data>
 <key>layout-id</key>
 <data>BwAAAA==</data>
</dict>

OpenCoreとAppleALCの最新版を使う

OpenCoreが0.6.0になり、またAppleALC.kextが1.5.1になり、その両方の資料で、Z490マザーボード搭載オーディオに対応したとの記述を見つけました。ならば、FakePCIIDを使わなくても音が出るようになったのかと思い、試してみました。

まずはAppleALC.kextだけ更新しました。それでFakePCIID_Intel_HDMI_Audio.kextを外してみました。FakePCIID.kextは、Ethernetチップを動かすためにも必要なので、外してません。でも音は出ませんでした。そこでOpenCoreも0.6.0にアップデートしました。0.5.9から0.6.0へのアップデート作業は、こちらをご覧ください。

OpenCore 0.5.9 から 0.6.0 に更新

AppleALCとOpenCoreの両方をアップデートしたところ、FakePCIID_Intel_HDMI_Audio.kext無しで、config.plistにもデバイスIDを書かなくても、音が出ました。config.plistの該当部分は、こんな感じになりました。

<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
<dict>
 <key>layout-id</key>
 <data>BwAAAA==</data>
</dict>

レイアウトIDは必要です。このマザーボードは7でしたので、それがBase64形式で書いてあります。

まとめ

ということで、OpenCoreとAppleALCの現行バージョンなら、レイアウトIDの指定だけで、何も特別なことをしなくてもZ490の音が出るようになりました。コメントでもOpenCoreとAppleALCの最新版でPCIIDの偽装が不要になったとの情報をいただいています。新型iMacで第10世代CPUが採用されたこともあり、これでZ490がさらに気軽に使えるようになったと思います。

第10世代CPU搭載iMac登場

Wed, 05 Aug 2020 23:28:12 +0900

Comet Lake-Sを搭載した新しいiMacがようやく登場しました。Z490マシンのSMBIOS情報に早速にも反映させたいところですが、いつものようにスペックが謎です。そこで、わかる範囲でメモしました。明らかになり次第、更新していきたいと思ってます。情報ありましたらコメントでお知らせください。

Model ID

今までの経緯からすると新27インチiMacのモデルIDは、iMac20,1になるのではないかと思います。と思って検索していたら、Appleの公式ページにiMac20,1とiMac20,2というモデル番号が出ていました。これによると27インチにはiMac20,1とiMac20,2の両方があるようです。どのCPUがどちらのIDになるのか知りたいところですが、20番になるのは確定です。またパーツナンバーはMXWT2xx/A, MXWU2xx/A, MXWV2xx/Aになるようです。

Identify your iMac model

追記：Geekbench Browserのベンチ結果投稿によると、Core i5-10500, Core i5-10600, Core i7-10700K搭載モデルがiMac20,1で、Core i9-10910搭載モデルが20,2のようです。上位モデルが「,1」だったiMac 2019モデルとは逆ですね。

CPU

新iMac 27インチには、ベースモデルが3種類、オプションで1種類、合計4種類があります。iMacの搭載CPUが何なのかあまり情報はありません。搭載CPUに興味があるのはhackintoshしている人たちだけなのかも。公開されているスペック情報も限られています。その公式情報によると搭載されているCPUの説明は以下のようです。

3.1GHz 6コア第10世代Intel Core i5（Turbo Boost使用時最大4.5GHz）
3.3GHz 6コア第10世代Intel Core i5（Turbo Boost使用時最大4.8GHz）
3.8GHz 8コア第10世代Intel Core i7（Turbo Boost使用時最大5.0GHz）
3.6GHz 10コア第10世代Intel Core i9（Turbo Boost使用時最大5.0GHz）

いつものようにコア数とクロック数しかわかりません。これだけの情報と、Comet Lake-Sとして公開されている情報からすると、6コアCPUと8コアCPUには、該当するクロック数のComet Lake-Sモデルがあります。なので、それぞれの機種のCPUは以下と思われます。

Intel Core i5 10500 (65W)
Intel Core i5 10600 (65W)
Intel Core i7 10700K (125W)
?

最上位のCPUに関しては、北森瓦版で10910というモデルが紹介されていました。元記事はtom’s Hardwareです。10900Kと10900の中間のモデルだそうです。ベースクロックが3.6GHzというのは合っていますがTBの値が少し違います。でもこの可能性は高いと思います。

追記：Geekbench Browserからの情報から10910なのは確実のようです

Intel Core i5 10500 (65W)
Intel Core i5 10600 (65W)
Intel Core i7 10700K (125W)
Intel Core i9 10910 (95W)

Geekbench Browserで検索する

Geekbench BrowserでiMac20,1を検索したところ、現時点で3件の結果が見つかりました。時間的にどれも同じ人が上げている様子です。Hackintoshである可能性もあるのですが、macOS 10.15.6のBuildが19G2005という見慣れない数値ですし、MotherboardのIDもそれっぽいので、いち早くiMac20,1を入手した人が動作させた可能性が高いです。これを見ると、3.8GHzマシン（ベースモデル最上位）のCPUは確かに10700Kのようです。

Geekbench Browserで検索する（続報）

その後、さらにGeekbench BrowserでiMac20の検索を試みました。投稿がさらに増えていました。この結果、全ての搭載CPUが判明しました。上の予想通りで、最上位モデルは、やはり10910だったようです。ということでGeekbench Browserから推測する搭載CPUとモデルIDは以下です。

Core i5-10500 3100 MHz (6 cores) iMac20,1 BID=Mac-CFF7D910A743CAAF
Core i5-10600 3300 MHz (6 cores) iMac20,1 BID=Mac-CFF7D910A743CAAF
Core i7-10700K 3800 MHz (8 cores) iMac20,1 BID=Mac-CFF7D910A743CAAF
Core i9-10910 3600 MHz (10 cores) iMac20,2 BID=Mac-AF89B6D9451A490B

それにしても10500と10600の性能差が僅差で、逆転している報告も多いですね。搭載グラフィックスも同じだし、なんでこんな微妙な製品構成にしたのかな。

GPU

上記のAppleのスペックページによると、GPUには

Radeon Pro 5300
Radeon Pro 5500 XT
Radeon Pro 5700
Radeon Pro 5700 XT

が搭載されているそうです。多分新しいチップです。以前と同じくProは、同じ型番のRXシリーズのApple社用カスタムチップだと思います。例えばPro 5700 XTは、RX 5700 XTより省電力にしてiMacの筐体に収まるようにしたバージョンのようです。新GPUに関する記事がこちらにありました。これによると、例えばPro 5700 XTはRX 5700 XTに比べて、プロセッサユニット数は同じですが、性能が9.75TFLOPSから7.6TFLOPSに落ちているようです。おそらくクロック数を落として発熱を抑えて、iMac筐体に対応させたのではと思います。でもProとRXは、ハード構成は同じようなので、新iMacをサポートしたmacOS (19G2005 ?)で、RX 5700 XTの互換性が向上したらありがたいです。

内部構造

分解記事と動画が上がっているようです。コメントで教えていただきました。

[VIDEO] Unboxing & Teardown: The 27-inch iMac 5K (2020)

SSDは半田づけで交換不可能ですが、CPUはソケット式で交換可能なようです。

シリアル番号フォーマット

シリアル番号の生成プログラムmacserialなどがまだ新機種に対応していませんので、新機種シリアル番号のフォーマットをぜひ知りたいところです。

ネットを徘徊していたら、開封動画がぼちぼち公開されていて、その中にシリアル番号を見せてくれている動画がありました。それからフォーマットを解析します。皆さんもネット上で新機種のシリアル番号を発見したらぜひコメントでお知らせください。

10700K搭載モデル

こちらは10700K搭載モデルのようで、C02CV0VDPN5Wという数値が読めます。この番号から、今まで通りの伝統的な12桁のシリアル番号フォーマットに従っているらしいことがわかります。それぞれの桁を調べると以下になります。フォーマットの詳細は、こちらの記事で紹介してあります。

C02: 製造場所番号で、中国のQuanta Computer製造です。
C: 製造年。2019年でZまで使い切ったので2010年の表記 (CとD) に戻ったと思われます。2020年前半を示しています。
V: 製造週。24週目（後半なら50週目）を表します。つまり2020年の6月8日からの1週間に製造されてます。
XXX: 次の3桁は、製造ライン番号もしくは、組み立て担当者のIDです。製品個体ごとに異なる番号です。
PN5W: プラットフォームモデルです。製品の種類を表す番号です。この番号は、一つのModel IDに複数存在します。iMac20,1の一つのプラットフォームモデル番号はこの番号だとわかります。

こちらでも10700K搭載モデルの番号が読めます。C02D33YEPN5Wです。PN5Wが10700K搭載iMac20,1の番号なのは間違い無いです。

10910搭載モデル

こちらの動画では10コアモデルのシリアル番号が読めます。C02D2018046Tです。これによると、

C02: 製造場所番号。中国のQuanta Computer製造です。
D: 製造年。2020年後半を示しています。
2: 製造週。28週目を表します。つまり2020年の7月6日からの1週間に製造されてます。
XXX: 次の3桁は製品個体ごとに異なる番号です。
046T: iMac20,2の一つのプラットフォームモデル番号はこの番号だとわかります。

こちらでも10910搭載モデルの番号が読めます。C02D5007090Yです。また、こちらにもありました。こちらは、C02D401H090Yです。090Yというプラットフォームモデル番号もあるようです。

10500搭載モデル

こちらの動画のAbout this Macでは、「3.1GHz六核」と読めるので、10500搭載モデルのようです。C02D4311PN5Tです。これから、

C02: 製造場所番号。中国のQuanta Computer製造です。
D: 製造年。2020年後半を示しています。
4: 製造週。30週目を表します。つまり2020年の7月20日からの1週間に製造されてます。
XXX: 次の3桁は製品個体ごとに異なる番号です。
PN5T: 6コアiMac20,1の一つのプラットフォームモデル番号はこの番号だとわかります。

シリアル番号のまとめ

2020 iMacも従来通りのフォーマットのシリアル番号のようでした。また、プラットフォームモデル番号は、それぞれ、

PN5T: Core i5-10500 3100 MHz (6 cores) iMac20,1
????: Core i5-10600 3300 MHz (6 cores) iMac20,1
PN5W : Core i7-10700K 3800 MHz (8 cores) iMac20,1
046T, 090Y : Core i9-10910 3600 MHz (10 cores) iMac20,2

となります。10600搭載モデルが発見されていませんが、グラフィックスが同じなのでおそらく10500と同じなのではと思います。ただ、10600搭載モデルは10910に変更できるのですが、10500搭載モデルはできないのでもしかしたら違うかもしれません。10600の情報が欲しいですね。

これで、iMac20,1とiMac20,2のシリアルを作れます。上記の製造週と、製造ライン番号を少し変えれば良いはずです。ただ、製造ライン番号は、同じ数値に対して重複して存在するので、そのうちの適切な数値を選ぶ必要があります。他のModel ID用に生成ソフトで作った製造ライン番号を使うと良いと思います。

まとめ

27インチ iMac2020に関して、仕様をまとめました。Geekbenchの情報は参考になりました。今のところ

CPUは4種類 (10500, 10600, 10700K, 10910)
GPUは4種類 (Radeon Pro 5300, 5500 XT, 5700, 5700 XT)
Model IDはiMac20,1(下位3モデル)とiMac20,2(最上位モデル)
Board IDはMac-CFF7D910A743CAAF (iMac20,1)とMac-AF89B6D9451A490B (iMac20,2)

というようなことが判明してます。

OpenCore 0.5.9 から 0.6.0 に更新

Wed, 05 Aug 2020 00:11:54 +0900

OpenCore 0.6.0が公開されたので、0.5.9から更新しました。まずは0.6.0になって更新されたファイルを差し替えるだけでもとりあえず動きました。次にconfig.plistを正しく変更しました。

Release 0.6.0 · acidanthera/OpenCorePkg

使用したのは、ASUS Z390 ROG MAXIMUS XI HERO、Intel 9900K、 Radeon RX 580の組み合わせのこちらのマシンです。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

更新ファイルだけ置き換える

とりあえず、更新されたファイルだけ差し替えてみました。ESPの中身のうち、OpenCoreの配布物に含まれないファイルは0.5.9からそのまま引き継ぎました。0.5.9から引き継いだのは、

最新にしてあったKextsフォルダの中身、
ACPIフォルダの中身はそのまま、
Resourcesの中身もそのまま、
とりあえず0.5.9のconfig.plistをそのまま使います。

0.6.0のファイルと入れ替えたのは、

BOOTフォルダの中身 (BOOTx64.efi)
Bootstrapフォルダの中身 (Bootstrap.efi)
Driversフォルダの中身 (AudioDxe.efi, OpenCanopy.efi, OpenRuntime.efi)
OpenCore.efi
Toolsフォルダの中身 (OpenShell.efiだけ)

です。quirkが変わったりしているようなので、config.plistも正しく更新すべきですが、とりあえずは、0.5.9から0.6.0へは、何もしなくても移行できました。

config.plistを正しく更新する

一応は動いたのですが、config.plistを正しく設定することにしました。OpenCore 0.6.0に付属しているsample.plistと現行のCoffee Lake-S用のconfig.plistをProperTreeを使って比較しました。変更点は以下のキーでした。

Booter–>Quirks–>ProvideMaxSlide

0.6.0で追加されました。タイプはNumberです。デフォルトでは0で、sample.plistでも0が設定してあります。KASLRのスライド値の最大を決めるようです。デフォルトの0はスライドさせないという意味かと思います。使用しているマザーボード（ASUS Z390 ROG MAXIMUS XI）はスライド幅に余裕があった気がしましたので、最大の255に設定してみました。KASLRの考え方からして、スライド幅が大きいほどセキュリティが向上するはずです。今のところ問題なく起動しています。もしも起動失敗することがあれば減らせば良いです。KASLRとスライドについてはこちらの記事で説明しました。

Misc–>Security–>BlacklistAppleUpdate

0.6.0で無くなりました。なので0.5.9のまま起動すると、画面に一瞬、BlacklistAppleUpdateに対するスキームが無いよというエラーメッセージが出ます。Appleのペリフェラルファームウェアのアップデートを無視する機能との説明です。指定する場所が、Misc–>Securityの場所から、次に説明するNVRAMに移動したようです。なので0.5.9のconfig.plistからこのキーを削除しました。

NVRAM–>7C436110-AB2A-4BBB-A880-FE41995C9F82–>run-efi-updater

0.6.0で追加されました。上記のBlacklistAppleUpdateの代わりです。設定場所がこちらに移動しました。macOSのEFIファームウェアアップデートを上書きします。これをNoに設定すると、macOSのファームウェアアップデート機能を阻止します。APFSに移行した時に、EFIがAPFSから起動できるようにアップデートされたのですが、あのようなことを阻止する機能のようです。実機ではないhackintoshならばファームウェアが全く違いますからNoに設定するのが妥当です。

UEFI–>APFS–>GlobalConnect

0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。0.5.9のconfig.plistにはありませんので、Falseとして追加しておきました。APFSドライバーをロードする時の、ハンドル（ポインターみたいなもの？）の扱いを、通常のやり方から再帰的なやり方に変更するオプションらしいです。これをTrueにすると起動に時間がかかるけど、古いHPラップトップがAPFSにアクセスするためには必要らしいです。なので古いHPラップトップ向けの設定ですね。

UEFI–>Output–>UgaPassThrough

0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。これもデフォルト通り、Falseとして追加しておきました。GOPプロトコルの上にUGAプロトコルを提供すると、説明にあります。UGAは古いプロトコルなのでもはやサポートされていない場合もあるのですが、古いEFIではUGAが画面表示に必要なこともあるらしいです。EFIの画面表示に問題がなければFalseで良いようです。

UEFI–>ProtocolOverrides–>AppleFramebufferInfo

0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。これもデフォルト通り、Falseとして追加しておきました。Apple Framebuffer Infoプロトコルをインストールし直す機能との説明です。VMや古いMacのフレームバッファ情報を上書きしてmacOS 10.4の古いEFIブートとの互換性を改善するとのことです。問題なければFalseで良いようです。

まとめ

OpenCore 0.5.9から0.6.0に移行しました。まずは新しくなったファイルを一つ一つ差し替えました。そのままで起動しました。次に、より正しく設定するために、config.plistを以下のように書き換えました。diffコマンドで0.6.0と0.5.9のconfig.plistを比較しています。<で示す行が追加した行で、>で示す行が削除した行です。

% diff config_060.plist config_059.plist
197,198d196
< <key>ProvideMaxSlide</key>
< <integer>255</integer>
648a647,648
> <key>BlacklistAppleUpdate</key>
> <true/>
704,705d703
< <key>run-efi-updater</key>
< <string>No</string>
801,802d798
< <key>GlobalConnect</key>
< <false/>
872,873d867
< <key>UgaPassThrough</key>
< <false/>
907,908d900
< <key>AppleFramebufferInfo</key>
< <false/>

OpenCoreで起動音を鳴らす

Tue, 14 Jul 2020 21:40:03 +0900

OpenCoreでMacの起動音が出るようにしました。起動画面をGUI化した際にインストールしたリソースファイルに起動音のファイルも入っていました。これとAudioDxe.efiを用意し、config.plistに幾つかの設定をすることで、起動音が鳴りました。

今回は、こちらの記事の続きです。

OpenCoreの選択画面をグラフィカルにする

少し前のMacでは起動音が出ましたが、煩わしいので消している人も多かったです。でも、最近のMacでは復活するという噂もあります。そうなると、起動音があっても良いのかなと思い、OpenCoreで試してみることにしました。今回も以下のガイドに従っています。

制限

起動音は、macOSが起動する前に鳴らすので、macOSのドライバーは使えません。コミュニティの皆さんが頑張って作ってくれたドライバーで音を出します。なのでマザーボード上の音源チップからのみ音が出せます。つまり、以下の制限があります。

USBオーディオからは起動音を出せません。
GPUオーディオからは出せる場合もありますしダメな場合もあります。

実際のMacは電源を入れると即座に音が出ます。ファームウェアが音を出しているのでタイミングが早いです。でもHackintoshで起動音の出るタイミングは、電源を入れて、BIOSのスプラッシュ画面が出て、OpenCoreのメニュー選択画面になったところです。電源投入から少し待たされます。ここまで来て、制御がようやくOpenCoreに引き渡されるので、仕方がないところです。

設定手順

音声ファイルを用意する

メニューGUI化の時にアイコンファイルを入手したのと同様に、以下から音声ファイルを手に入れます。

GitHub - acidanthera/OcBinaryData

このうち、OCEFIAudio_VoiceOver_Boot.wavが起動音のファイルです。これをOC/Resources/Audioの中に入れておきます。

ドライバーを用意する

AudioDxe.efiをOC/Driversの中に入れておきます。AudioDxe.efiはOpenCoreの配布ファイルに含まれています。

config.plistを設定する

config.plistをProperTreeで開いて、設定作業を行います。まずはSnapshot機能でAudioDxe.efiを登録しておきます。次に以下の設定を行います。

NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> SystemAudioVolume を0x46にする。10進数では70です。
UEFI -> Audio -> AudioSupportをTrueにする
UEFI -> Audio -> MinimumVolumeを50にする
UEFI -> Audio -> PlayChimeをTrueにする
UEFI -> Audio -> VolumeAmplifierを143にする

数字のところはボリュームの設定なので適当で良いようです。ただ、適切な範囲や大小関係の制約はあるようです。

ここまではガイドの例に合わせて設定するだけなので簡単です。問題は、ハードウェアごとに調整しなければならない3個のパラメータです。UEFI -> AudioのAudioDevice、AudioCodec、AudioOutです。

AudioDeviceを設定する

PciRoot(0x0)/Pci(0x1f,0x3)に設定しました。オーディオチップに割り当てられたPCIeのパスを指定します。すでにconfig.plistのDevicePropertiesで、マザーボード搭載コーデックのレイアウト IDが指定してあれば、そこのPciRoot以下の数値です。下の例ならPciRoot(0x0)/Pci(0x1f,0x3)です。

<key>DeviceProperties</key>
<dict>
 <key>Add</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

HackintoolのPCIeボタンからAudio deviceを探して調べることもできます。

またgfxutilというツールを使っても良いです。これを起動すると出てくるHDEFの行に、チップのPCIeパスが書いてあります。

% ./gfxutil | grep HDEF
00:1f.3 8086:a348 /PCI0@0/HDEF@1F,3 = PciRoot(0x0)/Pci(0x1F,0x3)

AudioCodecを設定する

0に設定しました。オーディオチップのアドレスIOHDACodecAddressを設定します。これはioregコマンドやIORegistryExplorerなどで調べることができます。ガイドに従って、以下のようにioregコマンドをタイプしたところ、

% ioreg -rxn IOHDACodecDevice | grep IOHDACodecAddress
 | "IOHDACodecAddress" = 0x0
 | "IOHDACodecAddress" = 0x2

上のように、0番と2番の二つの選択肢がありました。ここでアドレスが1個しか出てこなければ、迷うことなくその数値（たぶん0です）をAudioCodecに書いておけば良いです。ちなみに0番と2番が出てきたマザーボードはASUS ROG MAXIMUS XI HERO Z390です。一方で、ASUS ROG STRIX Z490-Gのマシンでは、IOHDACodecAddressは一個（0番）だけでした。

今回は2個の候補が出てきてしまったので、このどちらかを指定します。どちらかが、マザーボードに搭載されているコーデックです。ちなみにこのマザーボードのコーデックはRealtek ALC1220です。いろいろ調べる方法はあるようですが、ここでは以下のようにしました。まずは、grepの条件を緩めて、前後の情報を表示しました。

% ioreg -rxn IOHDACodecDevice | grep IOHDACodec
+-o IOHDACodecDevice@1F,3,0 <class IOHDACodecDevice, id 0x10000059d, registered, matched, active, busy 0 (1024 ms), retain 27>
 | "IOHDACodecVendorID" = 0x10ec1220
 | "IOHDACodecRevisionID" = 0x100101
 | "IOHDACodecAddress" = 0x0
 +-o IOHDACodecDriver <class IOHDACodecDriver, id 0x1000005a5, !registered, !matched, active, busy 0 (1022 ms), retain 25>
 +-o IOHDACodecFunction@1F,3,0,1 <class IOHDACodecFunction, id 0x1000005a7, registered, matched, active, busy 0 (1022 ms), retain 27>
+-o IOHDACodecDevice@1F,3,2 <class IOHDACodecDevice, id 0x10000059e, registered, matched, active, busy 0 (138 ms), retain 27>
 | "IOHDACodecVendorID" = 0xffffffff8086280b
 | "IOHDACodecRevisionID" = 0x100000
 | "IOHDACodecAddress" = 0x2
 +-o IOHDACodecDriver <class IOHDACodecDriver, id 0x1000005a6, !registered, !matched, active, busy 0 (135 ms), retain 25>
 +-o IOHDACodecFunction@1F,3,2,1 <class IOHDACodecFunction, id 0x1000005a8, registered, matched, active, busy 0 (135 ms), retain 25>

これを見ると、下のIOHDACodecAddressが2番のもののVendorIDに8086という数値が見えます。これはインテル社のものです。一方で、0番には、VendorIDに10ecという数値が見えます。Vendor IDは世界的に決められている番号なので「vendor id 10ec」でGoogle検索すると、メーカの名前が分かります。これは、Realtek Semiconductor Co., Ltd.のIDだそうです。

PCI Devices

ということで、これがRealtekのチップらしいので、AudioCodecには0番を指定すれば良いようでした。

AudioOutを設定する

0に設定しました。こちらは苦労しました。この番号で、オーディオピンの番号を指定するようです。バックパネルにアナログ5本、SPDIFが1本、さらにはマザーボード上にケースのヘッドフォン端子に接続するオーディオ用ヘッダピンもあります。これのいずれかを番号で指定するようです。0番から順番に試すしかないようです。手元のマシンで0番を試したところ、それがバックパネルのスピーカ出力でした。

まとめ

OpenCoreで起動音を出せるように設定しました。ほとんどの作業は、バニラガイドに書いてある通りで簡単ですが、AudioDevice、AudioCodec、AudioOutの設定は、環境に合わせて変更する必要があります。特にAudioOutは手探りでした。起動音は、最後まで鳴る時もありますが、どういうわけか中途で音が出なくなることもあります。起動音がなると、さらに本物のMacっぽくなって良いのですが、ちょっと煩いかもしれません。しばらく楽しむけど、常用はしないと思います。

Z490マザボ搭載WiFiをmacOS対応品に交換する

Wed, 08 Jul 2020 23:57:12 +0900

ASUSのZ490マザーボードのIntel製WiFi/BTモジュールをBroadcom製のBCM94360NGに交換しました。ただZ490から無線用M.2ソケットがCNVi専用になってしまいました。それでSSD用のM.2ソケットに、M Key, E Key変換M.2カードを使用して取り付けました。

デスクトップでE Key M.2を使う

macOSで使えるWiFi/Bluetoothモジュールは、こちらの記事で紹介してあります。

Hackintoshのパーツ選び【その4：無線編】

通常は、デスクトップマシンならPCIeスロット、ノートPCやミニPCならばM.2コネクタを使用して無線モジュールを取り付けるのが一般的です。とはいえ、デスクトップ構成でもPCIeスロットが使えない、もしくは温存しておきたい場合があります。特にmini ITXマザーボードにはPCIeが1本しかありません。これをmacOSでほぼ必須のグラフィックスボードに使用してしまうと、無線モジュール用のPCIeスロットがなくなってしまいます。その場合、M.2ソケットが空いていれば、それに無線モジュールを取り付けられます。

非CNViにも対応したマザボ

市販のWiFi機能搭載マザーボードには、M.2ソケット方のWiFi/Bluetooth無線モジュールが搭載されています。バックパネルのところにアンテナ端子が用意されていますが、その内側にシールドされた金属箱がある場合が多いです。この中に、M.2ソケットと無線モジュールが入っています。最近のかっこいいバックパネルカバーのついたマザボも、裏側のネジを外せばカバーが外れて、コネクタ部品が見えるようになります。

なお、このシールド箱内部のM.2ソケットは、SSDを接続するM Key M.2ソケットとは違い、E Key M.2ソケットと言うタイプです。M KeyがPCIeを4レーン持っているのに対して、E Keyは2レーンで、その代わりにUSBなどを備えています。Bluetooth機能はE KeyのUSBを利用しています。

M Key M.2 : PCIe x 4
E Key M.2 : PCIe x 2, USB ほか

シールド箱は、マザーボード裏側のネジを外すと取り外せます。取り外すと中にはE Key M.2無線モジュールがあり、マザーボードのM.2ソケットに挿さっています。

Z370世代までのWiFi搭載マザーボードでは、このE Key M.2ソケットに通常のPCIe/USB接続のM.2無線カードが取り付けられていました。Z390世代になって、インテルチップセットにWiFiサポート機能が搭載されていて、それと連携するインテル統合接続 (CNVi) という仕組みが用意されました。これは、WiFiのMAC層をチップセットで担当して、信号処理や無線の物理層をM.2カードで担当します。でもZ390では従来型の非CNVi方式M.2無線カードも引き続きサポートされていました。なので、Z390世代より前のマザーボードなら、以下の方法で、macOSと互換性のあるBCM94360NGに交換できます。

この金属シールドは、さらにネジ1個を外すと開けられます。これで、中の無線モジュールをBCM94360NGに交換し、macOSで使用できます。

Z490マザボの大半はCNVi限定

ところがZ490になって、多くの無線搭載マザーボードのE Key M.2ソケットが、インテルCNViに対応した無線モジュール専用になってしまいました。前回、ASUS ROG STRIX Z490-G GAMING (Wi-Fi)にmacOSをインストールしました。

Comet Lake-S 10600とZ490でmacOSを動かす

このマザーボードも、バックパネルのシールド内コネクタは引き続きE Key M.2ですが、従来型のM.2無線カードが動きません。ASUS ROG STRIX Z490-G GAMINGには、少し安価なWiFi無しのモデルもあります。あえてWiFiモデルを入手したのは、もしかしたらBCM94360NGが使えるかもしれないと思ったからです。でも、残念ながらE Key M.2ソケットはCNVi専用でした。SchmockLordさんのGitHubにも「使えません、信じてください」と書いてありました。実は上に掲載した写真は、このマザーボードでも、もしかしたら動くのではと思いつつ、作業した際の写真でした。

Z490でも非CNViに対応するマザボ

Z490でも従来型の非CNVi無線カードが使える製品もあります。これならば、上記で紹介した手順で、Broadcom製のBCM94360NGに交換可能です。IEEE802.11a/b/g/n/ac/axのWi-Fiは、新しいのでこれに対応したZ490マザーボードは恐らくCNVi専用と思われます。一方で、IEEE802.11a/b/g/n/acのみのZ490マザーボードならば、非CNViの可能性があります。例えば以下の製品はIEEE802.11a/b/g/n/ac対応なので、使えるかもしれません。

SSD用M.2に無線を取り付ける

今回はmicro ATXなので、PCIeスロットにも余裕があり、そちらにWiFi/BTカードを挿しても良かったです。でもせっかく割高のWiFiモデルなので、そのアンテナ穴を生かすことにしました。そこで、SSD用のM Key M.2ソケットを使うことにしました。このマザーボードは、SSD用のM.2ソケットが2個あります。1個しか使わない予定なので、余りを活用しようと考えました。

長いアンテナケーブル

バックパネルのアンテナ穴から、SSD用M.2まで配線するために、長めのアンテナケーブルを手配しました。バックパネルのコネクタの形状は、RP-SMA femaleと言うらしいです。見た目はmaleなのですが、名前はfemaleです。また、モジュールと接続する方の小さなコネクタにも種類があります。U.FLとかMHF4とかの名前のコネクタがBCM94360NGに適合します。ややこしいので、販売サイトの写真と実物を比較して確認するのが良いと思います。ケーブル長さは、30 cmを手配しましたが少し長すぎました。下のような20 cm長で十分でした。

M Key – E Key変換

マザーボード上のSSD用M.2ソケットに無線モジュールを装着する際に2つの選択肢があります。一つは、SSD用ソケットをBroadcom専用ソケットに変換して、純正のBCM94360CDなどを使う方法です。もう一つは、E Key M.2に変換してBCM94360NGを使う方法です。前者は、互換性としては安心ですが、変換器が少し特殊です。後者は、これもOOBで動き十分互換性が高い上に、一般的なM.2同士の変換なので変換器が容易に入手できます。今回は後者のE Key変換を行うことにしました。また、バックパネルのアンテナ穴が2個しかないので、同じアンテナ数2個のBCM94360NGで十分とも考えました。用意した変換器は、下のような製品です。

E KeyにはUSBがありますが、M Keyにはありません。そこで、アダプタには白いUSB用コネクタが付いています。付属のケーブルでマザーボードのUSB 2.0ピンヘッダに接続します。

取り付けと配線

実際に取り付け、配線を行った様子です。

バックパネルシールドからアンテナ端子を取り外して、長いアンテナケーブルの端子を取り付けます。アンテナ取り付け・取り外しで緩むことがないよう、ボックスレンチで締めておきました。ここからアンテナ線をM.2 SSDソケットまで引き回します。30cmと長すぎたので、CPU側のPCIeスロットを大回りして配線しました。USB 2.0のケーブルも長すぎたので、こちらもPCIeスロットを大きく迂回して配線しました。アダプタ上のUSBコネクタは、基板の端にあるので、ケーブルが隣のM.2 SSD用ヒートシンクに多少干渉します。でもケーブルを強く曲げておけばなんとか回避できます。バックパネルアンテナ端子のシールドは外したままですが、バックパネル端子カバーを取り付ければ見えなくなり、不自然さはありません。

まとめ

WiFi搭載マザーボードのインテルモジュールを外して、macOS互換無線モジュールを取り付けました。バックパネル部分のE Key M.2がCNVi専用だったので、M.2 SSD用のソケットを使い、そこにBCM94360NGを取り付けました。これにより、macOSの無線関連機能がOOBで動作しました。

400シリーズチップセットでも、一般的なM.2無線モジュールがバックパネルのM.2ソケットに取り付けられる製品もあるようです。WiFiの仕様が、802.11 a/b/g/n/ac/axとなっているマザーボードはおそらくCNVi専用で、802.11a/b/g/n/acとされているマザーボードはCNVi以外も動作する可能性があるようです。Redditの情報によるとASRock Z490M-ITX/acなどはBCM94360NGが使えるらしいです。

追記：コメントで教えていただきましたが、ASRock Z490M-ITX/acでBCM94360NGが動いたそうです。その一方で、Z390でも、GIGABYTE Z390I AORUS PRO Wi-FiはCNVi専用だったようです。

最近の構成で新旧グラボ (RX 580 vs. RX 5700) 性能を再測定

Sun, 05 Jul 2020 17:45:14 +0900

macOS Catalina 10.15.5, OpenCore 0.5.9, Z490 + 10600の構成で、再度、Radeon RX 580とRX 5700 XTのベンチマークを取り直しました。依然としてRX 580の方が高スコアでした。MacではApple特別仕様のNAVIを採用しているのですが、一般デスクトップ用GPUではドライバーが性能を発揮できないようです。Thunderbolt接続eGPUとして市販グラフィックスボードを使うユーザもいると思うので、対応してくれると良いと思います。

今までもRadeon GPUのベンチマークを紹介しました。

10.15.2にしたけどNaviの性能は向上しませんでした

Z490マシンをバラックで組んでいるので、最新の環境でもう一度ベンチマークをしなおしてみました。使用した機材と構成は以下です。

Intel UHD Graphics 630 (おまけで測定しました)
AMD Radeon RX 580, Sapphire NITRO+
AMD Radeon RX 5700 XT, ASUSのリファレンスファン
macOS Catalina 10.15.5 (19F101)
OpenCore 0.5.9
ASUS ROG STRIX Z490-G GAMING (Wi-Fi)
Core i5-10600
機種ID iMac19,1

Geekbench 5の結果は以下でした。前回の計測から、1回目の測定が良いスコアを出したので、今回は回数をあまりやっていません。ベンチを繰り返すと温度上昇してスコアが低下するのではないかと思います。以下の数値はベンチマークを2-3回実施した平均値です。


GPU	OpenCL	Metal
UHD 630	5020	4782
RX 580	43546	44448
RX 5700XT	41139	35489

グラフにしました。依然としてRX 580の方がベンチマークスコアが高いようです。以前の測定よりもさらに差が開いたような気がしないでもないです。ということで、RX 580がHackintoshに最適な状態はまだまだ変わらないようです。

GenSMBIOSを使って機種情報を設定する

Sun, 28 Jun 2020 10:04:25 +0900

以前、シリアル番号を決めるツールとしてmacserialを紹介しました。macserialを使いやすくしたツールにGenSMBIOSがあります。OpenCoreのガイドでよく使われていますので試してみました。config.plistにシリアル情報などを書きこめて便利でした。

Hackintoshの機種設定

Hackintoshを作ったら、それに機種ID、シリアル番号、UUID情報などのID情報を設定しておく必要があります。正しく設定しないと、macOSが動かないことがありますし、iCloudのサービスが使えないことがあります。さらにはユーザのApple IDが使用禁止にされてしまうこともあります。これらの設定はconfig.plistの中に書きます。CloverではSMBIOSのセクション、OpenCoreではPlatformInfoのセクションに書き込みます。

UUIDなどのIDは世界に一つしかない番号ならばなんでも良いです。uuidgenなどのコマンドで乱数発生させて作れば良いです。またOpenCoreのROM番号はEthernetのMACアドレスを流用するのが一般的です。一方でMacのシリアル番号は、生産地、生産年・週、番号、機種固有番号などから構成されています。全体の構成はMacの世代で違うことがありますし、機種固有番号は機種ごとに違います。シリアル番号の規則をリバースエンジニアリングして、生成・チェックするソフトが作られています。それがmacserialです。シリアル番号の仕組みとmacserialの使い方は、以下の記事で詳しく紹介しました。

Macシリアル番号の仕組み

GenSMBIOSの使い方

最近のOpenCoreのガイドでは、シリアル番号などの機種情報を生成するために、GenSMBIOSというPythonプログラムがよく使われています。これも中ではmacserialを動かしているのですが、より簡単に使えて、さらにconfig.plistへの書き込み機能を備えているので便利です。この記事ではGenSMBIOSを使ってみます。GenSMBIOSは以下からダウンロードできます。

GitHub - corpnewt/GenSMBIOS: Py script that uses acidanthera’s macserial…

ダウンロードするとGenSMBIOS.commandというファイルがあります。これが本体です。Terminal.appでこれを起動します（アイコンをダブルクリックしても良いです）。すると以下のメインメニューが現れます。

#######################################################
# GenSMBIOS #
#######################################################
MacSerial v2.1.2
Current plist: None
Plist type: Unknown

1. Install/Update MacSerial
2. Select config.plist
3. Generate SMBIOS
4. Generate UUID
5. List Current SMBIOS

Q. Quit

Please select an option:

このメニューを順番に説明します。

1. Install/Update MacSerial

最初のメニューは、内部で使用するmacserialの更新です。GenSMBIOS.commandがあるディレクトリの中に、Scriptsというディレクトリがあります。この中にmacserialが入っています。macserialの使い方は、過去の記事を見てください。macserialは、新しいMacが出るたびに、それをサポートするために更新されています。なので、GenSMBIOSのこのメニューは、macserialを最新版に更新します。既存のMacのシリアル番号生成規則も更新されている可能性もありますので、とりあえずは選択しておくのが良いと思います。

 #######################################################
 # Getting MacSerial #
#######################################################
Gathering latest macserial info...
- MacURL: https://github.com/acidanthera/macinfopkg/releases/download/2.1.2/macinfo-2.1.2-mac.zip

Downloading macinfo-2.1.2-mac.zip...
- Extracting...
- Found macserial
- Chmod +x...
- Copying to Scripts directory...

Cleaning up...

Done.

2. Select config.plist

生成したシリアル番号などを書き込む先のconfig.plistを指定します。ここで書き込み先のconfig.plistへのパスを入力するか、もしくは説明にあるとおりそのアイコンをドラッグ&ドロップします。すごいところは、Cloverのconfig.plistにも、OpenCoreのconfig.plistにもどちらにも対応しているところです。

 #######################################################
 # Select Plist #
#######################################################

Current:
Type: OpenCore

C. Clear Selection
M. Main Menu
Q. Quit

Please drag and drop the target plist:

試しに、OpenCoreに付属のデフォルトconfig.plistであるSample.plistをコピーして、config.plistに改名して入力してみました。

3. Generate SMBIOS

GenSMBIOSのメイン機能です。このメニューでSMBIOS情報を生成します。Macの機種IDを聞かれますので、入力します。ここではiMac19,1を指定しました。

 #######################################################
 # Generate SMBIOS #
#######################################################

M. Main Menu
Q. Quit

Please type the SMBIOS to gen and the number
of times to generate [max 20] (i.e. iMac18,3 5): iMac19,1

その結果、シリアル番号、ボードシリアル番号、UUIDが生成されます。2番目のメニューで、変更先のconfig.plistを指定してあれば、それに書き込まれます。指定していなければ、情報が表示されるだけです。その場合はテキストエディタなどで開いたconfig.plistにコピペします。

 #######################################################
 # iMac19,1 SMBIOS Info #
#######################################################

Type: iMac19,1
Serial: C02DN9ZSJV3Q
Board Serial: C020453004NLNV91M
SmUUID: 2BCB8DF6-7633-4F0E-B63C-975E3EFCEDFE

Flushing SMBIOS entry to /Volumes/Users/bootmacos/config.plist

Press [enter] to return...

今回は、前述のようにデフォルトのSample.plistと同一内容のconfig.plistを変更するように指定してあります。どのように変更されたかを確認するために、diffコマンドでconfig.plistと、元データのSample.plistを比較してみました。一見、多くの差分があるように見えますが、実は、

% diff config.plist Sample.plist
134,136c134
< <data>
< Q3B1UG0AAAA=
< </data>
---
> <data>Q3B1UG0AAAA=</data>

とあるように、元のSample.plistで情報という1行で記述された内容が、GenSMBIOSの処理により3行に分けられただけの場所が多いです。このような変更点を除いた、実質的に差分のある場所は、以下でした。

% diff config.plist Sample.plist

(略)
893c824
< 			<string>C020453004NLNV91M</string>
---
> 			<string>M0000000000000001</string>
903c832
< 			<string>C02DN9ZSJV3Q</string>
---
> 			<string>W00000000001</string>
905c834
< 			<string>2BCB8DF6-7633-4F0E-B63C-975E3EFCEDFE</string>
---
> 			<string>00000000-0000-0000-0000-000000000000</string>

ということで、000000…などの数値で仮に書かれていたシリアル番号、ボードシリアル番号、UUIDの場所だけが、今回新しく生成されたデータで書き直されていることがわかります。

なお、シリアル番号は、下記のサイトでそれが未使用であることを確認しておくべきです。ここで生成された番号を入力し、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば、その番号は未使用です。今回生成した番号はOKでした。

Check Your Service and Support Coverage - Apple Support

4. Generate UUID

これはおまけ的な機能だと思いました。UUIDだけを生成します。uuidgenというコマンドを動かしているだけだと思います。ちなみにこのメニューを選択しても、config.plistには書き込まれません。

#######################################################
# Generated UUID #
#######################################################

773F1659-07F1-4130-8C3B-FE2F900F9E95

Press [enter] to return...

5. List Current SMBIOS

これは現在起動中のマシンの情報を表示します。上のメニューで指定したconfig.plistファイルの内容ではありません。macserialの–infoオプションと同様に、シリアル番号の分析と有効性を表示してくれます。

まとめ

GenSMBIOSコマンドで、シリアル番号を生成して、config.plistに書き込む作業が楽になります。その過程で、シリアル番号が有効かどうかをAppleのサイトで確認しておく必要はあります。また、このコマンドでは、OpenCoreのconfig.plistにおけるPlatformInfo–>Generic–>ROMの設定は行ってくれません。Sample.plistでは0x112233445566になっています（Base64ではESIzRFVm）。任意の6バイトの数値で良いのですが、唯一の数字にしておくべきです。通常はEthernetのMACアドレスに設定しておくと良いようです。生成したシリアル番号は大抵の場合未使用ですし、ROMの値もAppleによって厳しくチェックされる情報でもありませんので、GenSMBIOSで設定すれば、とりあえずは起動してしまっても大丈夫だと思います。

HWMonitorを使う

Mon, 22 Jun 2020 00:21:52 +0900

CPUの温度、電力などをモニターするためにVirtualSMCに付属するモニター用kextを入れました。これにより、HWMonitorやHWMonitorSMC2などのアプリケーションでハードウェア状況をモニターすることができるようになりました。

HWMonitorなどのモニターアプリケーションをhackintoshで使用するためには、VirtualSMCやFakeSMCに用意されている、ハードウェアモニターkext類を使用します。いままでは、とにかく動作することが肝心だと思ってモニター用kextを使っていませんでしたが、ようやく試してみました。すでに使っている方は多いと思いますので、今さらな話題かもしれません。

Intel Power Gadget

CPUの状態をモニターする目的には、今まで、Intel Power Gadgetというアプリケーションは使ってました。これはインテルが配布しているアプリで、Windows, Linux, macOSで動きます。Hackintoshでも同様に動作するところがすごいです。このアプリは、FakeSMC/VirtualSMC用のkextが無くても動きます。

Intel Power Gadget

macOSにインストールすると、/Library/Extensionsの中に、EnergyDriver.kextというカーネル拡張がインストールされます。おそらくはこれがインテルのCPU周辺チップセットにアクセスして、温度や消費電力情報を取得してくれるのだと思います。なので、Macでもhackintoshでも同様に動作するようです。

ただ最近、Power GadgetのmacOS版がインテルのサイトから消えてしまったようです。一時的な状況かもしれませんが、メンテナンスが面倒で更新をやめてしまったのかもしれません。ということで別の手段を探しました。

HWMonitor

macOS専用のハードウェアモニターアプリケーションにHWMonitorがあります。昔のブラウン管式オシロスコープのアイコンです。ただ、これも最近は更新が止まっているように思いました。探したところ、以下のサイトでつい最近にアップデートされたバージョンが見つかりました。ダークモードに対応したとのことです。これ以外にもいろいろなアプリケーションがあるように思います。お勧めがありましたら、コメントで教えてください。（追記：HWMonitorSMC2を教えていただきましたので、記事の最後に追加しました）

Release HWSensors-V6.26.1465 EFI · chris1111/HWSensors-V6.26.1465-EFI

HWMonitorを、まずはMacBookで動かしてみました。インストーラを起動するとFakeSMC.kextなどをインストールするオプションもありますが、本物のMacなら不要です。アプリケーション本体だけあれば機能するので、アプリ本体だけをコピーして持ってきても動きます。起動するとメニューバーにアイコンが現れて、これをクリックするとプルダウンの中にCPU温度と電力が表示されます。バッテリーの残量も表示されます。

歯車のところをクリックするとメニューが現れ、このプルダウンをメニューバーから取り外すこともできます。

このMacBookのCPUは2コアです。なぜかCore 2とCore 3になっていますが、番号は気にしない方が良いようです。バックグラウンドでDropboxやiCloudドライブの更新が動いていたためかもしれませんが、CPU温度が90度後半です。MacBookはファンレスで静かなのですがこのように、触れないくらい熱くなり、応答動作がものすごく遅くなることがしばしばあります。グラフのボタンを押すと、温度・電力変化をグラフで見ることもできます。最高温度は100度ですね。

Hackintoshで動かす

次にHWMonitorを、先日作成したASUSのZ490マザーボードのマシンです動かしてみました。何の表示も出ません。

HWMonitorはMacに搭載されているSMC (System Management Controller) にアクセスして温度情報などを得ているようです。HackintoshではFakeSMC.kextやVirtualSMC.kextがSMCのフリをしてくれていますが、起動に必須ではない温度情報提供などの機能は無いようです。

次に別の、ASUSのZ390マザーボードマシンで動かしてみました。CPUの情報は、先ほどと同様に何も表示されません。しかし、搭載しているSATA SSD/HDDと、接続しているMagic Keyboard/Trackpadの情報が出ました。SSD Remaining Lifeは謎の表示がされて100％になってます。M.2 SSDも接続しているのですが、そちらの情報は表示されませんでした。どうやらSATA経由で温度情報が得られるようで、それが表示されているようです。

kextを入れて動かす

FakeSMD.kextにもVirtualSMC.kextにも、ハードウェア情報にアクセスするためのkextが作られています。VirtualSMC.kextの場合、配布パッケージに、

SMCSuperIO.kext
SMCProcessor.kext
SMCLightSensor.kext
SMCBatteryManager.kext

が同梱されて配布されています。このうち、SMCLightSensor.kextと SMCBatteryManager.kextはノートPC用のものです。光センサやバッテリーを搭載していないデスクトップマシンでは使いません。デスクトップでCPU温度などをモニターするのに必要なkextはSMCProcessor.kextです。SMCSuperIO.kextは、ファンコントロールなどを担当する入出力に関するもののようですが、HWMonitorの表示には変化がありませんでした。（追記：後述するHWMonitorSMC2というアプリケーションでは、SMCSuperIO.kextを入れておくとファン回転数などの情報が表示されるようになります。）

SMCProcessor.kextを上記のZ490マシンに入れて、HWMonitorを動かした結果が以下です。搭載したCPUは10600なので、6個のコアの温度が表示されました。コア1が2個表示されていますが、これも気にしないでおきます。MacBookと比較するとまともな温度で安心できます。

次に、上記のZ390マシンに入れた結果を以下に示します。搭載CPUが8コアなので、それぞれの温度が表示されています。ここでもCore 1が2個見えてます。

Z490マシンで、Geekbench 5を動かしつつ、Intel Power GadgetとHWMonitorを同時に動かした様子を下に示します。両方のアプリケーションで同じような結果が出ているので、信頼できる情報だと思いました。ベンチマークを動かすと瞬間的に70度を超えましたが、通常作業で90度越えの状態が続くMacBookよりはまともです。

HWMonitorSMC2

もう一つのハードウェアモニターアプリケーションです。コメントでまっくぷろさんから教えていただきました。これを使用するにあたって、HWMonitorと同様に、VirtualSMCに加えて以下をインストールしました。

SMCSuperIO.kext
SMCProcessor.kext

起動するとHWMonitorと同様にメニューバーに現れますが、表示される情報はより多いです。ファンの回転数、グラフィックス温度などの情報、メモリー使用状況などが表示されます。また、項目をダブルクリックするとその数値がメニューバーに常時表示されるようになります。ただグラフ表示する機能は無いようです。Z490マシンでHWMonitorSMC2を動かした結果を下に示します。

このマシンはマザーボードをケースに格納していない状態で試験中です。なので、CPUファンだけが接続されていて、その回転数が正しく取得できているようです。また、HWMonitorSMC2はVirtualSMCやFakeSMCの情報取得kext以外に、Intel Power GadgetのEnergyDriver.kextも利用するようです。Power Gadgetがインストールされた状態で、歯車ボタンで以下のように設定すると（デフォルトでは無効）、表示されるCPU情報項目が倍増します。

ASUS ROG STRIX Z490-G GAMINGのUSBを設定する

Fri, 12 Jun 2020 22:18:10 +0900

ASUSのZ490マザーボードのUSBポートを調査して、USBPorts.kextを作りました。レジストリに何故か現れないオンボードUSB 2.0ピンの割り当てを探し当てました。また、15個制限撤廃パッチが危険なことを確認しました。

USBポート設定の手順

前回作成したASUS Z490マザーボードマシンのUSBポートを設定し、El Capitanで導入されたUSBポート数15個制限に対処します。このマシンのOSはmacOS Catalina 10.15.5でブートローダーはOpenCoreです。

Comet Lake-S 10600とZ490でmacOSを動かす

USBポート設定の方法はこちらで紹介した方法です。

15個制限のためのUSBPorts.kextをHackintoolで作る

以下の手順で行います。この作業のツールには、ProperTreeとHackintoolを使います。

一時的に15個制限を撤廃して全部のUSBポートが見えるようにします。
USBコネクタに無線ドングルやメモリを挿して、ポートが割り当てられた名前を特定します。
15個以内で使用したいポートを選びます。
使用する15個以内のポートとそのコネクターを記述したUSBPorts.kextを作ります。
15個制限撤廃を中止して、USBPorts.kextを有効にして再起動します。

15個制限を撤廃する

ポートの調査のために、OpenCoreのUSB 15個制限撤廃quirkであるXhciPortLimitを使います。まず、エディタやProperTreeなどでconfig.plistを開いて、XhciPortLimitをtrueにします。つぎに再起動して、HackintoolでUSB一覧を見ると、レジストリーに現れるXHCポートの一覧が出ます。このマザーボードでは、以下のように21個のポートが見えていました。Hackintoolでは既にZ490マザーボードにも対応してくれているらしく、コントローラ名にComet Lakeの文字が読めます。

上の図では、HS11にだけデバイスが見えます。操作のために、以前紹介したトラックパッド付き無線キーボードを使っているので、その2.4 GHz無線ドングルが見えています。2.4 Gの文字の続きは文字化けしています。（「システム情報」で確認したら意味不明の漢字の羅列になってました。）

格安のトラックパッド付き無線キーボード

USBポートを特定する

初期状態では、Connectorの種類がでたらめです。またCommentの欄は空白です。そこで、USB 2.0と3.0のUSBデバイスをポートに一つ一つ挿しては外して調べます。バックパネルに出ているUSBポートはType-AとType-Cのコネクタになっているので調査は簡単です。でもマザーボード上のコネクタは通常のUSBコネクタではなく、内部接続用のヘッダピンとType-C用の特殊なコネクタ (Key-Aという名前らしいです) です。そこで、従来型USBヘッダピンをType-Aに変換するアダプター（と）と、を、それぞれ用意しました。

試験のために使うUSB 2.0デバイスには、出所不明のUSB WiFiドングルを使いました。USBメモリを使うと外す時にアンマウントの手間が不要ですが、無線ドングルならいきなり抜けます。USB 3.0のデバイスとしてはUSBメモリーを使いました。USBデバイスを挿していくと、Hackintoolの一覧の該当するポート名の行にデバイスの情報が現れます。これにより、ポート名と実際のポートの割り当てが特定できます。この時に、そのポート名のコネクタータイプ (USB2, USB3, Type-C Sw, Type-C, Internalのいずれか）を選択しておきます。またコメント欄に、対応する物理ポートの情報を英語でメモ書きしておくと、その内容がkextに反映されます。将来のメンテナンスなどの時に便利です。

バックパネルのType-Cは、反対向きに挿しても同じSS04に接続されました。これはスイッチで切り替えているようなのでコネクタタイプをTypeC+Swに設定します。一方で、オンボードのType-Cは、反対向きに挿すとそれぞれSS05とSS06に接続します。なのでUSB 3.2が2本使われている本格的なTypeCのようです。この作業により、上の図のポートの全てが、それぞれバックパネル（ASUSの仕様書に合わせてRearとコメントしました）とマザーボード上（仕様書に合わせてFrontとコメントしました）のUSBコネクタであることを確認しました。こうして完成したUSBポート一覧が以下です。何故かHS06が見当たりません。

オンボードUSB 2.0が見つからない

上の結果では、Z490-Gマザーボード上のUSB 2.0が見つかりませんでした。これは、昔ながらの黒いピンヘッダで、マニュアルにUSB_E12とUSB_E34と書かれています。

一つのヘッダピンに2個のUSB 2.0が配線されているので、合計4個のUSB 2.0が行方不明です。マザーボードのヘッダピンに、Type-A変換アダプタを挿して、USBデバイスを付けても、HackintoolやIORegistryExplorerの一覧に出てきません。USBメモリを付けても、マウントされずファインダーにも現れません。Windowsでは試していませんが、BIOSではここに挿したUSBメモリが起動ドライブとして見えています。macOSだけの問題のようです。Hackintoshで、純正WiFi/BluetoothモジュールをPCIe接続する場合、基板上のUSB 2.0ヘッダピンに信号を接続するのが一般的です。USB 3.1の2.0信号ピンに接続しても良いのですが、コネクタを付け替えるのが面倒です。なので、できればマザーボード上のUSB 2.0ヘッダピンを使いたいところです。

そこで怪しいのが欠番のHS06です。上のUSBポート一覧はHackintoolの画面をですが、IORegistryExplorerで調べてもやはりHS06は見えません。見えていないHS06がオンボードUSB 2.0である可能性が高いです。ASUSの最近のマザーボードでは（Z390がそうでしたが）オンボードのUSB 2.0は、USBハブを通して分割されて実装されているようです。このマザーボードも、HS06をハブで4個に分割してヘッダピンに接続していると思われます。もしかしたらハブを使っているために、レジストリーに現れないのかもしれません。

ということで、HackintoolのExportボタンで作ったUSBPorts.kextのInfo.plistに、HS06のエントリーを追加してみることにしました。具体的には、以下の記述を、HS05とHS07の記述の間に挿入しました。base64のBgAAAA==は、0x06000000です。

<key>HS06</key>
<dict>
 <key>Comment</key>
 <string>Front USB 2.0 (USB_E1234)</string>
 <key>UsbConnector</key>
 <integer>255</integer>
 <key>name</key>
 <string>HS06</string>
 <key>port</key>
 <data>
 BgAAAA==
 </data>
</dict>

こうして作成したUSBPorts.kextを使って起動した結果が以下です。目論見通り、HS06が現れて、それがUSB2.0 Hubに接続されている様子が表示されました。この状態で、Type-Aアダプタを経由してUSBメモリを接続すると、macOSのファインダー上に正しくマウントされました。

ここで作成したUSBPort.kextのInfo.plistを以下に公開しておきます。

USBPorts.Info.plist_ASUS_Z490G - Pastebin.com

注意していただきたいのは、このplistの中の、25行目と344行目です。それぞれ、

<key>iMac19,1-XHC</key>

と

<string>iMac19,1</string>

となっています。これは機種IDをiMac19,1にした場合の設定です。実はこの後、iMac20,1が発売されたので、config.plistの設定をCPUが合致するiMac20,1に変更しました。そしたらこのkextが動かなくなって悩んだのですが、ここに機種ID依存の設定が入っていました。Hackintool.appは、稼働しているマシンの機種IDを自動的に書き込んでくれます。なので、後から機種IDを変更する場合は、ここも変更する必要があります。

ASUS Z490-GのUSBポート一覧

ASUS Z490マザーボードROG STRIX Z490-G GAMINGのUSBポートは以下のように割り当てられていました。このマザーボードを使う方は参考になさってください。

HS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
HS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
HS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
HS04：リアパネルUSB 3.2 Gen 2 Type-C
HS05：マザーボード上のUSB 3.2 Gen 2 Key-A
HS06：ハブ経由でマザーボード上のUSB 2.0 USB_E12とUSB_34に接続
HS07：マザーボード上のUSB 3.2 Gen1 U32G1_78
HS08：マザーボード上のUSB 3.2 Gen1 U32G1_78
HS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
HS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）
HS11：リアパネルに2個あるUSB 2.0 Type-Aの上（基板から遠い方）
HS12：リアパネルに2個あるUSB 2.0 Type-Aの下（基板側）
SS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
SS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
SS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
SS04：リアパネルUSB 3.2 Gen 2 Type-C
SS05：マザーボード上のUSB 3.2 Gen 2 Key-A
SS06：マザーボード上のUSB 3.2 Gen 2 Key-A
SS07：マザーボード上のUSB 3.2 Gen1 U32G1_78
SS08：マザーボード上のUSB 3.2 Gen1 U32G1_78
SS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
SS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）

リアパネルの配置は以下になりました。

マザーボード上のUSBピンの割り当ては以下です。

15個のポートを選別する

こうして全てのポートがHackintoolに現れるようになったところで、全部で15個になるように選別します。今回は、マザーボード上のUSB 3.1ポートを全て使わない設定にしました。バックパネルのポート全てと、マザーボード上のUSB 2.0ポートだけを有効にします。ということで、以下の15個のポートを使うことにしました。

HS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
HS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
HS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
HS04：リアパネルUSB 3.2 Gen 2 Type-C
HS06：ハブ経由でマザーボード上のUSB 2.0 USB_E12とUSB_34に接続
HS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
HS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）
HS11：リアパネルに2個あるUSB 2.0 Type-Aの上（基板から遠い方）
HS12：リアパネルに2個あるUSB 2.0 Type-Aの下（基板側）
SS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
SS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
SS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
SS04：リアパネルUSB 3.2 Gen 2 Type-C
SS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
SS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）

HackintoolのExportボタンを使って15個制限版USBPorts.kextを作ります。全部を有効にしたUSBPorts.kextは、後に使用するポートを変更する場合に再利用できるので、USBPorts_all.kextというように改名して保存しておくことにしました。個数を制限したUSBPorts.kexを使い、XhciPortLimitをfalseにして起動したところ、以下のようになりました。全部で15個が有効になっています。マザーボード上のUSB 2.0 (HS06) も使えているので無線カードの使用にも問題ありません。

15個制限撤廃パッチは危険

今回の作業中に、USBポート一覧表に異常な現象が発生して、15個制限撤廃パッチはやはり危険なのではと実感しました。そのことをご紹介します。

USBポート一覧表をもう一度見てみましょう。上の一覧にUSBコントローラ（XHC）の情報が書いてあります。そのIDが0x14です。USB Portsの一覧には、Location IDの項目があり、XHC IDの0x14に引き続き1番から番号が振られています。つまり、0x141, 0x142, 0x143, …と順番にLocation ID番号が振られています。OpenCoreのマニュアルによると、macOSのLocation IDが4ビットしかないのに無理して個数を増やしているのが、15個制限撤廃パッチの問題点だと書いてありました。なので、macOSが正式に使っているLocation IDは、この場合、0x141から0x14Fまでの15種類だと思われます。パッチで15個以上のポートを有効にしてしまったので、0x14Fの次に来るSS05はIDが0x140になり、次のSS06以降では再び0x141に戻ってしまっています。つまりSS06以降のポートには、HS01以降のポートと同じLocation IDが割り当てられてしまっています。

Location IDが重複していては、何かの不具合が出ても不思議ではありません。さらには、本来割り当てされないはずの0番、つまり0x140のIDが割り当てられていることも問題のようでした。

ポートを調査している段階では、Location ID 0x140はSS05に割り当てられていました。これはマザーボード上のType-C (key-A) のUSB 3.1 Gen2の2個のうちの一つでした。ここにMacBookなどで使用する以下のようなType-Cアダプタ

を接続した時の一覧を下に示します。このアダプタには、USB 3.1 Gen1 Type-Aが3個、HDMIコネクタ、SDカードリーダーが装備されています。その結果、SS05に変換器の中にあるUSB3.0 Hubが現れています。また、HS05にもUSB 2.0 Hubが現れています。ここまでは正常なのですが、リアパネルに接続されているはずのHS03にも何故かUSB3.0 Hubが現れ、さらにはこれもリアパネルのHS04にも、NS1081という謎のデバイスが現れています。しかも、HS03に現れるUSB3.0 Hubの表示は、現れたり消えたりを毎秒数回繰り返し不安定です。謎のデバイスであるNS1081を検索したところ、SDカードなどをUSB接続するコントローラチップのようです。アダプタ内部のハブとデバイスが、全く関係ないポート(HS03とHS04)に不安定に現れてしまっているようです。ちなみにType-Cの向きを変えて、USB 3.1としてSS06の方を使用すると、このような不具合は発生しませんでした。本来使用されない0番のLocation ID (0x140) が割り当てられたSS05ポートが活性化してしまったので、このような不具合が発生しているのではと思われます。15個制限をパッチで回避したための副作用なのでしょう。

今回行ったように、15個を指定するkextを作って、XhciPortLimitをfalseにしていれば、このような異常現象は発生しません。15個制限撤廃パッチは、インストール直後の調整用の場面でのみ使用し、使い続けない方が良いと思いました。

まとめ

ASUSのROG STRIX Z490-G GamingマザーボードのUSBポート名を特定して、使用する15個を選択するkextを作りました。無線カードで使用するオンボードのUSB 2.0がレジストリに現れないので、kextで指定したところ認識できました。また15個制限撤廃するパッチは副作用があることがわかりました。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

Sun, 07 Jun 2020 16:27:15 +0900

前回紹介したASUSのZ490マザーボードで、動かなかったオンボードオーディオとEthernetが動きました。少しトリッキーな方式のような気がしますが、hackintoshコミュニティのサポートが充実するまでのつなぎとしては十分です。

追記：OpenCore 0.6.0とAppleALC.kext 1.5.1になり、オーディオはレイアウトID（このマザボは7）を指定するだけで動くようになりました。こちらをご覧ください。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

参考にしたページ

前回は、OopenCoreのComet Lake-S　バニラインストールガイドに従って、正攻法なインストールを行いました。そのためか、マザーボード搭載のオーディオコーデックと2.5 Gbps Ethernetが動きませんでした。

Comet Lake-S 10600とZ490でmacOSを動かす

OpenCoreのバニラガイドが出る前に、SchmockLoadさんがGIGABYTE Z490 Vision Dにインストールした様子をGitHubにまとめてくれていました。そこでは、オーディオも2.5 Gbps Ethernetも動いているようです。今回はこれを参考に作業しました。

GitHub - SchmockLord/Hackintosh-Intel-i9-10900k-Gigabyte-Z490-Vision-D: https…

オーディオを動かす

追記：オーディオに関するこの節の情報は古いです。こちらをご覧ください。

今回使用しているマザーボードに搭載されたコーデックはRealtek ALC1220です。もしかしたらALC1220Aなのかもしれません。ASUSはSupremeFX S1220Aと呼んでいます。300シリーズマザーボードでも搭載されていたコーデック（そちらはSupremeFX S1220無印）と数字部分は同じです。なので、AppleALC.kextで動くと思ったのですが、簡単には動きませんでした。

そこで、上記のSchmockLoadさんのGitHubガイドに従って、以下のkext、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を追加し、config.plistのDevicePropertiesに

<key>DeviceProperties</key>
<dict>
 <key>Add</key>
 <dict>

（略）

 <key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
 <dict>
 <key>device-id</key>
 <data>cKEAAA==</data>
 <key>layout-id</key>
 <data>BwAAAA==</data>
 </dict>

を追加しました。FakePCIIDの仕組みはこちらで説明されてます。ちゃんと理解できていないのですが、PCIeのデバイスIDを、macOSのドライバが認識するIOPCIDeviceに結びつけてくれる機能のようです。本体がFakePCIID.kextで、デバイスIDの情報だけが書いてあるInfo.plistだけのkext（今回の場合はFakePCIID_Intel_HDMI_Audio.kext）と組み合わせて使います。これによりmacOSが認識しないIDのデバイスを動かしてしまおうという機能のようです。

FakePCIID_Intel_HDMI_Audio.kextは、その名前の通り、100, 200, 300シリーズのHDMIオーディを実現する目的で作られているようです。今回の場合に当てはまるのか疑問でした。説明を見ると、100シリーズ以降で0xA170もしくは0x9D70のデバイスIDを使えるようにしてくれるようです。ここでは0xA170を使っています。これを動かすためには、動かしたいオーディオデバイスの、ACPIに現れるデバイスIDを0xA170に変更しておく必要があります。それが上記のconfig.plistの記述です。

Hackintoolで確認してみます。オーディオチップはPci(0x1f,0x3)のPCIeデバイスパスに配線されています。そのデバイスIDは0x06C8でした。

上記のconfig.plistを使うと、このデバイスIDが0xA170に変更されていることがわかります。デバイス名も、100 Series/C230 Series Chipset Family HD Audio Controllerと表示されるようになっています。それでも実際のコーデック名とはちょっと違う気がしますが、これで音声が再生されるようになりました。

Z490マザーボードでのサウンドチップの変更は、おそらくはデバイスIDなどが多少変更された程度の違いと思いますので、そのうちにAppleALC.kextが対応してくれるのだと期待しています。それまではこの対応で凌げると思います。

Ethernetを動かす

このマザーボードに搭載されているEthernetチップは、2.5 GbpsのIntel I225-Vです。上位のマザーボードでLANが2個あるタイプのものは、もう片方が従来と同じ1 GbpsのIntel I219-Vだったりします。I219-Vは300シリーズでも使われたチップなので、IntelMausi.kexe, IntelMausiEthernet.kextで動くようです。でもi225-Vしか搭載されていないマザーボードは有線LANに接続できません。

こちらも、オーディオと同様に、FakePCIIDを使って解決できました。FakePCIID_Intel_I225-V.kextが設定をしてくれます。

FakePCIID.kext
FakePCIID_Intel_I225-V.kext

また同様にconfig.plistでEthernetチップのデバイスIDを0x15F2に設定します。ちなみにこのマザーボードでは、元々のデバイスIDは0x15F3でした。

	<key>PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)</key>
	<dict>
		<key>device-id</key>
		<data>8hUAAA==</data>
	</dict>

SchmockLoadさんによるとFakePCIID_Intel_I225-V.kextを作ってこの設定を紹介したのはドイツのHackintosh-forum.deのBrumbaerさんだそうです。GitHubにあるconfig.plistの例では

 <key>PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)</key>

になっていますが、上記のHackintoolの一覧に現れているように、ASUSマザーボードではデバイスpathが違うようです。

 <key>PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)</key>

を指定したところ動きました。これでネット接続できるようになりました。おそらくはIDを偽装して、macOS標準のドライバで動かしているのだと思われます。とはいえ、1Gbpsのハブに接続して使用したところでは、速度が遅いとか、データが滞るなどの問題は感じられませんでした。IntelMausi.kextが対応するまでのつなぎとして十分に使用できそうです。

Geekbench 5でベンチマーク

ネットに接続できるようになったので、Geekbenchで測定しました。Geekbenchは結果がweb上で表示されるので、ネット接続してないと起動できませんでした。結果は、以下のようにマルチコアスコアで6000越えでした。

現行の非BTO版最上位iMacは3.7 GHz 9600Kを搭載しています。は無印なので（K付きは未発売でした。今もかな？）クロックが遅い (3.3 GHz) です。でも9600Kでは無効にされたハイパースレッドが復活しています。互角の性能である気がしましたので、Geekbench Browserで9600K搭載iMacのスコアを検索してみました。

マルチコアスコアが5000を切ったスコアも、6000を超えたスコアもありましたが、大半が5000代でした。結局、クロックが10%くらい低下しても、ハイパースレッドが効いたのか、10600無印の方が高速のようです。

まとめ

10600搭載Z490マザーボードの自作マシンでマザーボード搭載のオーディオとEthernetが動きました。AppleALC.kextとIntelMausi.kextが対応してくれるまでのつなぎとして使えます。ネットが動いたのでGeekbench 5でベンチマークをしました。これに相当する性能と思われる9600K搭載のiMacより高いスコアが出ました。

OpenCoreを0.5.9に更新

Fri, 05 Jun 2020 00:32:55 +0900

Kext Updaterを起動したらOpenCoreの0.5.9が来ていました。OpenCoreに移行してから初めてのアップデートだったので、戸惑いました。使用しているefiファイル類を、ダウンロードされたEFIフォルダの中のefiファイルで一つ一つ置き換えました。問題なく動いているので、この方法で正しく更新できたかと思ってます。

追記：コメントで指摘いただいて気付きました。上の作業ではconfig.plistはそのまま流用していましたが、0.5.9に添付してきた新しいsample.plistを見ると、形式が多少変更されているようです。BlockというキーがDeleteに変更されていたり、Quirksが入れ替わったりしていました。ガイドのページの内容も0.5.9に対応しているので、古いconfig.plistと比較しつつ、新しいsample.plistを元に新しいconfig.plistを作るのが良いようです。Proper TreeのOC Clean Snapshot機能を使えば、ACPI, Drivers, Kexts, Toolsの内容は反映されるので、比較する場所はそれほど多くないです。また、Proper Treeを使えばキーの内容をまとめて削除・コピーできるので、古いconfig.plistからの設定の移行作業も楽でした。

15個制限のためのUSBPorts.kextをHackintoolで作る

Sun, 31 May 2020 17:36:51 +0900

macOSのUSB 15個制限を解決するために、使用する15個未満のUSBポートを決定し、macOSに伝えます。以前の記事でいくつかの方法を紹介しましたが、今回はHackintoolを使ってkextを作ります。作業が楽で、作ったkextを1個インストールするだけなので簡単でした。

USBポート個数対処の方法

今までの記事では、USBポート個数制限に対処する方法として、

AppleUSBXHCIPCI.kextにパッチを当てる
OpenCoreのconfig.plistでXhciPortLimitをtrueにする
DSDTを書き換えて使用する15個のUSBポートを指定する
USBInjectAll.kextとブートオプションで15個を指定する
USBInjectAll.kextとこれに指示するSSDTを作って15個を指定する

などの方法を紹介しました。

USBポートを設定する

ASUS MAXIMUS XI HEROのUSBを設定する

先日の記事で、OpenCore用の手順を書いたところ、P2B-Fさんからコメントで「Hackintoolを使ってUSBPorts.kextを作る方が簡単です」と教えていただきました。試してみたら確かに簡単でした。その手順をまとめておきます。以下の方法は、個数制限に対応する方法の中で、現時点で一番おすすめの方法だと思います。

Hackintoolを入手する

Hackintoolは以下から入手できます。HackintoolはiGPUの設定でも使いました。色々便利な機能があります。USBポートの情報などのハードウェア構成情報はIORegistryExplorerでも見ることができますので、併用して確認するのも良いです。

Releases · headkaze/Hackintool

一時的に制限を撤廃する

まずOpenCoreのconfig.plistでXhciPortLimitをtrueにするなどして一時的に15個制限を解除します。Cloverでしたらconfig.plistで15個制限撤廃パッチを当てても良いです。また、以前紹介したようにUSBInjectAll.kextとブートオプションを使って少しずつ解除しても良いです。以下では、全てを解除した状態で説明します。全解除状態でHackintoolを起動し、ウィンドウ上部のボタンからUSBを選択すると、下の図のようになります。

ウィンドウの下には、7個のボタンが表示されています。マウスを持っていくと機能が文字表示されます。それによると左から、Info, マイナスマークのDelete, ホウキのマークのClear All, 回転矢印マークのRefresh, 注射器マークのInject, Import, Exportのボタンです。Clear All, Inject, Refreshの順に押していくと、現在認識されているポートが全て表示されます。Z390チップセットのASUS ROG MAXIMUS XI HEROでは以下のようになりました。上部のウィンドウに、Cannon Lake用の300シリーズチップセットのマザーボードであることが表示されていて、マザーボードが正しく認識されています。

ここでHS03とHS12がアクティブになっています。HS03には、一時的にLogicoolのタッチパッド付きキーボード用の無線ドングルを接続したので、それが見えています。また、HS12にはUSB 2.0のハブを接続しているので、それが見えてます。実はHS13には、Apple純正のBluetoothモジュールが接続されているのですが見えていません。マザーボード上のUSB 2.0コネクタなのですが、これがマザーボード内蔵のhub経由で接続されているらしく、そのためか、XhciPortLimitをtrueにしても見えないようです。なので設定作業用にLogicoolのキーボードを接続しているわけです。（さらにはSS10にもハブがつながっているのですがそれも見えていないようです。後の図で示すように、15個制限を設定したら、これらも見えるようになりました。）

USBポートを特定して選別する

この状態で、USBポートにデバイスを取り付けて、変化を観察します。例えば上の状態では、バックパネルのUSB 3ポートにLogicoolのキーボードドングルが反応したので、これがHS03であることがわかります。この作業には、キーボード、マウス、USB Bluetoothアダプタなどを使うと良いです。これらはUSB 2.0ですし、抜き差しも簡単です。USB 2.0メモリーを使用すると、アンマウントする手間が必要です。USB 3のポートを確認するには、USB 3対応のUSBメモリーなどを使います。この場合は、取り外す際にアンマウントしないと、データを壊す危険があります。（大抵は大丈夫ですが）

HackintoolのConnectorの欄をクリックするとポップアップメニューが出ます。この欄には、USBの速度ではなく、接続された物理的なコネクタの形状を書きます。HS03はUSB 2ですが、USB 3コネクターに接続されています。なのでHackintoolのConnectorの欄はUSB3に設定します。

Connectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。ここでの選択で、後で述べる出力ファイルのUsbConnectorプロパティ値が変化します。それによると、それぞれの選択で、0, 3, 9, 10, 255が割り当てられることがわかりました。これらの値について、Hackintoolのソースを調べたところ、ヘッダファイルに以下の記述がありました。

kTypeA		= 0x00,	// Type ‘A’ connector
kMiniAB		= 0x01,	// Mini-AB connector
kExpressCard	= 0x02,	// ExpressCard
kUSB3StandardA	= 0x03,	// USB 3 Standard-A connector
kUSB3StandardB	= 0x04,	// USB 3 Standard-B connector
kUSB3MicroB	= 0x05,	// USB 3 Micro-B connector
kUSB3MicroAB	= 0x06,	// USB 3 Micro-AB connector
kUSB3PowerB	= 0x07,	// USB 3 Power-B connector
kTypeCUSB2Only	= 0x08, // Type C connector - USB2-only
// These only implement the USB2 signal pair, and do not implement the SS signal pairs
kTypeCSSSw	= 0x09, // Type C connector - USB2 and SS with Switch
// These implement the USB2 signal pair, and a Functional Switch with a physical
// Multiplexer that is used to dynamically connect one of the two receptacle SuperSpeed
// signal pairs to a single USB Host Controller port as function of the Type-C plug
// orientation.
kTypeCSS	= 0x0A, // Type C connector - USB2 and SS without Switch
// These implement the USB2 signal pair and a Functional Switch by connecting each
// receptacle SuperSpeed signal pair to a separate USB Host Controller port.
// 0x0B – 0xFE: Reserved
kInternal	= 0xFF	// Proprietary connector

0, 3, 9, 10, 255以外にも、いくつかの設定値があるようです。ただ、Hackintoolのメニューにあるように、この5種類が一般的で、これ以外を設定することはなさそうです。この説明から、割り当ては以下のようです。

USB2 (0) はUSB 2.0 Type Aコネクター
USB3 (3) はUSB 3.x Type Aコネクター
TypeC+Sw (9) はスイッチ経由USB Type-C (Gen1またはGen2)
TypeC (10) はスイッチを経由しないUSB Type-C (Gen1x2またはGen2x2)
Internal (255) はマザーボード上の専用コネクタ

USB規格のType-A, Type-Cコネクタの場合は、0, 3, 9, 10を指定するのに対して、マザーボード上にあるヘッダピンのようなUSB規格外のコネクタに接続されている場合はInternal (255) を選択します。どのコネクタに接続されていてもUSBはUSBなので関係ない気もしますが、macOSの中での電力制御の扱いが異なるようです。IORegistryExplorerなどでコネクタの情報を見ると、コネクタ種類の違いで電流関係のパラメータが異なっています。その関係と思われますが、Bluetoothアダプタが接続するポートは、255に設定しないとスリープを妨げることがあるようです。

Type-Cコネクタの設定

Hackintoolのコネクタ選択肢であるTypeC+SwとTypeCの違いを説明します。Type-Cケーブルは、以下のように1セットのUSB2配線（A6, A7とB6, B7）と、2セットのUSB3配線（A2, A3, B11, B10とA10, A11, B3, B2）で構成されています。

このうち、Type-CのUSB2 (信号名はD+とD-) は、コネクタを裏表どちらに挿しても同じUSB2が接続されます。コネクタが冗長に使用されています。それに対して、2個のUSB3 (TX1+/-, RX1+/-, TX2+/-, RX2+/-) は、裏表どちらかに挿すことで、2セットのUSB3が別々に接続されます。なのでUSB3に関しては、2セット分用意しないといけないわけです。これを実現するために、もともと1個しかないUSB3をスイッチングハブで分岐して2個にして接続するか、もしくは2個のUSB 3ポートを用意するか、の2種類の実装方法があります。これがHackintoolのメニューにあるTypeC+Sw（スイッチ付）とTypeCです。どちらも2個のUSB3が使えますが、前者は一つを2個に分岐しています。なので2個のUSB3を両方とも使用した場合は、速度が半々になります。後者は、両方のUSB3を共に使用してもそれぞれのフルスピードが出ます。

最近になって従来のUSB 3.0や3.1の表記に代わって、USB 3.2という名称が使われるようになり、ややこしくなってます。色々調べてみると、以下のような分類になったようです。

USB 3.2 Gen1 : 昔のUSB 3.0 または今のUSB 3.1 Gen1と同じもの (5Gbps線を1組使用)
USB 3.2 Gen2 : 昔のUSB 3.1または今のUSB 3.1 Gen2と同じもの (10Gbps線を1組使用)
USB 3.2 Gen1x2 : Type-Cでスイッチを使わずに独立した5Gbps線を2組使う (合計10Gbps)
USB 3.2 Gen2x2 : Type-Cでスイッチを使わずに独立した10Gbps線を2組使う (合計20Gbps)

ちなみにGen2x2は「じぇんつーばいつう」と読むようです。x2が末尾につくコネクタはHackintoolのTypeCを選択し, x2がつかないコネクタはTypeC+Swを選択します。今回チェックしたマザーボードでは、裏表どちらに挿してもSS06に接続されました。スイッチで分岐しているだけのようなのでこれはUSB 3.1 Gen2x1です。HackintoolのConnectorメニューではTypeC+Swを選択します。

使わないポートを除外

こうしてUSBポートを特定していくと同時に、使わないポートを外していきます。最終的に15個のUSBポートまで削減していきます。使えるものなら使いたいけど、個数制限で諦めざるを得ないポートもあると思います。また、Comment欄のところにメモ書きをしておくと、後で説明する出力ファイルにもコメント記載されます。テキストエディタで修正する場合などに便利です。

今回も、以前の記事で選んだUSBポートを使うことにしました。結果として以下のようになりました。

USBPorts.kextを作る

この後、ウィンドウ下のExportボタンを押します。するとこの設定から、

SSDT-EC-USBX.aml
SSDT-EC-USBX.dsl
SSDT-UIAC.aml
SSDT-UIAC.dsl
USBPorts.kext

の5個のファイルをデスクトップに作ってくれます。以前のガイドで作っていたSSDT-UIACは、ここではSSDT-EC-USBXとSSDT-UIACの2つに分割されています。統合すれば内容は同じものでした。なので、SSDT関係のファイルはUSBInjectAll.kextと一緒に使うものであると思います。

USBPorts.kext/Contents/Info.plist

というテキストファイルが見えます。この中に、上で設定した内容が、plist書式のテキストで書かれています。こうして作成されたInfo.plistの内容を以下のところに置いておきました。

USBPorts.kext for ASUS Z390 - Pastebin.com

このUSBPorts.kextだけを使用すれば、15個のUSBを指定して動かすことができました。kextを使う場合は、USBInjectAll.kextやSSDT-EC.aml, SSDT-UIAC.amlは不要です。実は、Z97の時代にはこの手のインジェクトkextを使って使用USBのリストを設定していました。その後、チップセットが代わって、雛形となるファイルが見つからなくなったので、USBInjectAll.kextとSSDTを組み合わせて使っていました。Hackintoolでこんなに簡単に生成してくれるなら、今後はこのkextを使っていきたいと思います。

USBMap.commandを使う

こちらもコメントで教えていただきました。Hackintool.appと同様に、インジェクトkextを作るPythonスクリプト、USBMap.commandがcorpnewtさんによって配布されています。

GitHub - corpnewt/USBMap: Python script for mapping USB ports in macOS and cr…

こちらはCUIベースで設定していきます。操作が多少独特ですが、USB設定専用のアプリですのでシンプルです。生成されるインジェクトkextはUSBMap.kextという名前ですが、Hackintoolで作るUSBPorts.kextと全く同じ内容です。

% ./USBMap.command

#######################################################
# USBMap #
#######################################################

Plist: USB.plist
UIA Boot Args: None
USBInjectAll: Not Loaded - NVRAM boot-args WILL NOT WORK
AptioMemoryFix: Unknown

NVRAM Arg Options:
H. Exclude HSxx Ports (-uia_exclude_hs)
S. Exclude SSxx Ports (-uia_exclude_ss)
C. Clear Exclusions

R. Remove USB.plist from Scripts Folder
T. Reset Settings to Defaults
P. Edit Plist & Create SSDT/Kext
D. Discover Ports
U. Validate USB Power Settings
Q. Quit

Please select an option:

コメントでMifjpnさんから、USBMap.commandの使用例を教えていただきました。

USBMap.commandによるUSBポートの選択

まとめ

USBポート15個制限に対応するため、Hackintoolを使って、USBPorts.kextを作りました。このkextを使用するだけで、15個制限の設定が可能でした。今まで紹介した方法のどれよりも簡単だと思いますので、今後はこの方法で設定していこうと思います。コメントで教えていただきありがとうございました。

SSDのtrimを有効にする (OpenCore編)

Thu, 28 May 2020 22:42:16 +0900

2.5インチSSDのtrim機能をtrimforceコマンドで有効にしました。nvramを正しく動くようにしておいたためか、trimforceが効きました。もしtrimforceが効かない場合、Cloverでは、IOAHCIBlockStorage.kextにパッチ当てしてましたが、OpenCoreではThirdPartyDrivesをtrueにするだけで良いようです。

trim有効化方法 (OC対応版)

今回、trimの有効化を試したマシンは、ASUSのZ390マザーボードとSanDiskの2.5インチSATA SSDの構成です。また、trimの仕組みと設定方法は以下の記事で紹介しました。

SSDのTRIMを有効にする

SSDを使う場合、trimは有効になっていた方が良いと言われてます。そこで以下のステップでtrim設定に対処します。

SSDによっては、macOSがtrim対応している場合があります。特にNVMe方式のM.2 SSDはOOBでtrimが働くようです。その場合は、何もしなくて良いです。
非対応SSDの場合、trim機能をmacOSのtrimforceコマンドで起動することができます。このコマンドには、nvramが関係している様子です。ただし、trimforceが効かないこともあります。
trimforceが効かない場合は、config.plistに設定してパッチを当てます。Cloverでは、IOAHCIBlockStorage.kextにパッチ当てしてます。OpenCoreではThirdPartyDrivesをtrueにします。

でも実のところ、このマシンでは、メインのSSDをM.2 NVMeにしたため、データを入れる場所にした2.5インチSSDのtrim設定は長らくほったらかしにしていました。trimforceは効かないし、パッチ当てるのも面倒だったのも理由です。

ThirdPartyDrivesの説明を読む

という状況だったのですが、OpenCoreにしたところ、パッチ当てが簡単になっていることに気づきました。上のステップに書いたように、config.plistの中で設定できるThirdPartyDrivesというプロパティをtrueにすれば、IOAHCIBlockStorage.kextにパッチを当ててくれます。これなら簡単にtrim有効化できます。さらにその説明を読むと、以下のように、できればtrimforceが望ましいようなことが書いてありました。

**ThirdPartyDrives :**デフォルトはfalseです。IOAHCIBlockStorage.kextにパッチを当て、サードパーティのドライブでtrimやハイバーネーションを可能にします。このオプションは、ユーザの判断で使わないことにしても良いです。最近のmacOSバージョンには、専用のユーティリティであるtrimforceが提供されています。10.15以降では、このユーティリティは、01 00 00 00という値のEnableTRIMという変数をnvramに作ります。

ThirdPartyDrivesでパッチ当てをしてくれるものの、trimforceはmacOSがサポートするtrim機能を活性化するmacOSのコマンドなので、これでtrim有効化するのが望ましいそうです。trimforceで有効化できない場合の時だけ、ThirdPartyDrivesをtrueするのが良いと思います。

trimforceコマンドでtrim有効化する

そこで、久々にtrimforceを試したところ、すんなり動いてしまいました。Terminalからtrimforceとタイプすると、説明が出ます。

% trimforce
Usage:
trimforce enable
trimforce disable
trimforce help

次に、OpenCoreの説明にある、EnableTRIMがnvramの中にあるかどうか調べてみました。

% nvram -p | grep EnableTRIM

何も表示されません。定義されていないようです。そこでtrimforceコマンドで、trimを有効にするよう試みました。色々警告が出ますが進めます。

% sudo trimforce enable
Password:
IMPORTANT NOTICE:  This tool force-enables TRIM for all relevant attached devices, even though such devices may not have been validated for data integrity while using TRIM.  Use of this tool to enable TRIM may result in unintended data loss or data corruption.  It should not be used in a commercial operating environment or with important data. Before using this tool, you should back up all of your data and regularly back up data while TRIM is enabled.  This tool is provided on an “as is” basis. APPLE MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, REGARDING THIS TOOL OR ITS USE ALONE OR IN COMBINATION WITH YOUR DEVICES, SYSTEMS, OR SERVICES. BY USING THIS TOOL TO ENABLE TRIM, YOU AGREE THAT, TO THE EXTENT PERMITTED BY APPLICABLE LAW, USE OF THE TOOL IS AT YOUR SOLE RISK AND THAT THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY AND EFFORT IS WITH YOU.
Are you sure you wish to proceed (y/N)? y
Your system will immediately reboot when this is complete.
Is this OK (y/N)?

この後、警告の通り、自動的に再起動してしまいます。再起動後に、先ほどのnvram変数を調べてみました。

% nvram -p | grep EnableTRIM
EnableTRIM %01

OpenCoreのマニュアルにある通り、01という値のEnableTRIM変数が出来上がっていました。システム情報を見ると、設定前は「いいえ」だったTRIMサポートの項目が「はい」に変化していました。trimforceで正しく設定できたようです。

trimforceは長らく機能しなかったので、あきらめていましたが、設定できるようになっていました。trimforceがnvramを使うようになったためか、さらにはSSDT-PMC.amlでnvramが正しく使えるようになったおかげのようです。

まとめ

ひさびさにtrimforceコマンドを試したら、2.5インチSSDのtrimが有効になりました。ちなみにM.2 NVMe SSDの方は、何もしない状態でtrim有効でした。もしtrimforceが効かない場合は、OpenCoreでしたらThirdPartyDrivesをtrueにすれば良いと思われます。

使用するUSBポートを15個指定する (OpenCore編)

Wed, 20 May 2020 23:27:08 +0900

ここではUSBInjectAll.kextを使っていますが、最近はサポートが途絶えているので、以下の方法がよりシンプルでおすすめです。

15個制限のためのUSBPorts.kextをHackintoolで作る

———————————-

（以下は今でも有効ですが、古い情報です。）

OpenCoreではconfig.plistでXhciPortLimitをtrueにすれば15個制限を解除できます。Cloverでのパッチ作業より楽です。でもUSBInjectAll.kextとSSDTで使用する15個を指定する従来の方法も可能で、その方式がおすすめです。

OpenCoreで15個制限を全撤廃

macOS El Capitanから使用可能なUSBポートの数が、コントローラ当たり15までと制限されました。その解説と、Cloverのconfig.plistに書く制限解除パッチを以下の記事で紹介しました。この記事では、AppleUSBXHCIPCI.kextにパッチを当ててました。

USBポートを設定する

OpenCoreでは、config.plistのKernel, QuirksのXhciPortLimit項目をtrueにしておくと（デフォルトはfalse）、必要なパッチを当ててくれます。 AppleUSBXHCIPCI.kextの他に、AppleUSBXHCI.kextとIOUSBHostFamily.kextにパッチを当ててくれるようです。このパッチは、各種macOSバージョンに合わせた内容が必要なので、その点にも対応してくれているようです。なので、簡単に15個制限を解除できます。

しかし、OpenCoreのReferenceマニュアルにはこんな注意書きがあります。

このオプションは、可能な限り避けてください。USBポート制限は、locationIDの書式で割り当てられたビット数による制限です。この制限は、OSを大々的に変更しない限り解除できません。正しい解決策は、使わないポートを除外して、使用したいUSBポート15個を選定することです。

つまり、macOS内部で使用しているプロパティのlocationIDの中で、ポートを識別するための変数に、どうやら4ビットしか割り当てられていない様子です。15個を超えるポートを使用可能にすると、違うポートに同じIDが割り当てられる可能性があるわけで、とても危険なことだと推測できます。実際には15個制限を外したことで問題が発生した事例は、報告も無いし経験もしていませんが、避ける方が良いでしょう。XhciPortLimitの使用は、macOSをインストールする際や、使用するポートを取捨選択する作業の時だけに制限すべきでしょう。

OpenCoreで使用する15個を指定する

そこで、15個制限を撤廃するのではなく、必要な15個のポートだけを登録するようにします。まずはマシンのUSBポート割り当てを調べて、使用したい15個のUSBポートを選定します。この方法は、以下で説明しました。OpenCoreならば、この手順の中で、一時的にXhciPortLimitをtrueにすることで簡単に15個制限解除できるので、作業が楽になると思います。

ASUS MAXIMUS XI HEROのUSBを設定する

macOSは発見した15個までのUSBポートをアプリケーションに提供します。なので、使用する15個のポートを決定したら、その15個のポートだけがマシンに存在しているかのようにmacOSに伝えます。これにはいろいろな方法が可能ですが、USBInjectAll.kextと専用のSSDTを使用するのが一番おすすめだと思います。以下の記事で、仕組みと設定方法を説明しました。

15個制限を回避するUSBInjectAll.kextの役割と使用法

上の記事では、Cloverで使うための方法を書いていますが、OpenCoreでも同じように設定できます。ただし、kextとSSDTファイルを置く場所は、Cloverと違うディレクトリです。つまり、kextはKextsに、

SSDTは（SSDT-UIAC.amlという名前にしました）ACPIに置きます。

また、OpenCoreでは、config.plistにも、使用するkextとSSDTを記述する必要があるのは、すでに説明した通りです。ProperTreeのsnapshot機能を使えば、kextとSSDTを正しいディレクトリに置くだけで、config.plistの設定をしてくれるので楽です。

まとめ

OpenCoreでもUSBポート15個制限に対応するため、Cloverで使っていたUSBInjectAll.kextとSSDT-UIAC.amlをOpenCoreのESPに入れました。config.plistにも登録しました。これらは、Cloverの時と同じように、OpenCoreでも機能して、必要な15個のUSBポートが使えるようになりました。

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

Tue, 19 May 2020 22:29:04 +0900

抜き挿し可能なリムーバブルSATAドライブベイを使うために、Cloverでは、macOS稼動中にHDD/SSDドライブのホットプラグを可能にするパッチをconfig.plistに書いてました。OpenCoreに移行したのでこのパッチも移行しました。

5.25インチベイ用リムーバブルHDDラック

上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでCloverでは、ホットプラグが機能するようにconfig.plistにkextパッチを当て対応していました。

SATA接続HDD/SSDのホットプラグ

Cloverで使用していたパッチ

このパッチは、AppleAHCIPort.kextの一部を0x90 (マシンコードでNOPに相当します) に置き換えるものです。置き換える範囲は、kextの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。コメントでまっくぷろさんに教えていただいたパッチです。

このパッチを作るために、kextの中で0x40200000を探して、書き換えるべきデータ列を調べます。例として、macOS 10.15.4で、書き換えるべきデータを探してみます。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpします。

% hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less

lessが起動しているところ、以下のサーチコマンドをタイプし、40 20 00 00を探します。

/40 20 00 00

ところが運悪く途中に改行が入っているようで見つかりません。40 20だけでもう一度探索します。

/40 20

今度は見つかりました。改行の先に00 00があるので、間違い無いようです。他にも40 20は見つかりますが、その先に00 00が続く場所はありません。おそらくは2バイト単位で位置揃えされているので、この場所以外に改行が来る可能性は無いと思います。40 20 00 00と40 20の2種類の探索を試みれば、40 20 00 00の場所を発見できると思います。

0002a40 69 01 00 00 89 ca 81 e2 40 60 02 00 81 fa 40 20
0002a50 00 00 75 0c 81 e1 bf 7f ff ff 89 8b 69 01 00 00
0002a60 f6 c1 40 74 7e 3d 09 01 01 00 72 77 44 89 fa c1
0002a70 ea 0a 81 e2 80 00 00 00 81 e1 7f ff ff ff 09 d1

ここで発見した0x40200000の4バイト、その前8バイト、その後14バイトの、合計26バイトをNOP (90) に置き換えるパッチを作ります。つまり、

Find --> 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

というパッチを作ります。ProperTreeなどのツールならこのまま16進数が使えますが、テキストエディタで作る場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。

% echo -en "\x81\xE2\x40\x60\x02\x00\x81\xFA\x40\x20\x00\x00\x75\x0C\x81\xE1\xBF\x7F\xFF\xFF\x89\x8B\x69\x01\x00\x00" | base64
geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=

Replaceするデータは、NOPコマンド列である9090…なのですが、このbase 64は以下です。

% echo -en "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" | base64
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=

なのでCloverのconfig.plistには、

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>

というパッチを追加していました。これでBIOSでホットスワップ指定したチップセットSATA接続ドライブがオレンジ色アイコンになり、随時マウント・アンマウントできるようになりました。またスリープしても問題ありませんでした。

OpenCore用のパッチに書き換える

OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーの一部がCloverのパッチとは異なります。OpenCoreのパッチで使うキーは以下です。

Comment : Cloverと同じ。人が読むためのメモ書き。
Find : Cloverと同じ。検索データ列。
Replace : Cloverと同じ。置き換えるデータ列。
Identifier : CloverのNameに相当するキー。kextを指定するためのIDで、バンドルIDを使う。
Enabled : パッチを有効にする場合はtrueにする。（有効にしたいのでtrueにする）
Count : パッチを当てる箇所の数。今回の場合は1回なので1。
その他のキー : デフォルトで良いので省略。

kextのバンドルIDは、システム情報で知ることができます。

システム情報の拡張機能のAppleAHCIPortの項目を選択すると、

com.apple.driver.AppleAHCIPort

であることがわかります。そこで、上記のCloverのパッチに相当する、OpenCoreのパッチは以下になります。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>
</dict>

ProperTreeで設定するなら、以下のようになります。（0番から4番までに、OpenCore付属のSample.plistにあった無効設定のパッチを残してあるので、たまたま5番目になっていますが、何番目でも大丈夫です。）

このパッチをOpenCoreのconfig.plistに追加したところ、OpenCoreでも、ホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた2.5インチHDDです。

パッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber, SystemUUID, MLB, ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

まとめ

リムーバブルドライブベイのホットプラグを可能にするCloverパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。これでまた一歩、OpenCoreに適応できた気がします。

つづき

Big Sur対応パッチはこちらをご覧ください。

リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)

OpenCoreの選択画面をグラフィカルにする

Mon, 18 May 2020 21:04:59 +0900

OpenCoreのデフォルトブートメニューはシンプルすぎるので、Cloverのようにアイコンで選択するよう設定しました。0.5.7以降でこの機能が使えるようです。

OpenCore GUI

前の記事で、ASUSマザーボードマシンのブートローダーをCloverからOpenCoreに移行しました。そのコメントで、OpenCoreでもアイコンによる起動選択ができるようになっていることを教えていただきましたので、試しました。以下での設定が終了していることが前提です。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

OpenCoreの起動画面をGUI化する方法に関しては、以下のページに使い方の説明があります。これに沿って進めました。アイコンによる選択のほか、起動チャイムやボイスオーバーも設定できるようです。ただ起動チャイムは、今のMacにはもうありませんし、不要かと思い設定しませんでした。

Resourcesの中身を用意する

配布されているOpenCoreのパッケージでは、OC/Resourcesの中にAudio, Font, Image, Labelというディレクトリがあるものの、中身は空でした。この中身を、以下のページから取り寄せて、入れておきます。たくさんのファイルがあります。特にAudioは、多国籍語のボイスオーバー用音声ファイルが入っていて、数が多いです。今回は、アイコン表示だけの作業なので音声ファイルは不要だとは思いますが、一緒に入れておきました。

GitHub - acidanthera/OcBinaryData

OpenCanopy.efiを設定する

アイコン選択を動かすためには、OpenCanopy.efiというドライバーが必要なようです。配布されているOpenCoreパッケージには含まれていましたが、前回の作業ではDrivers_offというディレクトリを作って、これに入れて外していました。これをDriversディレクトリに戻します。こんな感じになりました。最小限の構成です。

新しくDriversに追加したので、config.plistも書き換えておきます。簡単な作業なのでProperTreeのSnapshot機能は使わずに、ProperTree上での手作業でOpenCanopy.efiを追加しました。これくらいの作業ならテキストエディタで十分で、ProperTreeを使うまでも無いかもしれません。

config.plistのMisc項目を設定する

引き続きProperTreeを使い、以下の項目を設定します。

Misc -> Boot -> PickerMode: Sample.plistではBuiltinだった値をExternalに変更しました。
Misc -> Boot -> PickerAttributes:1 ガイドには1にせよとありましたが最初から1でした。この値のデフォルト値は0です。今回設定した1の他に、2, 4, 8とその組み合わせの選択肢があるようです。8を試してみたのですが、見た目は変わりませんでした。

この結果、このページの冒頭の写真のように、アイコンで選択できるようになりました。

まとめ

OpenCoreの起動選択画面でアイコン表示されるように設定しました。Cloverコミュニティの皆さんが競って作っているようなド派手な画面やミニマムでおしゃれな画面ではありませんが、本物のMacと同じアイコンを使った正統な起動画面だと感じました。今回は起動音の設定を行いませんでしたが、設定すれば起動チャイムやボイスオーバーが可能になるようです。ボイスオーバーは、本来はバリアフリーのための機能です。OpenCoreの開発者の方々も、その意識を持って起動音機能を整備していることがガイドに書かれていました。

追記：モダンなアイコン

コメントでまっくぷろさんから、今風の起動選択画面アイコンの情報をいただきました。Cloverのようにこれから増えていきそうですね。

GitHub - blackosx/OpenCanopyIcons: A range of .icns files designed specifical…

OpenCanopy Icons

追記：ミニマムなテーマ

ミニマムなテーマもありました。実機とは違うアイコンになりますが、macOS起動前の白りんごアイコンにマッチしたシンプルなアイコンです。

OpenCore用のミニマムなテーマ

追記：起動音を出す

こちらをご覧ください。

OpenCoreで起動音を鳴らす

追記：アイコンファイルの変更

最近のOpenCoreでは、アイコンファイルの設定方法が変更されています。こちらをご覧ください。（2021/7追記）

OpenCore 0.6.9から0.7.0に更新

Pioneer光学ドライブのパッチをOpenCoreに適用する

Sun, 17 May 2020 11:16:49 +0900

Pioneerの光学ドライブを使用していると「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Cloverのconfig.plistでパッチを当てて対処していたのですが、OpenCoreに移行したので同様のパッチを当てました。

Cloverで使用していたパッチ

「空のdvdがセットされました」というエラーメッセージが出ることの原因と対策をこちらの記事で紹介しました。macOSがPioneerのドライブにスリープ指令を送りつけると、スリープ後も復帰しないことが原因のようです。そこで、光学ドライブにはスリープ命令を送らないように、macOSでは設定してあるらしいです。

光学ドライブを使う

なので、本物のMacと同型番のPioneer DVDドライブを使っていれば、操作不能に陥る問題は多分発生しないです。でも違う型番、例えばBDドライブを使う場合は、PioneerSuperDrive.kextにパッチを当てて、本物のMacが搭載している型番 (DVD-RW DVR-105) を、hackintoshで使用している型番 (例えばBD-RW BDR-205) に書き換えることで、この問題を解決できます。実際には、config.plistに以下のパッチを追加していました。これでスリープ命令が送られなくなり、操作不能に陥ることを回避できました。

<key>KextsToPatch</key>
  <array>
  <dict>
          <key>Comment</key>
          <string>PioneerBD-RW No Sleep</string>
          <key>Find</key>
          <data>RFZELVJXICBEVlItMTA1</data>
          <key>Name</key>
          <string>PioneerSuperDrive</string>
          <key>Replace</key>
          <data>QkQtUlcgICBCRFItMjA1</data>
  </dict>
  </array>

OpenCoreに移行したところ、再び、「空のdvdがセットされました」というエラーメッセージが出るようになりました。Cloverで使っていたパッチと同様の内容を、OpenCoreのconfig.plistにも書いておく必要があるようです。

CloverのKextToPatchをOpenCoreに移行する方法

OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、書式もCloverのパッチとは多少異なります。上記のCloverのパッチを、OpenCoreで書く場合は、以下になります。ちなみにReplaceの値は、BD-RW BDR-205の型番になっています。他の型番の光学ドライブを使用している方は、その型番に書き換えてください。詳しくは、以前の記事をご覧ください。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>PioneerBD-RW No Sleep</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>RFZELVJXICBEVlItMTA1</data>
 <key>Identifier</key>
 <string>com.apple.driver.PioneerSuperDrive</string>
 <key>Replace</key>
 <data>QkQtUlcgICBCRFItMjA1</data>
 </dict>
 </array>
</dict>

Cloverと比べてOpenCoreでは、一部のキーが削除追加されています。OpenCoreのサンプルconfig.plistを見ると、もっとたくさんのキーがあります。ただOpenCoreのパッケージに付属するマニュアルを読んでみたところ、デフォルト値のままで問題ないキーが多かったです。それらは省略しました。

Cloverのkeyのうち、Comment, Find, ReplaceはOpenCoreでも同じ名前で、同じ意味です。つまり、Commentは人が読むためのメモ書き、Findは検索データ列、Replaceは置き換えるデータ列です。これらはCloverの内容からそのままコピーしました。

Cloverでは、kextをファイル名（この例ではPioneerSuperDrive）で指定していました。使用するキーの名前はNameでした。OpenCoreでは、Identifierというキーで指定します。URLを逆順にしたような形式の一意の名前なので、より正確です。PioneerSuperDrive.kextがどのようなIdentifierなのかは、システム情報の拡張機能で、該当するkextを選択すると調べられます。

identifierは、バンドルIDという項目に書いてあります。以下のようです。Identifierの項目にはこれを書いておきます。

com.apple.driver.PioneerSuperDrive

Enabledキーでは、このパッチを有効にするかどうかを指定します。デフォルトがfalseですので、明示的にtrueを書いておかないと有効になりません。なので追加しました。

Countキーは発見された項目を何個置き換えるかを指定する箇所です。1個置換えてくれれば十分（それ以上検索する必要は無い）なので、1を指定しておきました。デフォルトは0で、それは発見できうる限り全て置換するという指定です。1箇所変換することで十分ならば、Countには1を指定したほうが、残りの部分を全部検索するという無駄な処理が不要になるので、高速になると思います。

このパッチをOpenCoreのconfig.plistに追加したところ、Pioneerのブルーレイドライブが正常に動くようになりました。パッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

PlistEDPlusで編集

（追記）PlistEDPlusでOpenCore 0.6.9のconfig.plistを編集する様子を以下に示します。いくつか項目が増えていますがデフォルトで良いです。データがASCII表示もされるので確認が楽です。

まとめ

Cloverに当てていた光学ドライブのパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。CloverとOpenCoreでは、パッチのキー構成が多少違います。Cloverに当てていた他のkext用パッチも、必要に応じてOpenCoreに移行して、動作を確認していこうと考えています。

ASUSマザーボードがPOST失敗してF1対応を促される

Sat, 16 May 2020 10:50:57 +0900

OpenCoreに移行したら再起動するたびに「safe modeでPOSTしたのでF1キーを押してsetupしてね」と言われるようになりました。config.plistでDisableRtcChecksumをtrueにすると治りました。

追記：当初、対策2と対策3の内容で対応していましたが、コメントでTakさんからDisableRtcChecksumで対応できることを教えていただきましたので、対策1として追記しました。

OpenCore移行したらPOSTエラー発生

ASUS ROG MAXIMUS HERO WIFI (Z390) をOpenCoreに順調に移行できたかに見えました。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

でも再起動をすると、POSTのエラーメッセージが出て、SETUP画面を起動しないと先に進めなくなりました。エラーメッセージは、

システムはセーフモードでPOSTしました。
これはシステムが不安定なために前回のPOSTの試みが失敗したこと、または、電源ボタンが長押しにより強制終了されたことが原因かもしれません。
もしUEFI設定を変更した後にPOST失敗したのでしたら、安定した設定に戻したいと希望されているでしょう。F1キーを押してSETUPを起動してください。

との表示です。この後、F1キーを押してSETUPに入り、そこから起動を選ぶと、今度は正しく起動します。なので大して困る状況ではないですが、次の再起動でまたこの画面になり、対応が面倒です。

Cloverの時はこのような現象はありませんでした。OpenCoreでシャットダウンして、Cloverを起動する場面でも発生します。なので、OpenCoreでシャットダウンするときに、何かしらの不具合が発生しているのかもしれないです。

ASUSでよくあること？

検索してみたところ、同様の現象は多数報告されています。今回と同様に、CloverからOpenCoreに移行したらこうなったという人も多いです。でも過去には、Cloverでも発生していたようです。発生はしていたけど、Cloverのバージョンが上がったら治ったという報告もありました。ということで、よくある現象のようです。

対策1：DisableRtcChecksumをtrueにする

対策2以降の記事を書いたところ、コメントでTakさんから教えていただきました。この方法で解決しました。OpenCoreコミュニティのおすすめの解決方法のようですので、対策2以降は無視していただいて良いです。config.plistのKernel, Quirksの場所にあるDisableRtcChecksumを、以下のようにtrue（デフォルトはfalse）に設定すれば治ります。OpenCore 0.5.8から可能になった方法です。

 <key>Kernel</key>
 <dict>
（中略）
 <key>Quirks</key>
 <dict>
（中略）
 <key>DisableRtcChecksum</key>
 <true/>

この問題はリアルタイムクロック (RTC) が関係する問題だそうです。macOSのAppleRTC.kextが、シャットダウンするときにチェックサム値をファームウェア（電池バックアップされたマザーボード上のCMOSメモリ？）に書き込むようです。おそらくはそのことでマザーボードのデータを壊してしまうらしく、次のPOSTで失敗を引き起こしているようです。チェックサムを書き込む場所が0x58~0x59（番地？）で、DisableRtcChecksumをtrueにするとそこへの書き込みを禁止してくれるようです。以下にも説明があります。

この説明によると、DisableRtcChecksumをtrueにしてもまだ問題が発生するようなら、RTCMemoryFixup.kextを入れて、ブートオプションで、

rtcfx_exclude=00-FF

のようにして、0x58~0x59以外の領域も保護するようにすると良いようです。これでうまくいった場合は、ブートオプションを変更して、保護する範囲を狭めると良いようです。

対策2：BIOSで設定する

追記：対策1が簡単で根本的なのでおすすめです。

有効な対策の一つが、このメッセージを出さないようにBIOSで設定する方法です。メッセージをよく読むと、「BIOS設定を間違って失敗した場合は、元に戻したいと思うから、F1キーでSETUPにすぐに入れるようにしておいてあげたよ。」という意味の内容が書いてあります。どうやらsafe modeでPOSTしたこと自体は大した問題ではなくて、利便性のためにF1キーですぐにSETUPに入れるよう配慮してくれているようです。今回はBIOS設定を間違えたわけではありませんので、この「親切機能」をoffにしても良いと思います。

BIOSの設定では、Boot, Boot Configurationの中に、Wait For ‘F1’ If Errorという項目があります。これが「POSTに不具合あったらF1キーを待つ」という設定です。デフォルトではEnabledなので、これをDisabledにします。これで問題なく起動するようになりました。

とはいえ、大元の原因は解決できていないので、応急措置な感じは拭いきれません。探したところ、もう少し根本的な対策もあるようです。

対策3：AppleRTCにパッチを当てる

追記：対策1の方が簡単です。そちらをおすすめします。

こちらで対策が紹介されていました。

OpenCore causes UEFI to POST in safe mode

ここで紹介されているパッチをOpenCoreのconfig.plistのKernel, Patchに追加したところ、この現象は発生しなくなりました。config.plistをテキストエディタで開いて、パッチを挿入します。Patchという項目は、ACPIの項目にもあるので、間違えないように注意です。（最初は間違えてしまってパッチが効きませんでした。）パッチを施したconfig.plistを以下に置いておきます。もしこのconfig.plistを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

まとめ

OpenCoreにしたらsafe modeでPOSTする症状が出ました。ASUSではよくあることらしいです。SETUPに入ることを求められるので面倒です。config.plistでDisableRtcChecksumをtrueにして、シャットダウン時にmacOSがチェックサムを書き込まないように設定すると治りました。ということでOpenCoreの問題ではなくて、macOSとマザーボードの相性の問題のようです。Cloverで発生していなかったのは、単にデフォルトで対策されていただけなのかもしれないです。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

Fri, 15 May 2020 01:17:30 +0900

ASUSのZ390マザーボードと9900Kの組み合わせでmacOSを動かしているマシンのブートローダーを、CloverからOpenCoreに移行しました。OpenCoreのconfig.plistはCloverに比べて複雑ですが、親切なページと便利なツールがあったので円滑に移行できました。

OpenCoreのガイドとツール

Youtubeのビデオ

OpenCoreを使ってみた、という程度の記事を書きました。OpenCoreの基礎知識に関してはこちらをご覧ください。

新ブートローダーOpenCoreを使う

この当時は、OpenCoreは、Cloverに比べてconfig.plistがややこしくて面倒という印象でした。設定項目が多いだけでなく、kextやSSDTやefiドライバーの一つ一つをconfig.plistで記述する必要がありました。ところが最近、YoutubeでOpenCoreの設定ビデオを見ていたら、ProperTreeという便利なツールと、手順を解説した親切なサイトが紹介されていました。ハードウェア構成も、手元のメインマシンに近いので、このビデオを参考に、OpenCoreへの移行を試すことにしました。

OpenCore設定解説ページ

こちらのページがとても親切です。デスクトップPCを対象にした解説ページです。

config.plistのそれぞれの設定項目を、詳細に網羅的に説明してくれているので、Cloverよりもわかりやすいかもしれません。歴史の長いCloverは、すでに使われない設定項目なども多く、説明を探して読んでも無意味だったりすることもあります。OpenCoreの設定は、Cloverに比べて簡単ではありませんが、最新の設定方法情報がCPU別に整理されているのは助かります。

ProperTree

このページでconfig.plist編集に使われているツールがProperTreeです。ProperTreeはPythonで書かれたクロスプラットフォームのプロパティ編集ソフトで、macOSやhackintoshを前提としたツールではありません。それに、RedditのHackintoshサブレディットで活躍されているcorpnewtさんが手を入れて、OpenCoreのための機能を追加されたようです。

GitHub - corpnewt/ProperTree: Cross platform GUI plist editor written in python.

今まで、config.plistはテキストエディタで編集する、というストイックな対応をしてきましたが、OpenCoreのconfig.plistは長くて複雑です。なので今後はこのツールを使っていきます。

ProperTreeを使うためには、上記のサイトからファイル一式をダウンロードします。ダウンロードしたファイルの中のProperTree.commandがメインのPythonプログラムです。ファインダーからこれを開くか、またはTerminalから起動します。ファインダーから開く場合は、Terminalのウィンドウが一つ開いて、GUIウィンドウが現れます。Automator.appなどを使えばもっとアプリケーションっぽく見せられるとは思いますが、こういう形式も無骨で良いと思います。これでconfig.plistなどを開くと、XcodeのPlistエディタのように項目を開いたり閉じたりして閲覧し、内容を変更・追加・削除できます。

OpenCore Sanity Checker

OpenCoreのconfig.plistの正常性をチェックしてくれるページです。CPUとOpenCoreのバージョンを指定して、config.plistファイルをドラッグ&ドロップすると検査結果を表示します。この記事の最後で、作成したconfig.plistのチェックを行いました。

OpenCore config.plist Sanity Checker

ハードウェア構成

この記事の対象としたマシンは、以下で紹介したZ390マザーボード＋9900Kです。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ハードウェアの構成を再掲すると、

マザーボード： (値上がりしてますね)
CPU： @ 4.00GHz
グラフィックス：
WiFi/Bluetooth： (中身はBCM94360CD)

です。最新のmacOS, Clover, kext類の構成で、全く問題なく稼働しています。以下では、これをOpenCoreに移行します。

ファイルを入手してESPに置く

OpenCoreのダウンロード

以前の記事で紹介したように、Kext Updater.appを使いました。ダウンロードした中身には、Docs, EFI, Utilitiesの3個のディレクトリがありました。DocsとUtilitiesの中身は、そのうち少しずつ調べていきたいと思います。メインなのはEFIです。

OpenCoreの初期EFIをコピーする

ダウンロードしたOpenCoreファイルの中にあったEFIフォルダは、そのままESPにコピーして使います。またDocsの中にあるSample.plistを、config.plistと改名して使います。そのために、現在のマシンのESPをマウントします。そして現行のEFIを、例えばEFI_Cloverという名前に改名します。いきなり稼働中ドライブのESPを変更するのは危険かもしれませんので、他のドライブのESPやUSBメモリのESPで試しても良いかもしれません。起動に失敗したらUEFIシェルで名前を戻せば良いと思ったので、今回はメインドライブを直接変更してしまいます。

% sudo diskutil mount disk0s1
Password:
Volume EFI on disk0s1 mounted
% cd /Volumes/EFI 
% ls
EFI
% mv EFI EFI_Clover
% ls
EFI_Clover

ここに、ダウンロードしたOpenCoreのEFIをコピーします。また、Docsに入っていたSample.plistをconfig.plistに改名してEFIに入れます。

% cp -R ~/Desktop/Kext-Updates/OpenCore/EFI .
% cp ~/Desktop/Kext-Updates/OpenCore/Docs/Sample.plist EFI/OC/config.plist
% ls
EFI		EFI_Clover
% ls EFI/OC 
ACPI		Drivers		OpenCore.efi	Tools
Bootstrap	Kexts		Resources	config.plist

ここではTerminalでシェルコマンドを使って操作していますが、ファインダーでドラッグ&ドロップで行っても全く問題ありません。（ドラッグ&ドロップ中のスクリーンショットを撮るのが面倒だったのです、すみません）。結果としてこんな状態になりました。

ACPIの中身を用意する

EFI/OCの中をこれから設定していきます。まずはACPIフォルダの中です。EFI/OCに移動して、ACPIフォルダの中を見ると、空っぽです。

% cd EFI/OC
% ls ACPI 
%

上記の解説ページのCoffee Lakeの説明によると、Coffee Lakeマシンに必要なSSDTは、以下の4個です。

SSDT-PLUG Haswell以降のネイティブなCPU電力制御を担当。
SSDT-EC-USBX 組み込まれたコントローラーを隠して、macOS用のフェイクなコントローラーを作ります。Catalinaユーザには必須で、他のバージョンでも使うことを推奨します。
SSDT-AWAC 300シリーズチップセット用のRTCパッチ。ほとんどのB360, B365, H310, H370, Z390といくつかのZ370マザーボードでこれがないとブートしない。
SSDT-PMC 本当の300シリーズマザーボード(つまりZ370は除く)はファームウェアでMMIOを宣言していないので、問題を起こします。そのようなマザーボードがNVRAMをサポートするために必要です。

上記のサイトにはコンパイルされたバージョンもありますし、ソースコードが掲載されたGitHubへのリンクもあります。なのでダウンロードすればokです。もしくは、ソースコードからコンパイルしても良いでしょう。その場合、GitHubのページに行き、Rawボタンをクリックして、全選択して、MaciASL.appでコンパイルします。MaciASLについては、こちらをご覧ください。

DSDTを編集する

例えば、SSDT-PLUGをコンパイルする場合は、ガイドに書かれているGitHubのページに行き、Rawボタンを押します。これで現れるテキストを全部コピーします。

次にMaciASL.appを起動し、新規ウィンドウを開いておき、ここにペーストします。

次に、MaciASL.appのFile, Save As…メニューを選び、出てくるダイアログでFile Format:をACPI Machine Language Binaryに設定し、SSDT-PLUG.amlという名前で保存します。こうして得られた4個のSSDTをACPIディレクトリに入れます。

あともう一つ。USBの15個制限対応のために、SSDTを作ってありました。このSSDT-UIAC.amlも、ACPIディレクトリに入れておきました。なので使用するSSDTは全部で5個になりました。

15個制限を回避するUSBInjectAll.kextの役割と使用法

Driversの中身を整理する

Driversディレクトリは、初期状態では以下のようになっています。

解説によると、必要なDriverは以下の2個だけのようです。

HfsPlus.efi
OpenRuntime.efi

HfsPlus.efiはCloverでも使われている、HFS+ファイルシステムを読み込むドライバーです。HFS+から起動する場合に必要です。OpenRuntime.efiは、CloverでのAptioMemoryFix.efiに相当するドライバーのようです。Catalinaの時代なのでHFS+で起動することはもう無いと思いました。配布物にもHfsPlus.efi (もしくはVBoxHfs.efi) が含まれていません。そこでOpenRuntime.efiだけを使うことにします。

使用しないドライバーを消してしまうと、後で必要になるかもしれないので、ファイルは残しておきたいと思いました。おそらく、ファイル自体はこのディレクトリに残しておいて、config.plistの方で無効にするのがOpenCore流儀なのではと思います。でも不要なファイルは所定のディレクトリから外すというClover方式に慣れているので、offにするディレクトリを作って、使わないファイルをそちらに移すことにしました。以下の例では、Drivers_offというディレクトリを作って、OpenRuntime.efi以外はそちらに移動しました。

Kextsの中身を用意する

Kextsディレクトリも初期状態では空っぽです。現在、Cloverで使っている以下のkextをそのまま入れておくことにします。

AppleALC.kext
IntelMausi.kext
Lilu.kext
USBInjectAll.kext
VirtualSMC.kext
WhateverGreen.kext

Toolsの中身を整理する

これもDriversディレクトリと同様に、多数のファイルが初期状態で入っています。

デバッグするときに使用するツールらしいです。上記のガイドによると全部不要らしいです。でもUEFI Shellは絶対に欲しいと思いました。なのでそれだけを残して、他はTools_offというディレクトリを作って、そちらに移動しておきました。

以上で必要なファイルが、必要な場所に保存されました。あとはconfig.plistを設定するだけです。

Config.plistを設定する

コメントを消す

config.plistの全ての設定にはProperTreeを使います。config.plistが複雑すぎるので、テキストエディタを使うことは諦めました。ProperTreeを起動して先ほどSample.plistをコピーして作ったconfig.plistを開きます。

最初の5項目の#WARNINGとあるのはSample.plistの警告のコメントです。不要なので削除します。行の上でコンテクストメニューを開くと、メニュー項目にRemove …があります。これを選びます。

OC Clean Snapshotを使う

ProperTreeにはOC Clean Snapshotというメニュー項目があります。この機能が凄いです。これがあることを知ったことで、OpenCoreに移行する気になりました。OpenCoreのconfig.plistで一番面倒だと思っている点は、使用するSSDT, kext, efiドライバー, efiツールなどを全部config.plistに記載しておく必要があることです。名前を書いておくだけでなく、いろいろな設定も書いておく必要があります。ディレクトリに放り込んでおくだけでokだったCloverに比べて、面倒でした。kextを起動する順番を、config.plistの記述順で指定できるので、必要な機能なのかもしれませんが。

このようなconfig.plistへの記述を自動化してくれるのがOC Clean Snapshotです。ProperTreeのメニューを開くと、OC SnapshotとOC Clean Snapshotの二つのメニューが現れます。

おすすめはOC Clean Snapshotの方です。これを選択すると、ACPI, Drivers, Kexts, Toolsディレクトリに入っているファイルを検出して、必要なconfig.plist設定を自動的に作ってくれます。例としてkextファイルの自動検出を示します。まずは初期状態のconfig.plistです。7個のkextが登録されていますが、先ほど保存したkextとは一致していません。Legacy_USB3.kextとAppleMCEReporterDisabler.kextの2個はKextsディレクトリに入っていません。その一方でKextsディレクトリに入れたUSBInjectAll.kextの項目がありません。従来ならば手作業で修正する必要がありました。

ここでProperTreeのOC Clean Snapshotを動かします。すると、ファイルを検出するOCディレクトリの場所を聞いてきます。そこで作業中のOCディレクトリを指定します。

すると、Kextsディレクトリに入っているkextのリストに自動的に置き換えてくれます。

このkextリストは、この順番に読み込まれるので、基本的なkextを先に読み込む必要があります。例えばLilu.kextは一番上に、次がVirtualSMC.kextなどの順番で記述する必要があります。ProperTreeのOC Clean Snapshot機能は、その順番も正しく判断してくれます。Kexts以外に、ACPIとDriversとToolsの中身も検索して、自動的に該当する箇所の記述を更新してくれます。

ACPIとKextsとToolsディレクトリのファイルに関しては、config.plistの記述の中でEnabledキーをTrueまたはFalseにすることで、個別にon/offすることが可能です。OC Clean Snapshot機能は、全てTrueにしてくれます。一方、OC Snapshot機能は、全てFalseにします。手動で必要なものを選ぶことになります。ACPIとKextsとToolsディレクトリ内にあるSSDT, kext, efiツールを有効にしたいという目的からしたら、OC Clean Snapshotの方が理にかなっていますし、こちらを使うのが便利だと思います。

ACPI項目

ではガイドのページと、ProperTreeのウィンドウを見比べながら細かい設定をしていきます。まずはACPI項目です。OC Clean Snapshot機能によりAddの内容は自動設定されています。これ以外の項目は全てデフォルト（Sample.plistの記述）のままで良いようです。

Booter項目

Quirksの項目のいくつかをデフォルトから変更します。辞書によるとquirksは、予想外の曲がり、ひねり、とか気まぐれのような意味だそうです。fuchsiaさんからコメントで教えていただいたUbuntu wikiの記載によると、ハードウェアのバグを回避するためのソフトウェア手法というような意味だそうです。ソースコードを読む時に、「なんでこんなことやっているんだろう」と不思議に思うだろうことから、予想外に曲折した状態というニュアンスで使われているのではと思いました。Sample.plistの設定から変更するQuirksは以下です。

DevirtualiseMmio: True、slideオプションの拡張。Z390のメモリ確保に有効。
RebuildAppleMemoryMap: True、macOS互換のメモリーマップを作る。
SyncRuntimePermissions: True、Skylake以降でMATテーブルの問題を解決。
SetupVirtualMap: False、仮想アドレスの問題を解決。Skylake以降では不要。

DeviceProperties項目

この項目の設定方法はCloverの該当項目と同様です。Sample.plistの初期値ではPciRoot(0x0)/Pci(0x1b,0x0)のオーディオに関する情報しか書いてありません。

mifjpnさんからコメントで指摘いただいたのですが、オーディオのdevice pathが違っていました。多分、マザーボードの配線によるのだと思いますが、使用したマザーボードでは、PciRoot(0x0)/Pci(0x1b,0x0)ではなくて、PciRoot(0x0)/Pci(0x1f,0x3)でした。Hackintool.appでも確認できますし、ioregコマンドでも確認できました。

% ioreg | grep AppleHDAController 
 | | | +-o AppleHDAController@1F,3 <class AppleHDAController, id 0x10000055a, registered, matched, active, busy 0 (976 ms), retain 34>

なのでPciRoot(0x0)/Pci(0x1b,0x0)をPciRoot(0x0)/Pci(0x1f,0x3)に書き換えます。内容の方の、Layout IDはCloverの時も、Sample.plistの通り1でしたのでこれはそのままです。

Audioに加えて、DevicePropertiesには、iGPUの情報をWhateverGreen.kextに伝える目的で、PciRoot(0x0)/Pci(0x2,0x0)の項目を追加します。Addの項目でコンテクストメニューを開き、New child under …のメニュー項目を選択します。すると新規な項目が現れるので、内容をPciRoot(0x0)/Pci(0x2,0x0)にしてtypeをDictionaryにします。さらにここにchildを作り、名前をAAPL,ig-platform-idにし、typeをDataにします。今回は、iGPUをヘッドレスとして使うので、値は、0300923Eにします。結果として、以下のようになります。

Kernel項目

Addの項目に記述するkextファイルの情報は、OC Clean Snapshot機能により自動設定されています。Quirksの項目のいくつかをデフォルトから変更します。デフォルトから変更する箇所は以下です。

AppleCpuPmCfgLock: True、BIOSでCFG lockが解除できるなら不要です。ASUSのZ390マザボは解除できるのでFalseでも良いです。CloverのAppleIntelCPUPMに相当します。
AppleXcpmCfgLock: True、BIOSでCFG lockが解除できるなら不要です。ASUSのZ390マザボは解除できるのでFalseでも良いです。CloverのKernelPMに相当します。
DisableIoMapper: True、BIOSでVT-Dを無効にできるなら不要です。ASUSのZ390マザボは無効にできるのでFalseでも良いです。dart=0より良い選択肢です。
PanicNoKextDump: True、カーネルパニックの情報が読めるようになります。
PowerTimeoutKernelPanic: True、パワー変化によるカーネルパニックを防ぎます。デジタルオーディオに関係します。

Misc項目

DebugとSecurityのいくつかの項目をデフォルトから変更します。

AppleDebug: True
DisableWatchDog: True watch dog timerを無効にします。
Target: 67、この値が0以外の場合、EFIディレクトリにopencore-2020-05-15-xxxxxx.txtというような名前のログファイルが書き込まれます。Sample.plistでは3になっています。67にするともっと多くのデバッグ情報がログファイルに書き出されます。ログファイルが不要なら0にします。
AllowNvramReset: True
AllowSetDefault: True
ScanPolicy: 0、0にしないとUSBメモリーから起動しないらしいです。
Vault: Optional、デフォルトのSecureのままでは起動しないです。Optionalは大文字で開始します。

NVRAM項目

本物のMacならばNVRAMに記録されるべき項目の設定です。Addでは、

boot-argsのデフォルトにdebug=0x100 alcid=1を追加しますとあります。どちらも追加しなくても良いように思います。debug不要ならその指定は不要だと思います。DevicePropertiesのところで1に設定してあるので、alcid=1も不要です。
prev-lang:kbdを手持ちのキーボードに合わせて設定します。デフォルトはロシア語になっています。USキーボードの場合は656e2d55533a30にします。

を変更します。またWriteFlashはNVRAMに設定値を書き込む設定で、Trueにしますと書いてありますが、どちらでも良いように思います。

Platform項目

CloverのSMBIOSに相当する項目ですね。機種IDは、Mojave以降はiMac19,1, High Sierra以前はiMac18,3が良いようです。その時代に未発売なMacの機種IDは使うなということですね。現在使用中のCloverのconfig.plistからSerialNumber, BoardSerialNumber, SmUUIDをコピーして、それぞれを、

SystemSerialNumber
MLB
SystemUUID

にコピーしました。またROMの項目には、NICのMACアドレスを書いておけば良いようです。システム環境設定のネットワークから取得したEthernetのMACアドレスを書いておきました。

UEFI項目

Driversの項目に記述するefiドライバーの名前は、OC Clean Snapshot機能により自動設定されています。Quirksの項目のRequestBootVarFallbackをTrueに変更します。と書いてありますが、説明読んでもあまり違いはない気がしました。

以上でconfig.plistの設定が終了しました。それぞれの項目の説明がそれなりに書いてあるので、Cloverよりも明朗な感じです。説明資料が整っている印象があります。この状態で再起動すればOpenCoreから起動するはずです。起動しなければ、UEFI shellからEFIディレクトリの名前を書き換えて、Cloverに戻せば良いと思います。と考えて再起動を試したところ、なんと1回で成功しました。完成したconfig.plistを以下に置いておきます。SystemSerialNumber、SystemUUID、MLB、ROMの値は、これを使用せず、みなさんで必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

Sanity Checkerで検証

ここで作ったconfig.plistを、OpenCore Sanity Checkerで検証しました。

OpenCore config.plist Sanity Checker

赤い❌マークで警告を受けたのはUEFI, Driversの箇所で、VBoxHfs.efiもしくはHFSPlus.efiが無いという項目1点だけでした。上でも説明しましたが、Catalinaより古いmacOSを使う予定がなかったので、入れてませんでした。無しのままにしておきます。

青い❗️マークが1点、Misc, Toolsで出ていました。「You can remove the tool EFIs here」と表示されています。Toolsには、OpenShell.efiだけを入れてあります。UEFI Shellは、File Vault起動のセキュリティを回避できてしまうので、デバッグが終わったら外しておくようにという意味かと思いました。Toolsの記述を消すと、このマークは出なくなります。ただ、File Vault起動は使っていないですし、いざというときにUEFI Shellは欲しいので、これも無視しておきます。

黄色の❓マークが、以下の3カ所で表示されていました。

SetupVirtualMapがNoだけど通常はYesです。
DisableIoMapperがNoだけど通常はYesです。
PointerSupportModeがASUSだけど通常は空白です。

上記で説明したように、SetupVirtualMapは仮想アドレスの問題を解決する機能ですが、Skylake以降では不要とのことでNoにしました。DisableIoMapperは、VT-Dを無効にする機能ですが、BIOSで無効にできているのでNoにしました。PointerSupportModeは、大もとのSample.plistでASUSとなっていました。OpenCoreのマニュアルを調べたところ、マウスポインター操作をサポートする設定らしいのですが、ASUSのZ87, Z97マザーボードだけがサポートされているらしいです。このパラメータは指摘どおりに空白にしておきました。

その他の設定

コメントでいただいた情報と、その後の記事で設定した項目を以下にまとめておきます。いろいろ情報をいただいて本当にありがとうございます。

起動ボリュームの指定

初期設定のままだと、リストの最初のドライブから起動します。起動ドライブを指定するには、macOSのシステム環境設定の起動ディスクを使います。ここで、起動させたいボリュームを選ぶと、その後、それで起動するようになります。Cloverでは起動ドライブの名前などをconfig.plistに書いていましたが、OpenCoreではよりmacOSに近い方法が可能になりました。

Kext Updaterを使う

Sample.plistの設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトでは6だったので7にしました。コメントで教えていただきました。

rtc-blacklistが見つからない警告

起動時に出るかもしれない警告、

Warn:oc:setting nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:rtc-blacklist – not found oc

は、NVRAMの4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102のrtc-blacklistを消すと出なくなります。コメントで教えていただきました。

Windowsが起動しない

Misc, Boot, BlessOverrideに, \EFI\Microsoft\Boot\bootmgfw.efi などと追加します。コメントで教えていただきました。

続きの記事

この記事に続く以下の記事でもOpenCoreの設定を行なっています。

ASUSマザーボードがPOST失敗してF1対応を促される

Pioneer光学ドライブのパッチをOpenCoreに適用する

OpenCoreの選択画面をグラフィカルにする

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

使用するUSBポートを15個指定する (OpenCore編)

まとめ

Z390マザーボードのマシンをCloverからOpenCoreに移行しました。それなりに時間はかかりましたが、すんなりと運びました。今回はCoffee Lake CPUマシンの移行でしたが、他のCPUについても同様に詳しい手順が説明されているので、問題なく移行可能と思います。説明資料やチュートリアルが充実していて、ツールも揃っているので、そろそろOpenCoreに移行しても大丈夫な時期になったかと感じました。細かい設定などを調べつつ、他のマシンも、順次切り替えていきたいと思います。

ThinkPad T460sのキーボード交換

Tue, 12 May 2020 17:30:48 +0900

中古で入手したThinkPad T460sのテカっていたJISキーボードをUSキーボードに交換しました。T460のキーボード交換は簡単です。交換後は何事もなく起動し認識してくれました。

ThinkPad T460s (6300U) にOpenCoreでCatalinaを導入

キーボードのテカり

キーボードは使い込むとテカりますよね。人の脂で汚れるわけではなくて、プラスチック表面のシボ加工が擦れて取れてしまい、プラスティック本来のツルツルな状態になってしまうのだと思います。なので、掃除しても元どおりにはなりません。擦れば擦るほどツルツルになるだけです。

中古のノートPCはキーボードが大抵テカってます。今回入手したT460sはかなり激しく摩耗しています。一部の印字も消えています。手触りもツルツルで、触れたくない感じです。おそらく企業のリースバック品で、日々の業務で酷使されたのだと思います。大活躍できて道具として幸せだったでしょう。今後は、macOSをたまに動かすだけの暇な余生になりますが、その前に綺麗なキーボードに交換してあげたいと思います。

交換用キーボード

ThinkPad, Dell, HPなどのグローバルな製品の中古を選ぶ利点は、補修部品が比較的潤沢に流通している点だと思います。T460s用のキーボードもAmazonやAliExpressなどで売られています。今回は以下のサイトから入手しました。送料税込3,000円くらいです。T460S, T460P, T470S, T470Pなどに対応しているようです。長らくUSキーボードだけを使い続けているので、これもUSです。Linuxするとか、hackintoshするなどのコアな使い方では、設定の一部でUSキーボードしか使えない場面も多いです。コンピュータ発祥の地で使われるUSキーボードが何かと便利です。

キーボードを交換

同世代のX260は、ほとんどバラバラに分解しないとキーボードにたどり着けないらしいですが、T460sのキーボード交換は楽です。交換手順を紹介する動画もたくさんあります。

まずは、裏側にあるダイアルのようなプラスティックのロックを60度ほど回します。写真にはプラスドライバーが写っていますが、これでは溝を痛めそうでした。幅広のプラスチックヘラのようなものを使った方が良いです。ロックにはキーボードと南京錠のアイコンが書いてあり、分かりやすいです。キーボードは消耗品だから、古くなったら取り替えて、大事に末長く使ってください、というメッセージが感じられます。

裏側のダイヤルを開錠状態にすると、表側のキーボードの背面板がスライドできるようになります。プラスチックヘラのような道具を使って、背面板を少しずつ上方にスライドさせると、隙間から6個のネジが見えます。下の写真では右側の3個が写ってます。

6個のネジを緩めると、キーボードがThinkPad本体から外れます。ただ、右下部分で2本のフラットケーブルで本体とつながっています。コネクタには黒いストッパーがあり、これを跳ね上げるとフラットケーブルが外せます。

これでキーボードを完全に取り外せるので、新しいキーボードに交換し、逆の手順で取り付けていきます。新品のUSキーボードは美しいです。

そしてこのキーボード、なんと光ります。初めはどうやって光らせるのかわからなかったので、macOSでは無理なのかと諦めていました。たまたま他機種のThinkPadを紹介するYoutube動画を見て、光らせ方がわかりました。Fnキーとスペースを押すと、暗くon, 明るくon, offの3段階に切り替わります。よく見たらスペースキーに、キーが光っている様子を表すアイコンがあります。

まとめ

ThinkPad T460sのキーボードを新品のUSキーボードに交換しました。裏のロックを外して、表側の6個のネジを緩め、フラットケーブルを外すだけの作業でした。macOSで問題なく動きました。

100シリーズチップセットで本物のNVRAMを使う

Sat, 09 May 2020 23:34:38 +0900

SSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れると、Intel 100シリーズチップセットでもNVRAMの値が保存されるようです。Q170搭載のHP社小型デスクトップPC、HP EliteDesk 800 G2 DMで試した結果を報告します。

これも、「HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM にmacOSを入れる」シリーズの記事ですが、小ネタです。

HPの小型デスクトップEliteDesk (1: macOS導入)

300チップセットでNVRAMを使う

NVRAMを使うために、従来は、EmuVariableUefi.efiドライバを入れていました。でも300シリーズチップセットではNVRAMの内容が正しく保存されない問題がありました。しかし、最近OpenCoreの成果で作られたSSDT-PMC.amlを使えば、300シリーズチップセットでもNVRAMが正しく使えます。という記事を、以下に書きました。

300シリーズマザーボードでも本物のNVRAMを使いたい

100チップセットでもNVRAMを使う

最近、HP EliteDesk 800 G2 DMのスリープ対策で色々試していたところ、このマシンでもEmuVariableUefi.efiではNVRAMに書き込めないことに気づきました。公開されている仕様書によると、HP EliteDesk 800 G2 DMはQ170チップセットを使っています。100シリーズチップセットでも300シリーズチップセットと同様な問題があるようです。

そこでSSDT-PMC.amlを使ってみたところ、なんと正しくNVRAMが動きました。ということで、SSDT-PMC.amlは、300シリーズに限らず、おそらく100シリーズでも有効なようです。以下に、EmuVariableUefi.efiを使った場合と、SSDT-PMC.amlを使った場合の比較を書いておきます。

EmuVariableUefi.efiを使う

まずは、EmuVariableUefi.efiを

EFI/CLOVER/drivers/UEFI/EmuVariableUefi.efi

の場所に入れて起動した場合です。ターミナルからnvramコマンドで、意味のないhogeという名前の変数にtestという文字を登録します。nvram -pコマンドで確認できるので、そこからhogeだけ取り出して表示します。この一連の作業を行った結果を以下に示します。

% sudo nvram hoge=test
Password:
% nvram -p | grep hoge
hoge	test

ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。

% nvram -p | grep hoge

再起動前に設定した変数が消えています。

SSDT-PMC.amlを使う

次にSSDT-PMC.amlを

EFI/CLOVER/ACPI/patched/SSDT-PMC.aml

に入れて起動します。この状態で、ターミナルからnvramコマンドで、同様に変数hogeにtestという文字を登録して、nvram -pコマンドで確認します。

% sudo nvram hoge=test
Password:
% nvram -p | grep hoge
hoge	test

ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。

% nvram -p | grep hoge
hoge	test

SSDT-PMC.amlを入れておけば、Q170チップセットでもNVRAMに値を入れて、再起動後も読み込めるようです。ちなみにSSDT-PMC.amlを入れた状態で設定した変数は、これを外してEmuVariableUefi.efiを入れた状態でも読み込めました。EmuVariableUefi.efiを使うと、再起動前に変更したり書き込んだ結果が消えてしまうものの、正しく書き込まれているNVRAM値は読めるようです。

まとめ

SSDT-PMC.amlは300シリーズチップセットだけでなく、他のチップセットでも有効なようです。300シリーズ以外のユーザの皆さんも、ぜひお試しください。その結果をコメント欄で報告いただければありがたいです。ちなみに設定してしまった意味のない変数は、

% sudo nvram hoge=

とすれば消せます。

HDMI用ダミープラグ

Mon, 04 May 2020 13:36:06 +0900

HDMI端子用のダミープラグを使ってみました。HDMI端子に挿しておくと、端子にディスプレイが繋がっているフリをしてくれます。ディスプレイ無しで動かしているmacOSサーバを安定動作させるために使いました。

macOSをディスプレイ無しで使う

macOS Serverはいろんな機能が削られてしまって、macOSラインナップから消滅したも同然です。でももともとmacOSはUnix系OSなので、サーバーバージョンではないmacOSもサーバとして十分に使えます。小型で省電力で安価なmacOSマシンをたくさん作っていると、サーバとしても使う気になってきます。ということで、NUCマシンにディスプレイを接続しないでサーバとして使っています。作業する場合は、別マシンから画面共有を使います。

ただ、macOSをディスプレイ無しで起動すると、少し不便なことがあります。まずは大抵の場合、画面画素数が1024×768画素になってしまいます。画面共有先からフルスクリーンにすると小さいので、いちいち変更するのが面倒です。また、場合によってはディスプレイを接続しないと、起動が不安定になることもありました。ということで、ディスプレイがつながっているように見せかけてくれるダミープラグを用意しました。

ダミープラグは、ディスプレイ無しサーバ以外でも使われます。グラフィックスカードを数値計算やマイニングに使う場合に、動作を安定させるためにも使われるようです。またコメントでは、グラフィックカードに負荷を掛けてベンチマークを取るというコアな使い方を紹介いただいています。

ディスプレイ無接続Intel NUCに使用

Core i3-3217U搭載のIntel NUCで使いたかったので、必要なのはHDMI用のダミープラグです。他にもDisplay Port用、mini DP用などがあります。また昔ながらのVGA用のダミープラグもあります。HDMI用は、需要がたくさんあるので、価格が安いです。送料込みで300円未満で手に入ります。

これをIntel NUCに接続したところ、1080pのフルHDディスプレイとして認識されていました。ディスプレイが無いと起動しない時もあったのですが、ダミープラグを取り付けたら安定しました。

システム情報を見ると、通常ならメーカーを類推できる型番が表示される場所が、28E860という数字になっています。プラグ本体には4K UHDと書いてあるのですが、NUCではFHDとして動いています。おそらくmacOSのIntel HD Graphics 4000ドライバーが4K非対応なので、そのように認識されているようです。

試しにメインマシンのRadeon RX580のHDMIポートに挿してみました。以下のように、4Kの選択肢も現れました。表記通りにUHDとして機能するようです。

HPの小型デスクトップEliteDesk (5: BIOS/CPU更新)

Sun, 03 May 2020 18:39:11 +0900

HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM のCPUをCore i3-6100Tからi5-6500Tに交換しました。交換に先立ってBIOSも最新にしました。2コア4スレッドから4C4Tになって、ベンチマークスコアが1.4倍改善しました。

HPの小型デスクトップEliteDesk (1: macOS導入)

4コアCPUが使いたい

スリープからの復帰で暗黒画面になってしまうことが判明して、少し残念なのですが、スリープしない設定でしばらく使うことにしました。このマシンは、リモートワークで盛り上がっているZoom専用機にしようと考えています。なのでスリープは必須ではありません。ただどうしても4コアCPUにしたいと考えました。というのも、Zoomは4コアあれば賢く背景を切り抜いて仮想背景に差し替えてくれるのですが、4コア未満では処理性能が足りないと判断されて、ブルーバックが必須になります。このことが最初からわかっていたら、4コアモデルを探すべきでした。

HP EliteDesk 800 G2 DMの色々なグレードの仕様を探してみたところ、第6世代Core i搭載製品で使用されているCPUは、

6100T
6500T
6600T
6700T

だそうです。6500T以上なら4コアなのでZoomの要求仕様を満たします。ただ、6600T, 6700Tはほとんど中古市場に出回っていませんし、あっても高価です。その点、6500Tならば、この手の小型PCに大量に使われているためか流通量も多いです。オークションサイトで8,000円程度で取引されています。ということで6500Tを入手しました。

BIOSを更新する

CPUを新しくするならばBIOSは最新版に更新しておいた方が良いと思います。BIOSのバージョン毎に対応CPUが違う可能性がありますが、最新版ならば旧版があつかうCPUの全てに対応しているはずです。HP EliteDesk 800 G2 DM のBIOSは以下で配布されています。ただ、OSとしてWindowsを選択しないと行き着けないです。BIOS更新はWindowsを前提としているようです。

HP EliteDesk 800 35W G2 Mini PC ソフトウェア及びドライバーのダウンロード | HP…

ここからダウンロードしたファイルはexe拡張子のファイルでした。自己伸長ファイルのようです。zipなどの一般的な形式で配布してくれればmacOSで扱えて楽なのですが残念です。伸長するためにVirtualBoxでWindowsを起動しました。配布されていたファイル類は、BIOS本体の他に、多分これをインストールするためのWindowsソフトと、資料文書で構成されていました。N21_0245.binというファイルがBIOS本体のようです。一方、History.txtというファイルには、BIOS更新の記録が書かれています。ざっとみたところ、CPUのいろいろなバージョンへ、その都度対応されている様子です。また、バグも多数修正されています。こういう記録を見ると、ソフトウェアは更新すべきだなと実感します。ちなみに、購入したマシンのBIOSバージョンは2.19で、このリストのずっと下の方です。それ以降、バージョン2.45まで様々なアップデートと修正が行われているようです。

BIOSアップデート作業は、一般のマザーボードと同様に、BIOSメニューから行えます。USBメモリーにHewlett-Packard/BIOS/new/というディレクトリを作り、その中に新BIOSのイメージファイル (N21_0245.bin) を入れれば、BIOSアップデートメニューから認識してくれます。そして無事、最新版のBIOSであるN21 Ver.02.45 12/25/2019になりました。今から4ヶ月くらい前の新しいバージョンです。

CPUを交換

交換前のCPUを確認しておきます。6100Tは2コア4スレッドで3.2GHzです。

CPUのヒートシンクとファンは、HP EliteDesk 800 G2 DM の中身の半分を占めています。ファンは、跳ね上げて下のメモリー交換できるようになっています。その軸受けの部分からファンを引き出して取り外すことができます。ファンはマザーボードから電源ケーブルでつながっていますが、外さなくても脇に置いておけます。

ファンを外した残りの部分、ヒートシンクはT15番のトルクスネジ3個で固定されています。ネジはコイルバネの中を通してあり、ヒートシンクはバネの力で押さえつけられています。以前、CPU交換を行ったMac Proのように、ネジを締め付ける力で直接ヒートシンクを押さえているわけではありません。なので、ネジ締めトルクは適当でも良いと思います。でもを使い正確にネジ締めします。写真にあるように工具としてカッコ良いです。このトルクドライバーで調べたところ、どのネジも30 cNm (センチニュートンメートル) で締められてました。かなり緩いです。

ファンとヒートシンクを外した状態です。ファンの電源ケーブルはつながったままです。グリースはまだしっとりしていました。また、美しく均一に塗られています。さすがはプロの技です。

グリースをアルコールで拭き取り、CPUを交換します。新しいグリースはいつもより高級にThermal Grizzlyを使いました。グリースを塗り、薄く伸ばして、ヒートシンクを取り付けます。締め付けトルクは30 cNmです。ファンを戻せば完成です。

これで起動を試みましたが、なぜか数回は起動しませんでした。BIOS画面が出ず、電源ボタンを押すとすぐに電源が切れます。ビープ音が短く鳴る時もありました。それでも起動を何度か繰り返すと、5-6回目くらいにBIOS画面が出ました。CPUが変わって、BIOSが混乱していたのかもしれないです。BIOS画面が出るようになってからは全く問題なくmacOSが起動しました。CPUも正しく認識されています。コア数は倍増するのですがクロック数は2.5GHzに落ちます。

まずはGeekbench 5のCPUスコアです。1740だったところが2442と、1.4倍ほど向上しました。

次はCinebench R20のCPUスコア比較です。825だったところが1121になり、こちらは1.36倍くらい向上しました。

クロックが下がった影響で、コア数が倍増しても、顕著に性能向上するわけではなかったです。コア数が倍増、スレッド数は同じ、クロック数が0.8倍なので、全体として1.4倍くらいなのは妥当なところかと思います。

まとめ

HP EliteDesk 800 G2 DM のCPUをCore i-3からCore i-5に交換しました。元々のラインナップにあったCPUだったこともあり、交換するだけで認識してくれました。性能向上は1.4倍程度でした。でも、ZoomはこのCPUを4コアの高性能CPUと認定してくれたようで、めでたく仮想背景がブルーバック無しで動くようになりました。よかったです。

ThinkPad T460s にWiFi/BTカードBCM94360NGを取り付ける

Mon, 27 Apr 2020 22:19:13 +0900

M.2ソケット用のWiFi/BluetoothアダプターBCM94360NGは、OOBで使える唯一のM.2無線カードです。T460sに取り付けたところ、BIOSで拒絶されることも無く問題なく動作しました。

BCM94360NG

BCM94360NGは、M.2ソケット用のWiFi/Bluetooth無線アダプターカードです。macOSとの相性が良くて、Handoff, Airdrop, Apple Watchでのログイン, SidecarなどがOOBで動きます。M.2無線カードとしては、互換性の高い唯一のカードだと思います。おすすめです。今のところ日本のAmazonでは扱っていないですが、AliExpressでは複数の販売者から入手できます。

AliExpressのサイトでは、macOS用無線カードを幾つかつ製造しているFenviのロゴが掲げられていました。そのサイトから送られてきたカードは、Fenviのロゴが入った透明パッケージに入っていました。

T460sに取り付ける

T460sの裏蓋を開けます。もともと付いていた無線カードは、Intelの8260NGWという製品でした。

これをBCM94360NGに差し替えます。どちらもアンテナ線2本のカードなので、交換は楽です。ただ、アンテナコネクタの位置が違うので、アンテナ線の取り回しが辛くなります。その上、いつものことですが、MHF4アンテナコネクタは小さくてはめにくいです。うまく位置が合えばカチッと気持ちよくはまります。ただ、元からのインテルのカードのコネクタより緩い感じで、力を入れると外れてしまいます。テープなどで固定した方が良いかもしれません。2本のアンテナは、最初のカードと同じく三角アイコンの白・黒を合わせて接続しました。ダイバーシティアンテナになっているだけだと思うので、逆にしても大丈夫とは思います。

交換後、T460sを起動したところ、直後はBIOS画面が2-3回現れて再起動している様子でした。その後無事macOSが起動しました。ThinkPadのBIOSは、動作確認のあるパーツのwhitelistを持っていて、それ以外のパーツを取り付けると起動しないと言われていました。その制約を外すために、ThinkPad X220のmini PCIeカードを交換した際には、改造BIOSに差し替えました。でも第5世代CPU搭載のThinkPadから徐々にwhitelist方式を廃止しているらしいです。なのでT460sではwhitelistの問題無く、動作したようです。ありがたいです。

動作チェック

カードの認識状況を「システム情報」でチェックしました。まずはネットワークとしては、種類もハードウェアもAirMacと表示されました。Apple純正カードであると認識されているようです。

次に、USBの項目でBluetooth部分を確認しました。製造元がApple Inc.となっています。これも純正のカードとして認識されているようです。ちなみに、Integrated CameraはT460sの液晶上部のカメラです。内部ではUSB接続しているようです。互換性が高かったはずです。

ソフトウェアの動作を確認したところ、App Store, iMessage, AirDrop, Sidecarが問題なく動作し、Apple Watchでのログイン認証も動作しました。iPhoneで開いていたwebページが、dockに現れるので、HandoffやContinuityも動作しているようです。Sidecarは、最初は動きませんでした。でも、以前もそうだったのですが、2-3日後になって動き始めました。Apple IDの認証に時間がかかっているなどのサーバー上の問題なのかもしれません。

M.2無線カードのおすすめ

今まで、M.2の無線カードは、BCM943602BAEDまたはDW1830の型番で販売されているカードが互換性が高いと考えていました。

こちらはアンテナが3本あります。WiFiの性能も上位で、今回使用したBCM94360NGが5GHzで867Mbpsなのに対して、BCM943602BAEDは1300Mbpsの規格です。なので高速なのですが、価格は3倍程度です。また、今回のT460sもそうですが、M.2無線カードはアンテナ2本が一般的なようで、ノートPCやデスクトップマザーボードでもアンテナは2本しか用意されていない場合が多いです。3本目のアンテナを追加するのに苦労します。さらには、BCM943602BAEDは完全なOOB動作をしないです。WiFiはそのまま動きますが、Bluetoothを動かすためには、いくつかのkextを追加する必要があります。

ということで、互換性からも、アンテナの本数でも、さらにはコストパフォーマンスの点でも、M.2無線カードはBCM94360NGがおすすめだと思います。将来、マザーボードのM.2カードを交換するかもしれない時のために、予備を確保しておこうかと思っています。

まとめ

ThinkPad T460sにM.2無線カードであるBCM94360NGを取り付けました。今のところmacOSの全ての機能が問題なく動いています。ThinkPadのBIOS whitelist機能によりカード交換が拒絶されるのではという心配も無用でした。BCM94360NGはmacOS下でOOBで動く、互換性の高い唯一のM.2無線カードだと思います。

ThinkPad T460sのBIOSを更新する

Sat, 25 Apr 2020 00:34:02 +0900

ThinkPad T460sのBIOSを更新しました。通常はWindows用アプリケーションで更新するようですが、macOSでBIOS更新用USBメモリーを作りました。Windowsを使わずに更新できました。

ThinkPadのBIOS

ThinkPad T460sで作ったhackintoshの続きです。

ThinkPad T460s (6300U) にOpenCoreでCatalinaを導入

BIOS設定画面で見ると、BIOSバージョンが古いことが気になっていました。2016年11月30日版の1.20です。

Lenovoのサポートサイトで配布されているBIOSは2019年12月13日版の1.47です。

BIOS アップデート (ユーティリティおよび起動CD用) (Windows 10 64bit/ 8.1 64b…

BIOSが古くても動いていれば問題なしです。むしろ新しくすることでOSが動かなくなる可能性もあります。サポートサイトに「問題なく動いているならBIOSは更新しなくても良い」と書いているマザーボードメーカもあります。でもソフトウェアには必ずバグがあって、それをバージョンアップで直してます。なので、アプリケーションも、OSも、BIOSもとにかく最新版にしたいと常々思っています。ということでThinkPadのBIOSを最新版にバージョンアップしました。

上記のサイトによるとBIOSバージョンアップには次の3通りの方法があるようです。

Windowsのツールをダウンロードして起動する
CD-ROM用isoファイルをダウンロードしてCD-ROMを焼いてそれで起動する
新BIOSのデータをダウンロードしてLinuxのツールを使う

です。通常のマザーボードだと、BIOSのメニューからUSBメモリに入れた新BIOSデータを指定して更新できます。でもThinkPadのBIOSにはそのようなメニューがありません。ユーザがうっかりBIOSを書き換えられないようにしてあるのだと思います。

1番のWindowsのツールは使いません。Windowsは使わないので、入手してすぐに内蔵SSDを初期化して消してしまったからです。残しておけば良かったと若干後悔していないわけではないですが、新たにインストールするのは面倒です。

3番のLinuxのを使う方法は試しました。UbuntuのLive CDイメージをUSBメモリーに焼いて起動して、ダウンロードしたBIOSイメージを指示されたLinuxコマンドで書き込もうとしました。しかしハードウェアを認識できないというメッセージが出て、更新できませんでした。Live CDなのでダメだったのかもしれません。でも新たにインストールするのは面倒なので、断念しました。

そこで、2番目の起動CD-ROMイメージを使う方法を採用しました。ただ、CD-ROMを焼くのも、ThinkPadにUSB接続CD-ROMドライブを接続するのも面倒なので、これもUSBメモリーから起動させるようにします。手順は以下です。

BIOS更新手順

Step 1: 起動CD-ROM用isoファイルを入手する

上記のLenovoのサイトから、「BIOS アップデートユーティリティ (起動CD用)」をダウンロードします。n1cur34w.isoという名前の24.5MBのファイルを入手できました。

Step 2: isoファイルをUSBメモリイメージファイルに変換する

起動用CD-ROMのデータと起動用USBメモリのデータは多少違うようです。ブートのためのファイルの配置場所などが違うのではないかと思います。なので、isoファイルを、起動用USBメモリー用のファイルに変換します。このツールとして、geteltorito.plというツールを以下のサイトから入手します。

Index of /~krienke/ftp/noarch/geteltorito

これはperlで書かれたプログラムなのでmacOSでも動きます。これを使い、ターミナルで以下のようにタイプします。

% ./geteltorito.pl -o bios.img n1cur34w.iso

ここでは、n1cur34w.isoからbios.imgというファイルを作っています。この結果、以下のように表示され、bios.imgが生成されました。

% ./geteltorito.pl -o bios.img n1cur34w.iso 
Booting catalog starts at sector: 20 
Manufacturer of CD: NERO BURNING ROM
Image architecture: x86
Boot media type is: harddisk
El Torito image starts at sector 27 and has 47104 sector(s) of 512 Bytes

Image has been written to file "bios.img".

Step 3: imgファイルをUSBメモリーに書き込む

USBメモリーを用意します。容量は24MBあれば良いです。手元にあった8GBのメモリーを使いました。一応、マスターブートレコードスキーム、FAT32でフォーマットして、アンマウントしておきました。次にddコマンドを使うので、このようなフォーマット作業は不要だったかもしれません。

次にターミナルからddコマンドで、USBメモリーにimgファイルを書き込みます。ddコマンドはファイルシステムなどは無視して、物理的に書き込んでいくコマンドです。USBメモリの場所がdisk2でしたので、以下のコマンドで書き込みます。disk2ではなくrdisk2にしたのは、その方が少し高速らしいからです。容量が小さいので/dev/disk2でも問題ありません。

% sudo dd if=bios.img of=/dev/rdisk2

その結果、以下のような表示が出て、USBメモリーが完成します。

% sudo dd if=bios.img of=/dev/rdisk2
47104+0 records in
47104+0 records out
24117248 bytes transferred in 15.043802 secs (1603135 bytes/sec)

Step 4: USBメモリーで起動してBIOSを書き換える

このUSBメモリーをThinkPadに挿し、起動します。その際にF12を連打します。すると起動ドライブ選択画面になるので、USBメモリーを選択します。BIOSでLegacy bootに設定しなければならないというネット上情報もありましたが、UEFI bootのままで大丈夫でした。USBメモリーで起動すると、以下のような画面になります。

1.のRead this first…は一応目を通しておいた方が良いです。2.のUpdate system programを選択すると、いろいろと警告が出てから、BIOS更新が行われます。

新BIOSを試す

BIOS画面でバージョンを確認します。最新バージョンになっていました。

macOSの起動にも問題ありませんでした。BIOSが更新されたから何が良くなったというわけではないので、単なる気持ちの問題です。

苦労したところ

起動用CD-ROMデータであるisoファイルから、起動用USBメモリーデータであるimg（またはdmg) ファイルに変換する際に、hdiutilというコマンドがお馴染みでした。例えば、今回のようにn1cur34w.isoという名前のファイルでしたら、

% hdiutil convert -format UDRW -o n1cur34w n1cur34w.iso

のコマンドで、n1cur34w.dmgというファイルが出来上がります。dmgとimgは同じもののようで、改名しても良いようです。また、UDRWというのは、read/writeできる光ディスクのフォーマットのようです。こうして作った結果のファイルを、ddコマンドでUSBメモリーに書き込めば、起動USBメモリーが作れるはずです。

しかし、ThinkPadでは起動しませんでした。BIOS設定を色々試したのですがダメでした。ところがこのUSBメモリーを、ASUSマザーボードの自作デスクトップで起動したら、メニュー画面が現れます。他のisoファイルで試しましたが、同様に、自作PCでは起動するものの、ThinkPadでは起動しません。そこで色々試行錯誤して、ネットを検索したところ、ThinkPadで起動させるためには、上で使用したgeteltorito.plが使えることがわかりました。

まとめ

ThinkPad T450sのBIOSが古かった (2016年版) ので最新版 (2019年版) に更新しました。サポートサイトで配布されている起動用CDのデータを変換してUSBメモリーに書き込みました。変換には通常のhdiutilコマンドではなく、ネットで配布されていたperlプログラムを使いました。BIOSが新しくなって変化した点はありませんが、以前と同じようにmacOSが起動しています。

USB接続のHDMIビデオキャプチャを使う

Sat, 11 Apr 2020 18:59:17 +0900

HDMI端子からUSB 3.0経由でフルHD動画を取り込めるアダプターを使ってみました。USB Video Class (UVC) というUSB標準のデバイスクラスに対応しているので、macOSで（hackintoshでも）OOBで使用できます。

USB Device Class

USBの規格には、データを通信するための基本的な規格の他に、もっと上位の、使用目的別のプロトコルを決めたDevice Classという規格があります。macOSは多くのDevice Classを標準でサポートしてます。なので、様々なデバイスを、それ専用のデバイスドライバーをインストールすることなく、OOBで動かすことができます。この状況は、USBの基本的なデータ通信ができていれば、hackintoshでも同じです。なので、キーボードやマウス (HID class)、USBメモリー (Mass storage class)、USBスピーカー (Audio class)、webカメラ (Video class)などが、hackintoshでもMacと同様に、ドライバー不要で使用することができます。

USBビデオキャプチャー

HDMI端子から1080pのフルHD (FHD) 動画を取り込めるUSB Video Class (UVC) 対応ビデオキャプチャー製品が多数出回っています。これを使えばHDMI動画を、webカメラからの映像のように取り込むことができます。macOS標準機能で動画を録画したり、ゲーム配信、動画配信、ビデオ会議でHDMI映像を流すことも可能です。動画を取り込むのは、昔は結構大変でした。MacだとIEEE 1394とか使ってました。

IEEE 1394 (FireWire) を使う

でも今ならUSB が十分速いので、安価なデバイスが使えます。AmazonやAliExpressで、USBビデオキャプチャーとして販売されている製品は、大体がUVC対応なので、macOSで使用可能です。

これなどは1,599円と格安です。ただし、USB 2.0接続で、フルHDで取り込めるのは30fpsまでです。

USB 3.0接続になると値段が高くなります。その代わりフルHDで60fpsの取り込みが可能になります。さらにこれはHDMI出力もついています。

実は、1年以上前に入手したまま未開封だったこちらの製品が手元にありました。USB 3.0接続でフルHD 60fps対応の製品です。今回はこちらを使ってみました。

大きさはクレジットカードくらいの小さなアルミ製の箱です。放熱効果は良いようで、長時間使用してもそれほど熱くなりません。入出力はシンプルで、HDMI入力、USBコネクタ、LEDがあるだけです。USBが特殊で、Type-Aのコネクタがついています。本来ならばType-Bが正しいと思います。なので、両端がType-Aになった、あまり見かけない、USBケーブルが付属しています。これをmacOSマシンに接続します。

UVC規格なので、macOSからは通常のwebカメラのように認識されます。例えばPhotoBoothから見たところ、FHD Webcameraという名前で見えていて、HDMIの動画を取り込んで利用できます。FaceTime, Skype, Zoomなどのアプリケーションからも同様にこの名前で認識されています。

HDMIの音声に関しては、USB Audio Classデバイスとして機能している様子です。webカメラのマイクロフォンのような扱いです。システム環境設定–>サウンド–>入力を見ると、マザーボードの音声入力端子と並んで、FHD Webcameraという名前で見えています。

HDMI動画を撮影する

これがあれば、HDMI端子の映像ならばなんでも取り込めます。例えば、Intel NUCを起動して、BIOS設定画面を開いて再起動して、CloverでmacOSを起動する様子もキャプチャすることができます。以下の動画は、QuickTime Playerの動画取り込み機能を利用して作成した動画です。取り込んだ生データは1080pの画素数ですが、動画編集ソフトで720pに削減してあります。また起動過程の一部をカットしてあります。

BootmacOSfromNUC230a.m4v

まとめ

USB接続のHDMIビデオキャプチャデバイスを試しました。OOBで使用することができました。高性能CPUと大容量HDDを搭載した自作PCを使ったhackintoshは、動画編集や動画配信に最適だと思います。HDMI出力のゲーム機の画面も取り込めるので、ゲーム実況にも使えます。動画配信、テレビ会議などで自作hackintoshの強みを生かせると思います。

Intel NUC DC3217のiGPU画面が乱れる

Wed, 08 Apr 2020 23:20:26 +0900

初代NUC、DC3217の表示が乱れてしまいました。2個あるHDMIのうちの片方が異常で、もう一方は正常です。WhateverGreen.kextで設定フラグを同一にしたら、両方とも正常になりました。

症状

DC3217は最初に販売されたCore i搭載NUCで、Ivy Bridge Core i3-3217Uを搭載しています。GPUはIntel HD Graphics 4000です。こちらの構成です。

Intel NUC DC3217, 3217U

サーバ的に常時稼働させていて、必要な時は画面共有で接続していました。Clover r5108のアップグレードのためにディスプレイに接続したら、画面が乱れていることに気づきました。ログイン画面がこんな表示になります。横方向の画素数が正しく伝わっていない様子です。ロストテクノロジーのアナログテレビで例えると水平同期が取れていない感じかな。

いつからこうなったのか不明です。前回のClover r5107アップデートか、macOS 10.15.4へのアップデートあたりがきっかけかもしれません。また、このディスプレイはメインマシンで使っているのですが、最近起動直後に色がおかしいことがあります。NUCの問題ではなくディスプレイが不調で、設定情報EDIDがうまく送出できなくなっているのかもしれません。

ig-platform-idの決め方

ig-platform-idは0x01620005にしてあります。config.plistのDevices –> Propertiesセクションには、これのBase64値であるBQBiAQ==が設定してあり、WhateverGreen.kext (WEG)にこの値を伝えてあります。

<key>Devices</key>
<dict>
	<key>Properties</key>
	<dict>
		<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
		<dict>
			<key>AAPL,ig-platform-id</key>
			<data>BQBiAQ==</data>
		</dict>
	</dict>
</dict>

どういう理由でig-platform-idを0x01620005にしたのか、もはや記憶がありません。多分、どこかでNUC DC3217の作例を見て、真似たのだと思います。最近、ig-platform-idのことを調べたので、今なら少し説明できるかと思います。

まずは、Intel HD Graphics 4000で使えそうなig-platform-idを探します。こちらのサイトによると、以下のIDが知られているようです。

0x01660000 (desktop, 4 connectors, 24 MB)
0x01620006 (desktop, 0 connectors, no fbmem, 0 bytes)
0x01620007 (desktop, 0 connectors, no fbmem, 0 bytes)
0x01620005 (desktop, 3 connectors, 16 MB)
0x01660001 (mobile, 4 connectors, 24 MB)
0x01660002 (mobile, 1 connectors, 24 MB)
0x01660008 (mobile, 3 connectors, 16 MB)
0x01660009 (mobile, 3 connectors, 16 MB)
0x01660003 (mobile, 4 connectors, 16 MB)
0x01660004 (mobile, 1 connectors, 16 MB)
0x0166000A (desktop, 3 connectors, 16 MB)
0x0166000B (desktop, 3 connectors, 16 MB)

ここでmobileと書かれたidは、一つのビデオ端子がLVDSになっています。LVDSというのは、LCDのためのインタフェースだそうです。ノートPCを使う場合はこれのどれかを使いますが、NUCもそうですが、デスクトップ構成ではLCDインタフェースは使わないので、desktopのidから選びます。また、端子が無い (0個の) idは、ヘッドレス構成、つまりiGPUにはディスプレイを接続しないで、PCIe接続のグラフィックスカードを使う場合に使います。なので、iGPUを外部ディスプレイに接続するNUCの構成では、desktopで端子ありのidを使うことになります。つまり以下のどれかです。

0x01660000 (desktop, 4 connectors, 24 MB)
0x01620005 (desktop, 3 connectors, 16 MB) (推奨)
0x0166000A (desktop, 3 connectors, 16 MB) (推奨、default, Macmini6,1)
0x0166000B (desktop, 3 connectors, 16 MB) (Macmini6,2)

上記のサイトでは、推奨idが0x0166000A (default), 0x01620005 であると書いています。またHackintool.appでは、0x0166000AがMacmini6,1、0x0166000BがMacmini6,2であると表示されます。おそらく、SMBIOSでそれぞれのMac miniのシステムIDを設定すると、何も指定しなければそれぞれ、0x0166000Aまたは0x0166000Bが選択されるのだと思います。

選択肢が4個だけなので、これを全部試してみました。その結果、DC3217では、0x01620005 だけが使えることがわかりました。それ以外の3個では、次のような症状になります：つまり、Cloverの起動ボリューム選択画面の後の林檎マーク表示で、進捗バーが止まります。-vモードで起動すると、文字表示がIOConsoleUsers: …というような表示場所で滞ります。でも、実は表示以外は起動していて、画面共有で接続すると機能しているようでした。

ig-platform-idに0x01620005を設定するには、config.plistのDevices–>Propertiesセクションに以下のように書きます。

<key>Devices</key>
<dict>
	<key>Properties</key>
	<dict>
		<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
		<dict>
			<key>AAPL,ig-platform-id</key>
			<data>BQBiAQ==</data>
		</dict>
	</dict>
</dict>

症状をもっと調べる

0x01620005を設定することで、長らく正しく表示できていたのですが、最初に述べたように、画面が乱れるようになりました。乱れていても、画面共有で接続すると正しく動いているようです。また、起動時にディスプレイを接続せず、起動した後で接続すると正しく表示されます。先に述べたように設定情報EDID関係なのかもしれません。

さらに、もっと興味深いことを発見しました。DC3217には、2個のHDMI端子がついています。以下、左（電源端子に近い方）をHDMI(1)、右（LAN端子に近い方）をHDMI(2)と呼びます。

画面が乱れる現象は、HDMI(2)で発生します。HDMI(1)を使えば、どのタイミングでディスプレイに接続しても、画面は乱れません。実はHaswell世代のNUC D54250でも、片方のHDMIの調子が悪いことがありました。今回も同じような現象のようです。ディスプレイは1台しか使っていませんので、HDMI(1)だけを使うことにすれば、とりあえず解決します。でも、最近はig-platform-id関連の設定に凝っているので、もう少しなんとかしたいと考えました。

HDMI端子のフラグ値を合わせる

Hackintool.appで0x01620005のコネクタ設定画面を見ました。3個のコネクタの設定があります。これがおそらく端子ごとのデフォルト設定なのだと思います。ここでのコネクタへの設定結果は、config.plistを生成する場合にそれぞれ上からcon0, con1, con2というコネクタ名で反映されます。なのでスクリーンショットにそのラベルを書き込んでおきました。

コネクタは3個ともDP端子になっています。実際にはDC3217には2個のHDMI端子があります。DPからHDMIへの変更は、この画面から設定できて、それを記述するconfig.plistのDevices –> Propertiesセクションも自動生成できます。ただ、どこかで読んだのですが、WEG(?)はDPからHDMIの変換を必要に応じてやってくれるらしく、デフォルトに任せておけば良いようです。

なので、DPであることはこのままで良いようなのですが、よく見ると3個のDPでFlagsの項目が違います。con0は0x00000011ですが、con1とcon2は0x00000107です。Flagsは、その下のリストにあるように、いろいろな設定を行うビットの集まりです。意味は不明ですし、さらにもともと機能が不明 (unknown) なフラグも多いようです。ということで、端子ごとに画面が乱れる・乱れないという振る舞いが違うことは、フラグが違うことにより引き起こされていると考えました。つまりHDMI(1)とHDMI(2)のどちらかが0x00000011で、もう一方は0x00000107になっていると考えられます。ちなみに0x00000011と0x00000107の違いは、いずれもunknownフラグが違うだけなので、違いの意味は不明です。

con1を調べる

まずはcon1を0x00000011に設定してみました。Flagsのカラムに数値を入力しても良いですし、下のConnector Flags:でクリックしても良いです。

この後、Patchタブを選び、Generate Patchボタンを押すと、config.plistが現れます。この時、Generalでは、DeviceProperties, Connectors, Graphic Devicesを選びます。またAdvancedとLSPCONは何も選択しません。コネクターの設定が現れ、かつ他の余分な設定が反映されないように調整すれば良いです。

ここで得られたパッチ部分を、config.plistのconfig.plistのDevices –> Propertiesセクションにコピーして、起動を試みました。この結果、何の変化もありませんでした。con1は、使われていないコネクターのようです。

con2を調べる

次にcon2に対しても、con1とおなじFlags設定、つまり0x00000011への設定を試みました。上で作ったconfig.plistの記述で、con1のframebuffer-con1-flagsの値を、framebuffer-con2-flagsにコピーします。これでcon0, con1, con2の全てのframebuffer-conX-flagsの設定が0x00000011 (Base64表記ではEQAAAA==) になりました。このconfig.plistで起動したところ、なんとHDMI(2)からの映像の乱れが治りました。以上の試みから、

HDMI(1)はcon0である
HDMI(2)はcon2である
flagsを0x00000011にすれば画面が乱れない

ということがわかりました。

config.plistを整える

これでHDMI(1)もHDMI(2)もどちらも正常に動くconfig.plistが得られました。でもDevices –> Propertiesセクションの記述が煩雑に思います。コメントみたいな説明の項目は不要に思われます。とりあえずコメント風の設定を外すと以下になります。

<key>Devices</key>
<dict> 
	<key>Properties</key> 
	<dict>
	<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
	<dict>
		<key>AAPL,ig-platform-id</key>
		<data>BQBiAQ==</data>
		<key>framebuffer-con0-busid</key>
		<data>BQAAAA==</data>
		<key>framebuffer-con0-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con0-flags</key>
		<data>EQAAAA==</data>
		<key>framebuffer-con0-index</key>
		<data>AgAAAA==</data>
		<key>framebuffer-con0-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con0-type</key>
		<data>AAQAAA==</data>
		<key>framebuffer-con1-busid</key>
		<data>BAAAAA==</data>
		<key>framebuffer-con1-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con1-flags</key>
		<data>EQAAAA==</data>
		<key>framebuffer-con1-index</key>
		<data>AwAAAA==</data>
		<key>framebuffer-con1-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con1-type</key>
		<data>AAQAAA==</data>
		<key>framebuffer-con2-busid</key>
		<data>BgAAAA==</data>
		<key>framebuffer-con2-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con2-flags</key>
		<data>EQAAAA==</data>
		<key>framebuffer-con2-index</key>
		<data>BAAAAA==</data>
		<key>framebuffer-con2-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con2-type</key>
		<data>AAQAAA==</data>
		<key>framebuffer-con3-busid</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con3-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con3-flags</key>
		<data>QAAAAA==</data>
		<key>framebuffer-con3-index</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con3-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con3-type</key>
		<data>AQAAAA==</data>
		<key>framebuffer-patch-enable</key>
		<data>AQAAAA==</data>
	</dict>
	</dict>
</dict>

変更したいのはcon2のflagsに関する設定だけで、あとはデフォルトで良いはずです。このconfig.plistは自動生成されたので、デフォルト値もそのまま書き込まれているようです。ということで、con2のflagsと、共通と思われる項目を除いて、以下のような記述にしました。これ以上、設定を削除すると画面乱れが復活します。なので、これがflagsを変更するための必要最小限の記述項目だと思われます。

<key>Devices</key>
<dict>
	<key>Properties</key>
	<dict>
		<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
		<dict>
			<key>AAPL,ig-platform-id</key>
			<data>BQBiAQ==</data>
			<key>framebuffer-con2-enable</key>
			<data>AQAAAA==</data>
			<key>framebuffer-con2-flags</key>
			<data>EQAAAA==</data>
			<key>framebuffer-patch-enable</key>
			<data>AQAAAA==</data>
		</dict>
	</dict>
</dict>

config.plistの全文は以下に置いておきます。いつものように、シリアル番号は実機とコンフリクトしないことを確認してあります。このままで動作するはずですが、実際に使用する場合は、シリアル番号、UUIDを設定し直してください。

config.plist for NUC DC3217IYE - Pastebin.com

まとめ

初代NUCのDC3217の2個のHDMI端子のうち、片方の端子で画面の乱れが発生しました。Hackintool.appで調べてみると、端子ごとにフラグのデフォルト値が異なっていました。画面が乱れる端子のフラグを、正常に表示される端子のフラグと同じになるよう設定することで、画面が乱れなくなりました。

ディスプレイはどうせ1台しか使わないので、画面が乱れるHDMIポートを封印するだけでも良かったです。でも使わないポートでも、動くように設定できると気持ちが良いです。こういう作業が楽しいと感じられないと、hackintoshは面倒くさいだけかもしれないですね。

HPの小型デスクトップELITEDESK (3: USB設定)

Thu, 26 Mar 2020 23:16:29 +0900

HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)のUSBを設定しました。使わないポートを除外して15個以内に収めます。Cloverの起動オプションで除外しても良いですし、SSDTを作っても良いです。

HPの小型デスクトップEliteDesk (1: macOS導入)

前回、このマシンにmacOSをインストールして、オーディオを設定しました。でもmacOSがUSBを15個に制限している関係で、USB 3.1ポートが全てUSB 2.0として稼働する状態でした。この続編では、USBが正しく見えるように設定を行います。USBポートの設定方法は、こちらのZ390、B360チップセットマザーボードの記事もご覧ください。

15個制限を回避するUSBInjectAll.kextの役割と使用法

MSI B360M MORTAR TITANIUMのUSBポートを設定する

USBポートの観察

HP EliteDesk 800 G2 DMには、前面パネルに3個、背面パネルに4個のUSBポートがあります。詳細は、こちらのスペック表でも確認できます。USBは全部3.1 Gen 1だそうです。ちなみにマザーボードのチップセットはQ170です。

前面パネルには、向かって左から右に、

USB 3.1 Type-C 【Type-C】
Type-A SS表示、稲妻表示【前面SS稲妻】
Type-A SS表示【前面SS無印】

の3個のポートがあります。SSの表示はSuper Speedの略で、USB 3.1であることを示しています。後のチェックでわかりやすいようにカギカッコ【】で示した名前をつけました。稲妻マーク付きポートは、USB充電に適しているという意味だと思います。供給電流量が強化されているのか、もしくは電源OFF状態でも5V供給されているのかもしれません。

背面には、同じく左から、

Type-A SS表示が2個【背面SS上】【背面SS下】
Type-A キーボード表示が2個【KBD上】【KBD下】

があります。キーボード表示のポートにはSSの表記が無いのですが、これも3.1です。

前面・背面パネルの他に、マザーボード上の無線接続用M.2コネクタにも、1本USB 2.0が出ているはずです。M.2無線カードがBluetoothの接続に際して、M.2コネクタのUSB端子を使用します。以下ではM.2コネクタに出ているはずのHSポートを【M.2のHS】と呼びます。

HS (High Speed)ポートを調べる

まずはUSBInjectAll.kextだけを入れて、IORegistryExplorer.appを起動します。次に、ウィンドウの右上にある拡大鏡アイコンのついた検索窓にxhcとタイプします。すると以下のようになりました。

USB 2.0であるHSが14本見えています。こんなに多数のポートを使っていませんので、USBInjectAllのデフォルトでこう解釈されているのだと思われます。SSもあるはずなのですが、HSが多すぎて15個制限のためにSSは見えていません。このため、USB 3.1ポートに含まれるUSB 2.0ピンしか機能しなかったのです。

HSは全て見えているので、最初にHSとUSBポートの関係を調べます。そのために、USB機器をポートに接続します。USBポートにデバイスを接続するとIORegistryExplorerのport-statusの数値が変化するので、これで位置関係が分かります。USBメモリーを使うと、抜き差しのほかにアンマウントする必要があるので、キーボードのドングルのようなデバイスの方が楽です。【M.2のHS】を探すためには、マザーボード上のM.2ソケットに無線ユニットを挿します。今回は、余っていたmacOS非サポートのインテルWiFiカードを挿しました。この結果、各項目とUSB 2.0ポートの関係が分かりました。ここで発見できなかった不明なHSは多分未使用です。

HS01 2.0 3.1 Gen 1【背面SS上】
HS02 2.0 3.1 Gen 1【背面SS下】
HS03 2.0 3.1 Gen 1【前面SS稲妻】
HS04 2.0 3.1 Gen 1【KBD下】
HS05 2.0 3.1 Gen 1【KBD上】
HS06 （不明）
HS07 2.0 3.1 Gen 1【M.2のHS】
HS08（不明）
HS09 2.0 3.1 Gen 1【Type-C】
HS10 （不明）
HS11（不明）
HS12（不明）
HS13 2.0 3.1 Gen 1【前面SS無印】
HS14 （不明）

SS (Super Speed) ポートを調べる

次に、今は見えていないSSポートを調べることにします。そこでUSBInjectAllの機能を使ってHSポートを一時的に無効にします。全部のHSポートを無効にすると、キーボード・ポインティングデバイスが使えないので、HS01だけは生かしました。また元から不要なUSR1, USR2も無効にします。このために、Cloverの起動オプションを以下にしました。

<string>-v uia_exclude=HS02;HS03;HS04;HS05;HS06;HS07;HS08;HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2</string>

この結果、IORegistryExplorerの様子は以下のようになりました。

SSが10個見えるようになりました。HS01を加えて全部で11個あります。15個制限以下ですので、SSはこれで全てだと思われます。そこで今度は、USB 3.1のUSBメモリーを使って、IORegistryExplorerの反応を調べました。その結果、以下のように割り当てられているようです。

SS01 3.1 Gen 2【背面SS上】
SS02 3.1 Gen2 【背面SS下】
SS03 3.1 Gen 1 【前面SS稲妻】
SS04 3.1 Gen 1 【KBD下】
SS05 3.1 Gen 1 【KBD上】
SS06 3.1 Gen 1 【Type-C】（逆挿しも同じ）
SS07 （不明）
SS08 3.1 Gen 1【前面SS無印】
SS09 （不明）
SS10 （不明）

これも不明の番号は多分未使用です。SS01からSS05まではSSとHSで同じ番号になっています。でもSS06とSS08は微妙にずれています。実際のパネルに合わせると以下になります。

以上から、未使用のポートを全て除外するためには、起動オプションに以下の設定を行えば良いことになりました。

<string>-v uia_exclude=HS06;HS08;HS10;HS11;HS12;HS14;USR1;USR2;SS07;SS09;SS10</string>

この結果、以下のように必要なポートが見えるようになりました。存在しているポートの数がちょうど15個ですので、macOSの個数制限で諦めなければならないポートはありません。

USBを設定するSSDTを作る

こちらで説明したように、Clover起動オプションを使うよりも、USBを設定するSSDTを作成して、使用すべきポートを指定するやり方がより正しいようです。USBポートの素性を正しく記述できるので、macOSの動きがより正しくなるはずです。詳しくは該当記事を見てください。この作業で必要な情報は、USBコントローラのdevice-idです。HP EliteDeskが使っているQ170の場合、vendor-idが0x8086で、device-idが0xa12fです。0x8086はインテルの番号ですので、インテルのチップセットを表しています。これらの数値はIORegistryExplorerでXHCの項目の中で発見できます。またファインダーで、「アップルメニュー」「このMacについて」「システムレポート」と進み「システム情報」を開き、このUSBの項目にも書いてあります。

そこで、先の記事で紹介したお手本amlファイルから、”8086_a12f”と書かれた”Package”の定義だけを残して、他のPackageの定義を削除します。残すのは以下の項目です。

"8086_a12f", Package()
{

...........

},

この中にはHS01からSS10までのUSBの情報が書かれています。これに対してコネクタの情報を実際に合わせて変更していきます。UsbConnectorの値は、

0: USB 2.0のコネクタ
3: USB 3.1のコネクタ。3.1に付随するUSB 2.0も3にします。
255: 内部接続で外部に接続しないコネクタ。マザーボード内部でBluetoothユニットに接続しているなどの場合にこれを使います。マザーボード上のコネクタで外部に引き出す可能性のあるものは0または3にします。
9: USB Type-Cのコネクタ。逆挿しにしてもSSの番号が変化しない場合。内部でハブに接続されているらしいです。
10: USB Type-Cのコネクタ。逆挿しするとSSの番号が変化する場合。個別に接続されています。

を表しています。上で調べた内容を反映すると、以下のようなファイルになりました。

SSDT-UIAC.dsl for Q170 motherboard in HP EliteDesk 800 G2 DM - Pastebin.com

これをMaciASLで開きます。次に、MaciASLのFileメニューからSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_excludeを指定しなくても、実存するポートのみが有効になるはずです。IORegistryExplorerで確認すると以下のようになりました。上で、Clover起動オプションで設定した場合と同じ結果です。

HackintoshでVirtualBoxを使う

Sun, 08 Mar 2020 22:44:24 +0900

久々に仮想環境のVirtualBoxでWindowsを起動しました。ついでにmacOSも動かしてみました。仮想マシンを動かすためにはBIOSでVT-xを有効にする必要があります。今回使用したASUS Z390マザーボードではVT-xはデフォルトで無効でした。

macOSで動くVMアプリ

「macOSだけで生きていけます」と言い切りたいところですが、たまにWindowsが必要になります。WindowsからしかアクセスできないWebサイトがあります。また、AliExpressなどから怪しいIoTデバイスを買うと、設定ソフトがWindows版だけのこともあります。なので3ヶ月に1回くらいWindowsが必要になります。マシンの性能を100%引出したいのでしたらマルチブートを設定すると良いです。こちらをご覧ください。

Windowsと同居する

でも、ほんの少しだけ利用するなら、仮想マシン(VM)で動かすのが楽です。再起動しなくても良いですし、macOSと一緒に動かせます。macOS上のVMアプリケーションにはご存知のように、

Parallels（有料）
VMWare Fusion（有料）
VirtualBox（無料）

があります。数年くらい前まではしばらくParallelsを使ってました。性能や機能の点からは、有料製品の方が良いです。でも、OSに深く関与しているVM製品はmacOSのバージョンアップに揃えてアップデートする必要があります。なので、毎年のようにアップデート料金がかかり、意外とコストがかかります。少ししか使わないなら、VirtualBoxで十分だと思います。ということで、最近はVirtualBoxを使わせていただいてます。

追記：最近VMWare Fusionが無料になったらしいです。コメントで教えていただきました。

個人なら無償インテルMac用仮想環境アプリ「VMware Fusion Player 12」レビュー (…

VirtualBoxをインストールする

VirtualBoxはOracleのサイトから無料でダウンロードできます。こんな素晴らしいソフトウェアを無料で配布してくれるなんて素晴らしいです。

パッケージには、アンインストールのスクリプトも入っています。今回、以前インストールした古いバージョンが動かなくなってました。そこで、まずはアンインストーラを動かして、古いバージョンを除去しました。次に、VirtualBox.pkgを起動してインストールします。

Catalinaになってセキュリティが厳しくなったのか、インストールと起動を阻む色々な罠がありました。基本的には指示に従って、「システム環境設定」の「セキュリティとプライバシー」を開き、セキュリティ設定を緩めていけば良いです。

VT-xを有効にする

VirtualBoxのインストールが終わったら、VMを作って起動です。まずはWindowsを動かすための仮想環境を作って起動しようとしました。そしたら、

のようなエラーが出て開きません。メッセージを見ると「BIOSでVT-xが無効に設定されている」のが原因のようです。MacユーザがBIOSの設定と言われても訳が分からないでしょう。おそらく本物のMacでは出ないメッセージなのだと思います。Windows版のVirtualBoxと同じメッセージを用意しているだけなのかもしれませんが、これを用意したプログラマーは、hackintoshのことが頭の片隅にあったのかもしれません。エラーメッセージ通りだとすると、BIOSでVT-xを有効に設定すれば良いことになります。

今回使用した、ASUS ROG MAXIMUS XI HERO (Z390) のBIOSでVT-xの設定を探しました。Advancedの中のCPU Configurationの中に、Intel (VMX) Virtualization Technologyという名前で設定項目がありました。VTがVirtualization Technologyの略だと知ってないと、見つけにくい設定項目です。しかもこの設定は、デフォルトでは無効でした。VirtualBoxの方の設定でVT-xを使わないこともできるのかもしれませんが、macOSの動作には影響無いので、BIOSで有効にしておきます。これで無事VMが起動するようになりました。

VMでWindowsを動かす

大昔に購入したWindows 10インストール用DVDイメージファイルがありましたので、これを仮想光学ドライブに設定して、Windows 10をインストールしました。特に問題なく動きます。SSDの上にVMファイルを作ったおかげかと思いますが、割と高速に動きます。ネットへの接続やIoT機器程度の用途でしたら問題ありません。

ネット接続やUSB関係は、macOSが管理しているEthernet, WiFi, USBポートを、VirtualBoxが頑張って中継してくれているので、ゲストOSからもアクセスできます。なのでネットやUSB経由で接続する機器なら問題なく扱えます。一方で、標準化されていないインタフェースで接続するハードウェアはVM上のWindowsからアクセスできません。端的な例が、前回紹介したマザーボードのスプラッシュ画面の設定です。ここで使ったASUSのユーティリティは、マザーボード搭載のASUS独自インタフェースにアクセスするので、VMのWindowsから設定することはできません。BIOSアップデートツール、オーバークロックツールなども無理なのではと思います。

VMでmacOSを動かす

VirtualBoxではmacOSのVMを作成することもできます。メニューを見ると、macOS一般設定の他に、Snow Leopard, Lion, Mountain Lion, Mavericks, Yosemite, El Capitan, Sierra, High Sierra用の設定が用意されています。MojaveとCatalinaはメニューに無いので、もしかしたらAPFSの関係などで難しいのかもしれません。

手元にSnow LeopardのDVDがあるのでインストールを試しました。MacユーザやMobileMeユーザに無料配布されていた非売品DVDです。Snow Leopardを最後にDVDでの配布が終了し、ダウンロード配布に移行したので、古いmacOSを使用している人のためにこのDVDは長らくAppleのオンラインサイトで販売されていました。でも今回チェックしたら販売終了していました。

このインストーラを起動するために、まずはSnow Leopard用のVMを作成します。

光学ドライブをVMに割り当てて、Snow Leopard DVDをセットしてVMを起動します。すると懐かしい壁紙でインストーラが起動しました。

この後は、いつものようにインストールを進めます。無事Snow Leopardが起動しました。macOSバージョンがわかりやすいように、デフォルトの宇宙壁紙から、雪豹壁紙に変更しました。古いmacOSが動くVMを用意しておけば、昔のアプリケーション、特に32bitアプリケーションを動かす必要に迫られた時など、便利かもしれません。

まとめ

VirtualBoxをインストールして、Windows 10とSnow Leopardを動かしてみました。OSに関与するアプリケーションということもあり、セキュリティ設定変更がいくつか必要でした。また、BIOS設定でVT-xを有効にしておく必要がありました。

マザーボード起動スプラッシュ画像をMac風に変更する

Sat, 29 Feb 2020 17:22:41 +0900

起動時にマザーボードBIOSが起動するロゴマークを、本物Mac風に変更しました。ASUSのROGシリーズZ390マザーボードなので、ブート時に下のような画面が現れます。これを、上に示したようなAppleマークにしました。変更にはWindowsのツールを使用しました。

システムやアプリが起動する時に現れる画面をスプラッシュ (splash) 画面と呼びます。アプリ画面に「突入」する直前に現れる画面だからなのだと思います。本物のMacでは、電源投入直後のスプラッシュ画面に黒字に白のAppleマークが表示されます。昔の機種では、グレー地に黒いAppleだった気がします。一方で、一般的なマザーボードではマザーボードブランドのロゴが表示されます。ASUS ROGシリーズでは多少控えめな上のようなロゴが表示されますが、一般的にはかなり派手です。簡単に変更できるものならシンプルなAppleロゴに変更したいと思っていました。

macOSだけで変更する

Windowsのツールを使えば簡単に変更できるらしいと知っていたのですが、できればWindowsを使わないでなんとかしたいと思っていました。そんな時、Redditに解説が投稿されていたのを発見しました。

r/hackintosh - [GUIDE] How to create your own BIOS Splash Page with new custo…

この投稿者はASRock Z390ボードで試したところ成功したらしいです。でも結論から言うと、ASUS ROG Z390では簡単ではなかったです。以下で、この方法を簡単にご紹介します。

UEFIToolを入手する

UEFIToolというツールでBIOSイメージを変更できます。このツールをダウンロードします。Hackintoshコミュニティでお馴染みのvit9696さんもフォークしているようで、なんとmacOS版もありました。以下から、UEFITool.appをダウンロードします。

Releases · LongSoft/UEFITool

BIOSのイメージを読み込む

次にUEFIToolを起動して、マザーボードのBIOS ROMファイルを読み込みます。今回は、ASUSのサイトから入手したROG-MAXIMUS-XI-HERO-WIFI-ASUS-1401.CAPという名前のファイルを使いました。読み込みが終了すると、以下のような表示になります。

下のメッセージ欄に、「BIOSイメージを加工するとAptio カプセル署名が無効になります」という警告が出ています。後でこれが問題になりました。

現在のスプラッシュ画像を確認する

ROMファイルが読み込めたら、現在のスプラッシュ画像の場所を確認します。そこで、File–>Searchメニューを開いてSearchダイアログを開きます。GUIDタブを選択し、7BB28B99-61BB-11D5-9A5D-0090273FC14Dを検索します。

UEFIToolウィンドウの下部のMessageウィンドウに、「GUID pattern “7BB28B99-61BB-11D5-9A5D-0090273FC14D” found as …」という表示が出るはずです。これの一つをダブルクリックすると、BIOSスプラッシュ画像が保存されているセクションが表示されます。

今回、3箇所見つかりましたが、一つだけが下位階層のあるFileでした。これしか開くことができないので、この検索結果をダブルクリックしました。この中のRaw Sectionがスプラッシュ画面のようです。これを選択して右クリックします。Extract Body…を選択します。

ここでファイル名を指定すると（今回はROGという名前にしました）、ファイルタイプがrawのファイルが作られます。プレビューで開くこともできて、以下のように現在のスプラッシュ画面であることが確認できました。

新しい画像に差し替える

新しい画像を用意します。画像は、1024×768画素 (72または96dpi) 以下が良いとか、1MB以下が良いなどのサイズ上限があるようです。50 ~ 100KBくらいが良いのではとのことです。今回は、Cloverテーマの一つのMinimalismからファイルをいただいてきました。ファイル形式は、jpegやpngやtiffなどが使えるそうです。raw形式でなくてもUEFIToolが自動的にrawに変換してくれるようです。先程の右クリックのメニューからReplace body…を選べば差し替えることができます。

画像を差し替えたら、いったん保存します。そしてUEFIToolで再度開き、先程のように7BB28B99-61BB-11D5-9A5D-0090273FC14Dを検索し、新しい画像に差し替えられているかを確認します。今回用意したpngとtiffのアイコンと、変更したBIOSファイルから取り出したrawのアイコンを示します。

こうして作成した新しいBIOSファイルにアップデートすれば良いのですが、ASUS ROG Z390ではダメでした。BIOSのアップデートツールEzFlashで、”Selected file is not a proper BIOS!”というメッセージが出てしまいます。

おそらくは上で書いたように、ファイルの署名情報が狂ってしまったことが原因だと思います。いろいろ検索したら、改造BIOSをインストールする方法もあるようです。UEFIツールだけを使ってできるようです。ただ複雑な手順が必要で、またセキュリティ機能を外して行う作業なため、面倒で危険な作業のようです。スプラッシュ画像を差し替えたいだけのためにそこまでやるのは割りに合わないと思いました。

Windowsのツールで変更する

ということで、仕方なくWindowsを使うことにしました。操作も不慣れなのであまり使いたくなくて、Windowsはもう何ヶ月も起動していません。久々に起動したら、更新項目が多数溜まっていて、起動するだけでも大変でした。使用するツールはASUS AI Suite 3です。この中にEZ UpdateというBIOSアップデートの機能があり、これを使います。ネットでも配布されていますが、マザーボード付属のDVDからインストールしました。アプリをインストールするだけなのに、何度か再起動させられたのですが、Windowsってこんなものでしょうか？ASUS AI Suite 3のメニューの中からEZ Updateを起動し、BIOSファイルを指定したBIOSアップデートをします。

ここではバージョン1401を選んでいますが、マザーボードはすでに1401になっているのでもう一度上書きすることになります。BIOSファイルを指定すると、右下のMyLogoのボタンが選べるようになります。これを選択すると、

新しいスプラッシュ画像を選択できるようになります。上で紹介したCloverテーマのMinimalismのアイコンをそのまま使うと、少し巨大過ぎました。UEFIToolで取り出したオリジナルの画像があれば、それを元に、消したり重ねたりして調整すると目指す大きさで表示されると思います。画像設定後、再起動になり、BIOSがアップデートされます。いつものBIOSアップデート作業と同様に、CMOS設定もクリアされるので、USBメモリーなどにバックアップしておくと再設定が楽です。

GIGABYTEのガイド

ここまではASUSのマザーボードの話でした。GIGABYTEに関するコメントをいただいたので調べてみたら、こちらにGIGABYTEマザーボードのスプラッシュを変更する方法が書いてありました。GIGABYTEが配布しているWindows用ツールを使う方法と、（なんと！）macOSユーザ用にUEFIToolを使う方法が説明してありました。

まとめ

ASUS ROG Z390マザーボード起動時の画像を白いAppleマークに書き換えました。UEFIToolを使用するとBIOSの書き換えが出来、これを使ってスプラッシュ画像も変更できます。ただメーカの署名が無効になり、アップデートが非常に困難だとわかりました。そこでやむなくASUSが配布しているWindows用ツールを使用しました。久々に慣れないWindowsを起動して大変でしたが、作業自体は簡単でした。Macのようなシンプルな起動画面になりました。だからと言って何も変わらないのですが、再起動してはニヤニヤしています。

MacBookと自作HackintoshをType-Cで接続する

Sat, 15 Feb 2020 01:39:41 +0900

現行の300シリーズマザーボードの大半にUSB Type-Cが搭載されています。これをMacBookと接続すれば、ある程度の充電とデータ交換が可能です。充電電圧をUSBテスターで確認しました。データ交換は、MacBookのターゲットディスクモードが使えました。

Type-Cコネクタに関してはこちらの記事で詳しく紹介しましたので、こちらもご覧ください。

USB 3.1とType-Cコネクタ

充電

パワーデリバリー

Type-Cで導入された新機能の一つがPD (Power delivery パワーデリバリー) 機能です。従来のUSB-Aコネクタなどでも5Vの電源を供給していて、電力供給したり充電したりしていました。これをさらに強化したのがPD機能です。PDでは大容量の電力を供給します。電流を増やせば電力は上げられますが、銅線に流せる電流量には上限があります。なのでPDでは、必要に応じて電圧を上げて、同じ電流でより多くの電力を供給する工夫がされています。そのために信号線を使って送電側と受電側で何ボルトに対応しているのかネゴシエーションします。最終的には20Vまで電圧を上げて、最大で5Aまでの電流を流します。これで最大100Wもの電力を供給します。下が、電圧と電流の組み合わせです。例えば30Wの電力供給をする場合は15V2Aで動作します。

USBテスター

従来は、USBといえば5Vを供給する規格だったのですが、PDにより様々な電圧が出てくることになります。これはぜひとも確認したいと思いました。そこで、USB Type-Cの電圧と電流を測定するUSBテスターを手に入れました。いつものAliExpressです。多種類のコネクタに対応していて、カラー表示で、この価格（執筆時点で送料込859円）はすごいと思いました。

いろいろなピンの電流・電圧が測定できて、さらには指定した電圧・電流になると警告音がなるようです（使わないですが）。まずはMacBookを30Wアダプターに接続して測定してみました。

電圧は19.8Vで電流が1.39Aです。27.5Wでした。MacBookの電池の充電状態によって電力は変動するようです。なおこのテスターの表示モードは数種類に切り替えられますが、ここでは電流線の電圧・電流が大きく表示される表示モードを使っています。

マザーボードから充電

では、いよいよMacBookをマザーボードのType-Cに接続してみます。マザーボードは、こちらのビルド例で紹介したASUS ROG MAXIMUS HERO WIFIです。

4.26V, 2.53Aで、10.8Wです。MacBookからは最大限の電力を受け入れようとしているけど、マザーボードのType-Cコネクタは5Vを超える電圧は供給してくれないようです。以前の記事で紹介しましたように、マザーボードのType-Cに接続したのではなかなか充電できない（数時間かかる）様子がここからもわかるかと思います。

データ転送

ターゲットディスクモード

Macに搭載された伝統的な機能に、ターゲットディスクモード(TDM: Target Disk Mode)があります。電源起動時にキーボードのTを押しているとTDMモードに入り、Macがハードディスクとして機能します。SCSI端子があった時代には、TDMによりMacの内蔵ドライブがSCSIハードディスクとして機能しました。FireWire (IEEE 1394)が搭載されていた時代にはFireWireドライブになりました。現在の機種はThunderboltが搭載されているので、TDMによりMacがThunderboltドライブとして機能します。SCSIもFireWireもThunderboltも、接続された機器同士が対等でした。TDMは、接続機器のどれもがコンピュータ側にもドライブ側にもなれる規格だったからこそできた機能です。つまり、Macを通常のように起動すれば他を制御するコンピュータ側になりますが、TDMで機能すれば、他のコンピュータから制御されるドライブ側になれるのです。

ところが従来型USBはコンピュータ側とドライブ側がハード的に固定でした。そもそもキーボードとマウスを接続するために考えられた規格なので仕方ないです。コンピュータ側はType Aのコネクタを持ち、ドライブ側はType Bのコネクタを持ちます。反対の関係で接続することはできないので、TDMを機能させることができません。なので、SCSIもFireWireもThunderboltも持たないMacはTDMが機能しませんでした。

でも、USB Type-Cは特別な新型USBです。コネクタ形状は1種類しかなくて、コンピュータ側もドライブ側も同じ形状です。接続された機種それぞれがネゴシエーションして、誰が制御側になるかを決められます。なので、USB Type-Cを備えていて、尚且つType-Cを使ったThunderboltを搭載していないMacは、TDMによりUSB規格のドライブになることができます。手元にありましたMacBook 2017はこのタイプのレアものMacで、TDMによりUSB Type-C接続のドライブとして機能します。

MacBookをTDMで起動

そこでMacBookをTDMで起動しました。Tキーを押したまま電源を入れるだけです。macOSのバージョンによっては、システム環境設定から起動ディスクを選ぶことでも、ターゲットディスクモードで起動できます。

ちなみに上の図は、Hackintoshのスクリーンショットです。IEEE 1394カードを接続していたので、このダイアログが出たようです。このように、HackintoshでもTDMの選択肢が現れる場合もあります。でもこれを選んでもTDMでは起動しません。TDMはmacOSの機能ではなく、Macのファームウェアが実現する機能（自作PCだとBIOSやUEFIの機能）なので、Hackintoshでは動きません。

TDMになるとMacの画面は真っ暗な背景になり、接続コネクターを示すアイコンが浮遊するように表示されます。今回のようにUSB Type-CのドライブとしてTDM起動すると、USBのロゴマークが画面に現れます。

TDMでデータ転送

この状態で、MacBookと上記のZ390マザーボードHackintoshをUSB Type-Cケーブルで接続します。すると、ファインダーにMacBookのドライブがマウントされます。今回はMacBookでFileVaultを設定してあったので、パスワードを聞かれました。

その結果、Hackintoshのデスクトップに、MacBookのドライブ内容が、リムーバブルであることを示すオレンジ色アイコンで現れました。

これを開けば、どのファイルにもアクセス可能で、読み書き自由です。余談になりますが、TDM可能な本物Macを持ち運んで使用するならば、ぜひともFileVault指定しておくべきだと思いました。盗難にあってTDM起動されたら、中身を閲覧されまくりです。検索したらこちらの記事などでも、TDMが危ないからFileVaultした方が良いと書いてありました。またFileVaultを使う方法以外に、Firmware passwordを設定するという手段もあるようです。ただFirmware passwordは簡単に回避できるのであまり当てにできないようです。

TDMの速度測定

便利なTDMですが、データ転送速度はそれほど高くありません。

60MB/s前後ですので、ざっくり600Mbps程度のようです。システム情報を見ると、接続自体は5Gbpsで接続されているようではあります。接続速度の1/10程度しか出ていません。TDMのオーバーヘッドが大きいようです。

ちなみにMacBookのUSB Type-CはUSB 3.1 Gen1なので5Gbpsなのです。Gen2ならば10Gbpsなのに、そこも残念ポイントです。

Type-Cのケーブル

MacBookのType-Cのもう一つの残念なポイントは、付属しているケーブルがなんとUSB 2.0であることです。何を言っているのかわからないかもしれませんが、Type-Cのケーブルだけど、中のUSB 2.0のケーブルしか接続されていないのです。これを使ってデータ接続すると、上記のベンチマーク結果 (60MB/s) のさらに1/10くらいの結果になってしまいます。MacBookに付属のケーブルは、充電を目的としたケーブルであり、データ転送はおまけ程度なのです。

このようにType-Cのケーブルはいろいろなものがありますので、注意が必要です。MacBook付属のケーブルはUSB 2.0接続でしたが、さらには電源だけしか接続されてないケーブルも世の中にはあるかもしれません。またUSB 3.1が接続されてはいてもGen 1速度用(5Gbps)であってGen 2の速度 (10Gbps) には対応していない可能性もあります。銅線ケーブルにとって10Gbpsは、物理法則の限界に挑戦する周波数です。良い素材を使って高速通信を前提に設計された製品でない場合は、額面通りの性能が出ません。Gen 2だけでなく、Thunderbolt 3 (40Gbps) やDisplayPortモードで使用する場合も、規格通りの性能の出るケーブルを選ぶ必要があります。大体は価格で見当がつきます。

AliExpressで300円くらいで売られているType-Cケーブルは、PDは機能するもののデータ転送はUSB 2.0です。PDにも対応して10Gbpsの性能も出るケーブルは1,000円程度します。例えば、AliExpressで300円くらいで売られている以下のUSB2.0接続ケーブル、

と900円くらいの以下のUSB3.0接続ケーブル

を比較してみました。どちらもPDの性能は60Wのようです。接続状態を比較すると、以下のように、ケーブルの違いで10Gbps接続になったり480Mbps接続になったりと、違いが出ることがわかります。

ただ高速通信対応のType-Cケーブルは、高価なだけでなく、太く、硬く、短いため取り回しが不便です。充電にしか使わない、低速通信にしか使わないならば、あえて安価な低速ケーブルを選ぶのも良いかと思います。

まとめ

自作HackintoshをMacBookとUSB Type-C接続しました。供給電圧は5V止まりで十分な電力は供給されませんでした。MacBookをTDMで起動すると、ドライブの内容をHackintoshから自由に読み書きできました。速度はあまり出ませんでしたが、ちょっとしたデータの交換に便利かもしれません。

手元にあるHackintoshはどれもThunderboltが付いていません。なので、ThunderboltコネクタでのTDMが起動するMacでの動作は確認できません。でもIEEE 1394カードはつけてあるので、FireWire方式TDMが起動する古いMacでならデータ交換できるかもしれません。

SATA接続HDD/SSDのホットプラグ（改訂版）

Tue, 11 Feb 2020 17:15:22 +0900

SATA接続HDD/SSDのホットプラグに関する以下の記事をアップデートしました。最近のmacOSバージョンでホットプラグが効かなくなっていたのですが、コメントでパッチを教えていただき、快調に動くようになりました。

SATA接続HDD/SSDのホットプラグ

300シリーズマザーボードでも本物のNVRAMを使いたい

Wed, 22 Jan 2020 23:43:17 +0900

現行の300シリーズチップセットマザーボードでは、macOSがNVRAMにアクセスできない問題があります。NVRAMが使えないと設定が保存されないだけでなく、シャットダウンやスリープの動作にも支障が出ます。そのためにEmuVariableUefi.efiを使って、NVRAMをソフトウェアエミュレーションする必要がありました。NVRAM問題を、エミュレーションを使わずに、根本的に解決するSSDTがRedditで紹介されていました。

このSSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れてみました。その結果、ASUS ROG MAXIMUS XI HERO (Z390)マザーボードのNVRAMが使えるようになりました。MSI B360M Mortar Titaniumでも試しましたが、同じ方法でNVRAMが使えるようになりました。

EmuVariableUefi.efiのエミュレーションは優秀で、ちゃんと動作して何の問題もありませんでした。でも、本来のNVRAMが使えると気分が良いです。たとえば、SSDT-PMC.amlを使った結果、以下のnvramコマンド

% sudo nvram hoge=test

で試験的に設定したパラメータが、システム終了・再起動後に確認すると、

% nvram -p | grep hoge
hoge	test

のように、電源を切っても保存されていた様子が確認できました。EmuVariableUefi.efiを使って動かしていた時には、保存されませんでした。これができなくてもmacOSの動作には関係ない様子ですが、何らかの機能で互換性が上がったかもしれないです。

追記：コメントで教えてもらいましたが、NVRAMが動くようになると、config.plistのBootのセクションで起動ドライブを設定するときの、LastBootedVolumeの設定が動くようになります。

以下はReddit投稿の抄訳です。

r/hackintosh - NVRAM for all! 300 series users rejoice!

OpenCoreパッケージの最新更新では、SSDT-PMC.dslという新しいSSDTが追加されました。このSSDTは、B360、B365、H310、H370、Z390用のNVRAMを復活させてくれます。

そもそもなぜ、300シリーズマザーボードのNVRAMは壊れているのでしょうか？とても簡単です。ACPIの中で、MMIOとしてファームウェアチップを宣言することを、**Intelが「忘れた」**のです。そのため、XNUはUEFIメモリマップで宣言されたMMIO領域を無視します。そしてマップされていないページアクセスによってNVRAM SMMページフォルトが発生してしまうのです。

このSSDTの使い方

使い方は簡単で、設定不要で入れるだけです。OpenCoreに縛られていないため、Cloverユーザーも使うことができます。このDSDTにはLPCBが必要ですが、Z390ではこれが非常に一般的であることに注意してください。PCI0.LPCBを検索すれば確認できます。（訳注：この意味がよく理解できないのですが、おそらくDSDTのDevice (PCI0)の項目の中に、Device (LPCB)の定義がされていることが必要という意味だと思います。MaciASLを起動するとデフォルトのDSDTが開くので確認できます。）

（訳注：このあと、macOS, Windows, Linuxでdslのコンパイル方法が説明されています。MaciASLの使い方についてはこちらをご覧ください。）

ファイルがコンパイルされると、SSDT-PMC.amlが得られます。コンパイルされたバージョンであるため、拡張子は重要です。dslは単なるソースコードです。SSDTを作成したら、これをEFI/CLOVER/ACPI/patchedまたはEFI/OC/ACPI (OpenCoreを実行している場合は、忘れずに設定に追加してください。) に入れます。コンパイルが面倒と思う人のために、ここにコンパイル済みのSSDT-PMC.amlを配布しておきます。

NVRAMエミュレーションを削除する方法

以下を削除します。CloverでRCスクリプトをインストールしている場合は色々削除します。（訳注：デフォルトではRCスクリプトをインストールしない設定なので、EmuVariableUefiの削除だけで良いと思います）SIPをオフにしてR/Wでマウントする必要があるかもしれません。

/Volumes/EFI/EFI/CLOVER/drivers/UEFI/EmuVariableUefi-64.efi
/Volumes/EFI/nvram.plist
/etc/rc.clover.lib
/etc/rc.boot.d/10.save_and_rotate_boot_log.local
/etc/rc.boot.d/20.mount_ESP.local
/etc/rc.boot.d/70.disable_sleep_proxy_client.local.disabled
/etc/rc.shutdown.d/80.save_nvram_plist.local

OpenCoreユーザーの場合は、設定で次の項目を無効にするだけです。

Booter->DisableVariableWrite->False
NVRAM->LegacyEnable->False

そしてEFIのルートにあるnvram.plistを削除するのを忘れないでください。

NVRAMの動作をテストする方法

ターミナルを開き、一度に1行ずつペーストします。（訳注：sudo nvram -cは実行しなくても良いと思いました。適当なエントリーに値を設定するだけなら、SIPを無効にする必要はありませんでした。）

sudo -s
sudo nvram -c 
sudo nvram myvar=test
exit

再起動して次のコマンドを実行します。

nvram -p | grep -i myvar

何も返されない場合は、NVRAMが動作していません。myvar testを含む行が返された場合、NVRAMは動作しています。

Note: nvram-cを使用するにはSIPがオフになっている必要があります。もしくはブートメニューでNVRAMを消去します。Cloverの場合は、F11キーを押します。OpenCoreの場合は、 CleanNvramを選択します。Misc->Security->AllowNvramReset->YESに設定する必要もあります。

MSI B360M MORTAR TITANIUMのUSBポートを設定する

Thu, 09 Jan 2020 23:20:04 +0900

長らくほったらかしになっていた銀色のマザーボード、MSI B360M Mortar TitaniumのUSBポートをちゃんと設定しました。USBポートの設定方法は、こちらのZ390チップセットマザーボードの記事もご覧ください。

15個制限を回避するUSBInjectAll.kextの役割と使用法

今回ご紹介するB360は、廉価版チップセットなのでUSBのポート数が少ないです。Z390が使用できるUSBポートは以下です。

USB2.0が14本
USB3.1が10本（そのうち6本までをGen 2にできる）

これに対して、B360は廉価版ですので、

USB2.0が12本
USB3.1が6本（そのうち4本までをGen 2にできる）

です。なのでmacOSの制限で15ポートになっても、諦めなければならないポート数は少ないです。

USBInjectAll.kextを入れる

まずはUSBInjectAll.kextだけを入れて、IORegistryExplorerでxhcを検索します。ウィンドウの右上にある拡大鏡アイコンのついた検索窓にxhcとタイプします。すると、

USB 2.0であるHSが14本見えています。B360は12本なのですが、USBInjectAllにB360の情報がなくて、Z390だと思われているのかもしれません。ここで、マザーボードにUSB機器を接続して、それぞれのポートの位置を調べます。USBメモリーを使うと、抜き差しのほかにアンマウントする必要があるので、キーボードのドングルのようなデバイスの方が楽です。またマザーボード上のピンをチェックするために、USB Type A変換器を用意しておくと便利です。こういう小物パーツはAliで買うと格安ですね。

この結果、USB 2.0の関係がだいたい分かりました。

HS01 2.0 2.0基板上 JUSB1 縁側
HS02 2.0 2.0基板上 JUSB1 内側
HS03 2.0 2.0バックパネル PS/2の下の上
HS04 2.0 2.0バックパネル PS/2の下の下
HS05 2.0 3.1 Gen 2 バックパネルのType-Cの上のUSB A
HS06 2.0 Type-C (HS05にも反応する。）
HS07 2.0 2.0バックパネル LANの下の下
HS08 2.0 2.0バックパネル LANの下の上
HS09 2.0 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明）
HS10 2.0 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明）
HS11
HS12
HS13 (B360なので使わない？）
HS14 (B360なので使わない？）

HS11からHS14は不明です。マザーボード上にはUSB 3.1 Gen2 Type-Cコネクタに接続するための内部コネクタがあるのですが、これに対応するパーツを持っていないので、試せませんでした。不明のうち2本は、おそらくそれに接続していると思います。また、B360はHSが12本のはずなので、不明のうちの2本 (多分HS13, HS14) は、元々存在していなかった可能性もあります。

使用しない2.0を無効にする

いずれにしてもこの4本は使用しないので、USBInjectAll.kextで無効にして良いと思われます。また、USB 3.1の様子を知りたいので、HS09とHS10も一時的に無効にしてみます。元から不要なUSR1, USR2も無効にします。そこで、Cloverの起動オプションを以下にしました。（slideはこちらの記事で設定したオプションです）

<string>-v slide=128 uia_exclude=HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2</string>

この結果、IORegistryExplorerの様子は以下のようになりました。

SSが6個見えるようになりました。総数が14個ですので、これで全部のSSが見えているはずです。今度は、USB 3.1のUSBメモリーを使って、IORegistryExplorerの反応を調べました。その結果、以下のように割り当てられているようです。

SS01 3.1 Gen 2 バックパネルType-Cの上のUSB A
SS02 3.1 Gen2 バックパネルのType-C 裏返しても同じ
SS03
SS04
SS05 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明）
SS06 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明）

SS03, SS04は、HSと同様にパーツが無くて調べられなかった基板上のUSB 3.1 Gen2 コネクタの可能性が高いです。このコネクタを使わないなら、USBInjectAllのオプションで

<string>-v slide=128 uia_exclude=HS11;HS12;HS13;HS14;USR1;USR2;SS03;SS04</string>

という設定を行えば良いかと思います。

USBを設定するSSDTを作る

こちらで説明したように、USBを設定するSSDTを作成して、使用すべきポートを指定するやり方がより正しいようです。USBポートの素性を正しく記述できるので、macOSの動きがより正しくなるはずです。詳しい手順は過去の記事を見てください。流れを説明すると、まずは適当な名前でdslという拡張子のテキストファイルを作ります（例えばSSDT-UIAC.dsl）。以下のようなファイルです。ここでは、HS11からHS14、SS03, SS04, SS07以上、USR1, USR2を削除しています。

SSDT-UIAC.dsl for MSI B360M MORTAR TITANIUM - Pastebin.com

これをMaciASLで開きます。次に、MaciASLのFileメニューからSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_exclude=を指定しなくても、指定したポートのみが有効になるはずです。IORegistryExplorerで確認すると以下のようになりました。

新Mac Proと勝負する

Sat, 21 Dec 2019 22:07:30 +0900

新Mac Proが供給され始めたので、Geekbenchのベンチマークサイトにスコアが上がるようになりました。最下位モデルは8コア16スレッドのXeon W-3223を搭載しています。これにならGeekbenchのスコアで9900Kが勝てるようです。

Mac Proと自作hackintoshで勝負

新Mac Proのベンチマークスコアが、紹介されています。（日本語の記事はこちらなどにあります。）

Base and Middle Tier Mac Pro Models Offer CPU Performance Similar to iMac Pro

それによると、最下位8コアモデルのマルチコアスコアが7606くらい、16コアモデルが14285程度のようです。また、8コアMac Proは、8コアiMac Proや9900K搭載の8コアiMacに負けているようです。勝負しても虚しいだけなのですが、自作hackintoshと比較しました。ベンチマークしたのは、9900Kを使った自作

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

と9600Kを使った自作です。

MSI B360M MORTAR TITANIUM, 9600K

それぞれでGeekbench 5を3-4回動かし、シングルコア値が一番良かったスコアを比較に使いました。シングルコアとマルチコアのベンチマーク結果は以下です。Mac Proのスコアは、上記の元記事からいただきました。シングルスコアは、コア数少なめで設計してある9900K, 9600Kの方が、Xeonよりも優れています。


	Single-core	Multi-core
Mac Pro 16 cores	1104	14285
Mac Pro 12 cores	1090	11599
9900K hackintosh	1360	8317
Mac Pro 8 cores	1008	7606
9600K hackintosh	1178	5601

一方で、Multi-coreの数値を比較すると以下のグラフになりました。

コア数の多いMac Proの性能は圧倒的です。でも、コア数の一番少ないMac Pro 8コアにならば、9900K搭載自作hackintoshは勝てました。元記事では、9900K搭載のiMacも比較対象になっていますが、同程度のスコアになっていて、Mac Pro 8コアを上回っています。9900K自作PCは、RX 580搭載の場合、税込20万円以内で組めると思います。これに対して8コアMac Pro（こちらもRX 580相当を搭載）は税別で599,800円、税込ならば66万円くらいします。3倍以上の差がありますので、自作hackintoshのコスパは圧倒的です。とはいえ、開封動画を見るとMac Proの作りは素晴らしいです。高いだけに贅沢な作りがされています。

What’s Inside the 2019 Mac Pro? Complete Disassembly and Analysis

一方、9600Kは、コア数が6なのでやはり厳しいです。（シングルコアならばどのMac Proよりもハイスコアです。）でも9600Kで普通のコンピュータ作業は全く快適なので、これくらいのスコアを出すモジュラー型MacがApple製品の選択肢に無いことが残念です。iMacからディスプレイを外したデスクトップ、もしくは、Mac miniとMac Proの中間のディスプレイ無しデスクトップの選択肢として、hackintoshの存在価値は大きいと思います。

10.15.2にしたけどNaviの性能は向上しませんでした

Sat, 14 Dec 2019 16:23:05 +0900

AMDのNaviグラフィックスがmacOS 10.15.1からサポートされたものの性能が引き出せないでいました。先週 (2019/12/11) 10.15.2がリリースされたので、改善されると期待しましたが変化なしでした。

Radeon RX580と5700XTの比較

進捗無しの記事です、すみません。AMDの新しいNaviアーキテクチャグラフィックスはmacOS 10.15.1から標準サポートされて、OOBで動きます。RX 580などのPolarisアーキテクチャ製品の後継として期待していました。でも、macOS上でのRadeon RX580と5700XTの性能を比較したところ、あまり差がなくて残念でした。

Radeon RX580/Vega 64/5700XTの性能を比較

この時使ったmacOSは10.15.1でした。10.15.1のリリース後に、NaviアーキテクチャGPUを搭載したMacBook Proが発売されました。なので、10.15.2になれば、ドライバーが改善されて性能が向上するのではと期待していました。でも実測したところ、10.15.1と10.15.2で性能差はありませんでした。残念でした。

上のグラフは、電源投入直後にGeekbench 5で5回計測したスコアの最大値です。実際の測定値は、以下です。


	10.15.1-OpenCL	10.15.1-Metal	10.15.2-OpenCL	10.15.2-Metal
580	47807	49600	47132	49624
5700XT	51988	41266	51170	42244

MacBook Proに搭載されているのは、実はPro 5300MとPro 5500Mという型番のGPUです。モバイル用のGPUで、市販されていません。先日、5500 XTというグラフィックスカードが発売されました。番号が同じなので、もしかしたら性能を引き出せているのかも知れないです。でもお手頃価格で入手できる旧型のRX 580の方がハードウェア仕様は上なので、微妙なところですね。しばらくはRX 580/590がHackintoshに最適な状態は変わらない気がします。

Mac Proでも同様の結果

先日発売されたMac Proに、Radeon RX 5700XT, Radeon VII, Radeon, Radeon RX Vega 64のリファレンスモデルを装着してGeekbench 5のスコアを測ってくれている動画がありました。

2019 Mac Pro - Everything you can Upgrade & How!

これによると、それぞれのリファレンスモデルの

Radeon RX 5700XTのMetalのスコアは42905
Radeon VII, RadeonのMetalのスコアは45885
Radeon RX Vega 64のOpenCLのスコアは57841

だそうです。今回と、前回の測定とほぼ同様のようです。実機でも、市販のカードだとこのくらいなのですね。

Liluとプラグイン：(3) AirportBrcmFixupなどの使い方

Fri, 06 Dec 2019 23:06:11 +0900

Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのでご紹介します。今回はAirportBrcmFixupとその他のkextの部分の抄訳です。原文は下のリンクを見てください。

Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhateverGreenとAppleALCを紹介しました。

Liluとプラグイン：(1) WhateverGreenの使い方

Liluとプラグイン：(2) AppleALCの使い方

（ここから抄訳）

AirportBrcmFixup

このプラグインの使い方は簡単です。これは、ネイティブまたは非ネイティブなBroadcom Airport WiFiカードに必要なパッチのセットを含んでいます。これによりcontinuityやhandoffを動かすこと, WiFiの名前をAirportデバイスと表示すること、そのほかいくつかのパッチを提供します。（訳注：日本語版macOSでは登録商標の関係でAirportではなくAirMacになります）他のLiluプラグインと同じく、大抵の場合、それまで試用していた全てのWiFi関係のパッチとエネーブラーkextを取り除いておく必要があります。このプラグインを使う理由の一つは、これがmacOS 10.13.Xと10.14.XでHandoffを有効にするCloverのパッチを使わなくて済む点です。このkextが自動的にWiFiデバイスを発見できれば、必要なすべてのパッチを当ててくれるので、Device Propertyを設定する必要はありません。

もし、インストールされたWiFiアダプターのVIDとPIDが不明ならば、Hackintoolを使って、デバイスを特定し、PCIアイコンをクリックして、リストの中からWiFiデバイスを発見して、VID (Vendor ID) とPID (Device ID) を知ることができます。

上の例では、WiFiデバイスのVIDは14E4 (Broadcom社のIDです) であり、PIDは43BA (BCM43602チップセット）です。

WiFiデバイスがサポートされているのかどうかは、Git-Hubプロジェクトページのinfo.plistを見て、そこでWiFiデバイスのPIDを探せば確認できます。

もしこのリストにVIDとPIDがあればokです。単にAirportBrcmFixup（とLilu）をインストールするだけです。

必要ならばmacOSのWiFi地域設定を書き換えることもできます。起動オプションに

brcmfx-country=XX

を追加します。これによりWiFiデバイスの国コードを明示的に設定することができます。（訳注：日本に設定するのでしたらbrcmfx-country=JPです）5GHz WiFiを稼働させたり、WiFiルーターをフルスピードで稼働させる場合、国コード設定が必要なことが時々あります。一般的な値は

brcmfx-country=#a

です。これはルーターが設定する国コードを無視するようにmacOSに指示する特別な値です。私のルーターでは、どのバージョンのmacOSでも、#aを付けないと5GHz WiFiの最大速度が得られませんでした。

注意： AirportBrcmFixupは、WiFiのことだけの面倒を見てくれます。Bluetoothを有効にするためには、RehabManさんのBrcmPatchRAMを使います。（訳注：コメントで指摘いただきましたがこちらもご覧ください。そちらのread meを見たら、アップル純正無線カードには関係のないようでした。）

私は、 DW1830 (BCM43602) 搭載ラップトップでAirportBrcmFixupをテストしました。また、BCM943602CS搭載のデスクトップでも使いました。とてもよく動作し、他のパッチもエネーブラーも不要です。

その他のLiluプラグイン

以下は、有用なLiluプラグインのリストです。ほとんどは、/L/Eに入れるだけです（訳注：ESPのkexts/Otherで良いと思います）。追加の設定は不要です。

VirtualSMC

Apple SMC (System Management Controller) を有効にするプラグインです。以前はFakeSMCを使うのが一般的でしたが、長らくアップデートされていません。環境によりますが、VirtualSMCは現在と未来のmacOSでより互換性があります。

FakeSMCからVirtualSMCに移行するためには、FakeSMC.kextを取り除くだけでなく、EFIドライバーのSMCHelper.efiも取り除きます。また、FakeSMCセンサープラグインも取り除きます。

VirtualSMCをインストールするには、VirtualSMC.kextの他に、VirtualSMC.efiもUEFIドライバーとしてインストールします。VirtualSMCの配布パッケージには、この他、光センサー、バッテリーモニター、CPU温度モニターやマザーボードセンサなどのプラグインkextも用意されています。詳しくはこちらをご覧ください。

BT4LEContiunityFixup

AirportBrcmFixupを入れてもなおBluetooth関連のcontinuity問題（AirDrop, Handoff, FaceTime, Apple Watch, Continuity など）が発生するようでしたら、BT4LEContinuityFixup を試してみるもの良いです。macOSのBluetooth LE Continuityを有効にするパッチが含まれています。 BrcmPatchRAM kextも一緒に使ってください。

HibernationFixup

その名の通り、HibernationFixup.kextはディスクにデータを保存するハイバーネーションモード3と25を特定のシステムで有効にします。私は使ったことがないのですが、これが動いたという報告は多数あります。ネイティブなNVRAMが使えることが条件です。エミュレートされたNVRAMでは使えません。

NoTouchID

最近のMacBookシリーズSMBIOS設定はアップルの指紋認証(TouchID)搭載機種を対象としています。これらのSMBIOSをHackintoshで使用すると、起動時とシステムパスワードを表示する場面で遅延が発生します。というのは指紋認証デバイスが搭載されていないからです。NoTouchIDプラグインは、この問題を解決します。

NightShiftUnlocker

デフォルトではアップルのnight shiftは一部のSMBIOSでしか機能しません。この簡単なプラグインは、通常はnight shiftをサポートしていない機種設定でも、有効にします。

Liluとプラグイン：(2) AppleALCの使い方

Sun, 01 Dec 2019 11:30:54 +0900

Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのでご紹介します。今回はAppleALCの使い方の部分の抄訳です。原文は下のリンクを見てください。

Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhateverGreenを紹介しました。

Liluとプラグイン：(1) WhateverGreenの使い方

AirportBrcmFixupに関しても後ほど紹介したいと思います。

（ここから抄訳）

AppleALCとは

AppleALCはLiluのプラグインです。ネイティブでないオーディオコーデックに対してHigh Definition Audio (HDA)を有効にするために、AppleHDA kextに動的にパッチを当てます。WhateverGreen (以下WEG) と同様に、オーディオを有効にするために従来使用していた多くのパッチとkextを置き換えてくれます。なのでAppleALCを使用する前には、既にあるAppleHDAを有効にするパッチ、ダミーのkext、DSDTへの変更などを取り除いておき、AppleHDAをオリジナルの状態のkextに戻しておく必要があります。

Nvidia HDMIオーディオ

AppleALCはほとんどのNvidia GPUでHDMIオーディオを有効にします。必要な作業は、LiluとAppleALCをインストールする事だけです。もしHDMIをサポートしたNvidiaカードが使われていたら、AppleALCはこれを検出して、HDMIオーディオコントローラを有効にします。サポートされたNvidiaデバイスはこちらのページを見てください。Nvidiaデバイスのこのリストの最後にあります。

オンボードオーディオコーデック

AppleALCは、Raltek (ALC)、Conexant、IDTなどの多くのビルトイン（オンボードの）オーディオコーデックをサポートします。大抵の場合、やるべきことは、LiluとAppleALCをインストールして、config.plistに簡単な変更を加えるだけです。が、その作業の前に、AppleALCがどのように機能するか知っておくと良いです。

AppleALCはどのように動くのか

AppleALCの動作は従来の、AppleHDAに予めパッチを当てたり、ダミーを使ったりする方法と少し違います。AppleALCはコネクター、レイアウト、プラットフォームパッチの大規模なデータベースと理解できます。ロードされる際に、LiluとAppleALCは使用されているオーディオコーデックのタイプを自動的に検出し、データベースからパッチを探して、AppleHDAに動的にパッチを当てます。

AppleALCが使うパッチは、インデックス識別子により定義されています。バックワード互換性のために、パッチセットのインデックス識別子はlayout-idと呼ばれるプロパティ値で定義されています。layout-idはhackintoshのコミュニティで昔から使われてきた値で、パッチを当てたバージョンのAppleHDA（もしくはダミーHDA kextの）のレイアウトを選択する値です。

AppleALCのwake verb

追加の機能として、AppleALCはほとんどのコーデックのwake verbの面倒を見てくれます。なので、Codec Commanderをインストールしたり使用する必要はありません。（訳注：コンピュータがスリープするとオーディオアンプもoffになります。スリープから目覚めるときに、アンプがonにならなくて、スリープ復帰後に音が出ない問題が発生する事があります。wake verbはスリープ復帰時にアンプをonにするための特別なデータのようです。これを流す事でアンプがonになるようです。〜という理解で正しいでしょうか？間違っているようでしたらコメントで指摘してください。）

LiluとAppleALCのインタラクション

（訳注：この節の内容は理解できませんでした。すみません）

Liluがロードされると、Liluはlayout-idの値を見つけて、その値をAppleALCに渡します。この値を継承して、AppleALCはalc-layout-idという名前の新しいデバイスプロパティを作ります。AppleALCは次に、layout-idの値を新しいターゲットID（通常は7）に設定し、AppleHDAのターゲットレイアウトに（Liluのパッチエンジンを使って）パッチします。この時、指定した（alc-layout-idで指定された）コーデックのための、コネクターID情報、infoファイル、プラットフォームファイルが使われます。

この方法により、AppleALCはMojaveのドロップドレイアウトIDを無視します。（詳細はこの記事のオーディオの節を見てください）。というのは、インジェクトされたlayout-id値は、AppleALCのコーデックパッチデータベースのインデックスとしてのみ使われるからです。AppleALCはこのlayout-idによる再マップする枠組みを、Mojaveだけでなく、全てのバージョンのmacOSで使います。

サポートされているコーデックを確認

使用しようとしているコーデックをAppleALCがサポートしているかどうかは、ソースコードのResoucesフォルダの中で名前を探せば確認できます。コーデックがサポートされていなかったら、公式のAppleALCヘルプスレッドに投稿して、次のバージョンで入れてもらうよう依頼してください。そのコーデックの詳細（このスレッドの#1投稿を見てください）を投稿します。達人の誰かが、その投稿を見て、手助けを申し出てくれるでしょう。おそらく、Linuxを使ってコーデックのダンプを用意する必要があります。このガイドの対象外の話題なので、ここでは詳細に関して説明しませんが、あなたの投稿を見た誰かがダンプの取り方を説明するリンクを示してくれるはずです。

もし、使用しようとしているコーデックが、既にAppleALCでサポートされていたら、どのレイヤーがサポートされているかを、対応するコーデックフォルダにある、info.plistファイルを開いて知ることができます。これから、どのレイヤーIDが使用可能なのかがわかり、また、コメントからそのうちのどれを使うべきかを知ることができます。

一例として、私の2017年版HP Spectre X360ラップトップの場合は、Realtek ALC295コーデックを搭載しています。そこで、ALC295フォルダの中のinfo.plistを開きます。以下に示します。

ALC295 の info.plist（tonymacx86.com の画像）

この例では、Mironeさんのパッチが必要なパッチであり、これがレイアウト3であることがわかります。このように、コメントを読めば、システムに必要なレイアウトの記述を簡単に見つけられます。もし、全ての使用可能なレイアウトID値のリストが不明な場合、一つ一つ試して動く値を探します。また、Hackintoolを使ってどのレイアウトがサポートされているのか（下の方法で詳細を説明します）知ることもできます。

AppleALCの設定

AppleALC.kextをインストールした後ですべきことは、layout-idを設定することです。2つの方法があります。

方法1：Audio Injectで設定する（古い方法）

Liluはconfig.plist内のレガシーなパラメータであるClover/Device/Audio/Injectからlayout-id値をCloverに問い合わせる機能があります。なのでInjectのString値を正しいlayout IDに設定すれば良いです。以下のようにします。

<key>Devices</key>
<dict>
 <key>Audio</key>
 <dict>
 <key>AFGLowPowerState</key>
 <true/>
 <key>Inject</key>
 <string>3</string>
 <key>ResetHDA</key>
 <true/>
 </dict>

LiluがClover/Devices/Audio/Injectからlayout-idを取得するというレガシーな方法をサポートしなくなる可能性があることは注意すべきです。なので、次に示す方法2が良いです。

方法2：Device Propertiesを使う（おすすめ）

AppleALCとLiluをインストールした後、config.plistを編集して、Devices/Audio/Injectを”No”にします。そしてLayout-idをカスタムDevice Propertyとして設定します。ここで、Audio Device Propertyコードを作成するために、Hackintoolを使います。HackintoolのAudioアイコンをクリックすると、検出されたコーデックタイプが表示されます。ここで設定したいHDAオーディオデバイスを選びます。するとAudio Infoに詳細な情報が出て、ドロップメニューでLayoutを選べるようになります。ドロップメニューには検出されたコーデックに適用可能なlayout IDのみが表示されます。

項目選択が終了したらPatchアイコンを押し、Patch機能を呼び出します。もしオーディオデバイスがシステム情報のPCIデバイスセクションの中で正しい名前で表示させたかったら、Advanced optionsの中のSpoof Audioオプションを選択します。この時Advancedページの他の項目は全てチェックを外します。

次に、Generalをクリックして、Device / PropertiesとAudio Deviceオプション以外のチェックを全部外して、Generate Patchをクリックします。

ここに現れたコードを、config.plistの該当する部分にコピーペーストします。以下のようになります。（訳注：Z390チップセット搭載マザボのALC1220を対象に同じ操作をしたのですが、心当たりのないmodel名になっていたり、hda-gfxという項目があったりしました。model名は適当に編集して、hda-gfxの項目は削除して良いのだと思います。）

 <key>Devices</key>
 <dict>
 <key>Properties</key>
 <dict> 

 <key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
 <dict>
 <key>AAPL,slot-name</key>
 <string>Internal</string>
 <key>device-id</key>
 <data>
 cKEAAA==
 </data>
 <key>device_type</key>
 <string>Audio device</string>
 <key>layout-id</key>
 <data>
 AwAAAA==
 </data>
 <key>model</key>
 <string>Sunrise Point-LP HD Audio</string>
 </dict>

 </dict>
 </dict>

config.plistの変更が完了したら、再起動してオーディオが動いているかどうかテストします。もし動いていなければ、他の有効なlayout-IDを試してください。

もし、全ての有効な値を試してもオーディオがまだ動かない場合は、新しいパッチセットが必要なコーデックを使っているのかもしれません。サポートされていないコーデックに関しては、AppleALCのヘルプスレッドを利用してください。

AppleALCのトラブル対策

AppleALCがロードされていることを確認する

AppleALCが正しくロードされて初期化されていることは、IORegisteryExplorerで確認できます。これはこちらのリンクからダウンロードできます。

IORegisteryExplorerを動かして、HDEFという文字を検索ボックスに入れます。ioregディレクトリーツリーにHDEFデバイスが見えるはずです。上の例では、次のように見えます。

HDEFが見えないようでしたら、LiluとAppleALCのインストール手順を確認してください。以下のACPI HDA/Codec Rename 問題も見てください。

上のスクリーンショットでは、AppleALCが動的に新しいプロパティalc-layout-idを作り出している事がわかります。ここでの3という値は、config.plistで設定した値です。同様に、layout-idという項目は7とあります。これは、AppleALCがパッチを当てようとしている対象のAppleHDAでのレイアウトで、macOSが使っているものです。

もし、HDEFの中にalc-layout-idが見つからない場合、AppleALCが正しくロードされていない、もしくは初期化されていないのかもしれません。この原因は、kextが正しくインストールされていないからです。kextを削除して、インストールを再度試みてください。

HPET 問題 (High Precision Event Timer)

上記のステップが正常でもなお音が出ない場合、HPETによってIRQの衝突が発生している可能性があります。

macOSにおいて、HPETは基本的に必要な仕組みです。これが正しく働く必要があります。このフォーラム（訳注：tonymacx86のフォーラム）のほとんどのガイドでは、BIOSでHPETを有効に設定していることを前提としています。しかしながら、いくつかのマザーボードとラップトップでは、HPETに関するネイティブなDSDTコードがIRQ衝突を引き起こし、AppleHDAの正しい初期化を妨げたり、雑音を出す事があります。

この問題を確認する一つの方法は、ターミナルで次のコマンドを入力する事です。

kextstat | grep 'Lilu\|AppleALC\|AppleHDA'

この結果、Lilu, AppleALC, AppleHDA kextがリストアップされるはずです。

MonkeyPro-2018:~ Jay$ kextstat | grep 'Lilu\|AppleALC\|AppleHDA'
 20 4 0xffffff7f81041000 0x22000 0x22000 as.vit9696.Lilu (1.2.8) 54014689-C8DA-318B-84F4-944BBA7AD2AC <8 6 5 3 2 1>
 23 0 0xffffff7f811bd000 0xdf000 0xdf000 as.vit9696.AppleALC (1.3.3) B60FCBAF-6BC2-36EF-A1E6-D5BE2863C35B <20 13 8 6 5 3 2 1>
 138 1 0xffffff7f830a7000 0x1d000 0x1d000 com.apple.driver.AppleHDAController (282.10) 70256EC9-AF38-31BD-A3C5-9C0E30B64AA3 <137 113 107 13 8 7 6 5 3 1>
 157 0 0xffffff7f8323a000 0xb7000 0xb7000 com.apple.driver.AppleHDA (282.10) B2208DA8-8CD9-36D8-BD59-C6D9A5379585 <156 138 137 124 113 107 7 6 5 3 1>
 159 0 0xffffff7f830c6000 0x2000 0x2000 com.apple.driver.AppleHDAHardwareConfigDriver (282.10) C4F674A0-5828-3D97-82BF-A81C8B8BDDBA <5 3>

この例から分かるように、AppleHDA、AppleHDAController、 AppleHDAHardwareConfigDriverとインストールされています。ここで重要なのは、 AppleHDAです。

もしAppleHDA (com.apple.driver.AppleHDA)が出力に現れていなかったら、HPETオプションが正しく有効になっているかどうかを確認してください。もし有効になっていてもAppleHDAが現れなければ、DSDTのHPETコードにパッチを当てる必要があります。

これを行う最も簡単な方法は、CloverのACPI/DSDT/Fixesの中の FixHPETをtrueにする事です。

<key>ACPI</key>
<dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>

この方法はほとんどのユーザで有効です。でも、もしCloverのHPETフィックスでもまだAppleHDAがロードされない場合、DSDTに直接パッチを当てる必要があるかもしれないです。RehabManさんがこのパッチを作ってくれていて、MaciASLを使って適用できます。

#Maintained by: RehabMan
# HPET fix to avoid AppleIntelCPUPowerManagement panic
into method label _STA parent_hid PNP0103 remove_entry;
into device name_hid PNP0103 code_regex Name\s\(_STA\,\s+0x0F\) remove_matched;
into device name_hid PNP0103 insert
begin
Name (_STA, 0x0F)\n
end;

into method label _CRS parent_hid PNP0103 remove_entry;
into device name_hid PNP0103 insert
begin
Method (_CRS, 0, NotSerialized)\n
{\n
 Return (BUF0)\n
}\n
end;

このパッチをDSDTに当てるためには、MaciASLを使い、Patchボタンを押し、上記のコードをパッチエディターにコピーペーストします。そしてApplyボタンをクリックして、DSDTを保存します。詳しい情報は、Rehabmanさんのガイドを見てください。また、DSDTにパッチを当てた場合は、Cloverのfixは無効にしておきましょう。

ACPI HDA/Codec 改名問題

WhateverGreenと同様に、 AppleALCとLiluはDSDTの中のACPIの名称を適切に自動的に改名してくれます。しかし時々失敗することもあり、手作業で改名する必要があります。この改名が正しく実施されているかどうかは、IORegistryExplorerを開いて、HDEFを検索してみればわかります。

もしHDEFがioregに存在すれば、これ以上の作業は不要です。しかし、もし存在していなければ、ここまで述べた作業が正しく行われているかどうかを確認してください。それでも解決しなければ、HDEF名称変更を手作業で行ってみる必要があります。

まずは、バニラな状態のDSDTをMaciASLで開いて、HDEFで検索して、元々のHDAデバイスの名前を確認します。もし検索結果がなければ、HDASで検索します。それがなければAZALで検索します。

もしHDAデバイスがHDEFと名付けられていたら、デバイスを改名する必要はありません。もしHDASと呼ばれていたら、次のコードをconfig.plistのACPI/Patchesに追加します。

<dict>
 <key>Comment</key>
 <string>change HDAS to HDEF</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 SERBUw==
 </data>
 <key>Replace</key>
 <data>
 SERFRg==
 </data>
</dict>

もしAZALでしたら、以下のパッチを追加します。

<dict>
 <key>Comment</key>
 <string>change AZAL to HDEF</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 QVpBTA==
 </data>
 <key>Replace</key>
 <data>
 SERFRg==
 </data>
</dict>

Liluとプラグイン：(1) WhateverGreenの使い方

Sat, 23 Nov 2019 23:49:44 +0900

Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありました。ここからLiluとWhateverGreenの部分を抄訳して紹介します。原文は下のリンクを見てください。

Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いですので、LiluとWhateverGreenの部分を紹介します。残りの、 AppleALCに関してはこちらをご覧ください。

Liluとプラグイン：(2) AppleALCの使い方

AirportBrcmFixupに関しても後ほど抄訳したいと思います。

（ここから抄訳）

Liluとは何か

LiluはmacOSのパッチエンジンです。カーネルとシステム拡張を起動時に拡張します。使用することのメリットは多いです。

特定のブートローダーに依存しない
リカバリーモードやmacOSインストーラ・アップデータでも動く
シンボリックパッチエンジンもサポートする
カーネルとシステム拡張へのAPIアクセスを可能にする
起動中のプロセスの変更も可能

Liluはパッチの仕組みを提供するだけで、それだけでは何もしません。プラグインと一緒に使うことで機能します。Liluパッチを作成するための開発キット(SDK) も用意されています。有名な3種のパッチは、WhateverGrenn, AppleALC, AirportBrcmFixupです。以下ではこれらについて説明します。Liluプラグインの全てのリストはLiluのGitHubをご覧ください。（訳注：VirtualSMCもLilu使ってたんですね。）

Liluプラグインはそれだけで機能し、同様の機能を提供する従来型のCloverのパッチやkextを置き換えます。そのため、関係するClover設定、FakeID, パッチ、kextがすでに導入されていたら、それを取り除いてください。例えば、LiluプラグインであるAppleALC.kextをインストールしたら、CloverのAppleHDAパッチとHDA Enabelerのパッチやダミーのkextは全て取り除くか無効にします。競合するパッチが残っていると、システムが予想外の動作をしたり、不安定な状態になります。

Hackintool

以下の説明ではHackintoolを使います。ぜひ備えておいていただきたいツールですので、ここからダウンロードしておいてください。

Liluとプラグインのインストール方法

LiluとそのプラグインはmacOSのkextとして提供されます。これらは、 /Library/Extensionsに入れるべきです。Cloverのkexts/Otherに入れるとしたガイドも多いですが、この方法は試験や開発だけに留めておくのが良いです。サードパーティのkextを入れる正式な場所は/Library/Extensionsです。（訳注：どちらが良いかは議論のあるところだと思います。簡単なのでkexts/Otherで良いのではないかと思います。これ以降、/Library/Extensionsに入れるための方法が続きますが省略します。Catalinaになるとセキュリティ保護が厳しくなるので、かなり面倒なようですね。）

WhateverGreen (WEG)

WhateverGreen（以下WEG）は2017年にAMD GPUのためにリリースされましたが、現在（2019年）では以下の機能を統合しています。

IntelGraphicsDVMTFixup –> Intel IGPU DVMT Pre-allocationのパッチ
IntelGraphicsFixup –> Intel IGPU’sをサポートするための多数のパッチ
NvidiaGraphicsFixup –> Nvidia GPUをサポートするための多数のパッチ
CoreDisplayFixup –> High DPI表示のパッチ (pixel clock patch)
Shiki –> DRMで保護されたビデオ再生のためのパッチ
AzulPatcher4600 –> HD4600 IGPUのAzulフレームバッファのためのパッチ
AppleBacklightFixup –> バックライト制御のプラグイン
EnableLidWake –> ラップトップの蓋操作でスリープ解除するためのパッチ

このようにWEGは、GPU/IGPUとディスプレイに関する全ての解決策を提供します。また、統合されてしまった上記のプラグインは、WEGと一緒に使わないでください。カーネルパニックやOSの異常動作を引き起こす可能性があります。

WEGの前準備

Cloverのconfig.plistから、IGPUに関する全てのインジェクション、設定、フェイクIDなどを除去してください。これを行わないと、WEGの動作と衝突することになり、想定外の結果を引き起こします。

最新版のLiluとWEGを/L/Eに入れます。（訳注：kexts/Otherでも良いと思います。）

WEGはデバイス改名処理も行います。なので、Cloverのconfig.plistに次のようなACPI Fix/Renameの箇所があれば、これを削除します（もしくは無効にします）。

GFX0をIGPUに変更するパッチ
PEG0をGFX0に変更するパッチ
HECIをIMEIに変更するパッチ

これらのClover ACPI Fix/Renameの手法は、ACPIのテーブル全体に変更を与えてしまうために、後に問題を引き起こす可能性があります。WEGの方法は特定のACPIコードを探索して、そこだけを変更しますので、優れています。

AMDとNvidiaのdGPU

AMDとNvidiaユーザは、Lilu と WEGをインストールすることで、フレームバッファもdGPU関係のパッチも全て対応できます。上級者向けには起動オプションが多数ありますので、WEGのreadme.mdを見てください。Liluの概要で述べたように、AMDとNvidiaのGPUに関するパッチは、config.plistから削除してください。WEGがこれらを全てやってくれます。

IntelのiGPU

iGPUだけのシステム、もしくはdGPUと併用するシステムでは、WEGは従来の方法より早くて簡単なカスタマイズ手段を提供します。従来の方法では、Cloverを使ったり、Intel iGPUドライバーにパッチを当てたり、フレームバッファkextにパッチを当てたりしていました。

WEGをそのまま使う

最近のWEG (V1.3.0以降) は、改善されたiGPU自動検出と自動設定の機能があり、追加の作業なしでたいていのシステムでそのまま動きます。まずは、上記で説明したWEGの前準備を実行しておいてください。その後、単にLiluとWEGをインストールして再起動するだけです。なお、SMBIOSの記述はWEGの自動設定に影響を与えます。

（訳注：GPUを動かすためには、「前準備」をして、LiluとWEGを入れるだけで良いということです。それで問題なく動く場合は、この先は参考程度に読んでください。）

WEGの自動設定は非常に改善されてはいますが、完璧ではなく、全てのシステムで機能するわけではありません。自動設定が機能しない場合は、WEGを手作業で設定しなければなりません。また、dGPUが搭載されている場合、WEGはiGPUを「ヘッドレス」に設定したいところです。でもそのためにはiGPUとdGPUがBIOSで正しく設定されている必要があります。ヘッドレスに関して後で詳細に説明します。

WEG手動設定に必要なID情報

WEGはDevice Propertiesを使って設定を行います。これはCloverを使ってデバイスioregディレクトリーツリーのカスタムプロパティを定義する比較的新しい方法です。Lilu開発メンバーからのリクエストでCloverに実装された手法です。デバイスプロパティについての詳細はClover開発ブログのこちらをご覧ください。

デバイスプロパティは、Cloverのconfig.plistのDevices –> Propertiesセクションで定義されます。プロパティは、PCIパスで決まる名前とデータ値から構成されます。名前とPCIパスはタイプで、データ値は次の3種類のうちの一つで表現されます。

iGPU デバイスプロパティ

全てのiGPUパッチは、Hackintoolのトップメニューの2番目のアイコンにあるパッチモードで実行できます。また、下のバーメニューを使ってパッチモードのサブ機能を使えます。Patchをクリックして、infoを選択してみました。

もしHackintoolがシステムのCPU世代を正しく特定しているものの、Platform IDドロップダウンメニューが空で、FramebufferとConnectorサブメニューにデータが表示されない場合は、HackintoolのメニューバーのFramebufferをクリックして、macOSバージョンを使用中のものに設定してください。

もしHackintoolがCPU世代を自動的に特定できなくて、Current Framebuffer Infoボックスに???が表示されたり、Hackintoolが誤った世代のCPUを選択しているようならば、ドロップダウンメニューから手作業で正しいCPU世代を設定できます。

Hackintoolを最初に起動すると、iGPUを検出して、それ用のデフォルトPlatformIDを選択しますが、多くの場合、これらは正しくないので、最初にこれを正しく選択させる必要があります。

Infoサブ機能を選択すると、検出されたiGPUのタイプが下のCurrent Framebuffer Infoボックスに表示されます。また選択されたPlatformIDの詳細と、合致したSystem Definitions (SMBIOS)が上のSelected Framebuffer Infoボックスに表示されます。

例えば、2017年版HP Spectre X350ラップトップで最初にHackintoolを動かした時は、PlatformIDとして0x591B0000が選択されて、System Definition (SMBIOS) としてMacBookPro 14,3が推奨されました。

上の図では、矛盾した情報が表示されています。iGPUは正しく検出されていて、Current Framebuffer InfoボックスにはHD 620であると表示されていますが、Selected Framebuffer Infoボックスには0x591B0000はHD 630 iGPUであると表示されています。なので、PlatformID 0x591B0000は間違っていることがわかります。これをPlatformIDドロップダウンメニューから正しいものに変更します。もし、必要とするPlatformIDが分からないなら、ドロップダウンメニューから一つ一つ順番に選択して、iGPUタイプに合致するIDを探します。（訳注：https://arc.intel.com/で使用しているCPUを検索すると16進数4桁のデバイスIDが分かります。IntelのベンダーIDは8086なので、このデバイスIDと8086をつなげた番号がGPU Device IDに現れるべき数値になります。Platform IDを変えていくと画面に表示されるGPU Device IDも変化するので、上位4桁がarc.intel.comの番号に合うように選択すると良いと思います。）

ラップトップPCの場合は、モバイル用のPlatform ID（Mobile の欄に Yesと表示が出ます）を選択します。デスクトップPCの場合はMobileがNoのものを選択します。

私のHP Spectre X360ラップトップでは、0x59160000が必要であると分かっていましたので、ドロップダウンメニューからこれを選択しました。

さてこれで、Selected Framebuffer InfoボックスとCurrent Framebuffer Infoボックスで同じiGPUタイプが表示されるようになりました。HP Spectre X360ラップトップはMobile HD 620 iGPUで、推奨のSystem Definition (SMBIOS)はMacBookPro14,2です。

プロの技：@headkazeさんによるリストを使うことでも、PlatformIDを見つけることができます。これは、macOSで使えるPlatformIDとFrameBufferのリストです。これを使えば、例えば、Coffee Lake CPUを使う場合、Coffee Lake CPUセクションまでスクロールすると、最初に全てのPlatform IDがまとめられています。ここには、MobileかDesktopシステムなのかが書いてあります。またコネクタの数が0になっているIDは、ヘッドレスのものです。

それぞれのPlatform IDの詳細は、少しスクロールすると見ることができます。例えばPlatform ID 0x3E9B0000の詳細は以下のように書かれています。

この情報から、このPlatform IDがMacBookPro15,1で使われていることがわかり、これがIntel UHD 630 iGPUのPlatform IDだとわかります。Hackintoolからもこれらの情報はわかりますが、リストアップされた形式で確認する方が簡単なこともあります。

HD 4600 iGPUに関する特記事項：上記のリストでIntel HD 4600 のPlatform IDが0x4160000になっています。でも私の経験では、Platform IDを0x0D220003 (これはIntel Iris Pro Graphics 5200のものです）にし、device-idは0x0412 (これはIntel HD 4600のもの）にし、iMac14,2にするのがよかったです。またHDMIを使うためには、こちらのパッチが必要です。この理由はわかりませんが、おそらくmacOSが他のIntel CPUとは違うAZUL Framebuffer kextを使っていることが原因かと思われます。

**重要：**選択したPlatform IDに合ったSystem Definition (SMBIOS)を使うようにしましょう。Hackintoolは多くの場合、推奨するSMBIOSを上のSelected Framebuffer InfoボックスのModel(s)欄に表示してくれます。Platform IDと合致しないSMBIOSを使うとmacOSが動作不良に陥ります。

**注意：**いくつかのPlatformIDでHackintoolのModel(s)欄に推奨System Definition (SMBIOS)が表示されない、もしくはUnknownと表示されることがあります。これはそのGPU、IGPU、Platform IDと合致するMac機種が存在しないからです。しかし、IGPU Platform IDは有効で機能するはずです。でも、できるならば、使用しているiGPUに合致したフレームバッファを持つ他のPlatform IDを選択し、それから推奨されるSMBIOSを選ぶのが良いです。

適合するPlatformIDが見つからない場合

もし使用しているiGPUに合致するPlatform IDを見つけられない場合、最も近いものを代わりに選ぶことになります。例えば、UHD 620を使っている場合、最も近いのはおそらくUHD 630のPlatform IDです。他の例では、HD 4400 iGPUの場合は、HD 4600またはHD 5200のPlatform IDを選ぶと良いです。これらの場合、システムをちゃんと動かすために、異なるPlatform IDをいくつか試すことになります。

もしシステムがラップトップならば、MobileがYesになっているモバイル用のiGPU Platform IDを選択します。（訳注： arc.intel.comで該当するCPUの仕様を見ると、「システムの種類：Mobile」などと書かれた項目があるので、それに合わせるのが良いと思います。）

もし、iGPUと合致しないPlatform IDを使う場合、対象のiGPUタイプのデバイスIDを知る必要があります。これは後で説明します。

適合するSMBIOSが見つからない場合

もし推奨SMBIOSに対するPlatform IDが見つからない場合でも、動かないわけではありません。この場合は、作ろうとしているシステムに一番近い、合致するSMBIOSを推測することになります。この作業に便利なツールがMacTrackerです。

**注意：**もしSMBIOSを変更する必要がある場合、iCloudなどのAppleのオンラインサービスからログアウトすることを忘れないでください。また、iDiot’s Guide To iMessage を見て、新たに設定をおこなってください。（訳注：Appleからbanされることもあるので注意しましょう。SMBIOSの試行錯誤をする場合は、ネットから切り離して作業するのが良いと思います。）

ヘッドレスPlatform ID

デスクトップHackintoshユーザが、Hackintoolが推奨するPlatform IDを上書き変更したいと思うもう一つの状況は、iGPUをヘッドレスモードで使いたいという場合です。（訳注：ヘッドレスというと、通常は、PCをネットから制御することを前提に、ディスプレイ無し使用することを言います。でもここでは、dGPUにはディスプレイを接続するけど、iGPUにはディスプレイを接続しないという意味のようです。）

iMacや幾つかのMac miniのように、デュアルGPUを搭載している純正のデスクトップ型Macは、ヘッドレスPlatform IDを使っています。これにより、macOSにiGPUには物理的なディスプレイが接続されていないこと、しかしハードウェア加速機能のためにmacOSがiGPUを使用できること、を伝えています。iGPUがヘッドレス利用と設定されると、macOSはiGPUを、AirPlayのミラーリング表示機能や、静止画・動画の符号化・復号化機能 (Intel Quick Sync -iOS)などで使うための、ある種のGPU副プロセッサとして使用します。これはmacOSの重要な機能です。ですので、もしdGPUの他にサポート対象のiGPUがあるならば、iGPUをヘッドレス構成に設定すべきです。

**注意：**ワークステーションクラスのCPU (Intel Xeon) を搭載したシステムは、iGPUを備えていません。なので、ヘッドレスPlatform IDを設定してはいけません。

もし、ヘッドレス構成が不要ならば、次の、「WEGの手動設定」まで読み飛ばしてください。

Hackintoshの主ディスプレイアダプターがNvidiaやAMDのdGPUであり、サポート対象のiGPUも備えていたら、ヘッドレスPlatform IDを使えば、そのHackintoshシステムは安定になり、iGPUによるハードウェア加速機能を備えた純正のMacのように振る舞います。

iGPUをヘッドレスモードで動かすためには、以下のBIOS設定を行います。

IGPU -> Enabled
Primary Display Adapter -> dGPU (PEG)
Multi-Monitor Mode -> Enabled (このオプションがある場合)

また、デュアルGPU構成をサポートし、使用中のCPU/iGPUタイプに合致するMacのSystem Definition (SMBIOS) を正しく設定しておく必要があります。ヘッドレスPlatform IDのためのオススメのSMBIOSは以下です。

Coffee Lake CPU = SysDef: imac19,x
Kaby Lake CPU = SysDef: imac18,x
SkyLake CPU = SysDef: imac17,x
Haswell CPU SysDef: imac14,x または imac15,x
Ivy Bridge CPU SysDef: imac13,x または macmini6,x
Sandy Bridge CPU = SysDef: imac12,x または macmini5,x

**注意：**もし使用中のCPU. iGPUと選択したヘッドレスPlatform IDが既知のMac構成と合致するなら、Hackintoolは合致したSystem Definition (SMBIOS)を上のSelected Framebuffer Infoボックスに表示します。

現在知られているヘッドレスPlatform IDは以下です。

Coffee Lake CPU
9th Gen UHD-630 IGPU = 0x3E980003 (MacOS 10.14.4+で使用)
8th Gen UHD-630 IGPU = 0x3E920003 or 0x3E910003 (MacOS 10.13.6 〜 10.14.Xで使用)
Kaby Lake CPU
HD-630 IGPU = 0x59120003 (MacOS 10.13.Xで使用)
Unknown = 0x59180002 (推奨しません)
SkyLake CPU
HD-510 IGPU = 0x19020001
GT2f IGPU = 0x19170001
HD-530 IGPU = 0x19120001
Iris Pro 580 = 0x19320001
Haswell CPU
HD-4600 IGPU = 0x0412000B or 0x04120004
Ivy Bridge CPU
HD-4000 IGPU = 0x01620006 or 0x01620007
Sandy Bridge CPU
HD-3000 IGPU = 0x00030030

**注意：**モバイル用CPUであるCannon-Lake と Ice-Lake CPUにはヘッドレスPlatform IDはありません。

Hackintoolを使って、Connectors機能を選択することで、選択したPlatform IDがヘッドレスであるかどうかを確認できます。全てのエントリーは次の値を持っている場合、ヘッドレスです。

index = -1
bus id = 0x00
pipe = 0
type = dummy

これに加えてHeadlessアイコンが表示されます。HaswellのヘッドレスPlatform IDである0x0412000Bの例を示します。

注意-1: ヘッドレスiGPUモードはデスクトップ機のデュアルGPU構成 (dGPU + iGPUの構成)でのみ良好に動きます。両方のGPUの出力が同じディスプレイに接続されるラップトップ機のデュアルGPU構成では動きません。このような構成では、RehabManさんのガイドのようにdGPUを常に無効にしないとmacOSが動かないからです。

注意-2: 既に述べたように、ヘッドレスPlatform IDの使用は、推奨された機種のSMBIOSでのみ機能します。それ以外のシステムを設定すると不安定になります。

注意-3: ヘッドレスPlatform IDを使う場合、iGPUは、BIOSで有効に設定してあっても、システム情報 -> ハードウェア -> グラフィックス/ディスプレイには現れません。これは正常です。これによりヘッドレスiGPUモードが機能していることを確認できます。

注意-4: Hackintoshに1個または複数のThunderbolt 3ポートが実装されていて、これをdGPU + ヘッドレスiGPUの表示に使いたい場合は、BIOSで”Above 4G Decoding”オプションを有効にする必要があります。

注意-5: iGPUをヘッドレスに設定した後、IORegistryExplorerを使ってIOREGを調べることで、全てが正しく設定できたことを確認できます。”IGPU”で検索して、iGPUエントリーのAAPL, ig-platform-idプロパティが、ヘッドレスPlatform IDに設定されていて（バイト順が逆になっています）、適合したモデル設定になっていることを確認します。

WEGの手動設定

HackintoolのPatchモードの他のサブ機能のボタンをクリックすると、現在選択されたフレームバッファー設定と変更をチェックできます。大抵の場合、ここでは何も変更する必要はないです。詳しくは WEG guideのpost #2を見てください。全てokでしたらPatchサブ機能ボタンを押します。

iGPUなりすまし

もしiGPUに合致しないPlatform IDを使用しているなら、iGPUのdevice IDを他の値に偽装しなければなりません。

例えば、UHD 620 iGPUを使用する場合、これに対応するPlatform IDはありません。もっとも近いPlatform IDはUHD 630 iGPUです。それでUHD 630のPlatform IDを選ぶことになり、iGPUをUHD 630に偽装する必要があります。

iGPUのなりすましを行うためには、Advancedページを使います。（訳注：上のアイコンでPatchを選び、下のボタンでPatchを選んだ後に上部に現れるAdvancedタブです。）ここでSpoof Video Deviceにチェックを入れ、ターゲットのiGPUデバイスIDを隣にあるドロップダウンメニューから選びます。下のスクリーンショットでは、UHD 620 iGPUをUHD 630になりすましさせています。

iGPUパッチ生成

次に、Generalのサブページをクリックして、Devices/Propertiesラジオボタンを選択して、Graphic Deviceチェックボックスを選択し、それ以外のチェックボックスはとりあえず非選択にします。そしてGenerate Patchボタンをクリックします。大抵の場合、AAPL,ig-platform-id (またはSandy Bridgeの場合はAAPL,snb-platform-id)がDevice Propertyとして設定されれば、WEGはiGPUを正しく設定できます。追加のプロパティーは、オプショナルですが、iGPUを正しく特定するために役立ちます。以下では、HackintoolをIntel HD 620 iGPUを搭載し、Platform IDが0x59160000である2017年版HP Spectre X360ラップトップで動かした例を示します。

このパッチコードを、plistの正しい構造を維持しつつ、config.plistにコピーペーストします。とのブロックの部分を選択してコピーします。

次に、これをconfig.plistのDevices -> Propertiesセクションにペーストします。上の例の場合、このような感じになります。

<key>Devices</key>
 <dict>
 <key>Properties</key>
 <dict> <<----- ここの後にHackintoolのパッチをペーストする

 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 AAAWWQ==
 </data>
 <key>AAPL,slot-name</key>
 <string>Internal</string>
 <key>device-id</key>
 <data>
 FlkAAA==
 </data>
 <key>device_type</key>
 <string>VGA compatible controller</string>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>model</key>
 <string>HD Graphics 620</string>
 </dict>

 </dict>
</dict>

注意: Sandy BridgeではDevice Propertyの名前はAAPL,snb-platform-idになります。 (AAPL,ig-platform-idではありません)

暗黒画面とコネクター不全

ほとんどの場合Hackintoolが生成するデバイスプロパティはWEGが正しくiGPUを構成するのに十分な情報量です。しかし、いくつかのシステムではさらにフレームバッファデフォルト値を変更する必要があります。例えば、iGPUのポートをDVIからDPに変更したい場合や、DPからHDMIに変更したい場合です。この場合、Hackintoolを使ってさらなる設定を行い、新たなパッチを作成して、config.plistのDevice Propertiesに追加します。これに関してはCaseySJさんの素晴らしいガイドがあるので、以下を見てください。

高DPI表示とデュアルモニター

高DPIディスプレイを使う場合、または私の場合のようにラップトップに外部ディスプレイを接続する場合、macOSの起動オプションに -cdfon を追加します。これにより、WEGのピクセルクロックパッチを有効にします。これにより高DPI表示に必要な解像度とリフレッシュレートを可能にします。この機能は、以前はCoreDisplayFixUpプラグインが担っていましたが、今はWEGに統合されました。

この場合iGPUのVRAMをデフォルト値の1536MBから2048MBに増加しておくことをお勧めします。これにより2面の1080P表示が可能になります。これには、config.plistのDevice Propertiesセクションに以下を追加します。

<key>framebuffer-patch-enable</key>
<data>
AQAAAA==
</data>
<key>framebuffer-unifiedmem</key>
<data>
AAAAgA==
</data>

注意: VRAMを2048MBに増やす設定は1080Pディスプレイ1個のシステムや、ヘッドレスPlatform IDのシステムでは何の効果もありません。

変更をテストする

必要な変更をconfig.plistに書き込んで再起動します。うまく起動したらHackintoolで状況を把握して、加速機構などが機能していることを確認します。

また、WEGがHECIデバイスを正しくIMEI (Intel Management Engine Interface)に改名できているかどうか確認することをお勧めします。これにはターミナルで以下のコマンドをタイプします。

ioreg | grep IMEI

IMEIに改名するパッチが効いている場合、以下のように表示されるはずです。

| | +-o IMEI@16 <class IOPCIDevice, id 0x100000264, registered, matched, active, busy 0 (36 ms), retain 11>

もしWEGによる改名が確認できない場合は、従来のCloverのHECI -> IMEI改名パッチを使ってください。

<dict>
 <key>Comment</key>
 <string>change HECI to IMEI</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 SEVDSQ==
 </data>
 <key>Replace</key>
 <data>
 SU1FSQ==
 </data>
</dict>

DRM問題

DRM (Digital Rights Management, デジタル著作権保護）されたコンテンツが再生できないことがあります。解決は困難です。特にKaby Lake以降のiGPUだけを使ったシステムでMojave以降を使用する場合、現状では対応不可能です。

WEGはDRMに対応していたShikiの機能を引き継いでいます。もし、iTunes、ウェブブラウザでのNetFlix再生などができない場合は、起動オプションでshikigva=1などして、試してください。shikigvaの番号には以下の機能があります。

001 = Force Hardware Online Renderer
002 = Allow Non BGRA
004 = Force Compatible Online Renderer
008 = Add Executable Whitelist
016 = Disabled Unused
032 = Replace Board ID
064 = Unlock FP10 Streaming

もしshikigva=1 (001 = Force Hardware Online Renderer)でも表示されなければ、shikigva=57 (001 + 008 + 016 + 032) を試してください。これはmacOSに別のBoard IDを使わせることになり、DRM問題を解決することもあります。

shikigvaの001オプションを使うと、macOSはもっとも適切なハードウェアレンダラーを使うようになります。でもこの自動設定を変更してDRM再生GPUを指定したい場合は、以下のどれかのコマンドを使います。

Intel iGPUを使うように指定する

defaults write com.apple.AppleGVA forceIntel -boolean yes

AMD/ATI dGPUを使うように指定する

defaults write com.apple.AppleGVA forceATI -boolean yes

Nvidia dGPUを使うように指定する

defaults write com.apple.AppleGVA forceNV -boolean yes

私の理解では、AMD GPUは多くの場合、良好に動作します。一方でNvidia GPUとIntel IGPUは世代によって良かったり悪かったりします。

もしshikigva=1でもshikigva=57でもDRM再生ができない場合は、shikigva=60 (004 + 008 + 016 + 032) を試してみてください。これは、代替Board IDを使い、さらに別の互換性のある、GPUハードウェアを使用しないDRMレンダラー手法を使う設定です。もしどれも（1, 57, 60のいずれも）だめなようでしたら、他に問題があると思われます。他の値を試してみてください。

ちなみにmacOSのDRM設定を元のデフォルト設定に戻すには、以下のコマンドを一つずつ使います。

defaults delete com.apple.coremedia
defaults delete com.apple.AppleGVA
sudo rm -rf /Users/Shared/SC\ Info
sudo defaults delete com.apple.coremedia
sudo defaults delete com.apple.AppleGVA

DRM問題はいまだに上手くいくこともあれば動かないこともある問題です。おそらくはハードウェアの特定の組み合わせ (Chipset + CPU + GPU) とSMBIOS設定に関係していると思われます。純正のMacであっても、Appleフォーラムで動かないという問題が指摘されています。主にIvy BridgeとHaswellで問題が多いようです。Appleのドライバーそのものが原因かもしれません。

DRM再生はCoffee Lakeシステム (第8世代と第9世代)において特に困難なようです。私はCoffee Lakeを持っていないのですが、@Jaco1960さんによる第8世代を使った報告によると、DRMを動かすたった一つの方法は、iMacPro1,1に設定することだそうです。その結果は以下のようです。（訳注：どの方法を使ってもSideCarが動かなくなるということかな。これは手を出しにくいですね。）

@pastrychefさんも、Coffee Lakeで動かすためには、iMacPro1,1の設定が必要と報告しています。現在は、DRMを100%動かせる方法はありません。

Radeon RX580/Vega 64/5700XTの性能を比較

Fri, 15 Nov 2019 19:55:55 +0900

Radeon Rx 580, Vega 64, RX 5700 XTの性能をGeekbench 5で比較しました。いずれもmacOSで動きますが、上位モデル・最新モデルの性能を引き出せていないようです。macOSしか使わないのであれば価格・電力性能比の良いRX 580が良いです。

巷のRadeon評価

AMDのRadeonシリーズGPUとmacOSの互換性は高く、現行製品のほとんどがmacOSで使えます。でもWindowsで動かすほどの性能を引き出せていないという意見をよく目にします。実際のところはどうなのかを、Radeon現行製品それぞれのアーキテクチャ製品を比較して調べました。現行製品のアーキテクチャと代表的な上位モデルを列挙すると次の表になります。製品は左カラムから右へ、発売日順に並んでいます。


	580	Vega 64	VII	5700 XT
構造	Polaris	Vega10	Vega20	Navi(RDNA)
線幅	14nm	14nm	7nm	7nm
CU数	36	64	60	40
SU数	2,304	4,096	3,840	2,560
ROP数	32	64	64	64
クロック数	1,257MHz	1,274MHz	1,400MHz	1,605MHz
メモリ	GDDR5	HBM2	HBM2	GDDR6
消費電力	185W	295W	300W	225W
4K性能	31.2fps	47.5fps	57.0fps	56.0fps
価格

ここで4K性能と書いた部分は、gpucheck.comでの結果です。演算性能よりはCG性能を重視した評価指標かと思われます。詳細な比較結果は以下をご覧ください。

この表の製品のうち、580とVega 64は去年（2018年）の製品です。なので発売当初の半額から1/3程度の値段で買えます。VIIと5700 XTは、今年（2019年）発売の製品なので、まだ価格は高いです。プロセッサー数などの仕様と発売当初価格から分かるように、Vegaアーキテクチャの2製品は、Radeonシリーズの最上位モデルです。それに対して、5700 XTは580/590に相当する中位モデルです。でも本年モデルのVIIと5700 XTを比較すると、5700 XTのコストパフォーマンスと、電力パフォーマンスがとても良いことがわかります。5700 XTはAMDのGPUとしては久々の優れたモデルとして人気があるようです。ただこれはWindows環境での話です。macOSではどれも動作はしますが、ドライバの作りが完璧でないためか、Windows環境と同じような性能は得られていないようです。

Geekbenchで測定

macOS環境では、それぞれどのような性能なのでしょうか。VIIは用意できなかったので、それ以外の3機種、RX 580, Vega 64, 5700 XTをGeekbench 5で調べました。RX 580がオリジナルファン版、他はリファレンス版です。

SAPPHIRE NITRO+ RADEON RX 580
MSIブランドのリファレンスファンRadeon RX Vega 64
ASUSブランドのリファレンスファン Radeon RX 5700 XT

今回はRX 580としてNITRO+を使いましたが、PULSEの方が安いですし、Apple純正のeGPUで採用されてますので何かと安心かと思います。一時期販売終了していましたが、最近は安定供給されているようです。

Geekbench 5のGPUベンチマークには、OpenCLとMetalの選択があります。それぞれを交互に5回測定しました。5回測定したものの、最初の1〜2回に良いスコアが出て、それ以降はだんだん低下していくようでした。おそらくはベンチマーク実行のためにGPUが発熱し、速度が抑えられるのでは無いかと思います。

特に、Vega 64は発熱が激しく、基板バックパネルの温度で52度以上になってました。触れない熱さです。GPU本体はもっと高温になっていると思います。それだけ電力を消費しているということですね。その一方で、580と5700 XTのバックパネルはほんのり温かくなる程度です。

ちなみにここで使った温度計は、AliExpressで送料込み800円くらいで売っている非接触赤外線温度計です。レーザ光線も出てカッコ良いです。

ということで、以下の比較では、5回測定したうちの最高スコア（大体は1回目のスコアでした）を採用しました。

測定結果

ベンチマークの結果を下に示します。上の表から、gpucheck.comの値も書いておきました。これはWindows環境のベンチマークなので、項目名の頭に(W)と書いておきます。今回測定したOpenCLとMetalのベンチマークはmacOS環境なので、項目の頭に(M)と書いておきます。


	580	Vega 64	VII	5700 XT
(W) 4K性能	31.2fps	47.5fps	57.0fps	56.0fps
(M) OpenCL	47807	61330		51988
(M) Metal	49600	60577		41266

RX 580, Vega 64, RX 5700 XTのOpenCL/MetalのGeekbenchスコアをグラフにすると以下のようになります。

こうしてみると、Windows世界の評価に対して、かなり異なる結果になりました。まず、Vega 64は確かに高速です。でもWindows環境だとRX 580の1.5倍くらい速いことになっていますが、こちらの結果では1.3倍くらいです。また、Windows環境ではVega 64よりも高速な5700 XTに至っては、RX 580と比較して、OpenCLで10%くらい高いスコアを出している程度で、Metalでは負けています。

手元の環境だけの異常なスコアなのかとも思いましたが、Geekbenchのサイトで検索しても似たような結果でした。下は、Geekbench 5のcompute resultsで、RX 5700 XT macOSで検索した結果です。

Metalのスコアは大体、30000後半から40000台でした。上記のスコアは一般的な結果のようです。

まとめ

5700 XTは残念なスコアでした。RX 580とVega 64に近いGPUは、Mac製品に搭載されています。しかし5700 XT、もしくはそれに近いGPUは採用されていませんでした。そのため、macOSのドライバーが5700 XTのアーキテクチャに十分に対応していないのかもしれません。

でも、つい最近に出た16インチMacBook ProではNaviアーキテクチャGPU (Radeon Pro 5300M, 5500M) が搭載されています。10.15.1で5700シリーズが動いたのもこのおかげかと思います。ちなみにProと名前がつくモデルはアップル専用モバイルチップです。強そうな名前ですが、実は計算ユニット数やクロック数を多少減らして発熱を抑えたチップです。Appleの公式サイトによると、前モデルのRadeon Pro 560Xに比べてRadeon Pro 5500Mは2.1倍速いそうです。Radeon Pro Vega 20と比較しても35%速いそうです。新MacBook Pro対応のmacOS （多分10.15.2）になれば、ドライバが改良されて性能改善されるのではと期待しています。

HackintoshでApple Arcadeする

Sun, 03 Nov 2019 16:20:24 +0900

Catalinaから始まったApple Arcadeを使ってみました。一月600円でゲームが楽しめるサブスクリプションサービスです。Hackintoshでも問題なくプレイできました。

Apple Arcadeの良いところ

昔のゲーム機のように、ゲームが買取式だった頃は、買ってみたらつまらなかったという状況に陥りがちでした。一方で現代のスマホゲームで一般的な、のめり込んだ人から課金する方式では、高額課金を恐れて熱くなれない側面もあります。どんなゲームも定額で試せて、自分が楽しめるゲームを探せるサブスクリプション方式は、良いアイディアだと思います。またApple Arcadeの月額600円という料金はお得なのではないかと思います。

Catalinaで一番期待していたのがApple Arcadeです。macOSを愛する立場からしたら、iOSと同じゲームがmacOSで動作する点が最高に素晴らしいです。追加料金も不要です。また、iOSマシンとmacOSマシン間で、ゲーム進捗状況がある程度同期されるようです。Windowsをインストールしてゲームをするのが自作PCの一つの使い道でしたが、Apple Arcadeの登場で、ゲームのためにmacOSを使うことのメリットがようやく生まれたと思います。

利用してみた

ゲームはヘタレなのでちゃんとしたレビューはできません。超大作という感じのタイトルはあまり無いような気がします。でもAppleが管理しているだけあってどれも完成度は高く、お洒落な画面と効果音の作品が多いです。Mini MortorwaysというSim Cityみたいな街づくりゲームが面白かったです。家と勤務先が現れるので、その間を道路でつないで、通勤自動車を円滑に流すのが目的です。短いターンで終わってしまうので、空き時間で気軽に楽しめました。

‎Mini Motorways

調べてみると同じ会社からMini Metoroというタイトルで、地下鉄路線を設計する同様なゲームがSteamで発売されています。980円です。macOS版のSteamでも動くようです。Mini Mortorwaysはその会社の新作のようです。Steamから出ていたら、同程度の値付けになっていたと思われます。単体で買うなら買取980円の方が得かもしれませんが、この手のゲームを継続していくつか試したい場合にはApple Arcadeの方がお得な気がします。今までmacOS用ゲームプラットフォームとしてはSteamが頑張っていました。でも、Windows, Linux, macOSで展開できるSteamと、iOSとmacOSで展開できるApple Arcadeを比較すると、後者も負けていないと思います。Appleのことなので、一つコードを書けば、iOSとmacOSの両方で動く仕掛けを用意しているはずです。なので今後は開発者が、macOS版SteamからApple Arcadeに移行していくかもしれないです。今後の品揃えに期待したいです。

Hackintoshで動かす

Appleのサーバで提供されるサービスですので、App StoreやiCloudなどと同じように注意してHackintoshを設定する必要があると思います。ただ、iMessageでの設定ほど厳格ではないような気がします。いずれにしても、iMessageが動く程度のしっかりした設定を行なった方が良いと思います。こちらをご覧ください。

iMessageを動かす

EULAに反してOSを使わせていただいているので、エコシステムの養分になってお礼をしていきたいと思います。macOSユーザが増えることでエコシステムが栄えることになれば、今後も黙認し続けてくれるかもしれないです。

まとめ

Apple ArcadeはHackintoshで問題なく動きます。画面の動きも、実機と同様です。iOSのアプリがmacOSで動くのは面白い体験です。でもiOSとmacOSはほとんど同じものですので、親和性が高いのは当然です。Windows 8でモバイルとの統合を強行して失敗したMicrosoftと違って、Appleは順当に統合を進めているようです。次はiOSアプリがmacOSで動くようになるかもしれないです。

HackintoshでSidecarを使う

Sun, 27 Oct 2019 00:45:55 +0900

Catalinaで導入されたSidecar機能が無線接続で使えました。使用したWiFi/BluetoothモジュールはBCM94360CDとFenvi T919です。どちらも最初は有線でのみ動作してましたが、うやむやのうちに無線でも動くようになりました。

Sidecar動作のための条件

Sidecarを使うと、iPadがmacOSマシンのセカンドディスプレイになります。ミラーリングもできます。またiPad側のApple Pencil操作で、macOS画面を操作できます。でもSidecarを動かすためには、いくつかの条件が必要なようです。必要そうな条件を以下にあげました。Hackintoshでは、この条件は間違っているかもしれませんし、今後のアップル社の対応で変わってくるかもしれません。

Apple IDと無線

実機のMacでは、macOSマシンとiPadが

同じApple IDでログインしていること、
同じWiFiに接続していること（有線LANでは駄目です）、
Bluetoothの到達範囲にあること、

がSidecarを使う条件だと言われています。もちろんHackintoshでも必要条件です。USBケーブルでSidecarする場合には、無線条件が満たされていなくても大丈夫のようです。

iGPUの条件

試したところでは、BIOSレベルでiGPUが機能していることが必要のようでした。macOSからiGPUが認識されている必要はないようです。なのでグラフィックスカードを使用しているマシンでも問題ありません。BIOSからiGPUを無効にしていると、Sidecarで接続はしても画面が暗いままです。おそらくは、iGPUの画像圧縮機能を使って、画面を転送しているので、それがないと表示されないのだと思われます。後述するようにBIOS設定でiGPUがマルチモニターで動くように設定します。

追記：コメントでは、iGPUの無いXシリーズCPUでも動いたという情報をいただきました。

T2チップ搭載の機種IDは使えない

コメントでいただきましたが、tonymacx86の情報によると、T2チップ搭載機種IDを使ったHackintoshではSidecarは動かないらしいです。T2チップ搭載モデルでは、Sidecarの認証または画面圧縮にT2チップを使っているのだと思われます。なので、以下のページで示された機種IDを使用している場合は、Sidecarは使えません。

Apple T2 セキュリティチップ搭載モデルの Mac

BCM94360CDで動かす

最初は、Z390+9900Kを搭載したマシンでSidecarを試した経緯を書いておきます。このマシンのパーツ構成、ESP構成、config.plistなどは、下のリンクを見てください。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

使用しているWiFi/Bluetoothモジュールは、純正のMacで使用されているBCM94360CDです。以下の製品です。これをPCIeカードに挿して使用しています。

HackintoshでSidecarを動かす前に、同じiPad/Apple PencilとMacBookで動作確認しました。この場合は、Sidecarが問題なく動きました。次に、このHackintoshで試したところ、画面は出たのですが、有線接続でしか動きませんでした。iPadをUSB接続しない状態では、システム環境設定・Sidecarの「接続先」に「デバイスなし」と表示されてしまい、iPadが現れません。

有線で接続すると、接続先が選べるようになり、iPadが選択できます。MacBookでは無線でも問題なく接続できるので、Hackintoshなりの調整が色々必要なのだと思って、しばらく放置していました。ところが、何かの拍子で繋がるようになりました。実際に何をしたのかというと

Z390マシンとiPadを有線接続でSidecarしました。
Apple Pencil をペアリングするためにiPadから線を外してPencilを挿しました。
この時「接続が切断されるよ」というような内容のダイアログがiPadに出ました。
ペアリングが終わってPencilを外したらなぜか無線でSidecar接続しました。

これで無線でもiPadが選択できるようになりました。iPadがセカンドディスプレイになりますし、またPencilを使って画面操作もできます。Hackintoshであっても、Sidecarの本来の機能は全て利用できていると思います。

これ以前に、有線でSidecar接続中にUSBケーブルを外すことは試みていました。でも接続が切れるだけで、無線では接続できませんでした。今回なぜ可能になったのかわかりません。

今回行ったPencilペアリング操作は、無線接続できたことは多分無関係です。SidecarはApple IDを介して動作していると説明されています。それぞれのマシンが同じApple IDで動作していることがSidecarを使うための条件です。なので対になるマシンの認定をアップル社のサーバーが行なっているはずです。今回、無線接続できた理由は、何らかのきっかけ、時間経過、またはアップル社の方針変更によって、Sidecar動作条件が満たされたからだと思います。有線接続の場合は、直接接続されていることが確実なので、ペアリング認定条件が緩かったのでしょう。このようなmacOS機能は、iMessageやFaceTimeと同じく、動作するかどうかはアップルのサーバー次第です。条件はいつでも変化するし、真相は謎のままです。

Fenvi T919で動かす

次に、Fenvi T919でも試しました。以下で紹介した無線PCIeカードです。中身は、おそらくBCM94360CDと同一と思われているので、問題なく動くはずです。

WiFi/BluetoothアダプタFenvi FV-T919

使用したマシンは、以下で紹介したMSI B360M MORTAR TITANIUMに9600Kを搭載したHackintoshです。

MSI B360M MORTAR TITANIUM, 9600K

こちらも最初は接続できませんでした。Sidecarの接続先がグレーになっていて、iPadが選択できませんでした。しかし、Z390マシンでSidecarが可能になった後で、こちらもどう言うわけか、iPad選択できるようになっていました。Sidecarのペアリングを管理するサーバの設定が変わったのかもしれません。しかしZ390マシンの場合とは違って、iPadをSidecar接続しても、iPad画面が真っ暗でした。画面をミラーリングにしてApple PencilでiPadを操作すると、macOS画面のポインターは動きます。なので、遠隔ポインティングは効いているけど、表示が出ていないことがわかります。

Sidecarのビデオ転送にはiGPUの機能が使われているらしいと言う話を聞いたことがありましたので、iGPUをチェックすることにしました。BIOSで設定を見るとIGD Multi-Monitorの設定がDisabledになっていました。iGPUにもモニターを接続して、マルチモニターにするかどうかの設定だと思います。Disabledの場合は、iGPUの機能を無効にしていると思われます。そこで、これをEnabledにしました。メモリの設定はデフォルトの64MBにしました。この結果、無事にiPadに画面表示されるようになりました。

まとめ

HackintoshでもSidecarが動きました。USB有線接続なら問題なく接続できました。無線経由では、最初は接続できませんでしたが、よくわからないうちに無線接続できるようになっていました。また接続を実現するためには、通常のMac/iPadの条件に加えて、iGPUが動いている必要があるようです。とはいえiGPUを搭載していないiMac ProでもSidecarは可能なようなので、機種IDにも依存しているのかもしれません。

今回、Apple Pencilを初めて使ってみました。使い勝手や速度はちゃんとしてました。でもiPadに差し込むという初代Apple Pencilの充電方式は、緊急時には良いけど、普通に充電したい場面では使いにくいです。そのうちにこんなアクセサリを揃えてみたいと思ってます。

base64コマンドの使い方

Wed, 16 Oct 2019 23:52:12 +0900

Base64変換（文字列を変換）

echo -n "AMD RX 580" | base64
QU1EIFJYIDU4MA==

Base64変換（16進数を変換）

echo -en "\x9B\x3e\x00\x00" | base64
mz4AAA==

Base64逆変換（文字列をデコード）

echo QU1EIFJYIDU4MA== | base64 -D
AMD RX 580

Base64逆変換（16進数をデコード）

echo mz4AAA== | base64 -D | hexdump
0000000 9b 3e 00 00 
0000004

いつも使い方を忘れてしまうのでメモしておきます。Base64はバイナリーデータを文字で表記する場面でよく使用されます。config.plistでもお馴染みです。なので、時々、変換・逆変換したいことがあります。そのためのツールはたくさんありますし、変換してくれるwebページもあります。でも、ターミナルから使えるbase64コマンドならすぐに使えて便利です。使い方さえ忘れていなければ。

Base64の仕組み

文字しか表記できない・通信できない環境で、任意のデータを効率良く表現するために考えられました。英大文字、英子文字、数字、記号(+と/) に数字を割り当てます。アルファベットは26文字なので、Aが0でZが25です。引き続き小文字のaに26を割り当ててzまで使うと51まで表現できます。この後、数字の0 (=52)から9 (=61)を割り当てると、61まで表現できます。後2つあればキリが良いので、+ (=62)と/ (=63)を最後に使います。これで、A~~Z, a~~z, 0-9, +, /を使って0から63を表現できます。64進数です。ビット数は6ビットになります。

通常のコンピュータのデータはバイト単位、8ビット単位です。なので上位から6ビットごとに区切って変換します。端数は0ということにします。例えば、ASCIIコードで大文字のAは、0x41です。ビットで表すと、0100 0001です。6ビットに分けると、010000 01です。端数に0を追加すると、010000 010000です。010000は10進数で16になり、これが2個続きます。16には、Base64では、17番目のアルファベットQが割り当てられています。なのでBase64で表すとQQになります。また、Base64では4文字の倍数になるよう調整します。足りない部分には＝を追加します。ということで、大文字AをBase64で表現すると、QQ==になります。

base64コマンド

macOSにはターミナルから使えるbase64コマンドがあります。使い方は以下です。

 base64 [-h | -D | -d] [-b count] [-i input_file] [-o output_file]

I, oオプションで入出力ファイルを指定できますが、指定しなければ標準入出力が使用されます。hはヘルプ表示です。bで数値を指定すると、出力に改行を入れてくれます。Dオプションしか使うことはないと思います。オプションなしならエンコード、Dオプションでデコードです。

標準入出力を使うので、echoコマンドをパイプします。echo helloとタイプするとhelloという文字が表示されるのですが、デフォルトでは最後に改行が入ります。-nオプションで改行を出さないよう指定できます。echoコマンドを、16進数標示するhexdumpコマンドにパイプしてみます。こんな感じです。0aが改行コードです。

% echo hello | hexdump
0000000 68 65 6c 6c 6f 0a 
0000006
% echo -n hello | hexdump
0000000 68 65 6c 6c 6f 
0000005

なのでhelloという文字列だけ（改行は不要）をBase64にしたい場合は、

% echo -n hello | base64
aGVsbG8=

とします。結果が7文字だったので＝が1個追加されました。-Dオプションで元に戻してみましょう。

% echo aGVsbG8= | base64 -D
hello

echoで16進数を出すのはちょっと面倒です。0x01, 0x02, 0x03という3バイトを出すには、”\x01\x02\x03″と書きます。\xで次の2文字が16進数だということを表現します。またこのように\xで16進数渡すためには-eオプションが必要です。hexdumpにパイプして確認します。

% echo -en "\x01\x02\x03" | hexdump
0000000 01 02 03 
0000003

これをbase64にパイプすれば、変換できます。

% echo -en "\x01\x02\x03" | base64 
AQID

逆変換して確認しておきます。

% echo AQID | base64 -D | hexdump 
0000000 01 02 03 
0000003

CatalinaにしたらCloverがインストールできない

Sat, 12 Oct 2019 12:14:13 +0900

CatalinaからCloverをインストールしようとすると、Cannot install without ensuring the file system is read-write というメッセージが出て、インストールできませんでした。これはSIP設定で回避できます。手作業でインストールする際には問題にならないので、将来のインストーラで対応されるかもしれません。

インストールできない

Catalinaからファイルアクセスの制限が厳しくなったと感じています。いろいろなアプリケーションにファイルアクセスの許可を出したり、ネットからのダウンロードを許可する作業などが必要になりました。システムの一部が読み出し専用になったことも関係していると思います。その影響で、インストーラでCloverをインストールしようとすると、上記のようなダイアログボックスが出てインストールできないことがあります。このようなソフトウェアインストーラは、macOS標準の「インストーラ.app」を使っています。/System/Library/CoreServices/に置かれているアプリケーションです。エラーメッセージは、このアプリケーションが引き起こしていると考えられます。

対策をネットで調べると、「リカバリーモードで再起動してターミナルからSIPを無効にすれば良い」という回答がありました。先日の記事へのコメントでも同様の方法を教えていただきました。ありがとうございます。ちなみに、リカバリーモードでSIPを解除しても、次の次の起動ではちゃんと元に戻るそうです。

r/hackintosh - Clover - Cannot Install w/o Ensuring File System is Read/Write

でもこの方法だと、インストーラを動かすまでに2回の再起動をする必要があります。手間の少ない方法を考えました。

SIPを限定解除

Hackintoshのconfig.plistで、SIPを全部外した設定をしていれば、このメッセージは出ないのかと思います。手元のマシンでは、できるだけバニラな設定にして実機と同じにしたいと考えていたので、SIPも全部有効になってました。なのでターミナルで確認すると、以下のように、SIPは全項目で有効になっていると表示されます。

% csrutil status
System Integrity Protection status: enabled.

SIPは色々な保護をしてくれますが、今回の問題に対してはファイルシステムへの制限を解除すれば良さそうです。SIPを完全に機能させている場合、config.plistのCsrActiveConfigの数値は、

<key>RtVariables</key>
<dict>
 <key>CsrActiveConfig</key>
 <string>0x00</string>
</dict>

となっていると思います。これの下位2ビット目を立てて、例えば、

<key>RtVariables</key>
<dict>
 <key>CsrActiveConfig</key>
 <string>0x02</string>
</dict>

のように書き換えれば良いです。でも、SIPを元に戻すにはまたこれを書き直すことになり面倒です。そこでCloverの起動画面のOptionから変更しました。まずは、下のメニューからOptionsを選択します。

次にSystem Parameters, System Integrity Protection (SIPのことです)と選んでいきます。SIPの設定は、config.plistで全部有効にしてあるので、設定値が0になってます。

ここでSIPの各項目を設定できるので、Allow Unrestricted FSを選びます。FSはファイルシステムの意味で、ファイルシステムアクセスの制約を外すという設定です。

これで起動すると、SIPが限定解除されています。ターミナルで確認すると、

% csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: disabled
Debugging Restrictions: enabled
DTrace Restrictions: enabled
NVRAM Protections: enabled
BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

のように表示されます。Filesystem Protectionsが無効になっています。どういうわけかApple Internalも無効になっていますが、セットで設定すべき値なのかもしれません。この状態でCloverインストールを行うと、問題なく実行できます。Cloverの起動画面で一時的に設定しましたので、次の再起動ではSIPは元に戻っています。

Catalinaにアップデートする

Wed, 09 Oct 2019 20:02:46 +0900

macOS Catalina 10.15の配布が開始されました。早速、Mojaveからアップデートしました。Cloverとkext類を最新版にすれば、時間はかかるものの通常の作業でアップデートできるようです。

アップデートの準備

昨日 (2019/10/8 JST)、macOS Catalina 10.15の配布が開始されました。例年だと1-2週間前に配布開始日がアナウンスされたのですが、今回は突然のことでした。慌ててインストールしたのですが、インストールが止まって見えてしまうトラブルがあって報告が遅れました。実は、単に時間がかかっていただけのようでした。

システムの構成

インストール先のマシンは、こちらです。

MSI B360M MORTAR TITANIUM, 9600K

これに取り付けたCrucialの1TB M.2 SSD, CT1000P1SSD8にインストールしました。

Crucialの1TB NVMe M.2 SSD (CT1000P1SSD8) を使う

光学ドライブとTimeMachine用のHDDなどが接続されているのですが、わかりやすいように一時的に取り外した状態で進めました。また、起動ボリュームは慣例に従ってMacintosh HDにしてあったのですが、これもわかりやすいようにMojaveにしました。ということで、diskutil listコマンドで見ると、次のように見えます。

$ diskutil list
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 1000.0 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk1
Physical Store disk0s2
1: APFS Volume Mojave 629.6 GB disk1s1
2: APFS Volume Preboot 47.5 MB disk1s2
3: APFS Volume Recovery 510.4 MB disk1s3
4: APFS Volume VM 3.2 GB disk1s4

SSDにはEFIシステムパーティション(ESP)と、APFSコンテナのパーティションができています。APFSコンテナのパーティションは、SSDの空きを全て割り当てて確保してあります。APFSコンテナの中には、改名したばかりのMojaveという名前のメインボリュームがあります。macOSのシステムもデータも全部がこの中に入っています。PrebootはFileVault用のボリューム、Recoveryはリカバリーモードで起動するためのボリュームです。VMは仮想メモリー用のボリュームです。APFSのボリュームは、サイズが可変で、必要な容量に対して柔軟に対応できます。

ESPを最新にする

バニラなインストールをしているので、Hackintoshに必要なファイルは全てESPに入っています。Catalinaに備えて、この内容を最新にアップデートしておきます。開発者の皆さんが対応してくださっていますので、アップデートで発生する問題の多くは、Cloverやkextが最新版にすることで対処できます。現時点でのCloverの最新バージョンは、5070です。最新でしたのでそのままにします。次に、Kext Updater.appで使用中のkextを最新にします。手元のシステムでは、WhateverGreen.kext, IntelMausiEthernet.kext, AppleALC.kextを更新しました。更新したら、念のために再起動して、Mojaveとして起動することを確認しておきます。

新ボリューム作成

現在のMojaveに上書きアップデートしても問題ないとは思います。でも念のためにMojave環境は残しておきたいです。また、せっかくだから気持ちよくクリーンインストールしたいとの考えもありました。APFSなら、新しいボリュームを作成するのは簡単です。ディスクユーティリティ.appを開いて、Macintosh HDという名前の新しいボリュームを作成しました。（よく考えたらもはやHDじゃないですね）

念のためにdiskutilコマンドでも確認しておきました。

$ diskutil list
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 1000.0 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk1
Physical Store disk0s2
1: APFS Volume Mojave 631.1 GB disk1s1
2: APFS Volume Preboot 47.5 MB disk1s2
3: APFS Volume Recovery 510.4 MB disk1s3
4: APFS Volume VM 3.2 GB disk1s4
5: APFS Volume Macintosh HD 647.2 KB disk1s5

Catalinaをダウンロードする

これで準備万端ですので、Mojaveで起動して、「システム環境設定」「ソフトウェアアップデート」を開いて、Catalinaをダウンロードします。8GBあるようです。

インストールする

ダウンロードするといつものように自動的にインストーラが開きます。デフォルトのインストール先は、現在起動しているMojaveになっていますが、新しく作ったMacintosh HDを選択します。

インストールが始まると、間も無く再起動します。再起動時のCloverの起動選択画面では、Boot macOS Install from Macintosh HDを選択します。デフォルトでこれが選ばれていると思います。

このあとインストール画面になります。今回の環境では、この先が長かったです。About 11 minutes remaining…という表示が出たまま、インストールが止まってしまったように見えました。小一時間様子を見たのですが、変化がありません。そこで強制終了していろいろ試したのですが、どうしても11分のところで止まってしまいました。仕方がないので、そのまま一晩放置したところ、インストールが終わっていました。単に、時間がかかっていただけだったようです。

実は以下で紹介したZ390マシンでも、同様な手順でCatalinaのインストールを並行して行いました。そちらでも、やはり11分で止まりました。でもZ390マシンはしばらくするとインストールが進みました。ということで、Catalinaへのアップデートでは辛抱強く様子を見る余裕が必要だと感じました。ちなみに本物MacのCatalinaアップデートでは、プログレスバーが停滞することはなく、割と順調に進みました。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

インストールが終了すると、再び再起動します。今度は、インストール用のボリュームは消えていて、Boot macOS from Macintosh HDに変わってます。この挙動はいつものアップデート作業と同じです。

インストール途中で、TimeMachineバックアップや他のMacのデータを転送するかどうかを聞かれます。最初の手順で、Mojaveのドライブを残してありました。これが転送元の選択肢に現れますので、これから復帰しました。クリーンインストールという観点からすると、古いデータを引き継ぐことになってしまうかもしれませんが、設定は楽です。ユーザデータは大量になるので、それ以外の設定とアプリケーションだけを引き継ぎました。ユーザデータは、古いUsers以下のディレクトリを、システム環境設定のアカウントで指定すれば簡単に引き継げるので、ここで転送する必要はないと思いました。

インストールが終了した状態で、diskutilコマンドでボリュームの様子を見てみます。インストール先のMacintosh HDに加えて、Macintosh HD – Dataという名前のボリュームができています。これがCatalinaから新しく作られたボリュームです。インストール先に指定したMacintosh HDボリュームは読み出し専用になって、保護されているらしいです。- Dataのついたボリュームに、ユーザデータを含む、書き換えするデータが置かれるようです。

% diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 1000.0 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk1
Physical Store disk0s2
1: APFS Volume Mojave 639.0 GB disk1s1
2: APFS Volume Preboot 129.2 MB disk1s2
3: APFS Volume Recovery 1.0 GB disk1s3
4: APFS Volume VM 3.2 GB disk1s4
5: APFS Volume Macintosh HD - Data 47.6 GB disk1s5
6: APFS Volume Macintosh HD 10.6 GB disk1s6

まとめ

インストールに時間がかかったので、待ちきれなくて試行錯誤してしまいました。でも、我慢強くじっと待っていればCatalinaへは何事もなく順調にアップデートできたと思います。

kextd stallというエラーで起動しないことに対処

Sat, 05 Oct 2019 14:06:57 +0900

10.14.6追加アップデート2を入れたマシンのうち1台が起動しませんでした。APFSが原因でした。ApfsDriverLoader.efiを外して10.14.6 (18G103) 付属のapfs.efiに差し替えたら起動しました。

症状

2019年9月27日にmacOS Mojave 10.14.6追加アップデート2 (Supplemental Update 2) が配布されました。ビルドは18G103です。追加アップデートの名前の最後に2という番号がつくのは珍しいと思います。Catalinaがまもなく出るので、おそらく最後のバージョンになると思います。追加アップデートを続ける理由は、もしかしたらMojaveを10.14.6で終わりにして、バージョン番号をあげたくなかったのかもしれません。

いくつかのマシンで、アップデータ経由で通常通りの更新が問題なく可能でした。ただ、iMac19,1に設定した9600Kマシン

MSI B360M MORTAR TITANIUM, 9600K

では、どういうわけか起動しませんでした。最近は大体問題なくOSアップデートできるのですが、たまにこういう状況になるのはHackintoshの宿命で仕方ないところです。

-vオプションで調べた症状は以下のようです。Cloverのメニューは出て、メモリー確保も正しく行えるのですが、その後メッセージが続いた後、表示が止まってしまいます。しばらく経過すると画面には、

busy timeout[0], (60s): 'iMac19,1'

という表示が出ます。iMac19,1に設定したこのマシンが60秒間応答しないという意味だと思います。この状態で、キーボードを接続すると、

kextd stall[1], (60s): 'Magic Keyboard'

というような表示が出ることもあります。

また、いろいろなUSB機器を抜き差しすると、同様にkextd stallというメッセージが出ます。

原因の推測

メッセージのkextdは、kext daemonのことだと思います。kext (カーネル拡張) を読み込んでカーネルに登録する機能を担っていると思われます。stallは、自動車のエンスト（エンジンストール）と同じ単語で、応答がなくて動かない、という程度の意味でしょう。つまりメッセージから判断するに、kextデーモンが特定のkextを呼び出そうとしたけど、60秒経っても応答がないようです。

失敗しているkextはどれもmacOS本体のkextです。Clover類はESP (FAT) にありますが、macOS本体のkextは主パーティション (APFS) の中にあります。となるとAPFS (アップルファイルシステム) の読み出しに失敗している可能性があると考えました。また、上記で紹介したtimeoutメッセージも、APFSからの読み出しをする局面になって、マシンから応答がなくなりタイムアウトしたとも解釈できます。

apfs.efiで解決

CloverがAPFSにアクセスするためには、macOS本体のapfs.efiを使っています。以前はmacOSからAPFSのドライバーである

/usr/standalone/i386/apfs.efi

をESPにコピーして使っていたのですが、最近は、 ApfsDriverLoader.efiを使って、macOSから自動的に読み込んでいます。動的に読み込むことで、macOSのバージョンに合わせたapfs.efiが使えるメリットがあります。でも今回は、この仕組みが何らかの理由で機能していないようでした。そこで、EFI/CLOVER/drivers/UEFIの中の

ApfsDriverLoader.efiを削除して
macOS本体からapfs.efiをコピー

しました。すると10.14.6 (18G103) が立ち上がりました。

実際に行った手順は、もう少し複雑です。というのは、このマシンは起動しないのでapfs.efiを取得できません。そこで、別のMacにUSBメモリーを挿して、これに

cp /usr/standalone/i386/apfs.efi /Volumes/USB

のようにしてapfs.efiをコピーします。次にこのUSBメモリを、起動しないマシンに接続し、CloverのメニューからUEFI Shellを起動し、cpコマンドでESPのEFI/CLOVER/drivers/UEFIにコピーしました。また、ApfsDriverLoader.efiは、rmコマンドで削除しました。UEFI Shellの使い方は、以下をご覧ください。

起動しないマシンをUEFI Shellで救う

ApfsDriverLoader.efiが動かなかった理由は不明です。他のマシンでは18G103でも動いていますので、このマシンだけの問題かと思います。ApfsDriverLoader.efiのアップデートで解決するかもしれません。何れにせよ、起動でtimeoutやkextd stallのメッセージで止まる場合には、APFS関係を疑うと良いかと思いました。

USB機器がスリープを阻害することがあります

Sat, 07 Sep 2019 20:51:21 +0900

スリープするとすぐに目覚めてしまうマシンがありました。ずっと諦めていたのですがようやく原因がわかりました。5インチベイに取り付けたUSBハブでした。取り外したら正しくスリープし続けるようになりました。

スリープからすぐに目覚める

こちらで紹介したコンピュータ（ASUSのZ390チップセットマザーボードを使用）が、ここのところずっと、スリープからすぐに目覚めてしまう問題を抱えていました。一旦はスリープに入るのですが、2~3秒で目覚めてしまいます。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

上の記事を書いた時点では、ケースに入れない状態で仮組をして動かしていたのですが、その時は正しくスリープしていました。ケースに入れて、本格的に使用し始めたら、スリープからすぐに目覚める現象が発生しました。pmset -gなどで目覚める原因を調べると、色々なデーモンがスリープを解除したと表示されて、またiCloudやDropboxの同期がずっと動いて、ドライブへのアクセスが続いていたので、環境構築過程の一時的な状況だと思っていました。

でもよく思い出してみたら、このマザボの先代のMSIのマザーボードでも同様にスリープから目覚める問題がありました。6年くらい前から引きずっていた問題でした。MSIマザーボードでは、BIOSメニューからOSからスリープ復帰しないという設定をして、電源ボタンでスリープ復帰していました。新しいASUSのBIOSでは同様な設定項目が見つからなくて、回避できません。そこで本格的に原因究明することにしました。

目覚めのきっかけ

スリープから目覚める原因には色々なものがあります。電源遮断するのではなくスリープすることの目的は、すぐに目覚めて動作再開することです。ですから、いろんなきっかけで目覚める事自体は正しい動作と言えます。

目覚めのきっかけは、大きく分けて2通りに分類できると思います。一つはOSのデーモンが引き起こす目覚めです。Power Napなどは代表的なものです。iCloud関連の同期や、Spot Lightの索引作成作業もスリープを妨げるようです。実際の仕組みは、RTCを目覚まし時計のように使って、デーモンが一定時間間隔で動作しているものと思われます。もう一つは入出力関係の信号変化です。キーボードを押すとスリープ復帰しますが、これはUSBに信号が来ることがきっかけです。他にも、ネットワーク, SATA, ディスプレイなどからの信号でスリープ復帰することもあります。

目覚める原因を調べる

macOSで設定する

目覚めの原因になりそうな要素を取り除いていくことで、原因究明できると考えました。

まずは「システム環境設定」の「省エネルギー」で、「ネットワークアクセスによるスリープ解除」「Power Napを有効にする」のチェックを外します。また、「Bluetooth」の「詳細設定…」で、「Bluetoothデバイスでコンピュータのスリープ解除を可能にする」のチェックも外します。これで、一般ユーザ向けのmacOS設定でできることをやり尽くしたはずです。でもスリープからすぐに復帰する問題は解決しませんでした。

ネットワークは問題なし

不本意なスリープ復帰は、ネットワークがらみで発生することも多いようです。そこで、まずはLANケーブルを取り外し、WiFiをoffにしました。これでネットワークからの働きかけで目覚める事はなくなると思いました。でも、スリープからすぐに復帰してしまいました。

USBとBluetoothを調べる

次に、バックパネルのUSBケーブルを全部外しました。これでもすぐに復帰します。Apple純正Magic Trackpad/KeyboardをBluetooth接続しているのですが、BTもoffにしてみました。その代わりに前回ご紹介した非Bluetooth接続の無線キーボードを取り付けました。それでもすぐに復帰します。OSでBTをoffにするのでは生ぬるいのかもしれないと考えて、BTアダプタが接続されているUSBポートをoffにしました。本当はケースの蓋を開けてコネクタを外すのが確実だったのですが、面倒だったので、まずはUSBInjectAll.kextの機能を使いました。config.plistのブートオプションに、以下を追加しました。BTはHS13に接続しているからです。これで13番目のUSB 2.0ポートが無効になります。するとスリープし続けるようになりました！

uia_exclude=HS13

どうもHS13に接続されている何かが問題のようです。ここには純正BTアダプタのBroadcom BCM94360CDが接続されています。macOSと高い互換性のあるアダプタでOOBで動くはずのものです。ここでようやく、ケースの蓋を開けてBCM94360CDのUSB接続を外しました。そしてuia_excludeの設定を削除してもと通りに戻しました。なんとスリープからすぐに復帰する現象が再発するようになりました。ということで、HS13が原因であるものの、これに接続したBTモジュールの問題ではなかったようです。

原因は5インチベイI/Oパネル

実は、ASUSのこのマザーボードでは、HS13はマザーボード内部のUSBハブに接続され4本に分岐します。これらはマザーボード上の4個のUSB 2.0ピンに接続されています。取扱説明書の図を以下に引用します。USB_E12とUSB_E34が、HS13から分岐したUSB 2.0ピンです。

そのうち1個 (USB_E34のうちの1つ) がBTアダプタに接続されていて、今はそれを外したところです。残りのUSB 2.0ピンのうち、2個 (USB_E12) は、実は5インチベイに取り付けたUSBハブ＋SDカードリーダーに接続していました。もう販売中止になっているこの製品です。これを買ったのがちょうど6年前でした。スリープが解除される現象が発生した頃です。

この5インチベイパネルには、USB 3.1 gen1ポートとUSB 2.0ポートがぞれぞれ4個あります。またUSB 3.1 gen1接続のSDカードリーダが搭載されています。このうちのUSB 2.0ポートをHS13 (USB_E12) に接続していました。そこで、マザーボードからこの5インチベイパネルへの接続を外してみました。するとスリープからすぐに復帰してしまう現象は治まりました。5インチベイアダプタの中にあるUSB 2.0ハブが、スリープ直後になんらかの信号（ノイズ？）を出して、スリープを妨げているようです。USB 3.1の接続には問題ないようなので、USB 3.1ポートとSDカードリーダは引き続き使用できます。でもUSB 2.0のポートは諦めました。

まとめ

スリープからすぐに目覚めてしまう原因はUSBハブでした。pmsetコマンドやDSDTファイルを駆使して高度な技術で解決するのだと意気込んでいたのですが、あっけない結末でした。USB機器は、スリープ設定でトラブルの原因になりがちな気がします。以前にも、USBスピーカーが原因でスリープしないことがありました。スリープ開始でUSBスピーカへの供給電源が遮断されることで、USB信号線に何らかの信号（ノイズ？）が出るようで、これが引き金でスリープを妨げていました。その時は、外部電源からUSB電力を供給し続けるタイプのUSBハブを調達して、これを介して接続したところスリープするようになりました。何らかの入力によってスリープが復帰される状況自体は、ソフトウェアとしては正しい動作です。なので、機器を取り外して様子を見るという単純なアプローチが有効なようです。

格安のトラックパッド付き無線キーボード

Wed, 04 Sep 2019 19:45:28 +0900

macOSの操作には純正キーボードとトラックパッドがお勧めです。しかしBluetooth (BT) 接続なので、OS起動前段階のBIOSやCloverの操作で使えないことがあります。なので非常用に非BT方式のトラックパッド付き無線キーボードを調達しました。

BIOSとCloverの設定

macOSが起動する前段階で、BIOS (UEFI) の設定を変えたい、Cloverの設定を変えたい、EFI Shellを使いたいなど、キーボードを使いたい場面は多いです。ポインティングデバイスも使いたいかもしれません。そこで、macOS起動前に使用する入力装置の選択肢について考えてみます。

Bluetooth HID Proxy

以前に紹介したように、macOSの操作には純正キーボードとトラックパッドがお勧めです。特にトラックパッドで実現できるマルチタッチジェスチャは便利で、これなしでは使いやすさが売りのmacOSが台無しです。

Magic Trackpad 2は良いです

純正のトラックパッドを使うなら、キーボードもデザイン統一された純正BTキーボードを使うことになります。でもOS起動前にBluetoothキーボードを使用しようとしても動作しない場合があります。というのはBTを制御するプログラムはOSのドライバとして提供されているからです。OSの指示でペアリングをしてデータ通信を確立しています。なのでOSが起動する前の段階ではBluetoothドライバは使用できないのです。

それでは不便だということで、HID Proxyという機能が用意されています。BT入力機器と簡易的にペアリングをして、HID（Human Interface Device, 具体的にはマウスやキーボードのこと）として機能させる仕組みです。本物のMacでも、macOS起動前に、オプションキー組み合わせでNVRAMをクリアしたり、起動ドライブが選択できます。これはHID Proxyのおかげです。この機能はBluetooth受信機に組み込まれているものなので、対応していない受信機もあります。Broadcom製の純正BTアダプタは対応しています。なので、HackintoshでもApple純正BTキーボードでBIOS/Cloverの設定を行うことが可能です。

Magic KeyboardをUSB接続

とはいえ、HID Proxyは時々失敗します。特にBIOS設定画面に入れないことがあります。マシンが起動直後なので、HID Proxyの準備が間に合わないのが原因ではないかと想像しています。キーボードが接続されていないという警告をBIOS起動画面が表示する場合は、HID Proxyが動いていないと考えて良いです。

最新モデルのMagic KeyboardとMagic TrackPad 2ならば、USBケーブルで有線接続することで、Bluetooth接続がキャンセルされて、通常のUSBキーボード／トラックパッドとして使用できます。ついでに充電できます。なのでHID Proxyがうまく動かない場合は、USBケーブルを用意してマシンに接続すれば良いです。USB接続なら確実です。

話が逸れますが、USBキーボードもBIOS設定に使えなかった時期がありました。PS/2キーボードからUSBキーボードへの移行直後のしばらくの間は、USBキーボードではBIOS設定できませんでした。当時はBIOSがUSBキーボードに対応してなかったためです。なので通常はUSBキーボードを使いつつ、BIOS設定のためにPS/2キーボードが手放せませんでした。

起動前作業用のキーボード

いっそのこと、OS起動前作業専用のキーボードを用意しておくのも良いと思います。ただ、有線USBキーボードは接続に手間がかかります。有線キーボードを用意するなら、Magic KeyboardとUSBケーブルの組み合わせの方が便利です。なので、用意するなら非Bluetooth接続の無線キーボードが良いと思います。非BT接続ならば、USBドングル（コネクターに挿す小さなアダプタ）がペアリングからデータ転送までの全て面倒を見てくれます。マザーボードからはUSB有線キーボードが接続されているかのように見えます。なのでOS起動前の作業に何の支障もありません。たくさんのWindows向けの無線キーボードが、手頃な価格で売られています。これらのUSB受信機ドングルをマシンに常時接続しておいて、BIOS/Clover設定したい時だけキーボードを取り出して電源を入れれば良いと思います。

価格以外にWindows向けのキーボードを使用するメリットがもう一つあります。それはdeleteキーが使えることです。BIOS画面を呼び出すキーとして、昔からdeleteキーが使われてきました。最近ではdeleteキーの他に、ファンクションキーでもBIOS画面を呼び出せますが、メーカーによってキー対応が違います。起動時の短い時間では焦って思い出せないこともあります。deleteキーなら確実です。Appleのキーボードにもdeleteと書いたキーはありますが、実はあれはback spaceキーなので、BIOS画面呼び出しには使えません。

AliExpressでキーボードを買う

独自規格の2.4GHz無線を使用したワイヤレスキーボードは多数販売されています。Amazonで探せば安価なものが見つかります。最近はタブレットPC用の製品も多いですが、それらはBluetooth方式なので、OS起動前作業には不向きです。独自の無線規格のものを選びます。また、トラックパッドやトラックボールのようなポインティングデバイスも一体化したキーボードが便利だと思います。BIOSでポインティングデバイスが使いたいこともありますし、互換性の低いBTアダプタを使う場合には、設定のために非BTのポインティングデバイスが必要になることがあります。

これは好みの問題なのですが、英語キーボードをずっと使っています。なのでJISキーボードじゃないUS配置のキーボードが欲しいと思いました。また、EFI Shellのような玄人向けのツールでは、しばしばUS配列が前提になっていることが多いです。パソコンはもともとUS発祥の技術ですので、ディープな作業をしようとするとUSキーボードが必要になります。ところが国内ではUSキーボードはなかなか入手できません。海外でも展開しているLogicool ( Logitec ) なども、国内ではJISキーボードしか販売していません。

ということでAliExpressを探してみました。海外サイトなのでUSキーボードが多数販売されています。ロシア語、スペイン語、UKなどのキーボードもあります。無線キーボードだけでなく、本格的なメカニカルキーボードの品揃えも多いので、うっかりキーボード沼にはまってしまいそうで危険です。それで選んだ製品は以下です。

送料込みで$17くらいのタッチパネル（トラックパッド）付きキーボードです。格安ですが、問題なく動作しました。探してみたところ、日本のamazonでもそっくりなキーボードを売っていました。ちょっとだけ高いです。

一体型なので、タイピングもポインティングも1台で行えるので便利です。に似た製品です。でも日本ではUS配列のK400が入手困難なのでありがたいです。プラスティック本体が安っぽいですが、K400でも同様なので仕方ないでしょう。K400に比べると、全部のキートップが標準サイズなので使いやすいです。キーボード部分のサイズは25cm x 14cmくらいです。Magic Keyboardとほぼ同じ大きさです。K400は単3電池ですが、この製品は単4電池です。電池の持ちは悪いのかもしれませんが、スリムで片付けやすいです。

タッチパネル部分のサイズは7.2 x 7.2 cmくらいです。同じ製品らしい他の販売店のページには、macOSでタッチ操作が機能しないようなことが書いてありました。でもこれは純正のMagic Trackpadと同等では無いという意味のようです。1本指ポインティングはもちろん、2本指でのスクロール（純正のようにはスムーズではありません）や、2本指タッチでのコンテクストメニュー呼び出しなどは機能します。でもmacOSの多彩なマルチタッチジェスチャは使えません。macOSが起動したらMagic Trackpadに引き継ぐ非常用キーボードなので、単純なマウスとして動けば良いと考えました。

格安海外物なので、日本の技適（技術基準適合証明）マークが無く、厳格には国内で使用してはいけません。でも、Bluetoothは3mくらい離れると動作しない微弱な電波で、おそらくはWiFiの電界強度の1/10以下です。そのうえ電子レンジやUSB 3.1 gen2のノイズだらけの2.4GHz帯なので、数メートルも離れたら測定不可能だと思います。使用時間もOS起動前の短時間ですので見逃してもらえたら嬉しいです。

パワーマネジメント入門

Sat, 31 Aug 2019 18:17:13 +0900

以下で紹介されていた記事の抄訳です。ちなみに原題の101というのは入門とか初級という程度の意味です。アメリカの大学で初学年向け授業の科目番号が100番台で、最初に履修すべき科目番号が101であることに由来しているらしいです。

r/hackintosh - Power Management 101

これを読むとdarkwakeの設定は謎です。いろいろ検索すると、0はPower Napをしない、それ以外はするなど、多少分析しているページもありますが、試してみるしかないようです。また、sleepで再起動してしまうとか、sleepから復帰しないような重篤な状態には対処すべきですが、sleepからすぐ目覚めてしまう症状は、ある程度仕方ないような気がしています。

（以下は上記ページの抄訳です）

Hackintoshが動いたら、次にはパワーマネジメントの設定をします。このガイドは、macOSがインストールできていて、安定して使用できていることを前提としています。まずはパワーマネジメントに関連したマシンの状態を説明します。

Shutdown: macOSが終了してハードウェアへの電源供給がoffになった状態です。新しいセッションを始めるためには、電源スイッチを押します。
Hibernate: macOS はセッションの内容をRAMからディスクに書き込み、RAMの内容を消去します。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はディスクに保存した状態へ復帰します。
Hybrid: macOS はセッションの内容をRAMからディスクに書き込み一方で、RAMの内容も保持します。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はRAMから読み込まれますが、スタンバイ中に電源が途絶えてRAMの情報が消えていた場合はディスクから読み込まれます。
Sleep: macOSはセッションをRAMに保持してディスクには書き込みません。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はRAMから読み込まれます。スタンバイ中に電源が途絶えてRAMの情報が消えていた場合は、元に復帰できないので、新規に起動します。

以下ではターミナルを使うことになります。高度な電力制御設定をしてくれるGUIツールはありません。また管理者のみが行える設定のために、sudoやsuコマンドも使います。以下の作業で使う一番重要なコマンドは、次のものです。

pmset -g assertions – パワー状態を邪魔した原因を簡潔に示します。
pmset -g log – logからパワー状態を詳細に示します。

電力管理設定を行う前に、configでdarkwake=0フラグを指定しておく必要があります。ここで=の後にyesやnoをつけては駄目です。0から10までの数字を指定します。そしてシステム環境設定を開いて以下の設定をします。

省エネルギー > ・・・コンピュータを自動スリープさせない > （チェックする）
省エネルギー > 可能な場合はハードディスクをスリープさせる > （チェックする）
省エネルギー > ネットワークアクセスによるスリープ解除 > （チェックを外す）
省エネルギー > Start up automatically after power failure > （チェックを外す）
省エネルギー > Power Nap を有効にする> （チェックを外す）
Bluetooth > 詳細設定 > Bluetoothデバイスでコンピュータのスリープ解除を可能にする > （チェックを外す）

スリープした後で、オーディオが動かなくなる場合があります。その時は、最初にAppleALCを試してみます。次にCloverオプションのAFGLowPowerStateを使ってみます。どちらも駄目で、まだCodecCommanderを入れてなければ、これが役立つかもしれません。Darkwakeは後で扱うことにして、ここでは簡単な部分を手がけます。

この記事の最初に示したスリープの状態から、どれを使うかをまずは決めます。もし電源喪失が心配ならば、3を使います。私は安心のために3を使っています。（訳注：デスクトップの場合は0で良いと思います。）

hibernatemode=0 – デスクトップのデフォルト。基本的なスリープ（訳注：手元の10.14.6 19G95ではiMac19,1でもデフォルトが3でした。）
hibernatemode=3 – ラップトップのデフォルト。ハイブリッドと呼ばれている。
hibernatemode=25 – pmsetからのみ設定可能。伝統的なHibernate。

どれを使用するか決めたら、それを指定します。でも、この変更を有効にする電源状況も指定することになります。pmsetコマンドは、いくつかのタイプの電源に対して設定できて、それらは-a, -b, -c, -uで指定します。

-a 全ての電源を対象にする
-b バッテリー電源を対象にする
-c 充電器を対象にする
-u UPS電源を対象にする

ラップトップに対しては、-a, -b, -cのいずれかを選びます。デスクトップには-a, -uを選びます。例えば以下のようにします。. 必要ならば、それぞれの電源条件に対して、違う設定をします。デスクトップに対しては、-aまたは-uを指定します。私が使用している設定例は以下です。

pmset -a hibernatemode 3

個人的には、デスクトップには3か25を推薦します（訳注：0でも良いと思います）。ラップトップを使うなら、既に設定してある数値で良いですが、変更もできます。

スリープ時にはセッションが常にRAMに保存されます。これにより素早く復帰できます。そこでdarkwakeの設定が重要になります。darkwakeはPower Napに関係します。Power Napはスリープ中にのみ機能します。そのプロセスは、トラブルを引き起こしやすいです。一連のエラーにより、スリープが機能しなくなり、時にはカーネルパニックを引き起こします。残念ながらdarkwakeで指定する値に関する資料はどこにもありません。他の人たちと同様に、一つずつの値を、正しく動くまで試してみるしかありません。私がみるところでは、多くの人たちはdarkwake=8かdarkwake=9が最良であると言っています。私自身は、darkwake=8を使っています。darkwake=1を使う人も多いです。（訳注：コメントで教えていただきましたが、こちらに参考になりそうな説明があります。また、darkwakeの8と10はCatalinaでは使われなくなったらしいです。）

この記事の最初に示した2つのコマンドで、スリープのデバッグができます。以下は、知っておくべき項目の一部です。

Wake from Normal Sleep [CDNVA] due to XDCI XHC/UserActivity Assertion: Using AC (Charge:0%) – これはスリープからの正常な復帰です。私のデスクトップマシンでは、キーボードを押すとスリープから目覚めます。
Kernel Idle sleep preventers: – カーネルがスリープを中断した理由が部分で説明されています。Noneであるのが理想です。
Wake reason: – スリープ直後にすぐに電源が復活してしまう場合、この部分を見てください。最も一般的なは、GLAN (internet)とXHCI (usb)です。

もしXHCIが問題を引き起こしているならば、USB SSDTを作って、不要なハードウェアを除去しておくと良いです。これは重要ですが初心者にはわかりにくいです。SSDTを作ることは、難しそうですがそうではありません。電力設定を正しく行いたいならば、避けては通れません。電力設定以外にも、デバイス接続の問題も解決します。もしコンピュータがGLANによってスリープ復帰しているなら、（訳注：Wake on Lanの）マジックパケット、またはEthernetからの復帰設定を、BIOSで無効にすべきです。これはバニラなインストールガイドにも書かれている項目です。OSの中でも無効にできます。最後にCloverインストーラにも、Ethernetを目覚めさせてしまうSleep Proxy Client (mDNSResponder)を無効にするRCスクリプトがあります。

これで、Power Napを有効にできて、ディスプレイをoffにした時に自動的にコンピュータをスリープにする、スリープの設定ができます。電力設定は以下のコマンドで確認できます。

pmset -g live.

（私が公開するテキスト情報はCC BY-NC-SA 4.0 ライセンスに準拠します。）

ワンクリックで最新KEXTに〜Kext Updater.app (Ver. 3)

Fri, 30 Aug 2019 21:13:28 +0900

この記事は、以下の古い記事のv.3対応改訂版です。

Hackintoshで使っているClover, EFIドライバ、kext類は、最新版を使うのが良いです。色々なバグが直されていて、安定しています。また常に最新にしておけば、macOSのバージョンアップにも対応できます。Catalinaに備えていつも最新状態にしておきたいものです。ただ、開発者の方々のページを巡回して最新版をチェックするのも大変です。

Hackintoshで使用中のkext類最新版をチェックして、新バージョンがあった場合にダウンロードしてくれる便利なツールがあります。ドイツのHackintoshフォーラムの人たちが作ってくれているKext Updaterです。以下から最新版が公開されています。

この記事ではVer. 3を紹介します。古い記事で紹介したVer. 2に比べてスッキリした画面構成になりました。

ボタンがいくつかあります。以下でそれぞれのボタンが提供する機能の説明をします。

Start

メインの機能です。「Start」ボタンを押すと、使用されているHackintoshのkextを全部調べ上げてくれて、それが最新版であるかどうか判断してくれます。最新版では無いkextは、自動的にダウンロードされて、デフォルトでは、デスクトップのKext-Updatesという名前のフォルダに入ります。このフォルダはフォルダーアイコンをクリックすると開けられます。そこで、必要ならば「EFI」ボタンを押してESPをマウントして、ダウンロードした最新版と入れ替えます。

Kexts

必要なkextを個別にダウンロードします。ソースコードのダウンロードもできます。また、更新があってもダウンロードしないkextの指定もできます。

WebDriver

nVidiaのグラフィックスドライバをダウンロードします。nVidiaドライバはMojaveから使えないのが残念です。この機能をボタンに割り当てているところに、開発者の皆さんがnVidia復活に期待している様子が伺えます。

Bootloader

ブートローダーをダウンロードできます。CloverとOpenCoreから選べます。OpenCoreは、Kext Updaterと同じコミュニティの人たちが開発している様子なので、ここに含まれているのだと思われます。

Report

ハードウェアやインストールされたkext, efiドライバ類の一覧の情報を作ります。しばらく時間がかかります。kext類についての情報を得るためは、SIPで署名のないkextを許容する設定が必要です。config.plistのRtVariablesのCsrActiveConfigの下位ビットを1にします（例えば0x01）。シリアル番号などは自動的にゼロにしてくれます。このまま公開して、フォーラムで質問するときに使ってくださいという意図のようです。

レポートファイルは、/tmp/kextupdater/の下にHTML形式で作成されます。情報取得が終了すると自動的に開くので、Safariなどのウィンドウで表示されます。

Tools

4種類のツールが使えます。どういう意図でこれらのツールが選ばれたのか少し謎です。いずれもちょっと微妙な機能です。

kextキャッシュと権限修復

/System/Library/Extensionsと/Library/Extensionsにあるkextのファイル権限とkextキャッシュを作り直します。バニラなインストールをしている場合は、この機能を使うことは無いかと思います。

AtherosのWiFi機能

Atheros (現在はQualcommと合併してQualcomm Atheros, Inc.)のAR92xx/93xxのためのkextが入手できるようです。ボタンを押してみたのですが、うまく機能しないようです。AliExpressで検索してみたら、AR92xx/93xxという名前のチップには、AR9380, AR9285, AR9280, AR9271, AR9377などがあり、PCIeカードの製品や、mini PCIe (mSATA)の製品などがあるようです。ただ、最新世代のWiFiではないようです。型番の数値が大きい、少しでも最新と思われるAR9380には以下のような製品があるようです。どれも14ドルくらいと安価です。こちらを参考にすると、IO80211Family.kextの中のInfo.plistのIDを変更すれば良いようです。でもOOBで動くBroadcomを使った方が良いですね。

Sleep設定

sleepに問題がある場合、役立つかもしれませんと書かれた機能もあります。hibernationが0に設定されて、hibernation用のイメージファイルが作成されないように、書き込み禁止でサイズがゼロのファイルが作られるようです。これも押してみましたがあまり動作がわかりません。pmset -a hibernatemode = 0とタイプするのと同じことが起こるのかと思われます。

ESPをマウントする機能

ドライブを指定して、ESPをマウントしたりアンマウントできます。これは妥当な機能かなと思いました。

HackintoshでFileVaultを使う

Thu, 22 Aug 2019 23:01:31 +0900

FileVaultを使うとファイルが全て暗号化されて、パスワードを知らない人は開けなくなります。OS標準組みなので面倒な設定や手順が不要です。以前はHackintoshで使えないと言われていましたが、最近では使えるようになってました。

FileVault

FileVaultはMac OS X 10.3で登場したシステム組み込みのディスク暗号化機能です。10.7でFileVault2になりました。ちなみにvaultというのは金庫室という意味です。Windowsにも標準機能でBitLockerというツールがあるようです。どちらも多分、同様な機能を提供するツールだと思います。

今のパソコンOSはアカウントのパスワードで保護されているから、暗号化の必要性をあまり感じないかもしれません。でもアカウント／パスワードは、ネットワーク経由のアクセスには一応の役に立ちますが、コンピュータ本体を操作されるとひとたまりもありません。シングルユーザモードで起動したらなんでもできてしまいます。リカバリーボリュームで起動されても同じです。さらにはSSD/HDDを取り外して他のマシンでマウントしたら、全て読み書きできてしまいます。そんな場面でも、FileVaultで保護してあれば、パスワードが知られない限り、アクセスされる恐れはありません。FileVaultを施したSSDをマウントしようとすると、以下のように必ずパスワードを要求されるからです。

FileVaultを使うと、読み書きに暗号化・復号化のオーバーヘッドがかかるために、ファイルアクセスが遅くなる欠点があります。そのため使っている人は少ないと思います。さらにHackintoshでは使えない、つまり、FileVaultを設定した途端に起動不可能になると長年言われていました。でも、最近ではFileVaultを使うためのEFIドライバーが充実しているようです。そこで、HackintoshでFileVaultを使ってみました。

USBメモリをFileVaultする

暗号化機能は、コンピュータやドライブを何処かに置き忘れたり、盗難にあったりした時に頼りになります。逆に、家から持ち出さないデスクトップコンピュータの場合、それほど必要ではないかもしれません。デスクトップコンピュータがメインのHackintoshユーザには、使わなくても良い機能かもしれないです。私もずっと使っていませんでした。

でも、持ち歩くUSBドライブに対しては是非活用したいところです。他人の個人データが入ったUSBメモリーを電車の中にでも置き忘れたら、このご時世では大変な事案になってしまいます。暗号化されていれば安心です。非起動ディスクのFileVault化は、Hackintoshであっても面倒な準備不要です。USBメモリーをディスクユーティリティ.appでフォーマットする際に、「暗号化」と書かれたフォーマットを選択するだけです。これでHackintoshでも実機でも同様に使用することができます。

起動ディスクをFileVaultにする

さていよいよ本題です。Hackintoshの起動ディスクをFileVaultにするとどうなるでしょう？こちらで紹介したマシンに接続した起動可能SSDに対してFileVaultを有効にしてみました。起動ディスクをFileVaultにするには、macOS稼働中に「システム環境設定」「セキュリティとプライバシー」から「FileVault」タブを選択します。次にウィンドウ左下の鍵マークをクリックして、パスワードを入力し、「FileVaultをオンにする」ボタンを押します。

次に、パスワードを忘れた時の対策を選択します。iCloudを使用する方法と、復旧キーをユーザが管理する方法を選択できます。復旧キーを選択した場合は、次のステップで表示される24文字のキーを記録しておく必要があります。

この後、バックグラウンドで暗号化処理が開始されます。起動ボリューム容量に依存しますが、インストールしたばかりのmacOSなら数分で暗号化されます。これで起動ディスクがFileVaultで保護されるようになります。

本物のMacならこれで設定終了です。次に起動する場合も、FileVaultになった起動ディスクから何事もなく起動します。しかしHackintoshではそうはいきません。

HackintoshでFileVaultから起動する

起動ボリュームが見えない

FileVaultにした起動ボリュームは、Cloverの選択画面から消えてしまいます。

下のスクリーンショットは、コンピュータに2個の起動可能なドライブである、2.5 inch SATA SSDと、M.2 SSDを取り付けた場合のボリューム選択画面です。左3個のリンゴマークがSATA SSDのボリュームで、右4個のリンゴマークがM.2 SSDです。ここでは、SATA SSDがFileVault化されていて、M.2 SSDは通常のドライブです。

通常のドライブでは、右側のM.2 SSDの項目に現れているように、

Boot FileVault Prebooter from Preboot
Boot macOS Install Prebooter from preboot
Boot macOS from XXXX （XXXXは起動ボリューム名）
Boot Recovery from Recovery

の4個の選択肢があります。起動ボリュームが、Boot macOS from XXXXという名前で見えています。一方で左側のFileVault化されたSATA SSDの項目には、

Boot FileVault Prebooter from Preboot
Boot macOS Install Prebooter from preboot
Boot Recovery from Recovery

の3個しかありません。通常の起動で使用するBoot macOS from XXXXというボリューム名の選択肢がなくなってしまっています。このボリュームがFileVaultで暗号化されたので、選択肢に現れなくなったのです。FileVaultになった起動ボリュームから起動するには、左端のBoot FileVault Prebooter from Prebootを選択します。preboot(er)という名前の通り、通常のブート手順に先立って処理を行うための選択肢です。ただ、FileVault用のefiドライバが入っていないと、この選択肢を選んだとしても、通常のブート手順に至る前に止まってしまいます。

FileVaultのためのefiドライバを追加する

Boot FileVault Prebooter from Prebootを選択して起動させるためには、FileVault用のefiドライバを入れておく必要があります。最近のCloverインストーラでは、efiドライバーが機能ごとに分類分けされています。分類カテゴリーに「FileVault 2 UEFI Drivers」があります。この中にあるefiドライバーを入れておけば起動できます。ここには6個のefiドライバーがあります。それぞれクリックすると、説明が出ます。それらは、

AppleImageCodec.efi : FileVaultのためにPNGとBMPをデコードします。
AppleKeyAggregator.efi : FileVaultのためにブートUIダイアログをサポートします。
AppleKeyFeeder.efi : FileVaultで使うためにPS/2キーボードをサポートします。
AppleUITheme.efi : FileVaultのためにブート用UIテーマをサポートします。
FirmwareVolume.efi : FileVaultで使うポインター画像用のためにFirmwareVolumeを作ります。
HashServiceFix.efi : UEFI BIOSに含まれていない場合のためにhashフィックスをサポートします。

です。説明文を見ると、ダイアログの表示、イメージの表示、キーボードのサポートというように、ユーザインタフェースを実現する機能ばかりです。後でわかりますが、実はこのユーザインタフェース機能が重要なようです。実際、これらのefiが無い場合には、「ログインダイアログを開けなかった」というような内容のエラーが出て止まります。

説明を見ると、全部は必要がないように思えます。例えば、PS/2キーボードを使わなければ、AppleKeyFeeder.efiは不要なような説明になっています。でも、このefiが無い場合、USBやBluetoothキーボードからの入力ができませんでした。他のドライバには、不要なものがあるかもしれませんが、とりあえずは、6個のドライバーの全部をCLOVER/drivers/UEFI/の中に入れることでFileVaultが機能しました。

FileVaultから起動する

これらのefiドライバーをCLOVER/drivers/UEFI/フォルダに入れた後、マシンを起動します。そして、上記で説明したように「Boot FileVault Prebooter from Preboot」を選択します。ちなみに「Boot macOS Install Prebooter from preboot」を選択すると途中で止まります。名前から推測すると、FileVaultの中のmacOSをインストール・アップデートするときに使う選択肢のように思えます。（ご存知の方いらしたらコメント欄で教えてください）。いずれにしてもここでは使いません。

「Boot FileVault Prebooter from Preboot」から起動すると、すぐに通常のmacOSのログイン画面が出ます。ただ、実際のログイン画面と違って、解像度が低い画面でした。恐らくは、本物のログイン画面ではなく、Cloverが頑張って表示している画面なのかもしれません。ディスプレイドライバーが機能する前段階なので、解像度が低いと思われます。このログイン画面でアカウントを選択しパスワードを入力することで、起動ボリュームの復号化が行われます。-vオプションで様子を見ると、この後、通常の起動手順が開始されるようです。これで正常に起動し、通常通りのmacOS操作が可能でした。

まとめ

HackintoshでもFileVaultは不具合なく使用することができました。ただ、起動ドライブをFileVaultにした場合、Bluetoothキーボード／トラックパッドが認識されるまで多少時間がかかる様子もありました。また、Prebootから起動した後で、起動ボリュームの起動を行うので、起動時間は長くなります。Hackintoshに適したコンピュータは、置き忘れや盗難の危険性が少ないデスクトップコンピュータですので、Hackintoshの起動ドライブにFileVaultを設定する必要性は低いと思いました。

一方で、ノートPCでHackintoshして外に持ち出している方は（あまりいらっしゃらないかもしれませんが）FileVaultを設定しておくと安心だと思います。またデスクトップユーザも、USBメモリーなどのリムーバブルドライブに対しては、FileVaultを活用すると良いと思います。起動ドライブ以外でしたら、実際のMacもHackintoshも同じようにFileVaultを利用できます。

Appleキーボードの☀︎キーで明るさ調整する

Tue, 06 Aug 2019 20:18:29 +0900

Appleキーボードにはディスプレイの明るさを調整するキーがあります。ところが、このキーを押しても外付け液晶ディスプレイの明るさは変化しません。そこでアプリケーションを入れて明るさ調整を可能にします。

太陽のキー

キーボードのF1, F2キーには、お日様マークが書いてあり、これに明るさ調整機能が割り当てられています。

本物のMacではこのキーを使って画面の明るさを調整できます。とはいえ、調整できるMacは、MacBookシリーズとiMacシリーズだけです。それ以外のデスクトップMac（Mac miniとMac Proだけですが）に市販のディスプレイを接続した構成では、このキーは機能しません。アップル社はMacBookとiMac以外には力を入れていないので、気にしていないのだと思います。なのでこれらのマイナーマシンユーザは、ディスプレイの調整ボタンに手を伸ばして、明るさ調整をする必要がありました。

VESAのDDC

外付けディスプレイだから、コンピュータから明るさを調整できないのは仕方ない、と思っていました。でもディスプレイの標準化を進めているVESA (Video Electronics Standards Association) では、コンピュータプログラムからディスプレイを設定するためのプロトコルを決めているようです。それがDDC (Display Data Channel) です。これを使えば、コンピュータからディスプレイの明るさ・コントラストを調整できて、さらにはディスプレイ内蔵（されていれば）スピーカ音量も調整できます。Mac miniやMac Proには通常はVESA規格のディスプレイが接続されるので、macOSでもDDCをサポートしてくれれば良いのにと思います。

DDCを使うアプリケーション

DDC機能を利用して、コンピュータからディスプレイの明るさやコントラストなどを調整するアプリケーションが複数開発されています。このようなアプリはWindowsやLinuxにもあるようで、macOSにもあります。私はこちらの記事へのコメントで教えていただき知りました。Redditでも紹介されていました。その一つがNativeDisplayBrightnessだそうです。でもファンクションキーへの割り当てなどで不具合があるようで、以下のMonitorControl.appが良いようです。記事冒頭は、このアプリケーションのアイコンです。

Release MonitorControl v1.3.0 · MonitorControl/MonitorControl

MonitorControl.appを使う

メニューバーから明るさ調整

GitHubのサイトからMonitorControl.appをダウンロードして、起動するとメニューバーにアイコンが表示されます。

これでモニターの明るさと音量が変えられます。Preferences…のメニューから設定すれば、コントラストも調整できます。Preferencesからは動作や、キーボードショートカット設定、ディスプレイ選択などを行えます。

ショートカットキーの設定

MonitorControl.appを起動すると以下のようなダイアログパネルが表示されます。キーボードの明るさキーから調整するためにはショートカットキーを設定してくださいという内容です。

その裏側には日本語のダイアログも出ていました。どのアプリケーションが動いていても、このアプリがイベントを受け取れるように許可してくださいという意味です。

そこで、「システム環境設定」「セキュリティとプライバシー」「プライバシー」「アクセシビリティ」と選択して、MonitorControl.appに「コンピュータの制御を許可」します。

これでキーボードから明るさ調整できるようになります。F1, F2キーを押すと画面に明るさ状態が表示され、これを変更できます。画面明るさがキーボードで簡単に変更できるのはなかなか快適です。

音量もキーで変更できるようにPreferences…で設定すれば、音量キーによりボリュームも変更できます。HDMIとは別にサウンドを設定しているので、下の写真ではmacOSのボリューム表示とディスプレイのOSDで表示されるボリューム表示が同時に出ています。

Apple純正キーボードの他にLogitech (Logicool) のキーボードも試してみました。F1/F2キーで明るさ変更できて、音量キーで音量調整できました。

自動起動

MonitorControl.appのメニューのPreferences…から、ログインで自動的に起動するというオプションが選べます。ただ、私の環境ではうまく動かなかったです。その代わり、「システム環境設定」「ユーザとグループ」「ログイン項目」にMonitorControl.appを追加したところ、問題なく自動起動するようになりました。

ExternalDisplayBrightnessというのもある

コメントでこういうアプリもあると教えてもらいました。本物のMacでも必要な機能なので、いろいろな人が作ってくれているようでありがたいです。

ExternalDisplayBrightness | František Nesveda

config.plistでDSDT項目名を変更するパッチ

Sun, 28 Jul 2019 23:28:12 +0900

config.plistに「XHCIをXHCに変更」とか「SAT0をSATAに変更」などのパッチを書いている方も多いと思います。これは一体何なのか考えてみました。

DSDTのPatches

USBを設定するスクリプトであるUSBMapを試していたところ（そのうち紹介できれば良いと思い試行錯誤しています）、次のようなメッセージが出ました。

「あなたのマシンにはEC0ってのがあるけどこれはECに変えた方が良いと思う。だからESPにあるconfig.plistを書き換えてあげましょうか？」

よくわからないのでとりあえず辞退させていただきました。これは、config.plistのDSDTの中にPatchesというkeyを作って、そのarrayとして下のようなdictを追加してあげようかという提案です。

<key>Patches</key>
<array>
	<dict>
		<key>Comment</key>
		<string>change EC0 to EC</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		RUMwXw==
		</data>
		<key>Replace</key>
		<data>
		RUNfXw==
		</data>
	</dict>
</array>

config.plistのサンプルには、このようなPatchesが書かれていることがあります。書かれているBase64の内容は、base64コマンドで確認できます。

echo RUMwXw== | base64 -D
EC0_

echo RUNfXw== | base64 -D
EC__

それぞれの結果はEC0_とEC__になります。コメント通り、EC0をECに変更しようとするパッチです。

この他にconfig.plist設定例でしばしば紹介される典型的な名称変更パッチには以下のようなものがあります。（変更前の名前）—>（変更後の名前）の形式で記載しました。

EC0 —> EC
XHCI —> XHC
XHC1 —> XHC
EHC1 —> EH01
EHC2 —> EH02
SAT0 —> SATA

Clover Configurator.appでもパッチを簡単に選べる機能があります。ACPI > DSDTを選択すると、パッチを選ぶメニューが出てきます。ここにはなぜかXHCに関するメニュー項目はありませんが、他にも多数のパッチ候補が表示されています。

この中からいくつかのパッチをよくわからずとりあえずconfig.plistに書いている方も多いと思います。私もよくわかっていませんでした。

パッチの目的

RehabManさんの解説などを読んで私なりに理解した理由は次のようなものです。間違っているかもしれません。私の理解が正しいのかどうか、皆さんにお聞きしたいと思い、この記事を書きました。詳しい方がいらしたら、ぜひコメントでお知らせいただけるとありがたいです。適宜修正していきます。

DSDTの項目名変更

これらのパッチは、config.plistのコメントから類推できるように、DSDTの項目名を変更する目的で使用されています。

DSDTは電源管理のための情報で、マザーボードに搭載されているハードウェアの状況が記載されています。例えばどういう名前のUSBやSATAが何本あってどう接続されているかなどが書いてあるようです。マザーボードのBIOS（ファームウェア）がこの情報を持っていて、OSに提供します。WindowsやLinuxなどのOSはこの情報を参考にしてハードウェアにアクセスします。ファームウェアが提供するDSDT情報と、これを利用するOSの関係は、同じようにEFIに基づいて設計されているMacでも同様です。Macのファームウェアがハードウェア構成をDSDTを通して提供し、macOSはそれに従ってハードウェアを制御します。

DSDTが提供する名称は、マザーボードによって違います。それがMacと同じ名前であることもありますし、違う名前のこともあります。例えば、iMac19,2のUSBコントローラはXHCIという名前ですが（最近のMac製品ならほぼ同じでXHCIです）、手元のZ390マザーボードはXHCです。

自作で使うマザーボードでの名前を、本物のMacで採用されている名前に合わせたり、あえて名前を変えたりしているのがconfig.plistで使われるパッチの役割です。上で紹介した例で、Macで採用されている名前を太字体にした対応表が以下です。

EC0 —> EC
XHCI —> XHC
XHC1 —> XHC
EHC1 —> EH01
EHC2 —> EH02
SAT0 —> SATA

EC0とSAT0に対するパッチは、Macで使われる名前に合わせるためのパッチで、残りのXHCI, XHC1, EHC1, EHC2へのパッチは、これとは逆にMacで使われている名前と違う名前にするためのパッチです。同じ改名パッチではありますが、動作が全く逆ですので、そのパッチを当てる動機も違います。

実機のMacに名前を合わせるパッチ

上記の例ですと以下の2つのパッチは、ATXマザーボードが提供するDSDTの項目名をMacで使われる名前に変更するパッチです。本物のMacにより近い設定にしたいという意図は理解できると思います。

EC0 —> EC
SAT0 —> SATA

どうやら10.11以前の古いmacOSは、DSDTの情報をあまり活用していなかったようです。どんなハードウェアが使われるか予想できないWindowsと違って、自社のハードウェアでしか動かさないOSなので、ハードウェア仕様をDSDTから得る必要がなかったのかもしれません。機種IDさえわかればハードウェアの詳細情報はわかってしまいますから。なのでこのようなパッチが必要だったようです。しかし、現在のmacOSではDSDT情報をちゃんと利用するようになったためか、この種類のパッチを当てなくても、大抵の場合、問題は発生しないようです。

例えば、手元のASUS Z390マザーボードでIORegistryExplorer.appを起動して検索したところ、SAT0という項目がありました。その一方でSATAという項目はありませんでした。

Clover Configurator.appのメニューには、SAT0 —> SATAというパッチ候補があります。これを選ぶと以下のパッチがconfig.plistに書き込まれるようです。

<key>Patches</key>
<array>
	<dict>
		<key>Comment</key>
		<string>change SAT0 to SATA</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		U0FUMA==
		</data>
		<key>Replace</key>
		<data>
		U0FUQQ==
		</data>
	</dict>
</array>

これも動かしてみたところ、SAT0からSATAに正しく名称変更されました。でもSATA関連は変更前でも変更後でも全く問題なく稼働しています。

冒頭ではEC0をECに変えるようにと指示された話を紹介しました。Hackintosh用のツールでは、実機の名前になっていることを前提にして動いていることもあるのかもしれません。でも、問題が発生しなければ当てなくても良いパッチだと思います。

実機のMacの名前を避けるパッチ

以下のパッチはどれも、実機で使われるUSBコントローラの名前と違う名前に設定するためのパッチです。

XHCI —> XHC
XHC1 —> XHC
EHC1 —> EH01
EHC2 —> EH02

ATXマザーボードと実機の名前が一致しているのに、わざわざ別名にするパッチなので、なぜ必要なのか理解に苦しむと思います。その経緯は以下のようです。

上で、macOSも10.11からDSDTに書かれた情報を利用するようになったらしいと書きました。ところが一部のMacハードウェアは、あろうことかUSBに関する正しいDSDT情報を持っていなかったようです。DSDT情報をOSで利用する予定がなかったのでいい加減に記述してあったのかもしれません。本来なら正しいDSDTを提供するようにファームウェアアップデートするべきですが、それは大変なのでOS側で対応したそうです。つまり、DSDTのUSB情報が間違っているMacに対しては、macOSで用意したUSB構成情報を使用することになりました。全てのMac機種のDSDT情報を無視しているわけではなく、DSDT情報が怪しいとわかっているMac機種に関してはOSで用意した値を使っているようです。

なのでATXマザーボードが持っているUSBコントローラに、たまたまMac実機と同じ名前がついていると、DSDTが提供する情報を使わずに、macOSが用意したMac実機の情報を使ってしまう可能性があります。それを避けるために、Mac実機と違う名前に改名するのがこれらのパッチです。

このパッチも、いろいろな理由で不要な場合が多いです。

まずは、もともとDSDTのUSBコントローラ名がMacの実機と違う名前だったら名称変更は不要です。例えば手元のASUS Z390マザーボード（機種IDはiMac19,1）でIORegistryExplorer.appを起動して、XHCを検索してみたところ、名称変更パッチを当てなくても、XHCという名前で存在していました。名称変更パッチの変更対象名として使われるXHCIとかXHC1という名前の項目はそもそも存在していませんでした。このような場合は、名称変更パッチは不要と考えて良いと思います。

次に、macOSがDSDTを信用してくれる機種IDなら名称変更は不要と考えられます。例えばこちらはNUCで作ったHackintoshの例です。機種IDはMacBookAir5,1です。IORegistryExplorer.appを起動して確認すると、名称変更対象に上がっているEHC1とEHC2があるようです。その一方でEH01やEH02は見つかりません。でもmacOSは、この機種のDSDTは正しいと認識しているようで、このままでも全く問題なくUSBが認識されています。NUCはUSBの数が少ないので15個制限も問題無いようです。

ちなみに、このNUCで、

EHC1 —> EH01
EHC2 —> EH02

の名称変更パッチを当ててみるとちゃんと変更されることが確認できました。config.plistに追加したパッチは、以下のものです。

<key>Patches</key>
<array>
	<dict>
		<key>Comment</key>
		<string>change EHC1 to EH01</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		RUhDMQ==
		</data>
		<key>Replace</key>
		<data>
		RUgwMQ==
		</data>
	</dict>
	<dict>
		<key>Comment</key>
		<string>change EHC2 to EH02</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		RUhDMg==
		</data>
		<key>Replace</key>
		<data>
		RUgwMg==
		</data>
	</dict>
</array>

この結果EH01とEH02がIORegistryExplorer.appのウィンドウに現れました。その一方で、EHC1とEHC2は無くなりました。名称変更のパッチが効いているようです。でもどちらの場合でも、USBは問題なく機能しました。

以上のように、Mac実機のDSDT項目名を避けるパッチを当てることで、DSDTのUSB情報がありのままにmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近の機種IDを設定していれば、DSDTの情報がそのまま正しくmacOSで使われるのでパッチは不要な気がします。古い機種IDであっても、MojaveのAPFS起動に対応した時にファームウェアアップデートされたので、信用できるDSDTに置き換わっている可能性もあります。なのでmacOSがDSDTを無視する必要性が少なくなったはずです。そのような状況を考えると、実機の名前を避けるパッチも、もはやそれほど必要でない気もしています。

まとめ

ということで、config.plistのDSDT Patchesの機能を考察しました。半分推測なので、間違っているかもしれません。詳しい方いらしたら、コメントで教えていただければ助かります。

まとめると、DSDT Patchesは、DSDTの項目名を変更するパッチでした。改名結果はIORegistryExplorer.appで確認できました。改名するとDSDT情報が正しくmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近では、パッチの必要性が下がっている気がします。使用しているマザーボードのDSDT項目が、パッチ対象の名前かどうかを調べておいて、パッチ対象の名称であった場合は、何か問題があった時に名称変更のパッチを試すのが良いと思います。

Crucialの1TB NVMe M.2 SSD (CT1000P1SSD8) を使う

Fri, 26 Jul 2019 01:16:55 +0900

NVMeプロトコルのM.2 SSDが安くなっています。1TBでも1万円代前半です。ということでCrucialのお安い1TB M.2 SSD, CT1000P1SSD8をmacOSで使ってみました。問題なく動作し性能もそこそこ良いです。

SSDが安くなった

メモリーの価格が下がっている関係か、M.2 NVMe SSDも安くなっているようです。以前は、1TBだと結構なお値段だったのですが、セールだと1万円を切ってたりします。以下はその時のスクリーンショットです。

残念ながら現在の価格は1,400円ほど上昇して11,323円ですが、それでも1TBでのこの価格は、ちょっと前なら考えられなかった状況です。ただし、品薄のようで納期が長いです。（この記事の執筆時の状況です。現在の価格、納期は下のリンクから確認してください。）

マザーボードに取り付け

ということで、このSSDをmacOSで動かしました。使用したハードウェア構成は以下です。マザーボードはMSIのB360搭載Micro ATXです。SATAコネクタに接続した2.5 inch SATA SSDでmacOS Mojaveが問題なく動作しています。

MSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh

CT1000P1SSD8JPをマザーボードのSSD用M.2ソケット（CPUのすぐ隣の方のソケット）に取り付けました。廉価版のB360マザーボードなので、M.2 SSD用のヒートシンクは用意されていません。なので別途ヒートシンクを用意しました。CPU隣のM.2ソケットは、PCIe拡張カードに干渉しない場所にあるので、背の高いヒートシンクを取り付けられます。大型の空冷CPUクーラを使わなければ、ケースの高さまで上空が空いています。ギリギリの高さまでヒートシンクとしたいところです。そこで入手し得る限り背の高いヒートシンクを探して取り付けました。以下の製品で高さは3cmあります。マザーボードがチタン色なのでシルバー（塗装無しアルミ）版を購入しましたが、黒いマザーボードをお使いならブラック（塗装ありアルミ）版が合うと思います。

Amazonの写真では、取り付けゴムが輪ゴム色（ブラック版は白色）で多少微妙でしたが、実際に届いた製品には白い耐熱ゴムでした。マザーボードに取り付けるとこんな感じです。それほど違和感はありません。CPUのリテールクーラと比べると、背の高さがわかるかと思います。このM.2 SSDも他製品と同様に、酷使するとコントローラチップが発熱します。でもこれだけの熱容量のあるヒートシンクだと、穏やかに暖かくなる程度でした。

フォーマット

M.2 SSDをマザーボードに取り付けたら、ディスクユーティリティ.appでAPFSでフォーマットします。HFS+でフォーマットしても良いですが、macOSをインストールする際に結局はAPFSに自動変換されると思います。以前だとシステム用とデータ用にパーティション分けしたりしていたのですが、今はAPFSのコンテナ機能により柔軟にボリューム作成できるので、ちまちまとパーティション分けするのはやめました。ということで1TBを丸ごと一つのパーティションにしました。ディスクユーティリティ.appでは、M.2 SSDを選んで「消去」ボタンを押します。この操作により、SSD全体を占める1パーティションが作られ、その中にコンテナが一つ出来上がり、コンテナにボリュームが1個追加されます。macOSの伝統に従って、ボリューム名はMacintosh HDにしました。APFSコンテナなので、将来、このコンテナにデータ用のボリュームを新設・追加することが容易です。そうすれば、システム用とデータ用の2つのボリューム構成になり、macOSをクリーンインストールするときに便利になります。

Mojaveのインストール

現用の2.5 inch SATA SSDで起動して、macOS最新版をダウンロードし、M.2 SSDにインストールします。ここまでは通常のMac機種と同じです。今回は、ダウンロードの時間節約のために、あらかじめダウンロードしてあった10.14.5をインストールしました。10.14.6へのアップデートも問題ないはずです。9900Kマシンでは10.14.6インストール時にiGPUを無効にする必要がありましたが、このマシンはFモデルCPUで、そもそもiGPUが存在しないので、その心配はないと思います。この段階ではM.2 SSDから起動できません。2.5 inch SATA SSDからCloverを起動してM.2 SSDのmacOSの動作を確認します。

ESP内容のインストール

次に、現用の2.5 inch SATA SSDと、M.2 SSDの両方のESPをマウントし（それぞれ/Volumes/EFIと/Volumes/EFI 1としてマウントされるはずです）、2.5 inch SATA SSDの内容をM.2 SSDに、ファインダーのドラッグ&ドロップ操作でコピーします。あとはBIOSでM.2 SSDを起動ドライブに設定するだけで、macOSが起動しました。

システム環境で確認

システム情報を開いてM.2 SSDの動作を確認しました。TRIMが有効になっているようです。しばらく使用しましたが、特に問題はありませんでした。Crucialの格安のSSDがmacOSで使用できることが確認できました。

速度測定

この格安SSDは自作PCユーザの間で評判のようで、Windowsで測定した速度がいくつかのページで紹介されています。例えば、以下のページです。

QLC型NVMe M.2 SSD「Crucial P1 1TB」をレビュー。SATA SSDに近い容量単価でSATA S…

これによるとCrucialの1TBモデルは、メーカー発表の仕様書通りの性能を発揮して、Readが2000MB/s, Writeが1700MB/sのようです。Windowsベンチマークでよく使われるCrystalDiskMarkに近い動作をするmacOS用の AmorphousDiskMark.app を使って速度を測定しました。その結果、仕様書通りの性能が得られました。macOSでもこのSSD本来の性能を活かせているようです。

10.14.6更新に失敗するのでiGPUを一時的に無効にしました

Wed, 24 Jul 2019 20:30:55 +0900

10.14.6が出たのでアップデートしました。いつものように簡単だとたかをくくっていたら、ちょっとつまづきましたので簡単にご報告します。アップデートしたハードウェア構成は、こちらです。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

以前も「グラフィックスカード(RX 580) に切り替わるタイミングで起動が止まる、もしくは止まって再起動する」という現象が発生しました。フォーラムで情報を頂いたように、この場合、BIOS設定でCPU内蔵グラフィックス (iGPU) を無効にすると直るようです。ただしiGPUが動かないとJPEGファイルのクイックルックが効かないので、ブートオプションに以下の記述をして、WhateverGreenに指示する必要があります。

shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94

今回、10.14.6へのアップデート作業の途中で再起動する過程で、この現象が発生しました。そこでBIOSでiGPUを無効にするよう設定したところ、無事にアプデートが完了しました。面白いことにアップデート後は、iGPUを有効にしても問題なくブートしました。なので上記のブートオプションは不要でした。原因はメモリー利用（メモリーマップ）の関係のように思えるのですが、条件によって発生したりしなかったりする微妙な現象のようです。

何れにしても、この問題が発生した時はiGPUを無効にすることで対応できるようです。

そういえばMojaveのインストーラやアップデータが、「インストーラリソースが見つかりません。」というメッセージを出して止まってしまうこともありました。これはインストールに無関係なドライブを一時的に切り離せば対応できました。今回の問題は、一時的なBIOS設定で回避できるので、少しは楽かもしれません。

Mojaveの「インストーラリソースが見つかりません」問題

新ブートローダーOpenCoreを使う

Sat, 20 Jul 2019 16:30:07 +0900

OpenCoreはCloverから分岐し、OZMOSISの流れを取り込んだ新しいオープンソースのブートローダーです。Z390マザーボードで動かしたところとりあえずはmacOSが起動しました。

追記：最近のOpenCore関連の記事もご覧ください。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

OpenCoreとは

OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダーです。Cloverから分岐し、OZMOSISの流れを取り込んでいます。OZMOSISを開発していたドイツのHackintosh-Forum.deの人たちが開発を進めているようです。OZMOSISってどんなものだったかと言うと、ファームウェア形式のブートローダーで、マザーボードのBIOSを置き換えて動作します。OZMOSISをマザーボードのBIOS更新機能を使ってインストールすれば、普通のマザーボードがmacOSを直接起動できるマザーボードに変身します。macOSもmacOSインストーラも実機と同様にそのまま起動できるという理想を追ったブートローダーだったのですが、調整やアップデートのたびにBIOS更新作業をするのは大変でした。ChameleonやCloverみたいにドライブの一部に書き込む方式の方が色々楽です。ということでOZMOSISはあまり流行りませんでした。開発チームもそれを認識して、今度はClover方式のブートローダーを作ることにしたのだと思われます。

使用したハードウェア

OpenCoreを試したハードウェアは、以下で紹介したZ390マシンです。モデルIDはiMac19,1で、macOS Mojave 10.14.5です。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ここで使っているkextは

AppleALC.kext
IntelMausiEthernet.kext
Lilu.kext
USBInjectAll.kext
VirtualSMC.kext
WhateverGreen.kext

です。efiファイルは大半がClover 5018で配布されているものです。

ApfsDriverLoader.efi
AptioMemoryFix.efi (これはKext Updater.appで入手)
FSInject.efi
VirtualSmc.efi （VirtualSMC.kextに同梱されているもの）
VBoxHfs.efi
EmuVariableUefi.efi

またUSBInjectAll.kextで使うためのSSDTファイルも使っています。こちらで作成したものです。これがSSDT-UIAC.amlという名前です。

OpenCoreを入手する方法

いろいろな方法がありますが、一番お手軽なのは最近のKext Updater.appを使う方法です。Kext UpdaterもOpenCoreを作っている人たちが活躍しているHackintosh-Forum.deで作られていますので、その関係でOpenCoreダウンロード機能が実装されているのだと思います。Load Bootloaderのラジオボタンを選択して、右のポップアップメニューからOpenCoreを選択します。

ダウンロードすると、Kext-Updatesフォルダの中にOpenCoreというフォルダができて、この中にデバッグ版とリリース版

OpenCore-0.0.4-DEBUG
OpenCore-0.0.4-RELEASE

のフォルダが出来ています。今回はRELEASE版を使ってみましたが、DEBUG版の方がより多くのエラーメッセージを出してくれるらしいです。

ESPディレクトリ構築

Docsフォルダの中には、とても詳しい取扱説明書が入っています。Cloverにはあまりなくて、ネット上のマニュアルも古かったりします。説明書を一緒に配布してくれているのは助かります。まだちゃんと読んでませんが、必要な情報は全部書いてあるのではないかと思います。マニュアルによると、構築すべきディレクトリ構造は以下の通りのようです。

グレーの項目は任意の項目です。なので、EFIの下に、BOOTとOCを作って、OCの中のDriversにefiファイルを、Kextsにkextファイルを入れれば良いようです。またOCの中にconfig.plistを置きます。名前がOCになっただけで、CloverのESP配置とだいたい同じです。この図に従ってESPの中にディレクトリを用意し、DriversフォルダとKextsフォルダに上記のefiファイルとkextファイルを入れました。またACPIフォルダにSSDT-UIAC.amlを入れました。

config.plist編集

Docsフォルダの中に、マニュアルと一緒にconfig.plistのサンプルファイルも入っています。名前が、Sample.plistとなっています。今回はこのファイルをもとに動かしてみました。まずはSample.plistをconfig.plistに名称変更します。そして以下の手順で書き変えました。

SMBIOS設定

まずは機種設定からです。どうやらPlatformInfoの中のGenericの中が機種設定関連のようです。この部分のMLBがCloverでのBoardSerialNumberに対応し、SystemProductNameがProductNameに、SystemUUIDがSmUUIDに対応するようです。それぞれの値を書いておきます。

	<key>MLB</key>
	<string>C02921130GULNV9JA</string>
	
	<key>SystemProductName</key>
	<string>iMac19,1</string>

	<key>SystemSerialNumber</key>
	<string>C02YR2YHJV3Q</string>

	<key>SystemUUID</key>
	<string>E45005B4-95C7-4B0C-9739-30947DDEB37C</string>

FileVault設定

この状態で起動させようとしたところ、FileVaultの用意ができていないというような内容のメッセージが出て起動が中断しました。config.plistを見ると、MiscSecurityの中にFileVaultらしい設定があり、有効にされているようです。ここのtrueの部分2箇所をfalseに書き換えました。これでメッセージが出なくなりました。

<key>Security</key>
	<dict>
		<key>ExposeSensitiveData</key>
		<integer>2</integer>
		<key>HaltLevel</key>
		<integer>2147483648</integer>
		<key>RequireSignature</key>
		<false/>
		<key>RequireVault</key>
		<false/>
		<key>ScanPolicy</key>
		<integer>983299</integer>
	</dict>

efi設定

次に、HFSPlus.efiが見つからないというメッセージで起動が中断されました。最近はAPFSになって、HFS+での起動は使わないので、上記のリストのようにCloverデフォルトのVBoxHfs.efiを使っていました。なんでこのメッセージが出るのかと思ったらconfig.plistのUEFIDriversの中にefiファイルの一覧が書いてありました。フォルダに入れるだけでなくconfig.plistにも書いておくようです。FileVaultに関係したefiファイルも入っています。これらのリストを、実際に使っているefiファイルに書き換えました。

<key>UEFI</key>
<dict>

	<key>Drivers</key>
	<array>
		<string>VBoxHfs.efi</string>
		<string>ApfsDriverLoader.efi</string>
		<string>EmuVariableUefi.efi</string>
		<string>FSInject.efi</string>
		<string>AptioMemoryFix.efi</string>
		<string>VirtualSmc.efi</string>
	</array>

kext設定

ほかも見てみると、KernelAddの場所に、kextに関する記載もあります。この記述順にロードされるようなので順番も大事なようです。

IntelMausiEthernet.kextの名前が違っている（IntelMausi.kextになっている）のとEnabledされていないようなので、修正しました。

<dict>
	<key>BundlePath</key>
	<string>IntelMausiEthernet.kext</string>
	<key>Comment</key>
	<string></string>
	<key>Enabled</key>
	<true/>
	<key>ExecutablePath</key>
	<string>Contents/MacOS/IntelMausiEthernet</string>
	<key>MatchKernel</key>
	<string></string>
	<key>PlistPath</key>
	<string>Contents/Info.plist</string>
</dict>

また、USBInjectAll.kextの記述も追加しました。順番が大事のようです。arrayの最初の方に入れたら動きません。arrayの最後に追加しました。

 <dict>
 <key>BundlePath</key>
 <string>USBInjectAll.kext</string>
 <key>Comment</key>
 <string></string>
 <key>Enabled</key>
 <true/>
 <key>ExecutablePath</key>
 <string>Contents/MacOS/USBInjectAll</string>
 <key>MatchKernel</key>
 <string></string>
 <key>PlistPath</key>
 <string>Contents/Info.plist</string>
 </dict>

SSDT設定

使用するSSDTもconfig.plistで指定する必要があるようです。今回は、SSDT-UIAC.amlを使います。そこで、ACPIAddのarrayの中に、

 <dict>
 <key>Comment</key>
 <string>USB list for USBInjectAll</string>
 <key>Enabled</key>
 <true/>
 <key>Path</key>
 <string>SSDT-UIAC.aml</string>
 </dict>

を追加しました。

動作確認

BIOSでOpenCoreをインストールしたドライブを選択すると、Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面です。ここで10.14.5の入ったMacintosh HDを選択しました（この例ではキーボードの5を押す）。この後、設定に不備があると上記のようなエラーメッセージが出ることもありますし、起動が停止することもあります。

でも、ここまでの設定で、なんと起動しました。config.plistで手付かずの項目がいっぱいあるのに、とりあえず起動したのは意外でした。よかったです。

使用したconfig.plistを以下においておきます。

OpenCore config.plist for Z390 - Pastebin.com

動くこと

画面が出て動作します。Radeon RX 580が正しく動きます。IntelMausiEthernet.kextも動きます。なのでLAN接続ができます。またBroadcomの純正WiFiも動きます。

USBInjectAll.kextと自作のSSDTの組み合わせで、USBの取捨選択ができています。15個制限問題を解決できています。

動かないこと

シャットダウンすると画面は消え、シャットダウンプロセスが実行されるのですが、電源が切れるところまで行き着きません。電源スイッチを長押しして強制的にoffにする必要があります。その影響で次の起動の時にBIOS表示で警告が出ます。ACPI関係の設定が足りないのだと思います。

OpenCoreに行くべきか？

ということで、OpenCoreでの起動を確認できました。今後は、USBの指定方法や、今回見た以外のconfig.plistの設定など、マニュアルや検索して調べて見たいと思います。

ではCloverをやめてOpenCoreに移行すべきでしょうか。OpenCoreの人たちは、以下のようなメリットを訴えています。

完全にオープンソースなので安心
設計が新しい

確かにCloverは開発過程がそれほどオープンになっていないので、わかりにくいところがあるかと思います。ロシアで開発されているCloverとドイツで開発されているOpenCoreでは、偏見かもしれませんが、なんとなくOpenCoreに安心感を感じます。開発がオープンなのでHackintoshの主流がOpenCoreに移行していく可能性は高いです。でも今現在では、Cloverに関するノウハウが大量にネットにありますし、しばらくはCloverが使われると思います。

主流ブートローダーは、数年前にChameleonからCloverに交代しました。ただ、この交代では、レガシーなMBR (マスターブートレコード)からESPに対応すること、起動時に動的にパッチを当ててくれる機能、macOSとの相性が良くなることなど、いくつもメリットがありました。CloverからOpenCoreに変えても、目に見えるメリットはないので、移行は緩やかかもしれません。CloverからOpenCoreに移行したらグラフィックスカードの動作が安定したと言う情報も見かけました。今後どうなるにしても、選択肢が複数あることは良いことです。

CLOVER 4988 でEFIドライバ関連が変更されました

Sat, 13 Jul 2019 22:14:47 +0900

新しいClover 4988が公開されたので深く考えずに更新しました。そしたら起動しなくなりました。EFIドライバの管理方法がいろいろ変更になったようです。

（EFIドライバの古い情報は以下に書いてあります。今でも参考になる部分はありますので、ご覧ください。）

Cloverで使うEFIドライバ

EFIドライバの管理方法

4988では、拡張子が.efiのEFIドライバーの管理方法が変わったようです。Cloverインストーラの選択肢もグループ分けされています。その影響なのか、次に述べるEFIドライバの格納フォルダ名が変更になった影響なのかわかりませんが、前回のインストール情報が継承されていないようです。単にアップデートすると全てのEFIドライバが非選択になっています。そのままインストールすると、EFIドライバが足りない状態で起動しようとして、当然ながら起動に失敗したようです。

もともと私のマシンでは、前のバージョンのClover 4972以前で、以下のようにEFIドライバを設定していました（6個です）。
補足：この6個のうち、SMCHelper.efiはFakeSMC.kextと一緒に使用するためのEFIドライバだそうです。VirtualSMC.kextを使用する場合はこれは不要らしいです。VirtualSMCを使用する場合は、VirtualSMCと一緒に配布されているVirtualSmc.efiを使用するのが正しい方法らしいです。

この状態で、4988を自動的にインストールしようとすると、以下のようになりました。ApfsDriverLoader-64以外が全部消えてしまいました。たまたまこれが残されたのは、新バージョンで名前から64が外れたためのようです。driversという新しいフォルダができていますが、こちらは空っぽです。このままでは起動しません。

インストーラでEFIドライバを選択し直さないといけないようです。以下のようになりました。このスクリーンショットではわかりませんが、グループ分けされたEFIフォルダの中から上記の6個を選択してあります。

その結果以下のようにインストールされました。driversのフォルダの中に、UEFIというフォルダが作られて、その中にEFIドライバーがインストールされるようです。ちなみに古いdrivers64UEFIフォルダはもはや使われていないようで、削除しても大丈夫でした。これで起動するようになりました。

新オプションDrivers off

4988のインストーラにDrivers offというオプションが追加されています。説明によると、利用可能な全てのドライバをEFI/CLOVER/drivers/off/にインストールするそうです。offフォルダは名前の通り使用されないドライバの置き場所で、ここに全てのドライバを入れておけば、必要になった場合にEFI/CLOVER/drivers/UEFI/にコピーして使えます。

これを選択すると、説明通りdriversフォルダの中にoffフォルダが作られて、その中に大量の (33個) ドライバが入ります。インストールしなかったドライバを試したい場合に便利です。こちらで紹介したようにEFI SHELLでmvコマンドで操作することもできるでしょう。offフォルダの中身の合計（ドライバの総容量）は815KBです。ESPの容量（200MB程度）からして負担になる量ではありません。

AptioMemoryFix-64が消えた

macOSカーネルを読み込むための連続メモリ領域確保を支援するAptio系のEFIにも変更があります。インストール画面からおなじみのAptioMemoryFix-64.efiが消えて選べません。

上記のoffフォルダを見ていただくとわかるように、こちらにも存在しません。ドイツ語のHackintosh-forumにはいち早く説明が書いてありました。英語に翻訳したURLは以下です。AptioMemoryFixは新しいドライバなのですが、CLOVERの開発者チームの作ではないので、同梱されなくなったようです。

今回は代わりにOsxAptioFix3Drvを使用しました。問題なく使えました。なお、フォーラムでいただいた情報によるとAptioMemoryFix-64.efiの-64を名前から外して、新しくできたdrivers/UEFIに入れれば動くらしいです。でも同梱されたドライバで問題ないならばその方が整合性の点で良いかと思いました。

またAptioMemoryFix.efiの最新版はKext Updater.appからも入手できます。こちらからは-64の名前のない、最新版が入手できます。これを利用しても良いと思います。

レガシーインストールが選べない

これはEFIドライバの話だけではありませんが、MBR (マスターブートレコード）にインストールするレガシーBIOSの方法がインストーラで選択できなくなっています。レガシーブートは手作業でインストールすれば可能かもしれません。でも自動的にインストールできるのはUEFIブートだけになりました。下は4972のインストール画面です。

これに対して下が4988のインストーラです。MBR, PBR（パーティションブートレコード）へのインストールオプションがなくなりました。

最近はMBRしかサポートしないレガシーなマザーボードはほとんど見当たらなくなりましたし、わかりやすくなって良いのかもしれません。

まだいろいろ変更されたことはありそうです。AptioMemoryFixがなくなったので、Aptioシリーズの選択方法も再検討すべきかもしれません。この記事に加筆していきたいと思います。

ASUSのBIOSを1105以上に更新すると起動しない

Sun, 07 Jul 2019 22:12:38 +0900

ASUSのZ390マザーボード、ROG MAXIMUS XI HERO WiFiのBIOSを最新版1105にアップデートしたところmacOSが起動しなくなりました。1005にダウングレードしたら復活しました。

BIOSアップデートで起動しない

ASUSの最新BIOS 1105が公開されていますが、これにアップデートするとmacOSが起動しなくなるとのことです。こちらのコメントで教えていただきました。検索すると色々なところで紹介されていました。

ならば試してみようということで、こちらのビルドで紹介したASUS ROG MAXIMUS XI HERO WiFiのBIOSをアップデートしてみました。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ROG MAXIMUS XI HEROは、BIOSからネットワーク接続してBIOSアップデートできます。この機能を使って最新の1105にアップデートしました。するとやはりmacOSが起動しませんでした。-vで起動すると起動途中で文字表示が止まってそのまま動かなくなります。apfs.efiなのかVirtualSMCのあたりのメッセージで止まります。

BIOSでRTCを設定する

この記事へのコメント欄で教えていただいた情報によると、原因はRTC (リアルタイムクロック）の関係のようです。BIOS設定でレガシーなRTCを使うように指定すれば解決するようです。RTCは、システムの日付や時計を管理しているだけでなく、割り込みでプログラムを制御するような使い方もされているようです。起動時に、RTC割り込みがある事を前提に作業を始めた起動プログラムが、RTCからの割り込みが発生しないために動作継続できなくなって、起動が止まってしまうようです。

上記のサイトでは以下のような設定画面の写真が紹介されていました。ASUSのBIOSメニューの、Advanced–>PCH Configuration–>System Time and Alarm SourceをLegacy RTCにすれば良いようです。メニューの内容などから判断すると、ACPIが提供するタイマー・アラーム機能を利用する方式がデフォルト設定になったため、Clover + macOSが対応できなくなったようです。従来型のRTCのタイマー・アラーム機能を使用するよう設定すれば、macOSを起動できるようです。

ところがどういうわけか、ROG MAXIMUS XI HEROのBIOS ver. 1105の画面にこの選択肢が出てきません。

IOAPICのエントリーの選択肢は、以前のBIOSでは表示されていました。今回は、それも無くなっていました。もしかしたら次のバージョンでRTCの選択肢が出てくるようになるのかもしれません。という事で、BIOSでLegacy RTCを指定する方法は使えませんでした。

追記：1302でもダメでした

2019/9/11付で1302が公開されていたので、アップデートを試みました。やはりそのままでは起動せず、また、System Time Alarm Sourceのメニューも現れませんでした。下記に説明したUSB BIOS Flashbackの方法で1005に戻しました。（2019年9月29日）

追記：1401でもダメでした

2019/12/11付で1401が公開されていたので、アップデートを試みました。やはりそのままでは起動せず、また、System Time Alarm Sourceのメニューも現れませんでした。下記に説明したUSB BIOS Flashbackの方法で1005に戻しました。（2019年12月21日）

パッチを当てる

ASRockのマザーボードなどで必要とされていたDSDTへのパッチ

を当てることでも対応できるようです。これで新しいBIOSでもmacOSが起動したそうです。以下のパッチをconfig.plistのACPI\DSDT\Patchesに書き込めば良いようです。

<dict>
 <key>Comment</key>
 <string>Fix Z390 BIOS DSDT Device(RTC) bug</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 oAqTU1RBUwE=
 </data>
 <key>Replace</key>
 <data>
 oAqRCv8L//8=
 </data>
</dict>

ただ、パッチを当ててまで新しいBIOSが使いたいわけではないです。そこで、ダウングレードすることにしました。ところが…

BIOSダウングレード出来ない

失敗したら古いバージョンにダウングレードすれば良いと思って、気楽に手がけたのですが、実は簡単ではありませんでした。実際に試したところ、1105より古いBIOSでは、BIOS画面からEzFlashというツールを起動して、古いBIOSイメージを指定すれば、簡単にBIOSダウングレードできました。しかし最新の1105では、1105より古いバージョンのBIOSイメージを指定すると、適切なBIOSでは無いと言われてインストールしてくれません。

USB BIOS Flashbackでダウングレード

MAXIMUS XI HEROにはUSB BIOS Flashbackという機能があります。ネットワークやUSBメモリからBIOSを更新できるEzFlashはBIOSのメニューから起動するツールで、搭載したCPUやメモリーを使用して動いています。これに対してUSB BIOS Flashbackは、CPUやメモリーを搭載していなくても動く更新ツールです。おそらくマザーボード上に専用のマイクロコンピュータを搭載していて、CPUの力を借りずにBIOS更新する仕組みかと思います。BIOS更新のためにわざわざコンピュータを搭載していると考えると、とても贅沢に思えます。上位機種のマザーボードにしか搭載されていません。これでBIOSダウングレードを試しました。

USB BIOS Flashbackを使用するには、FATでフォーマットしたUSBメモリーのルートに、更新したいBIOSイメージをM11HW.CAPという名前で置いておきます。これをバックパネルの、USB BIOS Flashback用のUSBポートに挿しておきます。PS/2コネクタ下にあります。次に、電源を切った状態で、バックパネル左端のUSB BIOS Flashボタンを3秒ほど長押しします。するとこのボタンが点滅を始めます。あとは点滅が終了するまで待つだけです。自動的に再起動しなければ電源投入します。2-3回再起動した後、インストールしたバージョンのBIOS画面になります。ここでmacOS向けの設定をすれば良いです。

今回は、1105の一つ前のバージョンである、1005に戻すことにしました。そこで、ROG-MAXIMUS-XI-HERO-WIFI-ASUS-1005.CAPをM11HW.CAPという名前に変更して、USBメモリに入れました。ちなみに現在の設定は、工場出荷状態に加えて、

Intel (VMX) Virtualization Technology –> [Enabled]
Memory Remap –> [Disabled]
iGPU Multi-Monitor –> [Enabled]
Connectivity mode (Wi-Fi & Bluetooth) –> [Disabled]
XHCI Hand-off –> [Enabled]

です。

SSDTで対応する

追記です。こちらの記事で紹介しましたようにSSDT-AWAC.amlを使っても解決しました。

300チップセットマザーボードのRTC設定

まとめ

ということで、ACPIのタイマー・アラーム機能を使うようになった最新のマザーボードでは、BIOSで古い形式のRTCを使うように設定する必要があります。ASUSのBIOSメニューでは、Advanced–>PCH Configuration–>System Time and Alarm SourceをLegacy RTCにすれば良いです。この設定ができない場合は、config.plistにパッチを書き込むことでも解決します。このマザーボードではどういうわけか、BIOSでLegacy RTCを選択できませんでした。そこで、パッチを当ててまで新しいBIOSを利用する必要はないと判断して、古いBIOSに戻しました。BIOSをダウングレードするために、マザーボードのFlashback機能を使用しました。

今回、マザーボードにとってBIOSを復活させる機能が重要だと思い知らされました。USB BIOS Flashbackならば、BIOSが徹底的に破壊されても復活できると思われます。再びマザーボードを買い換えるときには、この種の機能を重視していきたいと思います。

Catalina Public Betaが配布されました

Tue, 25 Jun 2019 18:45:55 +0900

Public Betaの配布

本日 (2019/6/25) からいよいよPublic Betaが配布され、無料で誰でも試せるようになりました。去年とほぼ同じタイミングです。

macOS Mojave Public Beta版を試す

無料配布のPublic版とは言っても、例年通り緩い守秘義務はあります。「Appleが公表していない情報はPublic Betaプログラム参加者以外に伝えてはいけない」のだそうです。以下の情報は公開済みの内容と思いますが、念のためにベータプログラム参加ページで登録してから読んでください。

Apple Beta Software Program

うっかり読まないように空行を入れておきます🙂

さて、上記のページから登録するとmacOSPublicBetaAccessUtility.dmgというファイルをダウンロードできます。この中に入っている

macOSPublicBetaAccessUtility.pkgを起動すると、ソフトウェアアップデートでPublic Betaが受信できるようになります。

ベータ受信機能は、ウィンドウ左下の「詳細」をクリックすれば、簡単にキャンセルもできますので、気軽に試してみましょう。

インストール方法

ダウンロードしたCatalinaのインストーラ、Install macOS Catalina Beta.app

を開いて、HDD内のHFS+でフォーマットした空きパーティションにインストールしてみました。使ったマシンは、こちらの構成です。Z390、第9世代CPU、Radeon RX580の構成です。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

EFIファイル類は上記のリンク先で紹介したものをそのまま使いました。Mojaveの起動に使用している構成です。ただ、Lilu関係のバージョンチェックを避けるために、念のために

-lilubetaall

を起動オプションに追加しました。これで問題なく起動しました。

（訂正：初稿に書いたリセット問題はCatalinaとは関係なく、BIOSの設定が足りなかったのが原因のようでした。BIOS設定の中で、System Agent (SA)関連のメモリ設定を色々変えていたら治りました。）

コンテナ構成が刷新

Public Betaをインストールしてコンテナ構成が新しくなったことに気づきました。上で書いたように試したボリュームはHFS+の古いタイプのHDDだったのですが、Catalinaのインストールで自動的にAPFSに変換されました。さらに、APFSのコンテナが2個作られました。今回はインストール先をCatalinaという名前にしたのですが、Catalina – Dataというコンテナが新たに作成されました。ディスクユーティリティ.appで見ると以下のようになります。

Catalinaで書き込み不可になったファイルとディレクトリー類が本体のコンテナに、それ以外の内容が – Data が末尾についたコンテナに自動的に振り分けられるようです。

まとめ

インストールは簡単でMojaveと同じ構成で起動可能です。また、サクサク動いて快適です。このままメインで使い続けても問題ないように思いました。

USB 3.1とType-Cコネクタ

Sun, 09 Jun 2019 17:30:24 +0900

USB Type-Cは逆さにも挿せる便利なUSBコネクタです。最近のほとんどのマザーボードに搭載されています。Z390/H370以降のマザーボードならOOBでgen 2の速度が達成できます。

USBの速度

まずはUSBの規格のおさらいです。今のコンピュータで使えるUSBには以下の三種類があります。

USB 2.0 速度は480Mbps。以下では簡単に2.0と書きます。5V、接地、信号線2本（D+とD-) の4本の配線を使います。D+とD-は、一般的にはhigh/lowが逆で動作しますが、特別の場合にはどちらもhighやlowになります。
USB 3.1 Gen 1 速度は5Gbps。長い間USB 3.0と呼ばれていた規格です。以下ではGen 1と書きます。信号線は、送信用に2本、受信用に2本の合計4本になります。それぞれの2本は、high/lowが逆になる差動対です。互換性のためにUSB 2.0の配線と一緒に使われます。
USB 3.1 Gen 2 速度は10Gbps (毎秒10Gビット)。以下では簡単にGen 2と書きます。また、Gen 1とGen 2のことをまとめて3.1と書くことにします。配線は Gen 1と同じです。

USBのコネクタ

速度の規格とは別に、コネクタもいろいろあります。ここではUSB AとUSB Type-Cを説明します。

USB Aコネクタ

一般的な四角のコネクタです。2.0, 3.1のどちらもAコネクタを使えます。

のぞきこむと4個の接点が見えます。これは2.0が使う電源、接地、D+、D-の4本です。

3.1も同じ形のコネクタを使い、やはりのぞきこむと4本の接点があります。ただこれは互換性のために残された2.0のコネクタです。なので3.1対応のAコネクタに2.0のケーブルや機器を接続すると2.0として機能します。3.1用のAコネクタの奥の方には、3.1のために、さらに5本のピンがあります。この5本は、送信用の2対、受信用の2対、接地用の1本です。

USB Type-C コネクタ

USB Type-Cのコネクタは24ピンで、逆挿ししても機能します。なので以下のように、上下に点対称でピンが配置されています。

中央のD+, D-は2.0の速度の通信のためのピンです。メス側（マザーボード側）は2組ありますが、これに接続するケーブル側は片方しかありません。なので、実際には裏か表の1組（D+, D-）だけが動作します。そこで、表のD+, D-と裏のD+, D-は同じものです。

これに対して3.1のための高速通信ピンには独立した2組があります。TX1+, TX1-, RX1+, RX1-の4本は1組目のピンで、TX2+, TX2-, RX2+, RX2-の4本が2組目のピンです。2組の3.1があるので同時に通信したら2倍高速になるような気もします。しかし、多くのマザーボードでは内部に3.1用USBハブを持っていて、TX1+, TX1-, RX1+, RX1-と、TX2+, TX2-, RX2+, RX2-は、1本の3.1を分岐しているだけのようです。なので同時に通信できたとしても合計で1本分の速度にしかならないです。

Type-Cの特殊能力

USB Type-C PD

Type-Cには以前のUSBコネクタには無かった新しい機能があります。その一つがPD (Power delivery パワーデリバリー)機能です。Aコネクタなどでも5Vの電源を供給していて、これを使って機器に電力供給したり充電したりしていました。これをさらに強化したのがType-CのPD機能です。PDでは、上記のコネクタに示す4本のVBUS線を使って大容量の電力を供給します。しかし、配線に流せる電流量には上限があります。なので必要に応じて電圧を上げて、同じ電流でより多くの電力を供給する工夫がされています。そのために、CCと書かれたピンを使って送電側と受電側で何ボルトに対応しているのかネゴシエーションします。双方が高電圧に対応している場合、20Vまで電圧を上げて、5Aまでの電流を流します。これで最大100Wもの電力を供給します。

多くのマザーボードはPDに対応していません。なのでMacBookを接続してもACアダプターほどの速度で充電できません。市販の30W PD対応ACアダプターとASUS ROG MAXIMUS XIで充電時間を比較しました。以下のように、ACアダプターだと1時間46分で充電できるところが、マザーボードだと約6時間かかるという表示になりました。

単純に比例計算するとマザーボードの供給電力は9Wのようです。通常のUSB 2.0端子が5V 2A程度（10W）ですので、従来のUSBの5Vがそのまま出ているだけでPDには対応していない様子です。

仕様書に「PDに対応している」ことが明記されたマザーボードもあります。例えば、[ASRockのZ390 Phantom Gaming-ITX/acは12V-3A (36W) までのPDに対応](https://www.asrock.com/mb/Intel/Z390 Phantom Gaming-ITXac/index.jp.asp#Specification)しているようです。このマザーボードを使えばMacBook付属ACアダプター並みの充電が可能と思われます。

USB Type-C Alternate-mode

Type-Cのすごい機能で、それゆえわかりにくいのがオルタネートモードです。ケーブルのデータ信号線を他のプロトコルによるデータ送受信に転用できるという機能です。3.1のデータ線のうち4本、2.0のデータ線2本などが他のプロトコルの信号を流すために使えます。使えるプロトコルには、Thunderbolt 3, DisplayPort, HDMIなどがあります。Type-CのコネクタがThunderboltやHDMIなどとして使えるのはこの機能があるからです。

現行製品でType-CがThunderbolt 3としても機能するマザーボードには、上記のASRock[Phantom Gaming-ITX/ac](https://www.asrock.com/mb/Intel/Z390 Phantom Gaming-ITXac/index.jp.asp#Specification)や、GIGABYE Z390 DESIGNAREなどがあります。ASRockのType-Cはディスプレイへの接続も可能と記されています。

Gen 1 も 2 もあるType-C

USB 3.1の速度仕様には紛らわしい点が多い気がします。長い間5GbpsのUSB 3.0が使われてきて、10GbpsのUSB 3.1が登場しました。その後、前者がUSB 3.1 Gen 1、後者がUSB 3.1 Gen 2と呼ばれるようになりました。5Gbpsでも3.1と呼んで良いことになり、なんとなく騙されそうな気分になります。一方、Type-CはUSB 3.1のためのコネクタとして登場しました。なのでType-Cに装備されている3.1は当然Gen 2だと思っている人も多いと思います。実際には、Type-CにもGen 1のものとGen 2のものがあります。

Mac

Macは他社製品に比べて早い時期からType-Cを積極的に搭載し、PD機能やThunderbolt, DisplayPortなどのオルタネートモード機能を採用してきました。でもUSB機能に関しては最近の機種でようやく対応したところです。MacBookシリーズではMacBookがまだGen 1です。デスクトップ機はMac ProがGen 1です。

マザーボード

マザーボードの3.1用Aコネクタにも、Type-Cにも、Gen 1とGen 2の両方があります。インテルのチップセットでGen 2がサポートされたのは300シリーズからです。（ちなみにZ370はZ270と同じ200シリーズです）。なので、300シリーズのマザーボードに搭載されているType-CコネクタはGen 2と考えて良いです。

200シリーズ以前でも、付加価値が求められる上位機種マザーボードでは、AsmediaなどのサードパーティUSBチップを搭載してGen 2をサポートしています。これらもHackintoshで使えなくはないようですが、使われているチップのバリエーションが多く不安定要素があります。これに対して、300シリーズのチップセット搭載Gen 2はmacOSがサポートしています。OOBで使えることが確実なので安心です。

同様な状況はGen 1の時にもありました。インテルのチップセットがGen 1（当時のUSB 3.0）をサポートしたのは7シリーズからです。それ以前のチップセットは2.0しかサポートしていませんでした。そこで色々なサードパーティUSBチップを搭載していたので、2.0は問題なく動くけどGen 1は不安定な状況でした。7シリーズになって何の問題もなくOOBで動くようになりました。

Type-Cの速度を実測する

測定方法

手元にあるマシンのType-Cの速度を計測しました。現在入手できるUSBメモリはType-C接続であってもほとんどすべてGen 1です。なので、M.2 SSDをGen 2ケースに入れて測定しました。M.2 SSDには以前のビルドでmacOSと相性の良かったWestern Digitalの250GB M.2 SSDを使用しました。

これをType-Cケースに入れました。これでUSB 3.1 Gen 2外付けSSDになります。このケースは透明で放熱板もついています。

ケーブルがGen 1にしか対応していなかったら台無しですので、Gen 2対応製品を購入しました。10Gbpsは電気的に厳しい周波数になるので、品質や長さに注意する必要があります。

測定にはAmorphousDiskMarkを使いました。

http://www.katsurashareware.com/pgs/adm-j.html

素のままのSSDは、M.2接続で以下のようなスピードでした。Readが30Gbpsです。Gen 2の速度 (10Gbps) よりはるかに高速ですので、外付けケースに入れるとUSB通信速度がボトルネックになります。

MacBook 2017のType-C

現行の製品ですがType-CはGen 1です。測定したらReadが4.3Gbpsでした。Gen 1の速度である5Gbpsと同程度です。

MSI H270M Mortar ArcticのType-C

こちらで紹介したビルトです。200シリーズのチップセットなのでGen 1です。チップセットのUSBがType-Cで使われているので、Type-CもGen 1です。MacBookと同程度の速度です。

システム情報を見てもスピードが5Gbpsであることが確認できます。コントローラのPCI製造元IDを見るとIntel (0x8086) なのでインテルチップセットを使っていることがわかります。ちなみにJMicron Technology Corp.は、このUSB Type-Cケースで使われているチップの製造会社と思われます。

ASUS ROG Maximus XI Hero (Z390)のType-C

こちらの記事で紹介したビルドです。こちらは300シリーズのチップセットなのでGen 2です。速度が9.7Gbpsと、ほぼGen 2の上限の10Gbpsになっています。

システム情報を見てもスピードが10Gbpsであることが確認できます。これもIntel (0x8086) のチップセットを使っています。

2019年式Mac Pro

Wed, 05 Jun 2019 22:18:02 +0900

拡張性の高いMac Proが6年ぶりに復活しました。PCIeスロットがなんと8本も装備されているようです。昔ながらのMac Proが復活したことはHackintoshにとっても嬉しいニュースです。

Mac Pro

PCIeスロットが復活

スロットは復活しないか、復活したとしても独自仕様になるのではと心配していました。なので標準規格のPCIeスロットが復活してよかったです。しかも4本しかなかった2012 Mac Proよりも本数が増えて8本もあります。太古のMacintosh IIですら6本でしたので、Mac史上最強の拡張性を誇ります。8本のうち4本は通常の倍の幅のカード用なので、標準PCIeの12本分のマザーボード領域が拡張スロットのために使用されています。ATX規格（最大7本）よりもはるかに拡張性があります。拡張性のなくなったゴミ箱Mac Proが不評だったことの反動ですね。これでmacOS対応のPCIeカードが、昔のように色々な会社から販売される可能性が高まりました。Hackintoshで使えるカードが増えるはずです。

ケースの形も期待以上

新型は、昔のタワー型Mac Proから、光学ドライブと3.5インチベイを取り外して、拡張スロットを増やしたような形状です。なので全体の大きさも重量もそれほど変わりません。（旧型が51.1 x 20.6 x 47.5 cm 18.1 kgに対して新型は52.9 x 21.8 x 45.0 cm 18.0 kg）穴だらけの外観は賛否両論あるようですが、昔のMac Proと同様に開けやすくてメンテナンス性の高い設計は好感が持てます。

昔のタワー型Mac Proにも取手と足がついていましたが、あまり実用的ではありませんでした。握ろうとすると角が立っていて手が痛かったです。アルミ板を曲げた構造だったので、見た目より華奢で、足の部分が変形しやすかったです。2019モデルの取っ手と足はステンレス丸棒らしく、頑丈で持ちやすそうです。キャスターも取り付けられるようです。ケースデザインはMac Proモデルの中で一番良いかもしれません。目ざといPCケースメーカーから、これを真似た構造のケースがすぐに発売されそうで楽しみです。Mac ProみたいなHackintoshが作れるようになると思います。

Hackintoshする必要性

この暗黒の6年間は、拡張性のあるMac製品が不在でした。なので拡張性のあるMacが必要なら、Hackintoshしか選択肢がありませんでした。その状況が6年前に戻り、拡張性のある最高グレードのハードウェアが欲しい場合には、再びアップル製品を買うことができるようになりました。なのでHackintoshの必要性は下がったと思います。ただ6年前と同様に、「Mac ProとMac miniの中間の性能でディスプレイ無しのデスクトップMacが欲しい」という要望にはHackintoshしか応えられません。デスクトップマシンとして一番需要のあるプロダクトラインが不在なのは以前と同じです。価格帯で見ても、miniが9万円からですが、新Proは5,999ドルからと、その間にかなりギャップがあります。この中間なら支払えるので、この中間の性能のデスクトップが欲しいというユーザは多いと思います。

搭載パーツとHackintosh

新Mac ProのCPUは公表されているコア数、クロック数などの仕様から、

Intel Xeon W3223
Intel Xeon W3235
Intel Xeon W3245
Intel Xeon W3265M
Intel Xeon W3275M

だと思われます。価格は749ドルから7,453ドルだそうです。これらのCPUを使ってのHackintoshは可能だと思われますが、今まで同様、メインストリームのCPUを使うより設定は大変だと思います。

グラフィックスカードは、AMD Radeon Pro 580X、AMD Radeon Pro Vega IIとのことです。どちらも新しいGPUのようですが、前者はiMac 2019にも搭載されています。後者はVega 20をベースにしたGPUらしいです。今までも、AMDはApple用に特別バージョンのGPUを提供していて、どれもProという名前が付いています。無印のオリジナルのモデルに比べてPro版は、Macの小さな筐体に合わせて少しクロックを落として発生熱量を下げているようです。何れにしてもRadeon RX 580やVegaがmacOSと相性が良い現状は変わらないと思います。新Mac Proは一番安いモデルでも5,999ドルだそうです。おそらく8コア12スレッドのXeon W3223とRadeon Pro 580Xが搭載されるのだと思います。i9 9900KとRX 580で組めば1/4くらいの価格で同程度の性能が手に入りそうです。

新Mac ProではT2チップが搭載されました。iMac 2019では搭載されなかったので、デスクトップではT2を使わないのかもという観測がありましたが、違っていたようです。もしもT2チップがハードウェアへのアクセスや拡張性を監視するようになると、Hackintoshに影響が出るかもしれません。でも先のことなので心配しても仕方ないでしょう。

PCIe拡張カードでSATAを増設する

Sat, 25 May 2019 23:17:47 +0900

SATAポートをASM1061搭載の格安PCIe拡張カードを使って増設しました。macOSから見たSATAチップの互換性は高いようで、大抵の拡張カードはそのまま「一般的なSATA」として認識されて動作します。

減少するSATAポート

マザーボードに搭載されているSATAポートの数が減っています。HDDの容量が増えたので、3.5インチのHDDを多数搭載する人が減ったためかもしれないです。光学ドライブも使われなくなりました。高速SSDはM.2でPCIeに直接接続するようになりました。このような理由なのか、従来のフルサイズマザーボードにはSATAが8本くらい搭載されていたところが、今は多くて6本止まりです。

SATA最大数が6本なのには理由があります。現行の300シリーズチップセット (Z390, H370, Q370, B360) がサポートするSATA 3.0の数が6本だからです（H310は4本）。これ以前のチップセットでも、サポートするSATAの数はだいたい6本でした。6本を超えるSATAポートを搭載したマザーボードは、チップセット以外にサードパーティのSATA 3.0チップを搭載していたのです。サードパーティメーカーには、ASMedia, JMicron, Marvellなどがあります。

SATAインタフェースカード

今の時代、SATAは6本もあれば大体足ります。でも昔風の大型ケースで作った自作パソコンに、光学ドライブを1台、3.5インチHDDを3台、2.5インチSSDを2台、さらにHDD2台搭載のリムーバブルベイを取り付けたりしていると、これでSATAが8本必要になります。そんなSATAを増やしたい人のために、PCIeソケット用SATAインタフェースカードが多数販売されています。そこで、SATAインタフェースカードを取り付けて増設することにしました。PCIeスロットを使ってなんでも増設できるところが、自作macOSマシンの強みです。

macOSは、インテルチップセットのSATAに加えて、サードパーティのSATAもサポートしています。なので大抵のSATAインタフェースカードはPCIeスロットに挿すだけで動作します。でも、「システム情報」のSATA装置ツリーを見ると、インテルのSATAはその名前で認識されているのに対して、サードパーティのSATAは「一般的なSATA」となっています。下は、後述するASMediaのSATAカードを取り付けた様子です。6本のインテルチップセットは正しく反映されているのに対して、追加の2本はGeneric Controllerと表示されています。

そのような場合に、MultiBeastと一緒に配布されているAHCI_3rdParty_SATA.kextまたは、AHCI_3rdParty_eSATA.kextを使用すると、正しい名称を表示してくれるようになります。

tonymacx86式インストール手順 (その2: MultiBeast)

更新：eのつく方のkextを使うと、以前のmacOSでは、接続したドライブが外部ドライブとして表示され、ホットスワップできました。ただ、Sierraあたりからこれが機能しなくなったようです。Sierra以降の対処法をこちらに書いておきました。

SATA接続HDD/SSDのホットプラグ（改訂版）

このkextの中のInfo.plistには、PCIeの製造者ID, 製品IDと製品名を結びつける記述があります。逆に、このkextに記述されたチップならば、macOSで間違いなく機能すると考えて良いです。すなわち、macOSで機能するSATAチップは、

ASMedia ASM1061
JMicron JMB360 AHCI
JMicron JMB360 RAID
JMicron JMB361 AHCI
JMicron JMB361 RAID
JMicron JMB362 AHCI
JMicron JMB362 RAID
JMicron JMB363 AHCI
JMicron JMB363 RAID
JMicron JMB366 AHCI
JMicron JMB366 RAID
Marvell 88SE9120
Marvell 88SE9123
Marvell 88SE9125
Marvell 88SE9128
Marvell 88SE9172
Marvell 88SE9230

です。これが搭載されたSATAインタフェースカードを入手すると良いです。ASM1061を搭載したカードは、2個のSATA 3.0コネクタがあります。価格は安いです。eSATA端子もついているので、外部HDDも使用できます。

こちらはeSATAの無いタイプです。

ちょっと高級なのがMarvell 88SE9230搭載のカードです。SATA 3.0が4個付いています。放熱板も付いて少し良い作りです。

激安SATAカードを試す

今回はSATAがあと2個欲しい状況でしたし、破格のカードを試してみたい気もしたので、ASM1061のカードを入手してみました。Amazonで送料込み1,000円未満なのがすごいです。（追記：その後、1,000円未満の商品は見つからなくなりました）中国から配送されるので、到着までに2週間ほどかかりました。購入した製品は、ジャンパーピンで、eSATAと内部用SATAコネクタを切り替えることができるタイプでした。挿すだけで認識されて機能します。AHCI_3rdParty_eSATA.kextを入れたところ、以下のように製造元・製品名が正しく表示されました。SATAが2.0しか搭載されていないタワー型Mac Proにも使えるカードだと思います。

15個制限を回避するUSBInjectAll.kextの役割と使用法

Sat, 04 May 2019 18:22:15 +0900

USBInjectAll.kextの役割を確認するために外して調べてみました。マザボ搭載USBポートの情報を正しく反映するために必要でした。さらに正確に反映させるためのSSDTを作りました。

USBInjectAll.kextの役割

このkextを外してみる

RehabManさんが開発してくれているUSBInjectAll.kextは、いつも使用しているのですが、そのありがたみがイマイチ理解できていませんでした。そこで外してみたらどうなるのか調べました。

USBポートの状態を調べるために、macOSから見えるハードウェア構成を確認するツールであるIORegistryExplorerを使用します。これを起動して、右上の検索欄でxhcとタイプすると、USB関連のポート一覧を見ることができます。この時、USBポートの名前がXHCではなくて、XHCIだったりXHC0だったりした場合は、config.plistでパッチを当てておいたほうが良いです。オリジナルのMacで使われている名前と衝突して問題を引き起こす可能性があるらしいです。

今回使用したのはASUSのZ390マザーボードであるROG MAXIMUS XI HEROです。これに搭載されているZ390チップセットの仕様を調べると搭載しているUSBは、

USB2.0が14本
USB3.1が10本（そのうち6本までをGen 2にできる）

だそうです。つまりIORegistryExplorerから見ると、HS01からHS14までの14本のUSB 2.0と, SS01からSS10までの10本のUSB 3.1が見える可能性があります。ただし、macOS El Capitanから導入された制約から、このうちの15本しか見えないはずです。

では、USBInjectAll.kextを外した状態でのMAXIMUS XIのUSBポート一覧です。こんな感じでした。

無意味に番号が飛んでいて、でたらめな感じがします。前の記事で調べたように、HS01はマザーボードのLED電飾機能が使っていて、HS14は内蔵Bluetoothが使っています。OSでもアプリケーションでも使用する重要なポートなのに、見えていません。また、このマザーボードでは、USB 3.1に付随する2.0は同じ番号を持っています。なのでSS01があるのにHS01が無いのは不自然です。明らかに、ASUSが提供しているマザーボード情報では無いと思われます。何かの方法で適当にリストアップされたように見えます。他にもHS13が見えてません。これはマザーボード上のUSB 2.0コネクタに接続しています。今回はここにmacOSと互換性のあるBluetoothモジュールを接続しているので、それがリストに無いと、Bluetoothキーボード、トラックパッドが使えません。

このkextを使ってみる

次に、USBInjectAll.kextを入れて起動した状態でのUSBポート一覧です。こうなります。

HS01から順番に欠番なくポートが見えていることがわかります。HSの次にあまり意味のないUSR1が来ていて、ここで15個の制限に達しています。なのでUSB 3.1のポートは見えていません。15個の制限がなければ、この後、USR2, SS01, SS02, …, SS10が、欠番なく全て見えるはずです。ということでUSBInjectAll.kextは、その名前の通り、もともと備えているUSBポートを全て認識させる機能を持っていることがわかりました。

このkextの中身を見る

このkextが、USBポート一覧をどうやって入手できたのかというと、作者のRehabManさんが用意しておいてくれたからです。kextの中の、Contentsの中に、Info.plistというテキストファイルがあります。これを開くと、前半部分に、USBコントローラのベンダーID、デバイスIDごとに、構成されているポート一覧が記載されていることがわかります。

使っているUSBコントローラのベンダーID、デバイスIDもIORegistryExplorerで知ることができます。

コントローラと思われるあたりをクリックすると、右側の詳細ペーンにvendor-id, device-idが現れます。リトルエンディアン方式なので逆に読みます。これによると、ASUSのこのマザーボードの場合、vendor-idは0x8086でインテル社であることがわかり、device-idは0xA36Dだとわかります。おそらくこれがZ390チップセットのUSBコントローラだと思われます。Info.plistで8086_a36dの場所を探すと、HS01からHS14と、SS01からSS10が記載されていることがわかります。

SSDTを作ってUSB15個制限に対応する

次に、USBInjectAll.kextの機能を使って、USB15個制限に対応する方法を説明します。今までの記事では、Cloverのブートオプションでuia_excludeを使う方法を紹介してきました。例えば、除外したいポートを以下のように指定します。

<key>Arguments</key>
<string>uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14</string>

などと書く方法です。この方式では、オプションをUSBInjectAll.kextが引き取って、Info.plistのリストから外してくれています。でも、RehabManさんおすすめの方法は、SSDTを作りUSBInjectAll.kextに知らせる方法のようです。

SSDTというのは、ハードウェアの情報を記載するDSDTファイルの補助的なファイルです。DSDTの一部の情報を上書きして変更します。USBポートに関する情報を上書きするSSDTを用意することで、USBInjectAll.kextは、Info.plistの内容ではなく、SSDTの情報を使用してくれるようです。この手順を以下で説明します。

USBポートを調べる

まずは、マザーボードに搭載されているUSBポートを調べて、使用したい15個のポートを決定します。上記のページには手順が詳しく説明してありますが、以前の記事で紹介したので省略します。その結果、今回使用したマザーボード、ASUS ROG MAXIMUS XI HEROには以下のポートがありました。

HS01 AsusTek社のAURA MOTHERBOARDが使用
HS02 (不明, マザーボード上のU31G2_2の可能性あり)
HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”)
HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”)
HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″)
HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下)
HS07 バックパネルUSB 3のUSB 2.0 (4列上から1番目、青、”SS”)
HS08 バックパネルUSB 3のUSB 2.0 (4列上から2番目、青、”SS”)
HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記)
HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”)
HS13 マザーボードの2.0端子USB_E12, USB_E34 (USB2.0 Hub経由)
HS14 マザーボード上のWiFi/Bluetoothモジュールが使用
SS01 (不明, 未使用?)
SS02 (不明, マザーボード上のU31G2_2の可能性あり)
SS03 バックパネルUSB 3.1 Gen 2 (4列上から3番目、赤、”SS10”)
SS04 バックパネルUSB 3.1 Gen 2 (4列上から4番目、赤、”SS10”)
SS05 バックパネルUSB 3.1 Gen 2 (Ethernetの下、赤、”SS10″)
SS06 バックパネルUSB TYPE CのUSB 3.1 Gen 2 (Ethernetの下)
SS07 バックパネルUSB 3.1 Gen 1 (4列上から1番目、青、”SS”)
SS08 バックパネルUSB 3.1 Gen 1 (4列上から2番目、青、”SS”)
SS09 マザーボードのU31G1_910の USB3.1 Gen 1
SS10 マザーボードのU31G1_910の USB3.1 Gen 1

このうち、以下の15個を使うことにしました。

HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”)
HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”)
HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″)
HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下)
HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記)
HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”)
HS13 マザーボードの2.0端子USB_E12, USB_E34 (USB2.0 Hub経由)
SS03 バックパネルUSB 3.1 Gen 2 (4列上から3番目、赤、”SS10”)
SS04 バックパネルUSB 3.1 Gen 2 (4列上から4番目、赤、”SS10”)
SS05 バックパネルUSB 3.1 Gen 2 (Ethernetの下、赤、”SS10″)
SS06 バックパネルUSB TYPE CのUSB 3.1 Gen 2 (Ethernetの下)
SS09 マザーボードのU31G1_910の USB3.1 Gen 1
SS10 マザーボードのU31G1_910の USB3.1 Gen 1

テンプレートからdslファイルを作る

この15個のUSBポートを指定するSSDTファイルを作成するために、そのテンプレートになるファイルSSDT-UIAC-ALL.dslを、こちらから入手します。コピーして、SSDT-UIAC.dslと改名しておきます。

このファイルには多数のUSBコントローラの情報が書いてあります。実際に使用するコントローラの項目だけを残して、他を削除します。ASUS Z390マザーボードの場合、vendor-idが0x8086で、device-idが0xA36Dです。この数値は上で説明したように、IORegistryExplorerでXHCの項目の中を探せば、vendor-id, device-idとして書いてあります。0x8086はインテルの番号ですので、インテルのチップセットを表しています。そこで”8086_a36d”と書かれた”Package”の定義だけを残して、他のPackageの定義を削除します。残すのは以下の項目です。

"8086_a36d", Package()
{

...........

},

この中にはHS01からSS10までのUSBの情報が書かれています。これに対して以下の作業をします。

コメントでポートの説明を記録しておく。後のメモになります。//で書き始めればコメントになります。
不要なポートをコメントアウトする。行頭に//を書いて、使用しないポートを除外していきます。削除せずにコメントにすれば、あとから復活させるのが楽です。
UsbConnector情報を更新する。これについては次に説明します。

UsbConnector情報

SSDT-UIAC.dslのそれぞれのUSBポート情報には、コネクタ種類が数字で記載されています。これを更新します。具体的には、以下のように書かれている部分の数字を、実際に合わせて書き換えます。

"UsbConnector", 3,

書き換える値は、以下の通りです。

0: USB 2.0のコネクタ
3: USB 3.1のコネクタ。3.1に付随するUSB 2.0も3にします。
255: 内部接続で外部に接続しないコネクタ。マザーボード内部でBluetoothユニットに接続しているなどの場合にこれを使います。マザーボード上のコネクタで外部に引き出す可能性のあるものは0または3にします。
9: USB Type-Cのコネクタ。逆挿しにしてもHSとSSの番号が変化しない場合。内部でハブに接続されているらしいです。
10: USB Type-Cのコネクタ。逆挿しするとHSとSSの番号が変化する場合。個別に接続されています。

この数字がどのように反映されるのか詳しくは知りません。でもIORegistryExplorerを見ると、255にした場合に電流に関するパラメータなどが消えるので、OSからの扱いが変化する可能性があります。また255にしたポートにArduinoを接続してみたところ、/dev/cu.usbserial-*などのデバイスが見えませんでした。USBシリアルドライバーが、この数字を基準に動作を変えているようです。Arduinoを接続するなら、0や3に設定しておくのが良いです。

どのHSポートがUSB 2.0になるのかUSB 3.1になるのか、さらにはどのポートがType-Cになるのかは、マザーボード次第です。USBInjectAll.kextのInfo.plistにマザーボードごとの情報まで反映できないので、RehabManさんは各自でSSDTを作って、使用するマザーボードに即したUsbConnector情報をOSに伝えることを推奨しています。

port-countを設定する

SSDT-UIAC.dslの最初の部分に、portsのセクションの前に、port-countというセクションがあります。

"port-count", Buffer() { 26, 0, 0, 0 },
"ports", Package()
{

ここに書く数値（10進数）には、今回作ったポートのバッファー値、例えば、

"port", Buffer() { 26, 0, 0, 0 },

などと表される数のうちの最大の数値を書きます。今回はたまたま末尾のSS10まで使用したので、26のままで変更無しです。

dslをコンパイルしてamlを作る

こうして作ったdslファイルはSSDTのソースファイルのようなものです。これをコンパイルしてSSDTであるamlファイルを作ります。これにはMaciASLを使用します。こちらの記事で説明しています。

DSDTを編集する

MaciASLで、上で作成したSSDT-UIAC.dslを開きます。次に、FileのSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。

こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_exclude=を指定しなくても、指定したポートのみが有効になるはずです。参考のために、今回作成したSSDT-UIAC.dslファイルを以下に置いておきます。

SSDT-UIAC.dsl for ASUS Z390 - Pastebin.com

SAPPHIRE PULSE RADEON RX 580 8G 再発売

Sat, 27 Apr 2019 20:29:13 +0900

一時期市場から姿を消したSAPPHIRE PULSE RADEON RX 580が、今年の3月から再販売されています。Apple純正のeGPU開発キットに搭載されている製品でmacOSとの互換性が高いです。

eGPU開発キット

ほぼ2年前のWWDC 2017でeGPUボックスの公式サポートが発表されました。一般的なPCIeグラフィックスカードをThunderbolt経由でMacに接続する外付けボックスです。そしてeGPUボックスを使ったアプリケーション開発のために、AMD Radeon RX 580を内蔵した開発者向けキット「External Graphics Development Kit」が発売されました。ただ、現在は品切れのようです。このキットに内蔵されているRX 580カードがSAPPHIRE PULSE RADEON RX 580です。

External Graphics Processors - Apple Developer

PULSEとNITRO+

SAPPHIRE社のRX 580製品にはPULSEとNITRO+があります。NITRO+は「品質と安定性に優れた」上位モデルで、PULSEはコスパ重視の下位モデルです。PULSEのブーストクロックは1,366MHzなのに対して、NITRO+は1,411MHzとよりオーバークロックされています。NITRO+の方が放熱モジュールも大きく、カードの高さ、長さ、幅が大きいです。PULSEはPCIe 2スロットで収まりますが、NITRO+は2.5スロットくらい占有します。PULSEもNITRO+も国内ではどちらも2017年4月に発売されました。

SAPPHIRE、Radeon RX 580/570搭載グラフィックスカード計6製品リリース - エルミタ…

しかしその後しばらくして、PULSEは店頭や販売サイトから姿を消して、NITRO+しか手に入らなくなりました。長らくそんな状態が続いていたのですが、今年の3月からPULSEが再発売されたようです。よく比べると型番の末尾が一文字だけ違いますが、仕様は同じです。おそらくは品切れに対応して、再度生産したのかと思われます。

セミファンレス対応のRadeon RX 580がSAPPHIREから、税込25,700円

PULSEのmacOS互換性

とにかく安いグラフィックスカードが欲しいとか、逆に高くて良いから最高性能が欲しいなどの強い要望がなければ、SAPPHIRE PULSE RADEON RX 580は良い選択だと思います。

上で述べたようにAppleが配布している開発キットのカードと同じなので、互換性が高いと考えられるからです。実際に、開発キットが出たばかりの初期の10.13.3では、PULSEだけが「このMacについて」に正しく名称表示されました。もっともこれは、単に表示だけの問題ですし、10.13.4以降では他の製品も正しく表示されています。なので他のカードを選んでも互換性の問題は全くありませんが、それでも、どれでもよければPULSEが良いと思います。開発者に出回っているカードなので、将来にわたって不具合が発生しにくいと考えられるからです。

PULSEは、販売サイトでも再登場しています。元々が普及価格帯モデルでしたので、マイニングブームの頃に比べたら手頃な価格になってます。

Xeon X5690を殻割りしてMac Pro Early 2009に取り付ける

Sat, 20 Apr 2019 16:08:00 +0900

Xeon X5690が安かったので2個買いました。これを殻割りしてMac Pro Early 2009に取り付けました。コア/スレッド数が8/16から12/24に増えて、Cinebenchのスコアが1.9倍向上しました。

古いMac Pro用のXeonが安い

今回は、Hackintoshの話ではありません。期待された方、すみません。

少し前にAliExpressでXeon X5690が1個$61で販売されていました。安さに惹かれて2個購入しました。この記事を公開した後、一時は$100くらいまで値上がりしましたが、今はまた$70以下に下がっているようです。国内でも、ヤフオクやメルカリを探すと1個あたり1万円台前半くらいで取引されているようです。

X5600シリーズは、Core iシリーズ第1世代のCore i7-980あたりと同世代の6コア12スレッドのCPUです。980も6コア12スレッドでしたのでそれのXeon版です。発売（2011年2月ころ）直後のX5690は15万円くらいだったようです。2個で30万円ですね。

3.46GHzの「X5690」など、Xeonシリーズに3つの新モデル！

いくら$61だったからと言って、こんな古いXeonをなぜ買ったのかと言うと、手元にあるMac Pro Early 2009 (MacPro4,1) のCPUと入れ替えようと思ったからです。このMac ProにはX5550 (2.65GHz)というCPUが2個搭載されています。4コア8スレッドなので2個で8コア16スレッドです。X5550だって発売当時（2009年3月ころ）は11万円以上したらしいです。

新型Xeonが一挙に8モデル登場！　LGA 1366×2マザーも (1/2)

このMac Proの次のモデル、Mac Pro Mid 2010 (MacPro5,1) では最上位機種にX5670が、Mid 2012 (これもMacPro5,1)にはX5675が搭載されました。X5670, X5675とX5690はクロック違いのほぼ同じCPUなので、同じハードウェアで動きます。X5690はクロックが上がっている分、TDPも上がっているので多少心配なところもありますが、気にしないことにします。

実はMacPro5,1とMacPro4,1は、ハードウェアはほぼ同じで、ファームウェアのみが異なっています。なので4,1のファームウェアを5,1にアップデートすれば、X5600シリーズCPUにも対応できます。この先のCPU交換を行うためには、ファームウェアをMacPro5,1にしておく必要があります。ファームウェアアップデートにはさらに大きなメリットがあります。MacPro5,1では現行のmacOS Mojave 10.14が動きますが、MacPro4,1ではmacOS 10.11までしか動きません。ファームウェアアップデートによりこの制限も解除されて、最新macOSを使えるようになります。ファームウェアのアップデートの手順は以下です。アップデートすると「このMacについて…」「システムレポート…」の表示がMacPro5,1になります。

2009 Mac Pro 4,1のファームウェアをアップグレードする方法

X5690を殻割りする

一般的に流通しているX5600シリーズCPUをMac Pro Early 2009に取り付けるためには、上で述べたファームウェアアップグレードの他にもう一手間必要です。というのは、Early 2009にはヒートスプレッダ（殻）のついていない、ダイがむき出しのCPUが使われているからです。それに対して流通しているCPUはほとんどが殻付きです。なので、Mac Pro Early 2009のCPUを交換している人たちは、次のどちらかの方法を行なっています。

殻付きのままのCPUを取り付ける。
殻を外して（殻割りをして）取り付ける。

殻割りをしない前者の方法には、色々と問題があります。本来、殻無しで設計されているところに、殻付きのCPUを無理やり取り付けることになります。なので殻の分だけCPUが分厚くなってしまい、CPUクーラーが浮き上がります。浮いたクーラーに対応するためにワッシャ等を入れてスペーサーとする方法もありますが、適切な高さに調整する事は困難です。適切に高さ調整できない場合は、クーラ締め付け圧力がCPU本体に直接加わってしまいます。その場合、ダイが破損したり、CPU基板が曲がる可能性があります。ちなみに、Early 2009では殻無しCPUに合わせたプラスチックカバーを用いて、締め付け圧力をソケットに逃がしています。殻付きのCPUを使う2010/2011年モデルのMac Proでは、通常の自作PCと同じくレバーで抑える金属のソケットカバーがあり、これが締め付け圧力を受け取り、CPU本体に力がかかりません。殻付きCPUをEarly 2009で使うと、このような仕組みが効かなくなってしまうのです。
一方、クーラーが浮き上がることは、周辺回路の冷却効果も損ないます。後の写真で示すように、CPUクーラーはCPUに電力供給しているVRM回路のMOSFET部分にも接触して冷却しています。しかしクーラー位置が上昇するとMOSFETとCPUクーラーが離れてしまいます。これを防ぐためには、熱伝導ゴムを重ねる必要があり、放熱効果が低下します。でも一番の欠点は、CPUクーラー内のファンに電力を供給するコネクタも浮き上がるので、コネクタ取り付け部分を破壊して、コネクタ位置を下げる必要がある事です。殻割りしない方法は、殻割りのリスクが無い以外は、デメリットだらけです。

殻割りをする後者の方法は、殻割りでCPUを壊すリスクがある以外は、何のデメリットもありません。取り付けの安定性も放熱効果も、設計通りのまま維持できます。Mac Pro Mid 2010 以降では殻付きCPUが使われていますが、これに対して無駄なヒートスプレッダが無いMac Pro Early 2009はより高い放熱性能が得られます。殻割りさえ成功すれば、この方法が理想です。

CPUを格安で入手したので、ここは殻割りをすることにしました。殻割りといえば、オーバクロックを目指す自作PCマニアの憧れイベントです。是非とも1度はやってみたかったです。しかもXeonはヒートスプレッダがダイに半田付けされています。グリスで付いている普通のCPUと違って、挑戦のしがいがあります。そこで、以下を参考に、CPU殻割りと交換を行いました。

『Mac Pro 2009アップグレード Xeon X5670装着＜CPU交換・換装編＞』

殻のシールを切る

ヒートスプレッダは周囲をゴム状の接着剤で貼り付けられています。また、中央部はCPUダイに低融点合金（以下、半田）で貼り付いています。まずは周囲の接着剤の部分を切り離しておきます。これにはカミソリの刃をつかいました。怪我をしないように手には軍手をはめ、CPU裏と縁はマスキングテープで養生しました。接着剤は硬いゴムのような手応えなので、力を入れてザクザク切っていきます。

下は、剥がしたヒートスプレッダの裏側写真です。黒い部分がゴム状シールです。このくらいの幅だけ差し込めば接着剤は切れます。これより内側には、コンデンサが表面実装されている場所もあるので、深く切り込まない方が良いです。周囲を切り終わっても、殻の中央がダイに半田付けされているので、殻は外れません。

半田を溶かす

次に半田を溶かして、殻を外します。Youtubeを見ると、たくさんの例が上がっています。基本的には、殻を外すような力を加えた状態で、殻を加熱します。加熱には、ヒートガン、アイロン、ガスバーナー、ライターなどが使われているようです。今回は、手近にあったヒートガンを使いました。またこの後の作業のために、スクレーパーを用意しました。

ヒートスプレッダにカミソリの刃を差し込んで、そこにスクレーパーを差し込みます。スクレーパーは片刃なので、刃の斜めになった面を下にして、刃の部分を差し込みます。カミソリの刃の弾力で、スクレーパーは差し込まれたまま固定されます。

またCPUの反対側をクリップでアルミ板片に固定しました。これでスクレーパーの片刃の根元部分が梃子の支点になり、これに柄の重みが加わって、梃子の作用点に当たる刃先に殻を外そうとする上方向の力が加わります。これを作業用の耐熱ゴム（写真の背景で青く見えている部分です）の上に置きました。このゴムシートは、500度までの耐熱性能があるらしいです。

次にヒートスプレッダをヒートガンで加熱します。あまり加熱すると、CPUが破損するかもしれません。そこで熱電対で温度を計測できるテスターを使って、CPUの温度をモニターしながら進めました。20-30秒くらい加熱したところで温度が200度を超え、230度くらいになったところでスクレーパーの柄の重みで殻が外れました。殻割りはあっけなく終了しました。

半田を剥がす

殻が外れても、ダイの上に半田が残っています。ダイが熱いうちにスクレーパーで剥がします。表面実装のコンデンサを保護するために、マスキングテープで養生した方が良いです。実は養生する前に、スクレーパーが滑ってコンデンサを1個剥がしてしまった気がします（小さすぎてよくわかりません）。コンデンサは、電圧を安定させるためのパスコンデンサーではないかと思います。結果としては、1個ぐらい外れても大丈夫でした。半田は、硬いチーズくらいの感じです。温度が下がったらヒートガンで再加熱すると柔らかくなります。

スクレーパーの刃はかなり精度が良いので、これだけでほぼダイの部分まで半田を剥がすことができました。指で触れても滑らかです。でも、鏡のように平らにした方が気分が良いので、さらにピカールで磨きました。綿棒でゴシゴシこすります。その結果、鏡面になりました（撮影しているスマホが写っています）。

接着剤を剥がす

CPUの基板の周囲には、ゴム状の黒い接着剤が残っています。これを剥がします。この後のCPU取り付けを、

ソケットにCPUを置く
その上にプラスチックの枠を置く
CPUクーラーを乗せてソケットにネジで締める

という手順で行います。黒いプラスチックの枠は、ソケットの周囲までカバーする形状をしていて、上に置いたCPUクーラーを締め付けた時の圧力を、ソケットに逃がす機能があるように見えます。この部品を使わないと、CPUのダイのみに力が加わってしまい、CPU基板が湾曲してダイを破損する可能性があるかもしれません。

このプラスチック部品は、ダイの厚みに合わせてあり、力を逃がしてくれつつ、ダイの表面がCPUクーラーに密着するよう作られているように見えます。ところが2番目の写真のように、殻を固定していた接着剤が残っていると、CPUクーラーとダイが、本来の間隔より接着剤の厚みだけ離れてしまいます。その場合、ダイがCPUクーラーに密着せず、放熱が妨げられる心配があります。そこで、接着剤をしっかりと除去しておこうと考えました。

ゴム状接着剤はかなり頑固で、アルコールでは除去できません。そのためにエレクトリッククリーナという製品を使ってみました。

クリーナーを吹き付けてると、硬いゴム状接着剤が消しゴムのように柔らかくなります。そこで、プラスチックのカードや、清掃用プラスチックのヘラ（100円均一で売ってます）で剥がします。クリーナーはしばらくすると蒸発して、綺麗になります。

さらにアルコールを浸したキムワイプで拭き取りました。これで、半田も取れて、シール材も取れて、美しいCPUになりました。

CPUを交換する

CPUボードを外す

Mac Proは良くできていてメンテナンスが楽です。CPUとメモリー部分は、マザーボードとは別にドーターボードに実装されています。これは、2本のレバーを外すだけで取り外せます。

ドーターボードの上に、銀色のCPUクーラーが2個あります。それぞれは3mmの六角ネジ4本で固定されています。上の黒い穴にドライバーを差し込んでネジを回します。細い穴の入り口からネジまでの距離が7.5cmくらいあるので、軸が細くて長い六角ドライバか六角レンチが必要です。そのために用意したのがこちらの六角軸ビットです。

5本セットですが、必要なのは3mmの1本だけです。バラ売りもあったのですが割高でした。バラ売り2本で5本セットが買える価格（2本買えば3本が無料）だったので、ついこちらにしてしまいました。普通の長い六角レンチなら、もっと安価な選択肢が多数あるのですが、今回は、次に述べるトルクドライバーを使いたいために、軸径6.35mmの六角軸ビットを用意しました。

トルクドライバー

CPUクーラーは六角レンチで簡単に外せます。でも外す前にトルクを調べておくことにしました。

自作PCで一般的に使われるCPUクーラーは、ヒートシンク部分をバネの力で押し付けています。取り付けネジが止まるまで締めれば、バネの力で適切な圧力がかかる設計です。これに対して、Mac ProのCPUクーラーは、ネジのトルクでCPUを押さえつけます。その場合、ネジ締めトルクがそのままCPUクーラーを押さえる力になるので、設計通りのトルク値でネジ締めする必要があります。自作PCに馴染みの深いCPUでは、RyzenのThreadripperがその方式で、CPUパッケージには一定のトルクで締められるドライバーが付属しています。

Mac ProのCPU交換をした先人の情報によると、CPUクーラーの取り付けネジは、締めすぎても、締め足りなくて駄目で、適切なトルクで締めないと起動しないそうです。そこで、トルクを調整できるドライバーを用意しました。少し高価ですが、金属製で精密な作りのドライバーで所有する喜びがあります。このドライバーには＋ネジ用のビットが2サイズ付属していますが、それではCPUクーラーに対処できないので、上で紹介した六角軸ビットが必要です。

CPUクーラーを外す前に、このドライバーを使って締め増しを試みました。トルクを40cNmに設定したところすぐに空回りをしますが、50cNmでは10度くらい回転し締め増すことができました。8本全てのネジを試しましたが同様でした。ということで、50cNmのトルクで締めれば適切のようです。

CPUを取付ける

あとは自作PCとほぼ同様です。まずは、CPUクーラーを取り外します。この時、グリスにくっついてCPUとプラスチック部品も外れるので、ソケット上に落とさないように注意します。また、CPUクーラ内のファンに電源を供給するコネクタを外す必要があるので力加減に気をつけます。埃が溜まっていると思いますので、掃除もしておきます。CPUクーラーのヘリには熱伝導ゴムが貼り付いていて、これがCPUのVRMのMOSFETにも接触して冷却しています。下の写真の細長い銀色のゴム状部分（青矢印）が熱伝導ゴムで、基板上の1列の四角い金属チップ（黄矢印）がMOSFET類です。埃で汚れている可能性があるので、これらもアルコールで掃除しておきます。

次に、殻割りしたX5690をソケットに乗せて、プラスチック部品を乗せて、グリスを塗って、CPUクーラーを取り付けます。ファンコネクタがはまるように注意します。トルクを50cNmに調整して、6角ネジを締めます。この時、4個のネジを、対角にあるネジを次に締めるような順番で、少しずつ締めていきます。最後にMac Proに取り付ければ完成です。電源を投入すれば、ジャーンという起動音が聞こえるはずです。

性能比較

X5550からX5690に交換したことで、GeekBenchのマルチコアスコアは、15168から22583と1.5倍向上しました。コア数が8から12と1.5倍になったので、その程度の差が出ました。

9900Kで動くmacOSのマルチコアスコアは30000超えが普通ですので、それには及びません。GeekBenchブラウザで他機種のスコアと比較すると、Mac Pro Mid 2012の最上位機種 (X5675) 程度のスコアです。

またCinebenchのCPUスコアは843から1579に向上しました。1.9倍の改善です。ベンチマークしながらアクティビティモニターでCPUコア一覧を開くと24スレッドが働いていて圧巻です。

発熱の状態（追記）

コメントでCPU温度やファンの状態について質問いただきました。確かに、本来のモデルはTDPが95WのX5670, X5675を搭載する設定に対して、ここではTDPが130WのX5690を取り付けました。排熱が追いついているのか気になるところです。

温度を測るために、Intel Power Gadgetをインストールしようとしたところ、マルチCPUには対応していませんでした。

それでHWMonitorを使うことにしました。

HWMonitorを使う

これらの準備をしている程度の負荷では、CPU温度は35~45度くらいのようでした。11月なので室温は20度くらいと思います。ファンはとても静かに回ってます。ちなみにPCH Dieという場所の温度が80度なのは何かの間違いな気がします。CPU交換以前でも、この場所は異常な温度を示していたように思います。

まずはGeekbench 5のCPUベンチマークを動かします。このベンチマークは、負荷を短時間しか与えないので、それほど温度は上昇しませんでした。最大で72度くらいです。

Geekbench 5の結果は、マルチコアで6055でした。上で示したGeekbenchとはバージョンが違うので、数値も違います。10コア20スレッドの10900Kが11,000くらいです。出たばかりのM1搭載MacBook Airは7400くらいらしいので、それにも負けてます。2 CPU 12 コア 24スレッドと構成ユニットの数は最強なのですが。

次にCinebench R23を数回連続して稼働してみました。

ちなみにCinebench R23の結果は8464 ptsでした。弟分のX5650が6867なので、妥当な結果でしょうか。

温度は80度を超えましたが、まだ頭打ちにはなってないのでもう少し頑張れるようです。また、ファンが爆音状態になるということはなかったです。

あとがき

CPUは格安だったのですが、これに対して結構色々と道具や工具を揃えてしまいました。でも往時なら総額30万円のCPUのためですから、これくらい良いかと思いました。とはいえ、CPUが2個、総コア数が12個もあって、消費電力も多いのにも関わらず、現代の8コア16スレッドの9900Kで作ったHackintoshの3分の2くらいの性能です。最新CPUで作るmacOSマシンのコストパフォーマンスの良さを再認識しました。

起動しないマシンをUEFI Shellで救う

Thu, 18 Apr 2019 20:06:05 +0900

UEFIマザーボードには各種設定やファイル表示・変更ができるコマンドラインシェル機能があります。これを使用すればOSが起動する前にファイル変更・移動・削除できるので、誤設定で起動しなくなったマシンを救えます。

UEFI Shellへの入り方

UEFI Shellは、UEFI環境で動作するオープンソフトウェアです。Cloverをインストールすると、EFI/CLOVER/toolsの下にShell64.efiというような名前でインストールされます。Cloverの起動ドライブ設定画面から「Start UEFI Shell 64」を選択すると起動します。

最近のマザーボードには、マザーボード内のメモリーにもすでにUEFI Shellがインストールされています。なので、BIOSメニューの中からもシェルを起動できます。起動メニューは、BIOSのSave & Exitの項目の中にあることが多いです。下は、MSIのマザーボードの例です。「UEFI: Built-in EFI Shell」というメニューを選ぶとシェルに入ります。

CloverのESPにあるシェルとマザーボードで用意されているシェルは、バージョンが異なります。Cloverから起動できるシェルの方が機能が多いです。以下では、Cloverから起動したシェルで説明します。

ESPのあるファイルシステムに移動する

シェルが起動したら、

help -b

とタイプするとヘルプの一覧が出ます。-bオプションは、画面１ページごとに一旦停止して表示するためのオプションです。このオプションはほかのコマンドでも使えます。今回使うべき機能は、

bcfg NVRAMに保存されたbootとdriverオプションを管理します。
cd ディレクトリーを移動します
cp ファイルやディレクトリをコピーします
edit エディタを起動してファイルを編集します
exit シェルを終了します
ls ディレクトリの中のファイルを表示します
map ファイルシステム (FS) のマップを表示・定義します
reset システムをリセットします
mv ファイルやディレクトリを移動・改名します
rm ファイルやディレクトリを消去します

です。このうちbcfg, edit, map以外はmacOSの（というかUnixの）シェルコマンドと同じです。シェルが起動したらまずは、

bcfg boot dump

とタイプします。NVRAMに保存された起動情報をdump（画面表示）するコマンドです。これでboot可能なドライブ一覧が表示されます。boot可能ドライブが1個しかなければ、1個が表示されます。複数あれば複数表示されます。複数現れる場合はbootの優先順です。

何かの不具合でブートドライブとして見えない場合はこのコマンドで追加もできます。例えばaddコマンドを使って、fs1:\EFI\EFI\BOOT\にあるBOOTX64.efiをブート順位2（先頭は0）に、Boot macOSという表示名で追加する場合は以下のようにします。

bcfg boot add 2 fs1:\EFI\EFI\BOOT\BOOTX64.efi "Boot macOS"

また不要なドライブを一覧から消すこともできます。例えばrmコマンドを使って順位4を削除する場合は、以下のようにします。

bcfg boot rm 4

今回はdumpコマンドを使って単に閲覧するだけにします。以下は、bootドライブが一つだけの場合のdumpコマンドの実行例です。

UEFIはBOOTX64.EFIというファイルを見つけてコンピュータのbootを行うのですが、そこに至るパスがDevPathという項目に書いてあります。最初がドライブの種類で、パーティションがGPTであるかなどが書かれています。そのあとに32桁の16進数があります。これはパーティションを特定するUUIDです。ESP (EFI System Partition) がdisk0s1の場合、macOSのターミナルからdiskutilコマンドを使って、

diskutil info disk0s1

とタイプするとESPのパーティションUUIDがわかるのですが、それと同一のものが見えているはずです。これでESPのパーティションUUIDの目星をつけてメモしておきます。UUID全部をメモする必要はなくて、最初と最後の数桁で良いです。

次に

map -b

とタイプします。ファイルシステムのマップが出てきます。この中に、先ほどのESPのUUIDと同じものがあるはずです。それを見つけて、ESPのファイルシステム番号を確認します。行頭にFSと書いてある次の番号です。ドライブが1個しかなければ、ESPは大抵FS0:に割り当てられています。以下は、ESPがFS0:に割り当てられていた場合で説明します。

次に

fs0:

とタイプします。Unix系のファイル操作と違って、ファイルシステム（ほぼパーティションに相当します）ごとにルートディレクトリがあります。C:ドライブやD:ドライブのあるWindowsの方式に近いです。Windowsではドライブキャラクタにコロンをつけるとそのドライブ内のルートディレクトリに移動します。このシェルでも同様にfs0:でESPのルートディレクトリに移動します。なのでこの後、

ls

コマンドをタイプすると、ESPのルートのファイル名（多分EFIというディレクトリが一つ）見えます。この後は、ls, cd, cp, mv, cp, rm, edit, type (Unixのcatに相当)コマンドを駆使して、ファイルを操作します。

config.plistを書き換える

動いているマシンのconfig.plistをちょっと変更したら起動しなくなってしまった、という経験は皆さん何度もされていると思います。そんな場合はUEFI Shellでconfig.plistを元のように書き換えてしまうことができます。起動しなくなってもCloverの起動選択画面表示はされると思いますので、そこでUEFI Shellを起動します。上記の手順を踏んで、ESPのファイルシステムに移動します。その後、

cd EFI\CLOVER
ls
edit config.plist

とタイプすれば、CLOVERのディレクトリに行き、ファイルを一覧し、config.plistを編集できます。ディレクトリの区切りは、Unixのように/（スラッシュ）ではなく、\（逆スラッシュ）です。これもWindowsのような流儀ですね。また、タブキーで補完機能が効くので、例えばedit conあたりでタブを押せばあとを補完してくれます。（Unixの補完と違って最初にヒットした名前に補完されるので多少注意が必要です。）

editコマンドではフルスクリーンのテキストエディタが開きます。コントロールEでヘルプが表示されます。操作は簡単で、

Ctrl-G 行に移動。行番号の入力を促される
Ctrl-S ファイルを保存する
Ctrl-Q 終了する
Ctrl-F 検索する
Ctrl-R 検索・置換する
Ctrl-K 行をカットする
Ctrl-U 行をペーストする
Ctrl-O ファイルを開く
Ctrl-T ASCIIとUNICODEの切り替え
Ctrl-E ヘルプを開く
Ctrl-W ヘルプを閉じる

です。これで大体の編集は可能なので、config.plistを元に戻すことができます。config.plistを保存し、エディタを終了した後で、

exit

もしくは

reset

コマンドをタイプしてシェルを抜けます。resetコマンドはシステムがリセットされます。exitコマンドでは、Clover選択画面に戻ります。大体はexitコマンドでokですが、変更内容によっては変更が反映されないことがあります。resetの方がより確実です。

kext/efiファイルを差し替える

kextやefiファイルを追加したり削除したことで起動しなくなる事故も多いです。これもEFI Shellの操作で復帰できます。kextやefiファイルを外したい場合は、cdコマンドでEFI/CLOVER/kexts/Otherに移動して（EFI Shellの中では区切りを逆スラッシュで指定します）、rmコマンドで削除するか、mvコマンドでバックアップ用のディレクトリに移動させるのが良いです。例えば、_unusedというディレクトリ（名前の最初の文字をアンダースコアにした理由は、ファインダーで上位に表示されるので分かりやすいかと思ったからです）がkextsの中に作ってある場合、ABCD.kextというkextは、

mv ABCD.kext ..\_unused\.

で移動します。もしくは、mvコマンドで、ABCD.kext.backupというようにファイルタイプを変えてしまうのも良いかと思います。バックアップせずにrmコマンドで消してしまっても良いです。

起動に必須だったkext/efiを削除して起動しなくなった場合も同様な方法が可能です。上の例と同様に、もし削除する前に_unusedフォルダのような場所にバックアップされてあればそこから戻せます。

mv ..\_unused\ABCD.kext .

kext/efiとは違うファイルタイプに変えてあるのでしたら、名称変更すれば良いです。

mv ABCD.kext.backup ABCD.kext

ということで、kext/efiを削除する場合は、起動しなくなる状況に備えて戻せるように、ESPのどこかに残しておく事が重要です。

また新たに必要なファイルをUSBメモリに入れて、それを起動ESPに追加することも可能です。例えば、USBメモリの場所がfs3だったら、

cp fs3:\DSDT-XXXX.aml .

のようにしてコピーすることが可能です。

Hackintoshが起動しなくなる前にやっておくこと

Sun, 14 Apr 2019 15:59:40 +0900

設定を変更したら起動しなくなってしまったという経験は誰にでもあると思います。その前に少しだけ準備しておけば復旧の手間を減らすことができます。そんな工夫をいくつか書き連ねてみました。

本物のMacではmacOSが起動しない事態に陥ることは滅多にありません。しかし色々設定してなんとか本物のMacに近い動きを実現しているHackintoshでは、ちょっとした設定の変更やOSのバージョンアップでマシンが起動しなくなることはよくあることです。真っ黒な画面を目にして、設定を変えなければよかったとか、もっと考えてからバージョンアップすればよかったと後悔することが多いです。どんなに間違った設定をしても、それ以前に動いていたなら、インストールした手順を最初から繰り返せば元に戻せます。でもそこまで手間をかけなくても、大抵の失敗はもっと簡単に取り戻せます。

追記：EFI Shellを使うと良いですとコメントいただきました。確かに、ここで書いた事態は、EFI Shellを使って回復できるようです。ということで、続きは以下をご覧ください。

起動しないマシンをUEFI Shellで救う

動作するconfig.plistをバックアップしておく

config.plistをちょっとだけ書き換えたら動かなくなるという失敗はいつもやってます。こんな事態に備えて、動いているconfig.plistを変更する場合には、そのコピーを作っておくと良いです。コピーの名前は、configXXXXX.plistとします。例えば、

cp config.plist config_old.plit

としてから、config.plistに変更を加えます。こうするとESPのCLOVERディレクトリにconfig.plistとconfig_old.plistの二つの設定ファイルが出来上がります。CLOVERはconfig.plistの内容を読んで起動します。config.plistを書き換えたことにより起動に失敗する場合は、Cloverの起動ドライブを選ぶ画面から、Optionメニューを選んで、config.plistメニューを選びます。するとconfig_old.plistをラジオボタンで選択できます。これを選べば元どおり起動するはずです。

ESP全体をクラウドにバックアップしておく

config.plistを別名でコピーしておくことを忘れてしまい、起動するconfig.plistがESPにもはや存在しない場合は、上の方法は使えません。ただ、Cloverのオプションメニューからは、いろいろな設定を一時的に変更できるので、それで復旧できることもあります。でも、config.plist編集以外の作業をした場合、例えばefiファイルやkextファイルを差し替えたとか、DSDTを書き換えたなどの場合は、復旧が難しい場合が多いです。

その場合、動いていた時のESP全体のバックアップがあれば復旧は楽です。バニラなインストールをしている場合、ESP以外は実機のMacと同じで、いろいろな復旧方法があります。OSならApp Storeからダウンロードし直せば良いです。またTime Machineでバックアップしておけば、データが壊れたとしても取り戻せます。HDDを多数接続できる自作HackintoshはTime Machineの利用がやりやすいので、是非検討してください。

Time Machineは良いです

ESPは常時マウントするものでは無いので、Time Machineバックアップには不向きです。量も少ないですし、手作業でバックアップしておくのが良いでしょう。バックアップ先は色々考えられますが、今時ならばクラウドが良いと思います。絶対安全ですし、紛失しませんし、他のマシンからアクセスできるので、復旧用USBメモリーを作成するのも簡単です。バックアップのタイミングも色々考えられますが、一番効率が良いのは、ESP書き換え作業の直前です。作業直前に動作している最新のESPをバックアップしておけば、次の起動に失敗しても復旧できます。ということで、ESPをマウントすると同時にバックアップを取っておく方法を以前にこちらで説明しました。

ESPをマウントしてついでにバックアップする

訓練：バックアップESPから復旧する

いざという時に本当に復旧できるのかどうか、訓練してみました。まずはメインで使っているHackintoshをシャットダウンします。次に、サブで使っているMacBookで、以下の作業をしました。

適当なUSBメモリ(GUIDパーティション) のESPをマウントして開く
iCloudドライブにアクセスして最新ESPをUSBメモリにコピーする

手持ちのGUIDパーティションのUSBメモリーにEFIがなかったり、diskutil repairdiskコマンドでEFIが作れるらしいとか、でもUSBメモリーのサイズが小さいとEFIが作れないなど、色々発見がありましたが、最終的にはUSBメモリーで無事起動できました。

画面共有・sshサーバを起動しておく

macOSのインストールに成功して、ネットワーク機能が動くようになったらすぐにやっておくと良いことがあります。それは、「システム環境設定」「共有」から「画面共有」と「リモートログイン」を有効にしておくことです。リモートログインはsshd (sshのサーバ) を動かす機能です。これらが有効になっていれば、他のマシンから画面共有やsshで接続することができます。

Hackintoshを設定していて、グラフィックス機能が動かなくなり、起動しても画面が出ないことがあります。また、スリープから目覚めた時に、グラフィックス機能が復帰できずに画面が真っ黒なままなこともあります。このような場合、コンピュータは止まっているように見えますが、内部では動いています。なので、画面共有やsshで接続して、設定を調整し直すことが可能です。また、それが可能ならば、不具合の原因がグラフィックス関係であることが特定できます。

APFSコンテナにボリュームを作っておく

macOSのバージョンアップで起動しなくなる場合もあります。Cloverやkext類が最新でないことが原因である場合が多いです。また、kextをバージョン別のフォルダに入れている場合、新しいバージョン用のフォルダを作り忘れるというケアレスミスもあります。現在動いているmacOSを非常用のシステムとしてインストールしておくと、このような場合に早く復旧作業に入れます。外付けのドライブやUSBメモリーに非常用のシステムを作っておくと、いざという時に見つからない場合もあります。接続中のドライブに非常用システムのボリュームを作っておくのが安心です。

APFSになってからボリュームを作る作業が楽になりました。APFSコンテナの中に、好きな時に必要なだけのボリュームを作ったり消したりできます。パーティション一つがボリューム一つだった時代は、使われない記憶領域ができて無駄だったのですが、APFSのボリュームなら必要な記憶容量しか使用しません。何も加えないmacOSならば14GBほどのサイズです。私が作ったMojaveの起動ボリュームは13.6GBでした。これが苦にならない程度のAPFSコンテナがあれば、非常用システムを作っておくと良いと思います。こちらで説明しておきました。

APFSのVolumeを活用する

ASUS MAXIMUS XI HEROのUSBを設定する

Tue, 09 Apr 2019 23:35:30 +0900

ASUS マザーボードのUSB設定をしました。使わないUSBポートの番号を調べ、その番号をconfig.plistに書きます。これでmacOSの個数制限によりUSB 3が使えなくなる事態を回避します。以下の記事で紹介しているように、ASUS MAXIMUS HEROマザーボードに9900Kを搭載したマシンは順調に稼働しています。

9900K搭載Z390マザーボードでHackintoshを作る

今回、回避しようとしているのは、macOSのUSB個数制限です。macOS El Capitanから使用可能なUSBポートの数が、コントローラ当たり15までと制限されてしまいました。理由は不明です。この対策は何通りかありますが、15個の制限は残したまま、使用しないUSBポートを除外するようconfig.plistに設定するのが一番良いと思います。

USBポートを設定する

上の記事では、MSI Z97A Gaming 7マザーボードを例に、使用しないポートをconfig.plistに書くことで、必要なUSBポートが使用可能になるよう設定しました。同じ手順をASUS MAXIMUS XI HEROマザーボードでも行いました。

USBInjectAll.kext

まずはUSBInjectAll.kextを入手してEFI/CLOVER/kexts/Otherフォルダに入れます。

RehabMan / OS-X-USB-Inject-All / Downloads — Bitbucket

このkextは、チップセットで用意されているUSBポートの全てをmacOSから参照できるように設定する機能があります。この記事で利用しようとしている機能、config.plistの起動オプションで使用しないポートを除外する機能は、このkextが提供しています。

何も対策しない場合のUSB構成

まずは、何も対策しないとどのUSBポートが見えているのかを確認します。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。

mac.softpedia.com

IORegistryExplorer.appを起動して、右上の虫眼鏡アイコンのところに、xhcと入力します。するとXHC関係の情報が現れます。全く対策しない状態のASUS MAXIMUS XI HEROマザーボードでは、以下のような結果になりました。

XHCの下にHS01~14とUSR1が見えています。これらが現在OSが認識しているUSBポートです。macOSは15個しか認識しないので、アドレスの低い方から15個のポートが見えています。マザーボードにはこれ以外にもUSBポートがあるのですが、15個超えているものは見えません。

USRを除外する

HSはHigh Speedの略でUSB 2.0のことです。USRは、tonymacx86の説明によると何らかの都合で見えてしまっているダミーのポートらしいです。なので除外しても良いらしいです。とりあえずUSR1を除外してみましょう。USBInjectAll.kextを使用した上で、config.plistのBoot Argumentsに以下のように指定します。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

新たにUSR2が見えるようになりました。実はこれも実存しない不要なポートらしいです。これも除外しましょう。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1;USR2</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

不要なUSR1, USR2を消したので、ようやくSSが見えてきました。SSはSuper Speedの略で、USB 3のポートを示しています。

HS (USB 2.0) ポートを特定する

この段階で見えているHSポートであるHS01からHS14の14個が、マザーボードにあるとmacOSが認識している全てのUSB 2.0ポートです。これがどこのポートなのか特定していきます。ちょっと大変な作業ですが、マザーボードの構成を把握できるので、達成感はあります。

マザーボード上のUSB 2.0ピンソケットを調べるためには、こんなアダプタがあると便利です。

それぞれのポートに対応する番号を調べるためには、

それぞれのポートにUSB機器（無線アダプタやマウスなど）を接続し、
IORegistryExplorer.app の表示の変化を確認する

ことで、特定できます。下の例は、とあるUSB 2.0ポートにLogicoolの無線キーボードアダプタを挿入してみたところです。HS11のport-statusが、最初は0x0だったのですが、下の図のように0x1100に変化しました。これで、このポートはHS11だということがわかります。USB 3のポートの場合、2.0と3の両方を持っていますから、USB 3.0のデバイスを挿せばUSB 3.0の番号が、USB 2.0のデバイスを接続すれば、USB 2.0端子の番号の、それぞれの該当項目が変化します。

こうしてASUS MAXIMUS XI HEROマザーボードのUSB 2.0を調べました。各ポートの番号は以下のようになっていました。

HS01 AsusTek社のAURA MOTHERBOARDが使用
HS02 (不明, マザーボード上のU31G2_2の可能性あり)
HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”)
HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”)
HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″)
HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下)
HS07 バックパネルUSB 3のUSB 2.0 (4列上から1番目、青、”SS”)
HS08 バックパネルUSB 3のUSB 2.0 (4列上から2番目、青、”SS”)
HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記)
HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”)
HS13 マザーボードの2.0端子USB_E12, USB_E34 (USB2.0 Hub経由)
HS14 マザーボード上のWiFi/Bluetoothモジュールが使用

HS09とHS10は、マザーボード上のUSB 3.1 Gen 1ポートに接続しています。マニュアルには下のような図面があります。マザーボード上にU31G1_910と書かれたソケットがあり、ここにUSB 3.1 Gen 1が2本出ています。それぞれに付随しているUSB 2.0端子がHS09とHS10に接続しています。

HS13は、マザーボード上のUSB 2.0端子に接続しています。マニュアルには下のような図面があります。マザーボード上にはUSB_E12, USB_E34という名称のソケットがあり、ここにUSB 2.0が4ポート出ています。ただ、これらの4ポートは内部でUSBハブに接続していて、HS13が大元になっているようです。今回は、この基板上USB 2.0端子の一つにBluetoothユニットを接続しています。なので、HS13だけは除外できない重要なポートです。

バックパネル部分は以下になります。

少し面白い発見だったのはHS01です。IORegistryExplorer.appの検索窓の文字を消すと、絞込み機能が無効になり、全ての情報が見えるようになります。そしてHS01の詳細を見てみます。すると以下のように、名前がAURA MOTHERBOARDになっていて、製造者名はAsusTek Computer Inc.と表示されます。どうやらマザーボードの電飾ユニットに接続されている様子です。もしもこれをプログラムできればmacOSから電飾をコントロールできるのかと思われます。

マザーボードが使っているUSB 2.0はもう一つあります。HS14です。これはバックパネルにアンテナが出ているインテル製のWiFi/Bluetoothモジュールが使っています。この無線モジュールは、内部がA/E KeyのM.2ソケットになっているのですが、このKeyのソケットにはUSB 2.0が1個含まれています。そのUSB 2.0がHS14に接続されているようです。BIOSで無線モジュールをEnabledにして起動すると以下のようにBluetooth Host Controllerと表示されます。Disableにした時は何も接続されない状態の表示になります。idVendorの項目を見ると0x8087です。これはインテル社のIDです。

Bluetooth以外のHS (USB 2.0)を全部除外する

USR1, USR2を除外したことで、USB 3としてはSS01があることはわかりました。他のUSB 3ポートは15個の制限で隠されています。そこで、全てのUSB 3ポートを調べるために、絶対必要なHS以外を一時的に除外します。Bluetoothは基板のHS13に接続されているので、これが無いとキーボードとトラックパッドの操作ができなくなってしまいます。そこで、これ以外のHSを全部除外してみます。Boot Argumentsに以下を書いてみました。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>>uia_exclude=USR1;USR2;HS01;HS02;HS03;HS04;HS05;HS06;HS07;HS08;HS09;HS10;HS11;HS12;HS14</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

HS13を含めて全部で11項目あります。15個未満なので、これで全てです。ということでこのマザーボードにはSS01からSS10までの10個のUSB 3があることがわかりました。

このマザーボードはインテルのZ390チップセットを使っているのですが、インテルの仕様によるとUSB 2.0が14本、USB 3.1が10本あり、最大で14本のUSB 2.0/3.1を使用できることになっています。このマザーボードはチップセットが提供するUSBの全てを使っているようです。

SS (USB 3) ポートを特定する

USB 3であるSSがSS01からSS10まで10個見えるようになりました。これらのうちバックパネルのSSを特定しました。これにはUSB 3.0のUSBメモリを挿しながら調べました。

SS01 (不明, 未使用?)
SS02 (不明, マザーボード上のU31G2_2の可能性あり)
SS03 バックパネルUSB 3.1 Gen 2 (4列上から3番目、赤、”SS10”)
SS04 バックパネルUSB 3.1 Gen 2 (4列上から4番目、赤、”SS10”)
SS05 バックパネルUSB 3.1 Gen 2 (Ethernetの下、赤、”SS10″)
SS06 バックパネルUSB TYPE CのUSB 3.1 Gen 2 (Ethernetの下)
SS07 バックパネルUSB 3.1 Gen 1 (4列上から1番目、青、”SS”)
SS08 バックパネルUSB 3.1 Gen 1 (4列上から2番目、青、”SS”)
SS09 マザーボードのU31G1_910の USB3.1 Gen 1
SS10 マザーボードのU31G1_910の USB3.1 Gen 1

このマザーボードはHSとSSの数字部分が対応しているようです。バックパネル写真に合わせると以下のようです。ちなみに、バックパネルのUSB 3ポートには、青いポートにSS、そして赤いポートにSS10と表示が書いてあるのですが、これはそれぞれ3.1 Gen 1とGen 2を示しているようです。10というのはおそらくGen 2の転送速度である10 Gbpsのことだと思います。

SS09とSS10はマザーボード上のUSB 3.1 Gen 1ポートであるU31G1_910に接続しています。マニュアルの図を再掲します。

SS01とSS02は発見できませんでした。上で書いたように、このマザーボードはUSB 3.1とこれに付随するUSB 2.0のそれぞれのHSとSSに、同じ番号を割り当てています。HS01はマザーボードの電飾コントローラと思われるので、これに対応するSS01は存在しないのかと推測されます。SS02とこれに関係する可能性のあるHS02は、共に発見できませんでした。このマザーボード上にはUSB 3.1 Gen 2のコネクタもついています。U31G2_2という名前です。別売の「USB 3.1 Gen 2 ポート増設用モジュール」というものを接続するコネクタらしいのですが、手元に無いのでチェックできませんでした。SS02とHS02は、このU31G2_2に接続しているのかもしれません。

必要なUSBポートを選んで他を除外する

さて以上からほぼ全てのUSBポートの番号がわかりました。ここから、使用したいUSBポートを最大15個選び、それ以外の使用しないポートを除外する設定をします。

基板上の3.1 Gen 1コネクタを使用しない場合

マザーボード上のUSB 3.1 Gen 1ポートであるU31G1_910を使用しない場合を考えます。基板上のUSB 2.0コネクタに関しては、Bluetoothモジュールが使用するのでこれ (HS13) は外せません。HS13と、バックパネルのポートを全て使うことにすると、必要なポートは以下のようになりました。

HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”)
HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”)
HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″)
HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下)
HS07 バックパネルUSB 3のUSB 2.0 (4列上から1番目、青、”SS”)
HS08 バックパネルUSB 3のUSB 2.0 (4列上から2番目、青、”SS”)
HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記)
HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”)
HS13 基板の2.0端子USB_E12, USB_E34 (USB2.0 Hub経由)
SS03 バックパネルUSB 3 Gen 2 (4列上から3番目、赤、”SS10”)
SS04 バックパネルUSB 3 Gen 2 (4列上から4番目、赤、”SS10”)
SS05 バックパネルUSB 3 Gen 2 (Ethernetの下、赤、”SS10″)
SS06 バックパネルUSB TYPE CのUSB 3 Gen 2 (Ethernetの下)
SS07 バックパネルUSB 3 Gen 1 (4列上から1番目、青、”SS”)
SS08 バックパネルUSB 3 Gen 1 (4列上から2番目、青、”SS”)

なんと全部でちょうど15個です。そこで、これ以外を除外するよう設定します。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14;SS01;SS02</string>

末尾に近いSS09以降は、除外リストに入れる必要はないです。この結果、IORegistryExplorer.appの表示が以下のようになりました。

基板上の3.1 Gen 1コネクタを使用する場合

大抵のPCケースには全面パネル近辺にUSB 3.1 Gen 1ポートが2個付いています。これを使用するためには、マザーボード上のU31G1_910に接続することになります。U31G1_910は、HS09, HS10, SS09, SS10です。先のリストは最大限度の15個に達しているので、4個を削除しないとこれらを使えません。そこでバックパネルにあるUSB 3.1 Gen 1の青いポートであるHS07, HS08, SS07, SS08を除外することにしました。なんとなく残念ですが仕方ないです。そうすると使用するポートは以下になります。

HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”)
HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”)
HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″)
HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下)
HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0
HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記)
HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”)
HS13 基板の2.0端子USB_E12, USB_E34 (USB2.0 Hub経由)
SS03 バックパネルUSB 3 Gen 2 (4列上から3番目、赤、”SS10”)
SS04 バックパネルUSB 3 Gen 2 (4列上から4番目、赤、”SS10”)
SS05 バックパネルUSB 3 Gen 2 (Ethernetの下、赤、”SS10″)
SS06 バックパネルUSB TYPE CのUSB 3 Gen 2 (Ethernetの下)
SS09 マザーボードのU31G1_910の USB3.1 Gen 1
SS10 マザーボードのU31G1_910の USB3.1 Gen 1

これ以外を除外するには以下のように設定します。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1;USR2;HS01;HS02;HS07;HS08;HS14;SS01;SS02;SS07;SS08</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

補足：バックパネルのUSBポート

マザーボードのマニュアルに掲載されているバックパネルのポートの説明図は以下です。USB 3ポートのうち、青いポートがGen 1ポート、赤いポートとType CポートがGen 2ポートのようです。

つづき：USB構成を記述したSSDTを作る

この記事では起動オプションで使用USBポートを指定しています。USBInjectAllの機能をフルに活用するためには、SSDTファイルを作ることが理想的です。続きは以下の記事をご覧ください。

15個制限を回避するUSBInjectAll.kextの役割と使用法

フォーラム（掲示板）を作りました

Sun, 07 Apr 2019 23:45:28 +0900

コメント欄にいろいろ書き込みをいただけるようになったので、記事内容にこだわらない話題や質問などを書き込めるフォーラムを作ってみました。上のメニューから「フォーラム一覧」を選ぶとフォーラムに移動します。今の所、カテゴリー分けしていませんので、なんでも自由に書き込んでください。フォーラム機能を使うことは初めてのことなので、色々と不具合あるかもしれません。それもおしらせください。匿名でも書き込めるよう設定したつもりなのですが、どうでしょう？メールアドレスはダミーでも投稿できるとおもいます。

9900KのためにmacOS 10.14.4 (18E2034) を入手する

Sat, 06 Apr 2019 12:47:04 +0900

（10.14.5が配布されたのでこの情報は不要になりました。）

この記事の執筆時点で配布されているmacOS Mojave 10.14.4はビルド18E226です。しかし最新のiMac Early 2019には18E2034が搭載されています。これが簡単に入手できることがわかりました。

新iMac対応Mojaveが欲しい

第9世代CPU 9900KでHackintoshを作ったら、機種ID、シリアル番号、ボードIDなどのSMBIOS設定も同じCPUを搭載するiMac Early 2019に合わせたいところです。ところがボードIDを27インチiMac Early 2019の値、Mac-AA95B1DDAB278B95に設定するとmacOSが起動しません。

Cloverのブートオプションに-no_compat_checkを追加するだけで簡単に回避できるのですが、できれば対応したmacOS Mojaveが使いたいと考えていました。10.14.5が出るまで待たねばと思っていたところ、コメント欄から、実機に搭載されている10.14.4 (18E2034)が入手できたとの情報をいただきました。試してみました。

iMac19,1の設定でMojaveを入手

入手方法は簡単で、iMac19,1として動いているマシンからApp Storeに接続してMojaveをダウンロードするだけです。

今回使用したマシンは、ASUS MAXIMUS XI HEROに9900Kを搭載したHackintoshです。iMac E2019が店頭に出回る前には、このマシンをMacmini8,1と設定していました。その時に、App StoreからMojaveを入手して、インストールしていました。これをiMac19,1のSMBIOS情報に設定し直した状態の「このMacについて」ウィンドウが以下です。

ビルドは通常配布されている18E226であることがわかります。iMac19,1に設定すると、上で述べたようにそのままでは起動しないので、Cloverのブートオプションに-no_compat_checkを追加して無理やり起動しています。CPUは9900Kなのですが、表示では不明になっています。この状態で、再び10.14.4を入手し直します。まずは、App Storeへ接続し、Mojaveを検索してそのページに移動します。

ここで「入手」をクリックすると、いつものようにソフトウェア・アップデートのウィンドウに移動します。次にダウンロードボタンを押すと、macOS Mojaveインストール.appを入手することができます。

この方法で入手できるインストーラのバージョンは14.4.10です。

これを使ってMojaveをインストールすると、ビルドが18E2034になります。

プロセッサは不明のままです。（途中でメモリを追加したので容量が増えていますが同じマシンの画面です。）

18E2034はEarly 2019限定？

面白いことにiMac19,1（と多分iMac19,2）に設定されていないマシンからApp Storeに行っても、18E2034はダウンロードできないようです。本物のMacでも試みましたがダメでした。その場合、ダウンロードされるインストーラのバージョンは14.4.08になります。これをインストールするといつものビルド番号である18E226になります。

手順のまとめ

以上から、現時点で、9900Kマシンを作って対応したmacOSを入手する手順はこうなると思います。

9900Kマシンを作る
本物のMacでMojave 10.14.4インストーラを入手する。本物はおそらくMacがiMac Early 2019では無いので、18E226になる。
9900Kマシンにインストールする。この時、SMBIOSをiMac19,1に設定しても良いが、ボードIDの関係で起動しないので、ブートオプションに-no_compat_checkを追加しておく。
起動した9900KマシンからApp Storeへ行って、再度10.14.4を入手してインストールする。これでビルドが18E2034になる。

第9世代CPU用のSMBIOSを書く

Wed, 03 Apr 2019 18:04:56 +0900

iMac Early 2019でようやく第9世代CPUがサポートされました。出回っている機種情報を使ってシリアル生成ソフトを用意して、config.plistのSMBIOSセクションを作りました。実機に近い設定ができたと思います。

iMac E2019の情報

以下で紹介しましたが、新型iMac Early 2019 (27インチのiMac19,1と21.5インチのiMac19,2) が出たおかげで、macOSもようやく最新のデスクトップCPUに対応しました。ただし新型iMacには、最新の10.14.4のビルド番号18E226よりも新しいバージョン (18E2034) が搭載されているようです。第9世代CPUに完璧に対応したmacOSを一般人が入手できるのは次のバージョン (10.14.5もしくはSU) になりそうです。

新型iMacに第9世代CPUがようやく搭載される

ここで参考にした情報は、「マックお宝」が公開しているYoutubeのビデオ、Geekbenchのスコアページ、店頭で見てきた情報などです。

シリアル番号

シリアル番号は「このMacについて」を見ればすぐにわかります。現在店頭にあるiMac E2019は、全て中国製で、（当たり前ですが）2019年製造です。なので、シリアル番号の最初4桁は、全てC02Yです。シリアル番号の仕組みはこちらをご覧ください。

Macシリアル番号の仕組み

次の桁は製造週ですが、店頭にある製品は9週もしくは8週です。9週のものが多かったです。2019年の第9週は2/26から3/4の週で、8週はその前の2/19から2/25の週を表します。

次の3桁は製造ライン番号と言われていて、製品個別の番号です。最後の4桁がモデルコードです。iMac19,1のモデルコードにはJV3Q, JV3P, JV3N, JV40が、iMac19,2のモデルコードにはJWDW, JWDXが発見されました。この他にも多数のコードがあるはずです。みなさんも発見できたら是非ともコメントでおしらせください。他の記事でも紹介していますが、正しいモデルコードならば次のURLのPPPPの場所に指定すると該当マシンの仕様ページが表示されます。

http://support-sp.apple.com/sp/index?page=cpuspec&cc=PPPP

以上のことから、現在店頭にあるシリアル番号は、C02Y9xxxJV3Qなどとなります。

ボードシリアル番号

ボードシリアル番号は、シリアル番号より確認しづらいです。後述のmacserialプログラムでも確認できますが、macOSの標準コマンドでしたらnvramコマンドが使えます。ターミナルから次のコマンドをタイプすれば表示されます。

nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB

現在店頭にあるiMac E2019のボードシリアル番号は、本体と同じく中国製のようです。製造年は、当然ながら2019年で、製造週は、本体より1週間早く、07週もしくは08週でした。ボードシリアル番号の後半には、ボードの種類を示すボードコードがあります。iMac19,1のボードコードにはLNV9, KDP0が、iMac19,2のボードコードにはKGQGが発見されました。なので、現在店頭にある製品のボードシリアル番号は C02908xxxxxLNV9xxなどになります。

その他のID

ボードIDは、iMac19,1がMac-AA95B1DDAB278B95、iMac19,2がMac-63001698E7A34814でした。これはGeekbenchのページでも確認できます。これ以外にはありません。

また、システム情報に出てくる番号として、ブートROMのバージョンがあります。これはどれも220.250.368.0.0でした。

シリアル生成プログラム

シリアル番号の仕組みの記事では、シリアル番号を自動生成してくれるプログラムmacserialをご紹介しました。これをforkさせていただき、上記で得たシリアル番号生成のための情報を付け加えました。これでiMac E2019のシリアル番号を自動生成できます。Intelの8600, 9600K, 9900KをCPUとして使用したHackintoshを作る場合には、iMac19,1のシリアル番号が最適です。8100, 8500, 8700の場合は、Macmini8,1でも良いかもしれませんが、iMac19,2も使えます。コンパイルしたバージョンのmacserialをこちらに置いておきました。

Releases · bootmacos/macserial

./macserialとして起動すると現在のマシンのIDを表示します。./macserial -hでヘルプが出ます。iMac19,1のシリアル番号を生成したいのでしたら、./macserial –model iMac19,1とタイプすると、シリアル番号、ボードシリアル番号の一覧を出してくれます。

./macserial --model iMac19,1
 C02YC017JV3Q | C02909207GULNV9AD
 C02Z7JYAJV3Q | C02933102GULNV9JA
 C02YNYZNJV3Q | C02918200GULNV91F
 C02ZP0XSJV3Q | C02946802QXLNV91H
 C02YRAYQJV3Q | C02921200GULNV9A8
 C02YN3ZGJV3Q | C02918403GULNV9CB
 C02YM085JV3Q | C02917403CDLNV9AD
 C02ZC0AFJV3Q | C02936303GULNV91F
 C02Y800NJV3Q | C029078024NLNV9FB
 C02ZP2YPJV3Q | C029467004NLNV91M

./macserial –info とすると、そのシリアルの情報を表示します。例えば、上の例の最初の候補の場合、

./macserial --info C02YC017JV3Q
 Country: C02 - China (Quanta Computer)
 Year: Y - 2019
 Week: C - 10 (05.03.2019-11.03.2019)
 Line: 017 - 41 (copy 1)
 Model: JV3Q - iMac19,1
 Valid: Possibly

と表示されます。2019年第10週の製造です。最初の製品の2週間後の製造なので、ちょうど良いくらいかと思います。数か月後くらいの多少の未来の番号でもおそらく大丈夫だと思います。しかし、最初の製品が第8週製造なので、これよりも以前の2019年1~7週の番号は避けた方が良いと思います。

シリアル番号を既に決めているのであれば、./macserial –mlb で、同じ国で、前の週に製造されたロジックボードのシリアルを生成してくれます。

./macserial --mlb C02YC017JV3Q
 C02909108GULNV9AD

SMBIOSを書く

それではiMac19,1に限りなく近い設定のSMBIOSセクションを書いてみましょう。上記の例のシリアル番号・ボードシリアル番号を使う場合、以下のようになるかと思います。（皆さんのご自分の番号を使ってください）SmUUIDも、ターミナルのuuidgenコマンドで適当に生成して記入してください。

<key>SMBIOS</key>
	<dict>
		<key>Board-ID</key>
		<string>Mac-AA95B1DDAB278B95</string>
		<key>BoardSerialNumber</key>
		<string>C02909108GULNV9AD</string>
		<key>EfiVersion</key>
		<string>220.250.368.0.0</string>
		<key>ProductName</key>
		<string>iMacm19,1</string>
		<key>SerialNumber</key>
		<string>C02YC017JV3Q</string>
		<key>SmUUID</key>
		<string>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</string>
	</dict>

Board-IDはiMac19,1に使用されているロジックボードIDを入れました。EfiVersionは、ここに書いておけば、本物のiMac E2019と同様に、「システム情報」のブートROMのバージョンの項目に表示されます。これ以外のSMBIOSの項目はCLOVERが自動生成してくれます。もしかしたら現バージョンのCloverはiMac19,1に対応していないかもしれませんが、将来のバージョンでは対応するはずです。

このSMBIOSを使ってみた

このSMBIOSを9900K搭載のHackintoshに設定し、App Storeで配布されている通常のmacOS Mojave 10.14.4 (18E226)で使ってみたところ、残念なことに起動しませんでした。こんな画面になってしまいました。

一般配布されている10.14.4は、iMac19,1に搭載されているビルド番号18E2034と異なっていて、ボードIDがサポートされていないようです。10.14.5まで待てば解決されるかと思います。それまでの間は、config.plistのBootオプションに、

<key>Boot</key>
   <dict>
     <key>Arguments</key>
     <string>-no_compat_check</string>

と記載して、互換性チェックをしないように指定しておくことにしました。

iMac E2019対応の10.14.4を入手する

と、思っていたところ、iMac E2019対応の10.14.4 (18E2034)を入手する方法をコメント欄で教えてもらいました。おかげさまで、-no_compat_checkのブートオプションを付けなくても起動するようになりました。この10.14.4を入手する方法は簡単で、iMac19,1 または19,2に設定したマシンでApp Storeを起動して、Mojaveを検索してダウンロードするだけです。これをインストールすると、iMacに搭載されているビルドと同じ18E2034になります。それでも、プロセッサは「不明」と表示されてしまいます。これはちょっと謎です。

Clover ConfiguratorがiMac19,xに対応

macserialをforkしてiMac19,1, 19,2に対応させた後、オリジナルのmacserialのacidantheraさんにPull requestsしておきました。そうしたらすぐに承認されて、macserialのソースコードに反映されました。コミュニティへの本当に些細な寄与ですが、初めてなので嬉しいです。その結果、かどうかわかりませんが、Clover ConfiguratorもiMac19,xに対応してくれたようです。これでSMBIOSが簡単に作れるようになりました。

シリアル番号をいくつか発生させてみたところ、上で紹介したモデルコードとボードコードを使ったシリアルが現れます。今回調べた情報を使ってくれているようです。

10.14.4で第9世代CPUの互換性が向上

Tue, 26 Mar 2019 17:58:21 +0900

10.14.4へのアップデートが現地時間で昨日公開されました。早速インストールしてみたところ、9900KのiGPUを使うためのconfig.plistの設定が不要になっていました。第9世代CPU搭載のiMacが発売された直後のリリースなのでこれに対応したものと思われます。

10.14.3以前で必要だった設定

9900Kを使うためには、config.plistのDevices, Propertiesの項目にiGPUの設定が必要でした。9900Kにも、MacBook Pro 2018やMac mini 2018のCPUにも、同じIntel UHD グラフィックス630が搭載されています。しかし、デバイスIDが異なっていました。そのため、config.plistに、本物Macに搭載されているiGPUのデバイスIDを書いておく必要がありました。以下のようにです。

<key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>

 <key>device-id</key>
 <data>
 mz4AAA==
 </data>

 </dict>
 </dict>

これを設定すれば完璧に動作しますが、書いておかないと、

スリープが正しく機能しない。（画面は暗くなるもののCPUファン電源が遮断されない。さらには、その後スリープから復帰しない。）
JPEGファイルのクイックルックができない。

などの不具合が発生しました。こちらをご覧ください。

9900Kのsleep問題〜原因はiGPUのデバイスID

10.14.4で互換性が向上

10.14.4にアップデートしたところ、device-idの記述を含めて、Propertiesの記載を全部削除しても、スリープとクイックルックが問題なく動作しました。（10.14.3でPropertiesの記載を削除すると、これらの問題が発生することを確認しています。）。新型iMacが対応したことで第9世代CPUの互換性がさらに向上したものと思われます。これを反映した9900K用のconfig.plistを以下に掲載しておきます。SMBIOSのProductNameはMacmini8,1です。新型iMacの情報が判明したら差し替えたいと思っています。

config.plist for 9900K w/o iGPU display - Pastebin.com

Macシリアル番号の仕組み

Sun, 24 Mar 2019 12:52:47 +0900

Hackintoshを作る時には、機種IDやシリアル番号などのいくつかのIDを決める必要があります。今回はシリアル番号とボードシリアル番号の文字・数値の意味を説明します。以下の、シリアル番号自動生成ツールの資料とソースコードを参考にしました。

GitHub - acidanthera/macserial: Decode mac serial number

Hackintoshに必要な番号

HackintoshがMacとして機能するためには、機種ID、様々なシリアル番号、ファームウェアバージョンなどを決めておく必要があります。これらはconfig.plistのSMBIOSセクションに記述されます。Clover configuratorを使うと、Macの機種を指定するだけでSMBIOSに書くべき内容を自動的に作成してくれます。しかし、最近のバージョンのCloverでは、SMBIOSのほとんどの内容を自動的に設定してくれますので、この機能に任せた方が間違いが無くて良いです。またBIOSバージョンなどの数値は、本来ならばmacOSインストーラがファームウェアアップデートすると更新される数値なので、Cloverが決めてくれる最新値を使う方が良いです。Cloverに任せておけば、間違いのない最新の数値を設定してくれます。

その一方で、手作業で設定した方が良い番号もあります。以下の設定です。

 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>xxxxxxxxxxxxx</string>
 <key>ProductName</key>
 <string>Macmini8,1</string>
 <key>SerialNumber</key>
 <string>xxxxxxxxxxxx</string>
 <key>SmUUID</key>
 <string>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>
 </dict>

ProductNameは、機種IDに相当します。一般には、ハードウェア構成（特にCPUの種類）が一番近いMacの機種IDを設定するのが良いです。SmUUIDは、ターミナルから何度かuuidgenとタイプして得られる32桁の適当な数値を設定しておきます。一部のソフトウェアではインストール台数制限のチェックにも使っているようです。一度決めたら変えない方が良いです。

SerialNumberはMacのシリアル番号です。本物のMacでは筐体に刻印されています。また、BoardSerialNumberはロジックボード（Apple社はマザーボードをロジックボードと呼びます）のシリアル番号です。ロジックボードに刻印されていることがあります。普通にMacを使っている限り、どちらの番号もずっと同じものですが、Macを修理してロジックボードを交換するとBoardSerialNumberは違うものになる可能性があります。

SerialNumberとBoardSerialNumberはとても重要です。これが正しい値に設定されていない場合、iMessageやApp Storeなどが正しく機能しない場合があります。2014年8月から2015年2月にかけて、iMessageでのシリアル番号チェックが非常に厳しくなった時期がありました。これをきっかけにシリアル番号のリバースエンジニアリングが進みました。

シリアル番号

Macのシリアル番号には11桁のものと12桁のものがあります。古い機種は11桁で、最近の機種では12桁です。それぞれの桁は、以下のような意味があります。

| Type | Location | Year | Week | Line | Platform |
| --------- | --------- | ---- | ---- | ---- | -------- |
| Old (11) | LL | Y | WW | SSS | PPP |
| New (12) | LLL | Y | W | SSS | PPPP |

以下では、以下のiMac15,1のシリアル番号の例（12桁）を使って説明します。

C02PJTYNFY10

製造場所番号(2 or 3桁)

最初の3桁 C02は製造国、製造都市、メーカなどを表します。C02は中国のQuantaコンピュータが製造したという意味だそうです。他に判明している3桁コードは以下です。

 - C02, China (Quanta Computer)
 - C07, China (Quanta Computer)
 - C17, China
 - C1M, China
 - C2V, China
 - CK2, Ireland (Cork)
 - D25, Unknown
 - F5K, USA (Flextronics)
 - W80, Unknown
 - W88, Unknown
 - W89, Unknown
 - CMV, Unknown
 - YM0, China (Hon Hai/Foxconn)
 - DGK, Unknown

ちなみに11桁シリアル番号では製造場所コードは2桁です。以下の意味だそうです。

 - CK, Ireland (Cork)
 - CY, Korea
 - FC, USA (Fountain, Colorado)
 - G8, USA
 - QP, USA
 - XA, USA (ElkGrove/Sacramento, California)
 - XB, USA (ElkGrove/Sacramento, California)
 - PT, Korea
 - QT, Taiwan (Quanta Computer)
 - UV, Taiwan
 - RN, Mexico
 - RM, Refurbished Model
 - SG, Singapore
 - W8, China (Shanghai)
 - YM, China
 - H0, Unknown
 - C0, China (Quanta Computer, Tech-Com)
 - C3, China (Shenzhen, Foxconn)
 - C7, China (Shanghai, Pegatron)
 - MB, Malaysia
 - EE, Taiwan
 - VM, Czech Republic (Pardubice, Foxconn)
 - 1C, China
 - 4H, China
 - MQ, China
 - WQ, China
 - 7J, China (Hon Hai/Foxconn)
 - FK, China (Zhengzhou, Foxconn)
 - F1, China (Zhengzhou, Foxconn)
 - F2, China (Zhengzhou, Foxconn)
 - F7, China
 - DL, China (Foxconn)
 - DM, China (Foxconn)
 - 73, Unknown

RMは整備品であることを表しています。

製造年(1桁)

例に示したシリアル番号の、次の一桁であるPは製造年を表します。12桁のシリアル番号では各年号に英字が割り当てられています。ペアの最初の英字が1-6月で、後半が7-12月を表しているそうです。なので、Pは2015年前半を表します。アルファベットのうち英字のI, Oなどが抜けているのは1や0と間違えやすいからだと思われます。他の欠番も何か理由があってのことと思います。

| Pair | Year |
| -------- | ---- |
| `C`, `D` | 2010 |
| `F`, `G` | 2011 |
| `H`, `J` | 2012 |
| `K`, `L` | 2013 |
| `M`, `N` | 2014 |
| `P`, `Q` | 2015 |
| `R`, `S` | 2016 |
| `T`, `V` | 2017 |
| `W`, `X` | 2018 |
| `Y`, `Z` | 2019 |

追記 : 上記の方式では2020にコードを使い切ることになります。実際にどうなったかというと、iMacの2020年モデルでは、こちらで紹介したように、CとDが使われています。2010のコードを再利用しているようです。(2020/8/14)

11桁シリアル番号では、製造年は西暦一桁めの数値です。

| Char | Year |
| ---- | ---- |
| `3` | 2003 |
| `4` | 2004 |
| `5` | 2005 |
| `6` | 2006 |
| `7` | 2007 |
| `8` | 2008 |
| `9` | 2009 |
| `0` | 2010 |
| `1` | 2011 |
| `2` | 2012 |

こちらは2012年に一巡して破綻してます。現行のシリアル番号も2020年以降の年番号がどうなるのか心配です。

製造週(2 or 1桁)

例に示したシリアル番号の、次の一桁であるJは製造週を表します。これは1月1日から始まる7日を最初の週としています。なので最後の週以外は全て7日間です。次の27種類の英数字が使われます。シリアル番号の例では、2015年の前半年とわかりましたので、Jは15週目を表しています。

| Char | 1st half | 2nd half |
| ---- | -------- | -------- |
| `1` | `1` | `27` |
| `2` | `2` | `28` |
| `3` | `3` | `29` |
| `4` | `4` | `30` |
| `5` | `5` | `31` |
| `6` | `6` | `32` |
| `7` | `7` | `33` |
| `8` | `8` | `34` |
| `9` | `9` | `35` |
| `C` | `10` | `36` |
| `D` | `11` | `37` |
| `F` | `12` | `38` |
| `G` | `13` | `39` |
| `H` | `14` | `40` |
| `J` | `15` | `41` |
| `K` | `16` | `42` |
| `L` | `17` | `43` |
| `M` | `18` | `44` |
| `N` | `19` | `45` |
| `P` | `20` | `46` |
| `Q` | `21` | `47` |
| `R` | `22` | `48` |
| `T` | `23` | `49` |
| `V` | `24` | `50` |
| `W` | `25` | `51` |
| `X` | `26` | `52` |
| `Y` | `-` | `53` |

11桁のシリアル番号では週は2桁で表記されて、週の数値がそのまま、00から53までの数値で表現されます。

製造ライン(3桁)

例に示したシリアル番号の、次の3桁であるTYNは製造ラインもしくは、組み立て担当者のIDを表していると考えられています。それぞれの桁は、IとOを除く0からZまでの英数字を0から33に割り当てた数値を表しています。この3桁は、製品個体ごとに違い、一台一台を特定する部分です。

| Char | Value | Char | Value |
| ---- | ----- | ---- | ----- |
| `0` | `0` | `H` | `17` |
| `1` | `1` | `J` | `18` |
| `2` | `2` | `K` | `19` |
| `3` | `3` | `L` | `20` |
| `4` | `4` | `M` | `21` |
| `5` | `5` | `N` | `22` |
| `6` | `6` | `P` | `23` |
| `7` | `7` | `Q` | `24` |
| `8` | `8` | `R` | `25` |
| `9` | `9` | `S` | `26` |
| `A` | `10` | `T` | `27` |
| `B` | `11` | `U` | `28` |
| `C` | `12` | `V` | `29` |
| `D` | `13` | `W` | `30` |
| `E` | `14` | `X` | `31` |
| `F` | `15` | `Y` | `32` |
| `G` | `16` | `Z` | `33` |

この3桁の値は次の式でIDに変換されているようです。

1桁目 x 68 + 2桁目 x 34 + 3桁目

この例のTYNは、それぞれ27, 32, 22を表し、上の式から2,946になります。

27 x 68 + 32 x 34 + 22 = 2,946

製造コピー

上の計算式はちょっと変わっています。34進数だと考えたら最初の桁は34×34倍すべきなのですが、68倍になっています。何か根拠のある計算式ではあると思われますが、この計算では、得られる数値に重複が発生します。

例えば、 0L0, 1J0, 2G0, 3E0, …, 920という複数の英数字が、どれも680という製造ライン番号になります。別の例では、KYL, LWL, MUL, …, Z4Lという英数字は、どれも2400という数字になります。同じ数値になってしまう英数字の組を、製造コピーと呼んでいます。最初の桁の値の小さい方から1, 2, 3,…と番号をつけます。この例では、0L0やKYLがコピー1、1J0やLWLがコピー2などです。920と74Lは、最後のコピーです。英数字の組み合わせによりコピーの総数は変わります。色々な実験で、最初のいくつかのコピーだけが、Appleから有効だと判定されるようです。無効だと判定されたコピー番号より大きな番号のコピーは全て無効になります。Apple内部のことはもちろんわかりませんが、一つのラインから製品が製造されるごとに、コピー値が増加するのではないかと推定されています。何れにしても、ある値を示す製造ライン番号のうち、最初のコピーを使用するのが安全であると言えます。

プラットホームモデル(3 or 4桁)

11桁シリアルでは最後の3桁、12桁シリアルでは最後の4桁が、製品種類を表す番号です。例に示したシリアル番号では、最後の4桁であるFY10がこのプラットホームモデルです。この4桁が製品機種を表していることは、以下のURLにアクセスすることで確認できます。

http://support-sp.apple.com/sp/index?page=cpuspec&cc=PPPP

ここのPPPPの部分にFY10を入れてアクセスすると

http://support-sp.apple.com/sp/index?page=cpuspec&cc=FY10

iMac15,1の仕様書ページにリダイレクトされます。iMac15,1にはLate 2014とMid 2015の2機種がありますが、このモデルはMid 2015年のiMacであることがわかります。

ちなみに一つの機種ID（例えばiMac15,1）が全て同じプラットホームモデル（ここではFY10）になるわけではありません。同じ機種IDでも製造時期が違うと仕様が異なります。それで複数のプラットフォームモデルが割り当てられています。例えば、iMac15,1に相当するプラットホームモデルは、以下の27種類が確認されています。

"FY10", "FY11", "FY14", "FY68", "FY6F", "GCTM", "GDQY", "GDR3", "GDR4", "GDR5", "GDR6", "GDR7", "GDR8", "GDR9", "GDRC", "GFFQ", "GJDM", "GJDN", "GJDP", "GJDQ", "FY13", "FY6D", "GL1Q", "GL1R", "GL1T", "GL1V", "GL1W"

シリアル番号の注意事項

シリアル番号は上記のフォーマットに従って、適切な値が入っている必要があります。そうしないと、iMessageへのアクセスなどでAppleから無効なモデルと判定される可能性があります。

また、細かい整合性もチェックしておいた方が良いと思われます。例えば、製造年、製造週は、プラットホームモデルが示す発売日より後の日付である方が良いでしょう。また、製造ラインのコピー数は、できるだけ小さい値、できればコピー1である方が安全です。

上の例で示したC02PJTYNFY10は、

Country: C02 - China (Quanta Computer)
Year: P - 2015 (前半)
Week: J - 15 (2015年4月9日-2015年4月15日)
Line: TYN - 2946 (copy 1)
Model: FY10 - iMac15,1 Retina 5K, 27 inch, Mid 2015, 2015年5月発売

となります。製造日が発売日より早いのが気になりますが、発売日に備えて前もって製造しているはずなので、それほど不自然ではないと思います。

また、下記のサイトで生成したシリアル番号が未使用であることは、確認しておくべきかと思います。「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。

ボードシリアル番号

SMBIOSでもう一つ設定しないといけない番号がボードシリアル番号です。12桁シリアル番号の場合、ボードシリアル番号は17桁です。ロジックボードのシリアル番号です。修理によってロジックボードは交換される可能性があることもあり、Appleはそれほど厳密にはチェックしていないと感じています。昔のガイドでは、12桁のシリアル番号に適当な英数字を5個足しておけば良いとか、LANのMACアドレスの一部を足しておけば良いなどというゆるい手法が説明されていることもあります。

Clover configuratorなどに搭載されている最近のシリアル番号発生機能では、シリアル番号と対になってボードシリアル番号も作り出してくれます。それを採用しておけば良いです。例えば、先の例で使用したシリアル番号C02PJTYNFY10と対で生成されたボードシリアル番号は

C02514701CDG2Y71H

でした。これを例に構成を調べていきます。

製造場所番号(3桁)

シリアル番号と同じで、最初の3桁は製造国、製造都市、メーカなどを表します。この例のC02は中国のQuantaコンピュータです。

製造年(1桁)

4桁目は年号です。西暦年号の1の位です。この例では、シリアル番号が2015年なので、それに合わせて5になっているようです。

製造週(2桁)

次の2桁は製造週です。上の例では、14週目の製造という意味です。シリアル番号は15週目でした。ロジックボードが製造されたあとで、本体が製造されるのが自然ですから、前の週に製造されたことにしているのだと思います。

MLBBlock1(3桁)

以下のいずれか一つの数値です。Clover configuratorやmacserialが自動生成する場合には、この中から乱数で選んでいるようです。

"200", "600", "403", "404", "405", "303", "108", "207", "609", "501", "306", "102", "701", "301", "501", "101", "300", "130", "100", "270", "310", "902", "104", "401", "902", "500", "700", "802"

MLBBlock2(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"GU", "4N", "J9", "QX", "OP", "CD", "GU"

ボードコード(3 or 4桁)

ロジックボードの種類を示す英数字です。一つのモデルに対して多数のコードが発見されているようです。例えば、上の例のiMac15,1では、以下のコードが使われているようです。このリストのうち、最初のコードG2Y7が、問題が少ないとされているので、これが使われることが多いようです。

"G2Y7", "G2Y8", "GG3L", "GG3N", "G2QD", "G2QF", "GG3T", "GG3W", "FT04", "FW6K", "GG3K", "GG3M", "FW29", "FW2C", "GG3Q", "GG3V", "FQY8", "FTPF"

MLBBlock3(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"1H", "1M", "AD", "1F", "A8", "UE", "JA", "JC", "8C", "CB", "FB"

ボードシリアル番号の注意事項

上記で、「自動生成する場合には乱数で選んでいる」と書きましたが、生成プログラムのソースを見ると、チェックサムも考慮しています。ボードシリアル番号が表す値を、最初から奇数番目の桁はそのまま、偶数番目の桁は3倍して足していき、その合計が34の倍数である場合は正しいチェックサムを持ったボードシリアル番号としているようです。正しいチェックサムになるまで、ランダムに候補を選んでいるようです。手作業では面倒なので、自動生成ツールを使うのが良いです。

機種のシリアル番号に比べて、ボードシリアル番号はAppleにより厳しく検査されることはないので割と適当でも大丈夫な印象があります。シリアル番号の製造週より前の製造週にしておいた方が良いでしょう。自動生成ツールでは、シリアル番号の前の週になるように生成しているようです。ただ、ロジックボード交換修理する可能性も考えると、それもチェックされていないと思います。何れにしても、以下の自動生成ツールを使えば、整合性のある番号を生成してくれますので問題ありません。

シリアル番号自動生成ツール

シリアル番号はClover configuratorでも生成できますし、この記事の冒頭で示したmacserialというツールでも生成できます。おそらくはClover configuratorもmacserialと同じアルゴリズムを使っているのではないかと思います。macserialは、冒頭のリンクからソースコードを入手してコンパイルしても良いです。また以下のサイトで、コンパイル済みのコードも配布されています。

Releases · acidanthera/macserial

更新：現在は以下で配布されているようです (2019/12/28)。

Releases · acidanthera/MacInfoPkg

更新2 : 現在はOpenCoreに含まれています (2020/8/14)。

GitHub - acidanthera/OpenCorePkg: OpenCore bootloader

現時点では2.0.4が最新のようです。mac版とwindows 32版があるようです。zipをダウンロードすると解凍されてmacserialというファイルができます。

$ ./macserial

として起動すると、現在のMac/Hackintoshのシリアル番号などの情報が表示されます。–helpとすれば使い方の説明が表示されます。

$ ./macserial --help
./macserial arguments:
 --help (-h) show this help
 --version (-v) show program version
 --deriv <serial> (-d) generate all derivative serials
 --generate (-g) generate serial for current model
 --generate-all (-a) generate serial for all models
 --info <serial> (-i) decode serial information
 --list (-l) list known mac models
 --mlb <serial> generate MLB based on serial
 --sys (-s) get system info

Tuning options:
 --model <model> (-m) mac model used for generation
 --num <num> (-n) number of generated pairs
 --year <year> (-y) year used for generation
 --week <week> (-w) week used for generation
 --country <loc> (-c) country location used for generation
 --copy <copy> (-o) production copy index
 --line <line> (-e) production line
 --platform <ppp> (-p) platform code used for generation

–generateオプションで現在モデルのシリアル番号とボードシリアル番号を複数生成してくれます。–generate-allで全てのモデルの番号を生成します。–model Macmini8,1などとすれば特定のモデルの番号を生成してくれます。–info シリアル番号でそのシリアル番号を分析してくれます。例えば、この記事で例に使ったC02PJTYNFY10でしたら、

$ ./macserial --info C02PJTYNFY10
 Country: C02 - China (Quanta Computer)
 Year: P - 2015
 Week: J - 15 (09.04.2015-15.04.2015)
 Line: TYN - 2946 (copy 1)
 Model: FY10 - iMac15,1
 Valid: Possibly

のように表示されます。

新型iMacに第9世代CPUがようやく搭載される

Wed, 20 Mar 2019 12:06:36 +0900

昨日(2019/3/19)、唐突に発表された新型27インチiMacに、第9世代CPUがようやく搭載されました。第8世代CPUを搭載したiMacもいくつか発表されました。搭載されているCPUの具体的な型番は公表されていませんが、第9世代CPUはCore i5-9600KとCore i9-9900Kのようです。

21.5インチモデル

21.5インチモデルでは新型2機種が発表されました。いずれもRetina 4Kディスプレイモデルです。ここでは仕様のページ

27インチiMac - 仕様

に準じて、CPUのクロック数でモデルを区別します。新発売されたのは以下の2機種です。

3.6GHzモデル

新発売の21.5インチの下位モデルです。最下位モデルがそのまま継続されているので、21.5インチモデルの中では中位モデルです。仕様によると「3.6GHzクアッドコア第8世代Intel Core i3プロセッサ」とあります。インテルのCPU仕様書サイト

インテル製品の仕様

で調べてみると、該当するCPUはCore i3-8100 もしくは Core i3-8100Bのようです。無印とBモデルの違いは、ピンがソケットか半田付けかの違いだけです。

3.0GHzモデル

新発売の21.5インチの最上位モデルです。仕様によると「3.0GHz 6コア第8世代Intel Core i5プロセッサ
Turbo Boost使用時最大4.1GHz」とあります。インテルのCPU仕様書サイトによると、Core i5-8500 もしくは Core i5-8500Bのようです。

オプション

新製品の2モデルともに、CPUをアップグレードできます。仕様によると「3.2GHz 6コアIntel Core i7（Turbo Boost使用時最大4.6GHz）に変更可能」だそうです。インテルのCPU仕様書サイトによると、Core i7-8700 もしくは Core i7-8700Bのようです。

27インチモデル

27インチモデルは全て刷新されました。3モデルあります。そのうち最上位モデルのみが第9世代CPUです。インテルの第9世代は生産の問題があり、下位モデルが発売されていません。アップルも苦肉の策で、最上位モデルのみ最新CPUを採用することになったようです。ここでもクロック数でモデルを区別します。

3.0GHzモデル

新発売の27インチの最下位モデルです。仕様によると「3.0GHz 6コア第8世代Intel Core i5プロセッサ
Turbo Boost使用時最大4.1GHz」とあります。インテルのCPU仕様書サイトによると、Core i5-8500 もしくは Core i5-8500Bのようです。21.5インチ最上位モデルと同じですね。

3.1GHzモデル

新発売の27インチの中位モデルです。仕様によると「3.1GHz 6コア第8世代Intel Core i5プロセッサ
Turbo Boost使用時最大4.3GHz」とあります。インテルのCPU仕様書サイトによると、Core i5-8600のようです。

3.7GHzモデル

新発売の27インチの最上位モデルです。仕様によると「3.7GHz 6コア第9世代Intel Core i5プロセッサ
（Turbo Boost使用時最大4.6GHz）」とあります。ようやく第9世代CPU搭載モデルの登場です。インテルのCPU仕様書サイトによると、Core i5-9600K ~~または Core i5-9600KFのようです。KFモデルはiGPUが搭載されていないモデルです。~~今までの流れからしてiGPU無しのCPUは使われないと思います。なのでCPUはCore i5-9600Kのようです。

オプション

27インチモデルの上位2モデルは、CPUをアップグレードできます。仕様によると「3.6GHz 8コアIntel Core i9（Turbo Boost使用時最大5.0GHz）に変更可能」だそうです。インテルのCPU仕様書サイトによると、Core i9-9900Kのようです。

現行iMacのCPU一覧

ということで予想したCPU番号をまとめておきます。継続して販売されている21.5インチ最下位モデルもまとめに入れておきました。

21.5インチiMac最下位モデル Core i5-7360U
21.5インチiMac中位モデル Core i3-8100 ~~or Core i3-8100B~~
21.5インチiMac最上位モデル Core i5-8500 ~~or Core i5-8500B~~
21.5インチiMacオプション Core i7-8700 ~~or Core i7-8700B~~
27インチiMac最下位モデル Core i5-8500 ~~or Core i5-8500B~~
27インチiMac中位モデル Core i5-8600
27インチiMac最上位モデル Core i5-9600K
27インチiMacオプションCore i9-9900K

第9世代CPUが搭載されたことで、9900Kや9600Kを使ったHackintoshがさらに安定すると思われます。新iMacに対応したmacOSは次のアップデートから入手可能ですので、次のmacOS Mojave 10.14.4が楽しみです。

標準モデルの27インチ最上位が6コア6スレッドの9600Kなのはちょっとバランスが悪い気がします。コア・スレッド数は下位モデルと同じです。ここは8コア8スレッドの9700Kを搭載して欲しいと思いました。

T2チップは搭載されず

今回はCPU交換のマイナーチェンジのようです。そのためかT2チップは搭載されていないようです。Hackintoshから見ると色々厄介になることが予想できるので、搭載されなくてよかったです。次の本格的なアップデートでは搭載されるのかもしれません。

その後の情報

2019年3月19日あたりから店頭でも販売されるようになりました。実機に触れるようになったので、色々情報がわかってきました。SMBIOSが構成できるだけの情報が早く用意されると嬉しいです。

搭載macOS

コメントでいただいた情報などによると搭載されているmacOSは10.14.4 (18E2034)だそうです。一般の10.14.4が18E226なのでだいぶ違うようです。ちなみに10.14.3 SUは18D109でした。

機種ID

コメントでいただいた情報や、他のネット上の情報などを見ると、機種IDは以下のようです。いままでは、27インチモデルの方が,2になっていたことが多いと思うので、逆ですね。

iMac19,2 21.5インチiMac Early 2019
iMac19,1 27インチiMac Early 2019

CPU

英語版のWikipediaに仕様が書かれていました。公式の情報ではないですが、ある程度信用できそうな気がします。それによると、CPUは、

iMac19,2 8100, 8500, 8700 (option)
iMac19,1 8500, 8600, 9600K, 9900K (option)

とのことで、上の予想であっているようです。第8世代は、Mac miniとは違い、Bモデルでは無いようです。

シリアル番号

アップルストアで「このMacについて」を撮影していた動画がありました。これです。それによると、以下のシリアル番号が確認できました。

iMac 27-inch 3.7 GHz Intel Core i5-9600K: C02Y90H3JV3Q
iMac 21.5-inch 3 GHz Intel Core i5-8500: C02Y93YXJWDX
iMac 21.5-inch 3.6 GHz Intel Core i3-8100: C02Y81DCJWDW

最後の4文字、JV3Q, JWDX, JWDWがモデルIDです。以下のURLでApple社の仕様のページに行くことができるので、モデルIDであることを確認できます。

C02Yは、中国製造で2019年上期の製造を表し、その次の9は2/26から3/4の週、8は2/19から2/25の週にそれぞれ製造されたことを表しています。残りの3文字は個体の番号です。

ボードID

Geekbenchにもベンチマーク結果が上がるようになってきました。iMac19,1で検索するといくつか見つかります。Build 18E2034となっているので、Hackintoshではなくて本物のようです。ここからボードIDがわかります。Apple Inc. Mac-AA95B1DDAB278B95 iMac19,1のようです。BIOSはApple Inc. 220.250.368.0.0のようです。SMBIOSのどれに当たるのかはちょっと不明です。ちなみに、iMac19,2の方はApple Inc. Mac-63001698E7A34814 iMac19,2とのことです。

ASUS MAXIMUS XI HEROにM.2 SSD (WD SN750)を取り付ける

Mon, 11 Mar 2019 18:08:02 +0900

Z390チップセットの9900Kマシンは順調に動いているのですが、起動ドライブは手元にあった2.5 inch SSDを流用してました。これを今風のM.2 SSDに交換しました。

9900K搭載Z390マザーボードでHackintoshを作る

ストレージ構成をどうするか

ATX基板を使っていますし、ケースはそれなりの大きなケースを考えているので、SATAケーブルで接続するドライブはいくつか使用するつもりです。大容量の3.5 inch HDDを2台くらいは使って、片方をデータの倉庫に、もう一方をTimeMahineのバックアップに使おうと考えています。Windowsは滅多に使わないのですが、気が変わってWindows用に2.5 inch SSDを一個くらい付けるかもしれません。

M.2 SSDは高速・小型なので、将来はM.2が主流になって、SATAケーブルで接続するドライブはマイナーな存在になると思います。ただ現状では、M.2 SSDは、割高ですし、体感速度で考えると2.5 inch SSDとそれほど違わないし、他のマシンやMacにつなぎ変えて動作を確認するなどの場面では取り外し・取り付けが面倒です。ということで、メインで作業するデータ領域（/Users）は、2.5 inch SSDにして、システム領域（/、/System、/Applications、/Libraryなど）だけをM.2 SSDにするのが良いと考えました。ということで、ゆくゆくは

250GB程度のシステム用（root用）M.2 SSD
1TB程度のデータ用（/Users）2.5 inch SSD
4TB程度のTimeMachine用3.5 inch HDD
4TB程度のデータ倉庫用3.5 inch HDD

の構成を考えています。

M.2 SSDを選定

そこで第一歩として、中小容量のシステム用M.2 SSDを物色しました。OSとアプリケーションを入れるだけなら120GB程度でも十分な容量なのですが、SSDの構造上、容量が小さいと書き込み時間が遅くなります。120GBは製品もあまり多くないので、選択肢の多い250GBを選ぶことにしました。Hackintoshでは、SamsungのSSDがよく使われているようです。tonymacx86などでも実績があります。今回はいろいろ探して評判の良かったWestern DigitalのWD BLACK SN750を使うことにしました。カタログスペックでは、シーケンシャルRead:3,100MB/s、シーケンシャルWrite:1,600MB/sで高速です。以前使っていたSSDはコントローラがかなり高温になったものですが、この製品はそれほど発熱しないような気がします。

最近のSSDの低価格化に寄与している技術が、記憶セルあたりの情報量を増やす手法です。通常のメモリは、セルに電荷を貯める・貯めないの2状態で1ビットを記録します。貯める電荷量を、3段階にすれば、電荷が無い状態を含めて4状態になり、2ビット記録できます。記憶セルあたり1ビット記録する方式をSLC (シングルレベルセル)、2ビットをMLC (マルチ〜)と呼ぶようです。さらに8状態にして3ビット記録するTLC (トリプル〜)や、16状態にして4ビット記録するQLC (クアドラプル〜)があるようです。セルあたりの記憶量を増やすことで、低価格なSSDが作れます。その一方で、速度や耐久性が弱くなると指摘されています。WD BLACK SN750はTLCのSSDのようです。（最初の記事ではSLCだと勘違いしていました。訂正します。）若干不安はありますが、ちゃんとした製品なので当然のことですが、何の問題もなく動いています。

マザーボードに取り付ける

ASUS MAXIMUS XI HEROにはSSD用に2個のM.2ソケットが用意されています。

マザーボードの中央、CPUの近くにあるM.2_1と、マザーボードの端にあるM.2_2です。それぞれ多少機能が違います。

M.2_1はKey M, Type 2242/2260/2280のSSD用で、インタフェースはPCI Express 3.0 x4およびSATAに対応します。ただしSATA SSD取り付けた場合、SATA 6Gb/s 第 2ポート(SATA6G_2)は無効になります。
M.2_2はKey M, Type 2242/2260/2280/22110のSSD用で、インタフェースはPCI Express 3.0 x4のみに対応します。

WD BLACK SN750は、2280のSSDでPCI Express 3.0 x4接続なので、どちらのソケットにも取り付けることができます。どちらでも良かったのですが、M.2_2の方を使うことにしました。というのは、M.2_1は、CPUに近くて、大きなCPUクーラを使用すると、取り付け・取り外し作業が困難です。また、M.2_2の方がより大型の22110対応なのでヒートシンクが大きく、多少は放熱性能が良いと考えたからです。

Hackintoshのインストール

すでに2.5 inch SSDでHackintoshが動いているので、この先の作業は簡単です。成功することが見えているようなものです。

M.2 SSDをソケットに取り付ける
現在の2.5 inch SSDで起動してM.2 SSDをAPFSでフォーマットする
App StoreからmacOS Mojaveインストール.appを入手する
macOS Mojaveインストール.appを起動してM.2 SSDにmacOSをインストールする
（インストール中に2度ほど再起動しました。Cloverのドライブ選択画面でBoot macOS install from xxxx (M.2 SSDにつけた名前）が表示される間は、そのドライブを選びます。）
Cloverインストーラを起動してブートローダ類をM.2 SSDにインストールする
config.plist, efi, kext類を2.5 inch SSDからM.2 SSDのESPにコピーする

今回は、何の問題もなくインストールできました。しかしMojaveになってからmacOSのインストールに失敗する場面が増えたように思います。どうしてもmacOSがインストールできない場合は、最後の手段として、M.2 SSDを本物のMacにUSB接続してインストールするのも良いと思います。その場合、M.2 SSDを2.5 inch SATAドライブのように変換してくれるアダプタがあると便利です。

macOSのインストールが終わったら、2.5 inch SSDのCloverからM.2のmacOSを起動します。macOSとしての設定を色々終了したら、CloverをM.2にインストールします。また、2.5 inch SSDのESPから、config.plistやkext類を、M.2のESPにコピーします。以上で、M.2 SSDに問題なく移行できました。

macOSをアップデートしたらNUCが起動しない

Sun, 03 Mar 2019 12:04:50 +0900

Intel NUCのmacOSをアップデートしようとしたら起動しなくなりました。原因は、CMOSメモリーバックアップ関係のようです。電池交換しても改善しませんでしたので、電池なしで使うことにしました。Hackintosh自体の問題ではないのですが、ありがちなトラブルの一つなのかと思います。

OSアップデートで不調に

IntelのNUCは、小型省電力のHackintoshを作るのに適しているので

NUCで作る超小型macOSマシン

Haswell搭載のD54250WYKHでmacOSをサーバにしています。これをmacOS 10.14.2で動かしていたものを、10.14.3にアップグレードしようとしたことがトラブルの発端でした。Mojaveになってから一部のHackintoshで、macOSインストーラが止まってしまうトラブルがあります。

Mojaveの「インストーラリソースが見つかりません」問題

このNUCもその一つで、High SierraからMojaveへのアップデート、10.14 –> 10.14.1, 10.14.1–>10.14.2のアップデートでこの問題が発生しました。mSATA経由のSSD（システムとユーザデータ用）とSATA経由の2.5インチHDD（データ保存用）を搭載しているのですが、HDDを一時的に外すことで問題なくアップデートできました。今回試みた10.14.2–>10.14.3へのアップデートでも同様に、「インストーラリソースが見つかりません。」のメッセージが出ました。そこでHDDを取り外すことにしました。

HDD取り外しのために、電源を外して、裏蓋を開けて、HDDを取り外します。その後、起動しようとしたのですが、画面に何も表示されなくなりました。電源LEDも点灯しません。何度か試しているうちに、CPUファンが高回転で回り始めました。でも画面には相変わらず何も表示されません。

EFIのCMOSが原因？

UEFIの設定画面を含めて画面への表示が一切出ません。NUCのファームウェア関係の問題のようです。念のために、HDD、SSD、無線LANカードなど、メモリー以外の後付け部品を取り外しました。が、症状は変わりません。

検索したらこんな情報がありました。

この人は、Ubuntuを入れていたようです。CMOSメモリのバックアップ用ボタン電池を外して戻したら復活したとあります。この方法を試してみることにしました。ボタン電池は、基板の裏側にあるので、相当分解しないと到達しません。基板はギリギリでハマっているので、外すには手間がかかります。ようやくボタン電池に行き着いて、取り外したところ無事起動しました。CMOSデータのチェックサムがおかしいとか、時刻が未設定とのメッセージが出ます。電池外したので当然かと思います。UEFI設定画面も出たので、念のために工場出荷時状態にリセットして、Hackintosh用の設定（iGPUへの割り当てメモリを増やす、Vt-Dをdisableにする、起動ドライブを設定する）を行いました。

これで無事、10.14.3にアップデートできました。ただ、ボタン電池をつけた状態で、電源を外すと再び起動不可能になるようです。ボタン電池を外したままなら、時刻が初期化されますが、正常に起動します。そのほかのUEFIの設定は、短時間電源を外したくらいでは消えないようでした。ボタン電池が消耗していて中途半端にバックアップされているようにも思えます。ただ、ボタン電池の電圧をテスターで測ると3.25ボルトあるので、無負荷ならば電圧に問題はないようです。

そこで同等のボタン電池を取り寄せて、取り付けてみました。新品の電池は3.40V程度でしたので、改善するかと思いましたが、残念ながら結果は同じです。CMOSメモリ本体の問題なのかもしれません。ということで電池を外したまま運用することにしました。ACアダプタを抜かなければ、起動に問題はありません。ACアダプタを抜いても、CMOSの内容が一部クリアされることと、時刻がリセットされること、チェックサムエラーの警告が出るだけです。起動ドライブが変わってしまうので設定し直す必要がありますが、それ以外の手間はありません。時刻も、macOSが起動すればNTPサーバから時刻を取り寄せて設定してくれます。

古いmacOSをコレクションする

Mon, 11 Feb 2019 12:54:54 +0900

過去の特定のバージョンのmacOSが必要になることが稀にあります。でも古いバージョンのmacOSは入手困難です。アップルから正規に入手できる時期に忘れずにダウンロードして確保しておきましょう。
（更新：CatalinaとBig Surの情報を追記しました。2021/10/29）

古いmacOSが必要になる時

OSの更新で使えなくなったハードウェアでマシンを組もうと思う時、古いOSが必要です。例えば10.14 MojaveからIntel HD Graphics 3000のドライバが削除されてしまったので、Sandy Bridgeの内蔵GPUは動かなくなってしまいました。そこで10.12 SierraからIntel HD Graphics 3000のドライバを持ってくると動きました。10.13 High Sierraのドライバでは動きませんでした。2世代前のmacOSをたまたま持っている人だけが対応できる方法です。

また、最初のiMac Proには10.13.2が搭載されていましたが、この時に10 GbpsのEthernetがmacOSで動くようになりました。搭載されているのは、一般的に使われているAquantia AQC107というチップです。ただし拡張カードのファームウェアが違うのでそのままでは動きません。10.13.3になった時に、なぜかmacOS対応のファームウェアが含まれていて、10 Gbpsカードを挿したままアップデートするとファームウェアが書き換えられてmacOSで動くと報告されています。10.13.2以下のHigh Sierraをたまたま持っている人だけが対応できる方法です。

以上はかなりニッチな事例です。しかしMojaveでNVIDIAのドライバが動かなくなったので、いまだにHigh Sierraなどの古いmacOSが必要になる場面は多いかと思います。

古いmacOSの入手方法

App Storeアプリから入手する

App Storeから一旦購入したアプリケーションは、いつでも入手可能なところがApp Storeの優れた点です。この原則はmacOSでも有効で、一旦ダウンロードした古いmacOSは「購入済み」ボタンを押すとApp Storeの画面に現れました。

でもMojaveになって、これが出来なくなりました。Mojaveからは、左下の名前をクリックすると現れる「アカウント」のページに、購入済みのアプリケーションが現れるようになりました。ただmacOSは現れません。私の場合は、なぜか古いmacOSのPublic BetaやGM Candidateが表示されます。昔購入したServer版も現れます。でもmacOSは現れません。現行のMojaveだけは、検索窓からMojaveを検索すると現れます。

ということでまだMojaveに移行していないみなさんは、High Sierra以前で稼働しているうちに、昔に購入したmacOSをダウンロードしておきましょう。

プロダクトIDを手掛かりに入手する

App Storeで配布されているソフトウェアは、プロダクトIDという一意の番号で管理されています。これを知っていればMojaveで選択肢に現れない古いmacOSをダウンロードできる可能性があります。

こちらのサイト

OS X 10.7 Lion ~ macOS 10.13 High Sierraまでのインストーラーアプリをダウンロ…

ではいくつかのmacOSのプロダクトIDを紹介してくれています。それによると、

OS X 10.7 Lion 444303913
OS X 10.8 Mountain Lion 537386512
OS X 10.9 Mavericks 675248567
OS X 10.10 Yosemite 915041082
OS X 10.11 El Capitan 1018109117または 1147835434
macOS 10.12 Sierra 1127487414
macOS 10.13 High Sierra 1246284741
macOS 10.14 Mojave 1398502828
macOS 10.15 Catalina 1466841314
macOS 11 Big Sur 1526878132

だそうです。この番号を使って、

https://itunes.apple.com/jp/app/idプロダクトID?mt=12

にアクセスすると古いmacOSのApp Storeアプリ画面が開きます。ただ、現時点で試したところではYosemite以前はこんなダイアログが出て利用できないようです。

この方法でダウンロードできるのは以下のバージョンでした。

El Capitan https://itunes.apple.com/jp/app/id1147835434?mt=12
Sierra https://itunes.apple.com/jp/app/id1127487414?mt=12
High Sierra https://itunes.apple.com/jp/app/id1246284741?mt=12
Mojave https://itunes.apple.com/jp/app/id1398502828?mt=12
Catalina https://itunes.apple.com/jp/app/id1466841314?mt=12
Big Sur https://apps.apple.com/jp/app/macos-big-sur/id1526878132?mt=12

masコマンドを使う

上記のサイトではHomebrewで導入できるmasコマンドを紹介してくれています。コマンドラインからMacのApp Storeにアクセスするためのアプリケーションです。ターミナルで以下のようにすれば、Homebrewをインストールして、次にmasをインストールできます。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install mas

単にmasとだけタイプすると

mas
Available commands:

account Prints the primary account Apple ID
help Display general or command-specific help
home Opens MAS Preview app page in a browser
info Display app information from the Mac App Store
install Install from the Mac App Store
list Lists apps from the Mac App Store which are currently installed
lucky Install the first result from the Mac App Store
open Opens app page in AppStore.app
outdated Lists pending updates from the Mac App Store
reset Resets the Mac App Store
search Search for apps from the Mac App Store
signin Sign in to the Mac App Store
signout Sign out of the Mac App Store
uninstall Uninstall app installed from the Mac App Store
upgrade Upgrade outdated apps from the Mac App Store
vendor Opens vendor's app page in a browser
version Print version number

とヘルプが出ます。

mas intall プロダクトID

とすればダウンロードできるようです。info, searchなどはあまり効きません。それに出てこなくてもinstallコマンドは動くことがあるようです。

mas install 444303913

でプロダクトIDが分かっているうちの一番古いLionをダウンロードしてみました。

App Storeアプリからダウンロードする方法も、masコマンドも、どちらも購入したことのあるmacOSしか再入手できません。一旦はダウンロードしておく必要があります。

マイナーバージョンを入手する

今までの方法で、運が良ければ古いmacOSを入手できます。でも入手できるのは、それぞれのメジャーバージョン（MojaveとかHigh Sierraなどのバージョン）の最終版です。例えばHigh Sierraなら10.13.6が入手できます。では10.13.3が必要な場合はどうしたら入手できるでしょうか？

アップル社は統合アップデート(combo update)を長期にわたって配布してくれています。統合アップデートなら同じメジャーバージョンのすべての古いバージョンからアップデートできます。統合アップデートは、サポートページで検索したり、

[Apple - Support - Downloads](https://support.apple.com/downloads/combo update)

Googleの検索で「macOS 10.13.3 combo update」などと検索すると出てきます。私が探せた一番古いcombo updateは10.2.4でした。

OSメーカとしては、少しでも新しいバージョンにアップデートして欲しいので、全てのマイナーバージョンへのアップデートを配布し続けてくれているのだと思います。なのでできるだけ最初のマイナーバージョンを持っていれば、多くのマイナーバージョンへアップデートできます。例えば、10.13.0を持っていれば、10.13.1から10.13.6のすべてにアップデートできます。10.13.0は1ヶ月少しだけ配布されていました。今では入手できない貴重なバージョンですので、大事に保存しておきましょう。

LionとMountain Lionが無償配布

（追記：2021/7/18）Appleの公式サポートページから、LionとMountain Lionが無料でダウンロードできるようになったようです。以下です。

Mac OS X Lion Installer

Mac OS X Mountain Lion Installer

まとめ

古いmacOSを入手可能にしておくためには以下のことが重要です。

どのメジャーバージョンのmacOSも一度はダウンロードしておくと良いです。例えば、Mojaveは嫌いだからといって次のバージョンが出るまでダウンロードせず放置していると、正規に入手するチャンスを逃してしまいます。
古いmacOSがApp Storeで入手できることをあてにしてはいけないです。いつダウンロードできなくなるかわかりません。手元にコピーを置いておくべきです。
できるだけ最初のマイナーバージョンを持っておくと良いです。全部のマイナーバージョンのコピーを集めておくのは面倒ですし、ストレージの場所も必要です。10.xx.0を持っていれば統合アップデートでどのバージョンにもアップデートできます。実用上は一番安定と思われる最終バージョンも持っていると良いと思います。High Sierraなら10.13.0と10.13.6を持っていれば完璧なコレクションになります。

kextはどこに置けば良いのか

Sat, 02 Feb 2019 22:17:14 +0900

今までkextファイルはEFI/Clover/kexts/Otherに置くと良いと紹介してきました。でも以下の投稿によるとそれは「全く正しくない」のだそうです。

今回はHackintoshに必要なカーネル拡張ファイル（kextファイル）を置く場所に関する議論を紹介します。（コメントで紹介いただいた情報です。ありがとうございます。）

kextを/L/Eに置く利点と方法

上記の投稿にはkextを/L/Eに置くべきである理由と、推奨するkextの置き方が書かれています。抄訳します：

macOSの流儀である

FakeSMCなどを含むすべての3rdパーティkextは/Library/Extensions (以下/L/E) に置くべきです。多くの人が「これらのkextをEFI/Clover/kexts/Other (以下ESP) に置き、config.plistでInject KextsをYESにすることが、メンテナンスフリーであり、よりネイティブなmacOSインストール方法だ」という印象を持っているように思えます。しかしこの考えは完全に間違っています。

この俗説とは逆に、Cloverに3rdパーティkextをインジェクトしてもらうことは、クリーンなインストールにはならないどころか、その逆です。インジェクトされたkextはmacOSの保護メモリー空間の外側で機能します。大量のkextをインジェクトすると、システムが不安定になる可能性があります。Cloverによってインジェクトされる多くの3rdパーティkextは正しく動きません。インジェクトされたkextはカーネルキャッシュに含まれず、その結果macOSが行うエラー検査の対象外になります。kextを/L/Eに置くことは、アップルが推奨しています。何らかの周辺機器を買ってドライバをインストールする時、kextは/L/Eにインストールされます。Hackintoshのkextも同じです。

Cloverのkext読み込み機能の目的

/L/Eに追加のkextを置くのが正しいやり方なのだとしたら、なぜCloverはESPに置いたkextをインジェクトする機能を持っているのでしょうか？それは、次のような形式のmacOS、つまり

MacOS Installer
MacOS Updater
MacOS Recovery

をブートする場合に、最小限必要なkextを読み込むために必要だからです。これらはどれもフルサイズのmacOSではないため、通常の方法では必須kextを読み込めないので、Cloverがそれを行う必要があるのです。ほとんどの場合、これらのパッケージを機能させるためには、通常はEFI/Clover/kexts/Other に FakeSMC があれば良いです。場合によっては3rdパーティのストレージ制御用ドライバ、NASで動かすTimeMachineバックアップへのアクセス用ドライバ、ノートPCのマウス用ドライバなどが必要なこともあります。このような、本当に必要なkextだけをEFI/Clover/kexts/Otherに入れます。

CloverのDetect設定

Hackintoshに必要なkext類を、

通常のmacOSブート時は、/L/Eにkextを置いてmacOSでロードしつつ、
Installer/Updater/Recoveryの時だけESPに置いてCloverでインジェクトする

ように設定するには以下のようにします。

Cloverのconfig.plistのSystem Parameters セクションでは、Inject Kextsの設定ができます。ここでは、Cloverがkextをインジェクトしてくれるよう、通常はYESを設定します。

<key>InjectKexts</key>
<string>YES</string>

これをDetectに設定すると、

<key>InjectKexts</key>
<string>Detect</string>

Cloverは/L/Eにあるkextを調べて、

FakeSMCが/L/EにあればCloverはkextをインジェクトしない
FakeSMCが/L/Eに無ければCloverはkextをインジェクトする

という動作をします。なので、macOSの/L/Eと、CloverのEFI/Clover/kexts/Otherの両方にkext類を入れておけば、フルサイズのmacOSを起動するときは/L/Eのkextを、Installer/Updater/Recoveryの時はCloverがインジェクトするkextを使えることになります。

抄訳はここまでです。

/L/Eにkextを入れる方法

今まではバニラな方法しか説明していませんでした。/L/Eにkextを入れるとするといくつかの手順が必要です。

まずはHackintosh用のkext類は、当然ながらアップル社の承認を受けていませんので、「署名されていないkextも動く」設定にSIP (System Integrity Protection)を設定する必要があります。これにはconfig.plistで

<key>CsrActiveConfig</key>
<string>0x01</string>

と設定します。また、/L/Eに必要なkextをコピーした後で、パーミッションを設定して、キャッシュを作り直す必要があります。ターミナルから行うには、

sudo cp -R *.kext /Library/Extensions/.
sudo chown -R 0:0 /Library/Extensions/*.kext
sudo kextcache -i /

などとします。*.kextの部分は、追加するkextだけ指定すれば良いです。これで再起動するとキャッシュが再構成されます。

kextをESPに置く利点と欠点

以上で、/L/Eにkextを置く方法が良いという意見とその実際を紹介しました。kextをESPに置くバニラな方法と比較して、長所短所を検討してみます。

macOSの流儀からは外れる

macOSの設計では追加のkextは/L/Eに置くべきのようです。Cloverがインジェクトする方法では、メモリー不足になる可能性があるようです。ただ、そのような報告はあまり聞いたことがないので、実際には支障はないのかもしれません。

また、/L/Eに置くと、キャッシュに入れる際にkextのエラーチェックをしてくれるそうです。ただこれも、kext開発者でなければあまり恩恵の無い機能のように思います。ちなみに、/L/Eに置くと、そのkextがシステム情報–>ソフトウェア–>拡張機能に現れます。これを使って得られる情報がトラブル対応の参考になるかもしれません。

ESPでは動かないkextもある

一部の kextはESPでは正しく動きません。これらは/L/Eに置かざるを得ません。ただ、そのようなkextは少数で、大体はESPで動きます。

SIPを有効にできる

もともとHackintoshのkextは、macOSの規格外の拡張です。なので署名が無く、/L/Eで有効にするにはSIPで署名の無いkextを許可する設定が必要です。せっかくのSIPの仕組みなので、マルウェア対策としてSIPは有効のまま使いたい気がします。もちろんESPにkextを置くことも同様に危険なことですが、Hackintoshを狙ったマルウェアは少なそうですし、署名のあるkextと、署名の無いkextを、/L/EとESPに分けて管理するのは、セキュリティ対策として有効です。/L/EにHackintoshのkextを入れると、混在してしまいます。

ESPに置くと管理が楽

/L/Eに置くと、パーミッションを設定し、キャッシュを作り直す手間がかかります。ESPへ置くのはコピーするだけなので簡単です。また、上記で説明したInject KextsをDetectにする手法では、/L/EとESPの両方にkextを置かないといけません。この方式ではkextの入れ替えや、アップデートの手間が倍以上になります。/L/Eにkextを簡単に置くためのツールもありますが、手間が増えることには変わりありません。

以上のことを考えると、このままバニラな方法（ESPに置く方法）を続けても良いように思いました。

Cloverのテーマ

Sun, 27 Jan 2019 17:00:26 +0900

Cloverが起動した直後に、起動ドライブや起動オプションの選択をする画面があります。この画面はカスタマイズ可能で、色々な人が凝った画面を作ってくれています。これらの「テーマ」は以下のサイトなどで配布されています。

Clover EFI bootloader / Themes / [649fa8] /themes

設定方法

ここから気に入ったテーマのフォルダをダウンロードして、EFI/CLOVER/themes/フォルダの中に入れます。次に、（例えばフォルダの名前がMinimalismの場合）config.plistで

	<key>GUI</key>
	<dict>
		<key>Theme</key>
		<string>Minimalism</string>
	</dict>

のように設定します。config.plistや起動ドライブを変えて色々実験する時に、それぞれ違ったテーマを設定しておけば、切り替えられたことを確認できて便利です。

LattePanda AlphaのUSB

Sun, 06 Jan 2019 14:12:18 +0900

シングルボードコンピュータLattePanda AlphaにmacOSをインストールした記事を書きました。その続編です。今回は、USB環境を整えました。

LattePanda AlphaでmacOSを起動する

USBポートの名前を調べる

LattePanda Alphaには3個のUSB 3 Type-Aコネクタと、1個のUSB 3 Type-Cコネクタがついています。USB 3 Type-Cコネクタは電源供給に使っていますが、こういうタイプの変換器を使ってみたらUSB 3として機能していることが確認できました。

BIOS設定画面では、USB 3が4個あることになっていました。それぞれをenable/disableできます。

どうやらType-CのコネクタにはUSB 3が一本あって（Type-Cの本来の規格ではUSB 3は2本可能です）、それがPort1という名前になっているようです。ということは明らかにPort2, 3, 4が3個のType-Aのどれかに相当するはずです。BIOSで一つずつdisableにして、どのコネクタが使えなくなるのか確認しました。その結果、

上のような名前が割り当てられていることがわかりました。以下、この名前でコネクタを区別していきます。

macOSのUSB個数制限

こちらで説明したようにEl Capitan以来のmacOSには、使えるUSBが最大15ポートであるという謎の制限があります。その制限に該当してしまうと、USBコネクタが使えなくなります。回避の方法はいくつかありますが、一番簡単で、副作用がなくて、macOSのアップデートに影響されない方法は、

USBInjectAll.kextを使用して
config.plistのBoot Argumentsで除外するポートを記述する

という方法です。これを行うためには、LattePanda Alphaのどのポート番号が使いたいUSBコネクタに対応しているのかを特定する必要があります。

Lattepanda AlphaのUSB構成

無対策で起動

まずは、USB個数制限に対してなんの対策もせずにmacOSを起動してみました。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。IORegistryExplorer.appはAppleの開発サイトからダウンロードできます。

ここからAppleIDでログインして、Additional Toolsで検索して出てくるツールをダウンロードします。検索結果は複数出てきますが、最新のものをダウンロードすれば良いです。その中にIORegistryExplorer.appがあります。

IORegistryExplorerが起動したら、xhcで検索します。するとUSBポート一覧が出てきます。15個制限がかかっているので15個しか現れません。HSはHigh Speedの略でUSB 2のポートで、SSはSuper Speedの略でUSB 3のポートです。USRは何か不明ですが、SSよりも優先的に機能するポートのようですので、何か重要なものなのかもしれません。とりあえずここでは無視しました。

それぞれのポートをクリックすると右のエリアに詳細が出ます。ここで、port-statusが0の値になっているポートは未使用のポートで、0以外は現在使用中のポートです。

LattePanda AlphaについているPort1, 2, 3, 4にそれぞれUSB 2.0のデバイス（ここではLogitechの無線キーボード・マウス用USBドングルを使いました）を挿して変化を見ていきます。その結果、

HS03 USB3 Port2のUSB 2.0
HS05 USB3 Port3のUSB 2.0
HS07 USB3 Port4のUSB 2.0

であることがわかりました。Type-C（つまりPort1）には規格上はUSB 3.0が2本あり、それぞれにUSB 2.0が付属しているはずですが、反応しませんでした。テストにはApple社のMacBook用の純正Type-C –> display, USB, Type-C 変換器を使いました。この変換器の中でUSB 2.0が配線されていないのかもしれませんし、元々LattePandaで配線されていないのかもしれません。またこの変換機にはUSB Type-Aが1個しか付いていないので、もう一つのUSBも存在する可能性はあります。今回はType-Cは電源供給にしか使用するつもりがなかったので、これ以上は調べませんでした。

無反応のHSポートを除外する

LattePanda AlphaのUSBポートにLogitech無線ドングルを挿しても反応しなかったポートは

HS04
HS05
HS08
HS10

でした。不要な様子ですのでこれらを除外します。こちらの方法を使います。つまりUSBInjectAll.kextを使った上で、config.plistのBootセクションに以下を書きます。

<key>Boot</key>
<dict>
<key>Arguments</key>
<string>uia_exclude=HS04;HS05;HS08;HS10</string>

他に必要なArgumentsがあればスペースで区切って列挙しておけば良いです。また、Cloverの起動画面でOptionを選べば一時的にArgumentsを書き換えられます。一時的な試験の場合は、起動画面で書き換えるのが便利です。この結果、

このようになりました。優先的に選択されるHSのポートが減ったので、SSが増えました。結果としてSS04, SS05, SS06が増え、総数は全部で14になりました。15以下ですので、これ以上SSは無いと思われます。この状態では、4個のポートを除外しましたが、3個でも良いようです。

LattePanda AlphaのUSB構成

HS01, 02, 09は、USBコネクタの接続状態に関わらず常に使用中になっています。内部で使用されているようです。uia_excludeオプションで一つずつ除外して、何が動かなくなるかを確認しました。またSSポートもUSB 3のUSBメモリを挿して、動作を確認しました。その結果、SS01, 02, 03, 04がLattePanda AlphaのUSB 3コネクタに接続していて、SS05, 06は使われている様子はありませんでした。ということで、LattePanda AlphaのUSB構成が以下のようであることがわかりました。

HS01 システムが使用中（搭載無線チップのBluetooth）
HS02 システムが使用中（不明のUSBシリアル。M.2 E-keyソケット用？）
HS03 USB3 Port2のUSB 2.0
HS04 未使用?
HS05 USB3 Port3のUSB 2.0
HS06 未使用?
HS07 USB3 Port4のUSB 2.0
HS08 未使用?
HS09 システムが使用中（Arduinoに接続）
HS10 未使用?
SS01 USB3 Port1 (Type-C)
SS02 USB3 Port3
SS03 USB3 Port4
SS04 USB3 Port2
SS05 未使用?
SS06 未使用?

HS02については確認しませんでしたが、M.2 E-keyにはUSB 2.0が出ていて、Bluetoothチップなどで使用します。なのでおそらくこれはM.2ソケットに接続されていると思います。

除外するUSBポート

何も除外しないと、最初に示したように、優先度の高い10個のHSと謎の2個のUSRから使用されて、SSは3個しか機能しません。すると、SS04が機能しないのでPort2のUSB 3が使えません。HSを1個以上除外すれば、SS04まで使用できることになります。そこで、

uia_exclude=HS10;SS05;SS06

をArgumentsに指定して、必要なUSBポートが全て動くようにしました。除外リストにSS05, SS06を含めなくても、15個制限に引っかかって除外されるので同じですが、覚書の意味から記載しました。今後、USBがらみで動作不良になるようでしたら、除外リストを再検討することにします。

LattePanda AlphaのBluetooth/WiFi

Sun, 06 Jan 2019 12:14:13 +0900

シングルボードコンピュータLattePanda AlphaにmacOSをインストールした記事を書きました。その続編です。今回は、Bluetooth/WiFi環境を整えました。

LattePanda AlphaでmacOSを起動する

LattePanda搭載無線モジュール

LattePandaには、Intelの無線モジュールが半田付けされています。Model 3165D2Wと書いてあります。これは802.11 ac（2.4 G & 5 G）のWi-Fiに加えて、Bluetooth 4.2をサポートしています。インテルのモジュールなのでmacOSからは全く使用できません。なので、BIOSメニューでDisabledに設定します。

無線モジュールを追加する

WiFi/Bluetooth無しで使う用途もあると思います。Arduinoを搭載している特徴を生かして、組み込み用のシステムを作るなら有線LANだけで使うことも多いと思います。また画面共有などのネットワーク越しで開発がメインなら、マウスやキーボードの利用頻度は少ないのでBluetooth無しでも良いかもしれません。

IO DATAのUSB-BT40LE

とはいえ、せっかくmacOSが動くのですから、macOSを生かせるトラックパッドを接続したいです。それにはBluetoothだけは欲しいところです。簡単に安価にBluetoothを追加するなら、USBアダプタのIO DATAのUSB-BT40LEが良いです。iOSとのcontinuityは難しいですが、通常のキーボード、トラックパッド、サウンドデバイス接続なら問題なく使用できます。

ただ、少ないUSBソケットを一つ占有してしまうのはちょっともったいないかもしれません。LattePanda Alphaには、せっかくM.2 E-keyソケットが付いていて空いているので、これを生かしたいと思います。以下では、ここに追加する無線ユニットを考えてみます。無線モジュールの詳細は、こちらの記事をみてください。

DW1830

M.2ソケットのモジュールでmacOSと互換性の高い製品に、DW1830があります。$50程度とちょっとお高いのですが、互換性は高いです。WiFiはOOBで動き、Bluetoothもkextを追加すれば動くようです。iOSとの連携も期待できます。

純正カードアダプタを使う

多少分厚くなっても構わないなら、純正品で使われているBCM943602CSと、それをM.2に変換するカードを使用しても良いかもしれません。こちらの方が互換性が完璧な上に、合計金額も安いです。ただ、ネジ穴が合いませんので、両面テープと結束バンドなどで固定する必要があると思います。

DW1560

iOSとの連携を諦めれば、DW1560も良いと思います。DW1560のWiFiは安定して動きます。またBluetoothにはIO DATAのUSB-BT40LEと同じく、昔のMacで使われたBCM20703が採用されています。iOSとの連携が無かった時代のチップですのでその機能はありません。頑張ってパッチを当てれば連携機能が動かなくはないようですが、困難な作業です。しかし、通常のキーボード、トラックパッド、サウンドデバイス接続なら問題なく使用できます。今回は、iOS連携は不要と考えたので、これを使ってみました。RehabMan-FakePCIIDと、 RehabMan-BcrmPatchRAMから以下のkextを入手すれば動きました。

FakePCIID.kext
FakePCIID_Broadcom_WiFi.kext
BrcmFirmwareData.kext
BrcmPatchRAM2.kext

DW1560はDW1830と比べると半額くらいです。また技適マークも入っていましたので安心して使えると思います。ただ、LattePandaには2280サイズ用の取り付け穴しかありませんので、ネジで固定できませんでした。ネジの代わりに、100円ショップで売っている強力両面テープで貼ってみましたが、かなり発熱するためか、しばらくすると浮いてきます。プラスチック板で押さえ板のようなものを作って、固定した方が良いかと思いました。

DW1560はamazon.co.jpでも売られていますが、少し・かなり高いです。

Recoveryからブートする

Sat, 08 Dec 2018 01:54:37 +0900

macOSをインストールすると、macOSの本体が入るボリュームの他に、Recovery（回復）用のボリュームが自動的に作成されます。Recoveryボリュームは、Cloverの起動画面に起動選択肢として現れます。右下の十字マークは、赤十字や病院の印です。macOS本体が起動しなくなってしまった非常時には、Recoveryボリュームから起動して復旧作業を行えます。

Recoveryボリューム

Recoveryボリュームの場所

diskutil listコマンドでマシンに接続されているドライブを見ることができます。コマンドの結果例を以下に示します。このマシンには512GBのSSDが接続されていますが、それがdisk0に割り当てられていることがわかります。disk0はEFIが使用するESP (EFI System Partition)とAPFSのコンテナに分割されています。APFSのコンテナは仮想的なドライブとしてdisk1に割り当てられています。

$ diskutil list
/dev/disk0 (internal, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *500.2 GB disk0
 1: EFI EFI 209.7 MB disk0s1
 2: Apple_APFS Container disk1 500.0 GB disk0s2

disk1の項目を見ると、これが合成された(synthesized)ドライブであると書いてあります。disk1という名前は付いているけど、物理的なドライブではないということです。disk1の中には4つのボリュームができています。これも仮想的なボリュームです。SSDの上では、それぞれがコンテナに割り当てられた500GBを共有しています。ここには実際に使用している容量が書いてあります。

/dev/disk1 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +500.0 GB disk1
 Physical Store disk0s2
 1: APFS Volume Macintosh SSD 331.6 GB disk1s1
 2: APFS Volume Preboot 46.0 MB disk1s2
 3: APFS Volume Recovery 517.0 MB disk1s3
 4: APFS Volume VM 20.5 KB disk1s4

ここに現れたボリュームの中で重要なのはdisk0s1, disk1s1, disk1s3です。

disk0s1: ESPです。ここにClover関係のファイル、Cloverが読み込むkext類があります。マザーボードのBIOS設定では、起動ボリュームとしてここを設定します。電源投入後、Cloverがkext読み込みとパッチ当てを終えるとmacOSを動かせます。
disk1s1: macOSの本体です。通常はこれで起動します。電源投入後にESPからHackintoshに必要なパッチやkextが読み込まれていれば、純正インストーラがインストールしたそのままで（バニラの状態で）動きます。
disk1s3: Recoveryボリュームです。非常時に起動することができます。ESPのファイル群によりHackintoshに必要な処理が終っていれば、これもバニラのまま動きます。

というわけで、バニラなCloverインストールが行われていれば、純正インストーラによりインストールされたmacOSだけでなく、Recoveryからも起動できるわけです。

/posts/131/

ちなみに、残りの二つのボリューム、PrebootとVMは、以下のものです。PrebootはAPFSボリュームからmacOSをブートするための作業用ボリュームらしいです。詳しい働きはわかりません。VMは仮想メモリ(Virtual Memory) のスワップ用ボリュームのようです。使われていないメモリ内容をここに保存します。以前のmacOSではスワップ領域がファイルだったようですが、APFSになってボリュームになりました。従来の物理的なボリュームだと記憶領域が固定されてしまうけど、APFSなら他のボリュームと共用できるので無駄がありません。ということで、ファイルよりおそらく効率の良いボリュームに変更されたのかと思います。

Recoveryボリュームの内容

Recoveryの中に何が保存されているかを調べてみましょう。これがdisk1s3だとわかっているので、以下のコマンドでマウントできます。この結果、/Volumes/Recoveryというフォルダにマウントされます。

$ diskutil mount disk1s3
Volume Recovery on disk1s3 mounted

マウントされたフォルダにはUUIDらしい名前のフォルダが一つだけありました。その中を見てみると以下のようでした。（結果を編集して作業ファイルらしい細かいファイルは省略してあります。）

$ ls -l /Volumes/Recovery/A486A01B-7777-8888-9999-000000000000/
total 1058320
-rw-r--r--@ 1 root wheel 1984 11 30 15:41 BaseSystem.chunklist
-rw-r--r--@ 1 root wheel 485344690 11 30 14:28 BaseSystem.dmg
-rw-r--r--@ 1 root wheel 3900 11 14 13:44 PlatformSupport.plist
-r--r--r--@ 1 root wheel 533 11 30 13:07 SystemVersion.plist
-rw-r--r--@ 1 root wheel 592440 11 30 14:20 boot.efi
-rw-r--r-- 1 root wheel 397 12 6 22:36 com.apple.Boot.plist
-rw-r--r--@ 2 root wheel 27924868 11 15 17:52 immutablekernel
-rw-r--r--@ 2 root wheel 27924868 11 15 17:52 prelinkedkernel

ここにあるBaseSystem.dmgが、最小限の機能でmacOSを動かすための一式が入ったディスクイメージファイルです。これを使って非常時の起動を行なえるようです。

Recoveryでできること

Cloverの起動画面からRecoveryボリュームで起動すると、以下の画面が現れます。Recovery起動中のスクリーンショットの撮り方がわからなかったので、写真です。見にくくてすみません。画面にはmacOSユーティリティが現れます。macOSをインストールするときに現れるお馴染みの画面です。ここから4つの機能を利用できます。

メニューバーにはユーティリティという項目があり、ここにはさらに3個の機能が用意されています。全部で7種類のツールを使えます。順番に見ていきます。

起動セキュリティユーティリティ

Hackintoshでは動きません。Appleのサポートサイトに機能の説明があります。Apple T2 セキュリティチップを搭載した Mac コンピュータでファームウェアパスワードによる保護、安全な起動、外部起動を実現するツールのようです。HackintoshだけでなくT2非搭載のMacでは動かない機能です。

ネットワークユーティリティ

ネットワークの状況がわかります。Ethernetが機能していてDHCPでアドレス取得しているようです。LANチップのAtheros Killer E2200が動いています。CloverがESPにあるAtherosE2200Ethernet.kextを読み込んでくれていて、それが機能していることが確認できます。

WiFiも動いています。こちらはパスワードを入れなくても接続していました。いつものパスワードがRecoveryから使用できているようです。画面右上にはWiFiアイコンが出ています。もしアクセスポイントの選択やパスワード入力が必要ならば、WiFiアイコンから行えます。

ターミナル

ターミナルさえ動けばなんでもできるので安心です。大体のボリュームがすでにマウントされていますので、/Volumesからどれでも操作できます。ESPの内容も、diskutilコマンドでマウントすれば編集・修正できます。ただ、ESPの内容に不具合があったらRecoveryの起動もできない可能性が高いので、ESPを変更する場面は少ないかもしれません。通常はmacOSボリュームやNVRAMなどが変更対象になるかと思います。

TimeMachineバックアップから復元

これを選択すると、接続されているドライブとネットワーク上TimeMachineサーバが表示されます。その中から、必要なタイムスタンプのバックアップを復元できます。Recoveryから起動しているので、macOSのシステムも復旧できます。

macOSを再インストール

おなじみのmacOSインストーラが起動してインストールできます。インストールのためにはネットワークに接続している必要があるらしいです。

ヘルプ情報をオンラインで取得

Safariが起動してヘルプのファイルが開きます。ネットワークが接続されていれば、外部にも接続できます。

ディスクユーティリティ

ディスクユーティリティ.appが起動します。BaseSystem.dmgがディスクとしてマウントされている様子がわかります。ディスクユーティリティ.appが動けばドライブのフォーマットもボリューム追加・初期化も思いのままです。ただし起動しているRecoveryボリュームは使用中ですので初期化できません。

macOSに不具合がある場合は、初期化されたボリュームに新規インストールすることが多かったかと思います。APFSになってボリュームが幾つでも作れて、容量も気にする必要がなくなりました。なので、macOSを新規インストールする場合に、既存のボリュームを消去せず、それを残したまま新規にボリュームを追加しても良いかと思います。

VirtualSMC: もう1つのFakeSMC

Fri, 23 Nov 2018 00:12:56 +0900

SMCとは何か？

SMC (System Management Controller) はIntel版Macに搭載されたサブシステムです。小さなコンピュータチップですね。Intel版になる前にもこのようなサブシステムは存在していて、SMU (System Management Unit)とかPMU (Power Management Unit)などと呼ばれていたようです。SMCは、メインのIntel CPUとは独立して動いて、次のような仕事を担当しています。

温度と電力のモニターと制御
バッテリー充電
ビデオモードの切り替え
スリープ、wake, ハイバネーション、LED表示

ちなみに最近のMacに搭載されているApple T2セキュリティチップは、SMCも内蔵しているらしいです。

SMCのふりをするFakeSMC.kext

一般的なATXマザーボードにはSMCは搭載されていません。SMCは独立したサブシステムですが、OSからアクセスすることもあるので、SMCが無いとmacOSが起動しません。FakeSMC.kextは、名前の通り、SMCがあるかのように振舞ってくれるkextです。macOSを起動するために唯一必須のkextなのです。

また上述のように、SMCには温度をセンシングして冷却コントロールする機能もあります。FakeSMCはこれらの機能も提供するので、連携するアプリケーションを使用することで、コンピュータの温度やファン回転数を知ることもできます。

新登場のVirtualSMC

FakeSMCと同じ機能を実現するために、最近VirtualSMCというkextが登場しているようです。最初のリリースは今年(2018)の9月12日です。出たばかりです。

GitHub - acidanthera/VirtualSMC: SMC emulator layer

githubのページには、特徴として以下のことが書かれています。

macOS 10.8 以降をサポート（10.9 以降を推奨）
MMIOプロトコルと割り込み応答により最近のOSとの互換性を確保（MMIOってメモリマップドIOのことかなぁ？）
キー割り当てとR/W保護を正しく報告
機種に合わせたチューニングとSMCバージョンを提供
センサとキーのためのプラグイン拡張可能
smcdebug=xxブートオプションをサポート
本物のSMCが見つかったらそれを置き換える（本物のMacのSMCを置き換える目的でも使用できる）
全機能を発揮するにはLilu.kextが必要

だそうです。redditでも紹介されて、FakeSMCとVirtualSMCの比較が書かれていました。

r/hackintosh - FakeSMC vs VirtualSMC

redditの達人達の評価によると、

FakeSMCは歴史もあって安定していてちゃんと動く
FakeSMCはハードウェアモニタ機能が充実しているので、それを使いたい場合には引き続き使用すべき
VirtualSMCは新しい設計に基づいてより厳密なエミュレーションを目指している。性能やデバッグで有利なので、将来性がある。

ということです。安定性を求めるなら定評のあるFakeSMCを使い続けて、新しいものに興味があるならVirtualSMCを使ったら良いのではということでした。ChameleonがCloverに置き換わった時も、こんな感じの評判でしたので、将来はVirtualSMCに置き換わっていくと思われます。

VirtualSMCを使ってみた

そこで早速使ってみました。githubからダウンロードしてmakeするのは面倒なので、コンパイル済みを探します。そこで、最近お世話になっているKext Updater.appを使いました。

ここで、Load Single Kextを選ぶと、VirtualSMCをダウンロードできます。

こうして入手したVirtualSMC.kextをFakeSMC.kextと置き換えてみました。

入れた場所は、ESPの中です。ドキドキしながら再起動したところ、無事、ブートできました。最初の起動には少し時間がかかった気がしましたが、２回目以降の起動はFakeSMCの時よりも早くなったような気がしました。ただし気のせいかもしれません。FakeSMCと同じく、問題なく動く様子ですので、新しい物好きとしてはVirtualSMCを使っていきたいと思います。

ダウンロードしたファイルには、VirtualSMC.kext本体の他に、センサー関係のkextらしきものがいくつか入っています。

今回は、一つもインストールしませんでしたが、そのうち調査したいと思います。

蛇足：両方使うとどうなる？

試しているうちに、うっかりFakeSMCとVirtualSMCを両方使ってしまった期間がありました。気づかず使っていたのですが、手元の環境では、macOSを終了しても電源が切れずにまた起動するようです。気づいて片方のみにしたら、正常に戻りました。両方使う意味はないですし他にも副作用が出ると思いますのでご注意ください。

NVRAMのエミュレーション

Thu, 15 Nov 2018 19:20:52 +0900

NVRAMは不揮発性メモリの意味で、電源を落としても記憶が消えないメモリーのことです。マザーボード上にもありボタン電池などでバックアップされています。コンピュータ機器では、音量とか起動ディスクなどの情報が記憶されています。昔のMacではPRAM (パラメータRAM) と呼ばれていたこともありますが、NVRAMと同じものです。

本物のMacのハードウェアにも、ATXマザーボード上にも、どちらにもNVRAMはあります。しかしHackintoshでは、macOSからATXマザーボード上のNVRAMがうまく読めないこともあるようです。

そこで使われるのがEmuVariableUefi-64.efiです。Cloverのdrivers64UEFIフォルダに入れておくと、NVRAMのふり（エミュレーション）をしてくれます。NVRAMが覚えておくべき情報を、おそらくSSD/HDDなどの上で記憶しておいてくるのだと思います。マザーボード上のNVRAMがmacOSから利用できていればEmuVariableUefi-64.efiは不要です（あっても構わないです）。利用できていなければ、後述するNvidia Webドライバの利用などで必要になります。

NVRAMの内容を見る

NVRAMはterminalからnvramコマンドで読み書きできます。man nvramとすると使い方が表示されます。それを見ると：

nvram [ -p ] [ -f filename ] [ -d name ] [ -c ] [ name [= value ]] ...
OPTIONS
-d name
Deletes the named firmware variable.
-f filename
Set firmware variables from a text file. The file must be a list of "name
value" statements. The first space on each line is taken to be the separator
between "name" and "value". If the last character of a line is \, the value
extends to the next line.
-x Use XML format for reading and writing variables. This option must be used
before the -p or -f options, since arguments are processed in order.
-c Delete all of the firmware variables.
-p Print all of the firmware variables.

のように、いろいろなことができるようです。例えば-pxオプションでNVRAMの内容をXML風に見ることができます。長いのでlessにパイプすれば、スクロールや検索もできて便利かもしれません。

nvram -xp | less

-xpオプションでわかるように、NVRAMにはキーとデータの対でデータが保存されています。Hackintoshで重要なキーの一つがNVIDIAのWebドライバを使うかどうかを記憶するキー、nvda_drvです。Webドライバが機能しているならば、以下のコマンド

nvram nvda_drv

で1%00というデータが返ってくるはずです。16進数で表すと0x3100というデータで、アスキーコードの1と、数値のゼロの2バイトです。C言語などの文字列は、文字列の最後を0x00で表しますので、1を表す文字列だと思われます。使用中ということでtrueを表す1になっていると思われます。このキーが無い場合はドライバが動かないため、低解像度表示になったり、画面表示されない可能性もあります。

NVRAMの機能を確認する

NVRAMが機能しているかどうかを確認するためには、適当なキー・データ対を作って電源を切っても保存されているかどうか調べれば良いです。例えば、

sudo nvram hogehoge=HelloWorld

とすると、hogehogeというなんの意味もないキーが作られて、それにHelloWorldという文字が割り当てられます。

nvram hogehoge

で確認することができます。ここで、マシンを再起動してもこのデータが残っていればNVRAMが働いていることになります。確認ができたら、以下のようにして消しておきます。

sudo nvram -d hogehoge

手元の3台のマシンで調べたところ、2台はNVRAMを保持してくれていました。hogehogeも残っていました。一方で、1台はNVRAMが消えてしまいました。hogehogeが消えるだけではなく、nvramコマンドが返してくれるキーの数も6個しかありません。

nvram -xp | grep key
<key>EFIBluetoothDelay</key>
<key>LocationServicesEnabled</key>
<key>SystemAudioVolume</key>
<key>SystemAudioVolumeDB</key>
<key>bluetoothActiveControllerInfo</key>
<key>bluetoothInternalControllerInfo</key>

NVRAMが消えてしまうマシンでも、EmuVariableUefi-64.efiを入れておけば、NVRAMが消えなくなります。

バージョンを誤魔化してNVIDIAドライバを入れる

Fri, 09 Nov 2018 00:30:00 +0900

これはMojaveでNvidiaのドライバを動かす方法ではありません。Mojave対応ドライバが待ち望まれている時節柄紛らわしい記事ですみません。この方法でWebドライバがMojaveで動かなくはないらしいですが、性能が全く出ないらしいです。

経緯

MojaveではNvidiaドライバが動かないので、Nvidiaを搭載したマシンはHigh Sierraで使っていました。先日、それにうっかりPublic Beta版のセキュリティアップデートを当ててしまいました。これです。

通常版のアップデートだと勘違いしました。ベータ版配布をoffにしておくべきでした。

もうmacOSベータ版は要らないと思ったあなたに

アップデートしたことでmacOSのビルドが上がりました。17G4005です。

配布されているWebドライバの最新版は17G3025用なのでバージョンチェックで動かなくなってしまいました。そこで、17G3025用のドライバを、無理やり17G4005にインストールして動かすことにしました。

バージョン違いのドライバをインストールする

17G3025用のドライバ（こんなアイコンです）

をダウンロードサイト

NVIDIA DRIVERS Quadro & GeForce macOS Driver Release 387.10.10.10.40.108

から入手しても、バージョンが違うと、そもそもインストールできません。そこで17G3025用ドライバのパッケージを開いて、設定を変更します。まずは、パッケージユーティリティを使って展開します。

pkgutil --expand (pkgへのパス) (展開先ディレクトリ)

例えば

pkgutil --expand WebDriver-387.10.10.10.40.108.pkg exp

とします。こうするとexpというディレクトリに内容が展開されます。この中に、Distributionという名前のテキストファイルがあります。これを開いて、インストールチェックをしているところ

function InstallationCheck()
{
if (!validateSoftware()) return false;

return true;
}

をコメントアウトします。

function InstallationCheck()
{
//if (!validateSoftware()) return false;

return true;
}

もしくは、後ろの方にvalidateSoftware()関数の定義がありますので、そこのビルド番号を書き換えても良いです。つまり、

function validateSoftware()
{
var supportedOSVer = "10.13.6";
var supportedOSBuildVer = "17G3025";

というところを、

function validateSoftware()
{
var supportedOSVer = "10.13.6";
var supportedOSBuildVer = "17G4005";

とします。

次に、以下のコマンドでパッケージし直します。

pkgutil --flatten exp webdriver.pkg

これは上の例でexpという名前のフォルダを作った場合です。このパッケージを使ってWebドライバをインストールします。

バージョン違いのドライバを動かす

インストールはできましたが、バージョンが合わないのでドライバが動きません。Not compatibleというメッセージが出てしまいます。そこでパッチを当てます。

ドライバにパッチを当てるためのスクリプトが、benjamin.dobellさんによって配布されています。以下のコマンドで入手できます。

curl -O https://raw.githubusercontent.com/Benjamin-Dobell/nvidia-update/master/nvidia-update.sh

こうしてできたnvidia-update.shを実行可能にして起動します。

chmod a+x nvidia-update.sh
./nvidia-update.sh

最初の質問（ダウンロードするか？）にはN、次の質問（パッチを当てるか？）にはYとタイプします。そして再起動します。無事動くようになりました。

ここまで、SIPは有効のままでも問題なく作業を進められました。

2018 Mac miniはすごい

Fri, 02 Nov 2018 00:30:00 +0900

Mac miniが4年ぶりにリニューアルされて話題になっています。Apple社はディスプレイなしのデスクトップMacなどにもはや興味がないのではと思っていました。特にローコストのminiは見捨てられているのだと感じていました。なので、今回の新製品は意外でした。素晴らしいです。

CPUはモバイル用のBモデル

一番素晴らしいことはCPUがデスクトップに匹敵するCPUになったと言われていることです。従来のminiはひ弱なモバイル用CPUを搭載していたのが残念に感じていました。重量やサイズの制約がないデスクトップなら、性能を追求して欲しいと思っていました。

CPUはインテルの第８世代CPUと言われています。型番が8000番台のCPUです。製品が出回ればすぐに明らかになると思いますが、実際にどの型番なのかは今現在では明らかになっていません。でもおそらく8100, 8500, 8700ではないかと思われます。というのは３モデルの仕様が、インテルの仕様に合致しているからです。公式サイトで紹介されている仕様は以下です。

	mini i3 4コア	mini i5 6コア	mini i7 6コア
動作周波数	3.6GHz	2.8GHz	3.2GHz
Turbo Boost	記載無し	4.1GHz	4.6GHz
L3キャッシュ	6MB	9MB	12MB

これに対して、8100, 8500, 8700の仕様は以下です。

	Core i3 8100	Core i5-8500	Core i7-8700
Core/TH	4/4	6/6	6/12
動作周波数	3.6GHz	2.8GHz	3.2GHz
Turbo Boost	非対応	4.1GHz	4.6GHz
L3キャッシュ	6MB	9MB	12MB
TDP	65W	65W	65W

完全に一致しているので、ほぼ間違いないと思います。いずれもTDPが65Wなので、miniの筐体に入ると思われます。

ただし、通常の自作PC用に販売されているデスクトップ用の8100, 8500, 8700ではないと思われます。実は、本年４月に、Intelがデスクトップ版Core i7-8700と同仕様の8700Bを投入したというニュースがありました。

Intel、デスクトップ版Core i7-8700と同仕様の8700Bをモバイル向けに投入

Bモデルは、デスクトップ用無印CPUと同じスペックのようです。ただ、パッケージがデスクトップ向けのLGA1151ではなく、モバイル向けのHプロセッサと同じFCBGA1440となっています。8700Bについてはこちらのサイトで詳細が紹介されています。

Core i7-8700B – Intel – WikiChip

CPUの形状はこんな感じです。

この記事の冒頭にある、アップル公式サイトの写真とそっくりです。なので2018 miniのCPUは8100B, 8500B, 8700Bだと思われます。

自作PCで使う現行インテルCPUはマザボとの接続がLGAです。ランドグリッドアレイという名前で、CPUの底にランドと呼ばれる楕円の電極パターンが印刷されています。マザボのソケットのピンがランドに接して接続されます。ソケットを使用することを前提とした構造です。これに対してminiで使われるBモデルはBGAだそうです。Bはボールで、接点部分にハンダボールが付いています。マザボ上の接点パターンに乗せて炉で加熱してハンダ付けします。なのでiMacのように簡単にCPU交換する事は出来ないでしょう。

今のタイミングなら、9000番台の第９世代CPUで作って欲しかった気もします。とはいえ、第８世代デスクトップ用CPUがmacOSで正式サポートされたことで、同じCPUを使っているHackintoshの安定性がさらに向上するものと思います。

チップセット

iFixItで分解されたところによるとチップセットはCM246というもののようです。CM246はCoffee Lake用のモバイル版チップセットで、H370/Z390などと同様にUSB 3.1 Gen 2と無線機能も搭載している様子です。これらがmacOSでサポートされていれば、H370/Z390搭載マザーボードでの自作が楽になると期待できます。

でも、新しいMac miniの「システム情報」を見ると、macOSではチップセットの無線機能を使わずに、従来通りBroadcom互換チップを使っているようです。こちらの記事に、システム情報のスクリーンショットが紹介されています。

一方でUSB 3.1 Gen 2の方は、インテル製コントローラをmacOSが使用しているようです。店頭にあった新Mac miniの「システム情報」を見たところ、USB 3.1バスのホストコントローラの記載に、PCI製造元IDが0x8086とありました。8086は、インテルの有名な初代16bit CPUの型番ですが、インテルのID番号にもなっています。インテル製ということです。ちなみに今までのmacOSではASMediaのコントローラを使っていましたので、PCI製造元IDはASMedia Technology Inc.のIDである0x1b21でした。インテルチップセットのUSB 3.1 Gen 2にmacOSのドライバが対応したと思われます。

省電力・iGPU Hackintoshは無用

今回のminiはピンは半田付けBGA方式のモバイル版ではありますが、中身はデスクトップ用と同等のCore i3 CPUを初めて搭載しています。CPU内蔵のiGPUだけを使って、省スペースで強力なHackintoshを作る必要性がなくなりました。グラフィクスカードを搭載しないMini ITXやMINI STX型小型Hackintoshはもはや不要です。本物のMac miniを買えば、デスクトップCPU搭載macOSマシンが手頃な価格で入手できるからです。もともとApple社が欲しいMacを作ってくれないので自作Hackintoshを始めたので、今回のMac miniが出て、Hackintoshが不要になることは嬉しい限りです。モバイル用省電力CPUではなくなったので、省電力を目指してi3 NUCでHackintoshする価値はまだあるかもしれません。

一方で、グラフィックスカードを搭載した重量級デスクトップHackintoshはまだまだ必要です。強力なグラフィックス性能が必要ならば、Thunderbolt経由の外部GPUボックスを使って欲しいというのがAppleの方針かと思います。でもThunderboltはPCIe x 4なので、フルサイズPCIe x 16に比べると接続ケーブルがボトルネックになります。ジサトラKTUのベンチマークテストでもかなりの差が出ています。

youtu.be

小型軽量が重要なモバイル機器ならThunderboltで拡張する意義はありますが、デスクトップではせっかくのGPUがもったいないと感じます。来年発表されると噂の「モジュラー型」Mac Proで、タワー型デスクトップHackintoshも無用の存在にして欲しいと願っています。

MojaveでJPEGファイルが開けない

Sat, 27 Oct 2018 00:30:00 +0900

MojaveではAMD Radeon RX570 RX580などがOOBでほぼ問題なく動きます。でも多少の不具合はあります。それをメモしておきたいと思います。以下では、CPU内蔵GPUをiGPU, 内蔵ではないGPUをdGPU, Thunderbolt拡張ボックスで増設するGPUをeGPUと書くことにします。

GeekBenchの性能低下は解決

BIOSでiGPUを機能させないように設定すると、しばらく使っているうちにGeekBenchのOpenCLスコアが下がってしまう問題がHigh Sierraではありました。この問題はMojaveになってから解決したようです。iGPUはoffのままでも、性能低下は発生しないようです。

SafariでAmazonの動画が見られない

BIOSでiGPUが機能するように設定すると、なぜかSafariでAmazon動画が見られません。謎です。Google Chromeなどでは見られます。表示が出ない・乱れるという訳ではなく、「再生エラー」というダイアログがAmazonから出されるので、デジタル著作権保護に関する問題かもしれません。もしかしたら、実機のeGPUでも同様の症状が発生するのかもしれません。またAmazon以外でも動画再生に問題が発生するのかもしれません。でもSafari以外のブラウザを使えばokなので大した問題ではないです。~~BIOSでiGPUを機能させない設定にすれば、SafariでもAmazon動画が再生されます。~~BIOSでiGPUを機能させない設定にすると、今度はSafariで「プラグインが見つかりません」というエラーメッセージが出ます（10.14.1で確認)。

JPEGファイルがクイックルックできない

BIOSでiGPUを機能させないように設定すると、JPEGファイルのクイックルックができません。プレビュー.appでもJPEGファイルを開くことができません。レインボーカーソルが出て止まってしまいます。JPEGの展開にiGPUの機能を使っているためこうなるようです。これはかなり不便です。この問題はNVIDIAのグラフィックスカードでも発生するようです。この問題の解決策として以下の３通りが知られています。

BIOSでiGPUが機能するように設定します。ただし、上の、SafariでAmazon動画が再生されない問題が発生します。
同系統のdGPUを搭載しているMacの機種IDになるように、config.plistのSMBIOS設定を変更します。ただしCPUやチップセットが違う機種に設定することになりうるので、動作が不完全になる可能性があります。あまりお勧めできません。
NoVPAJpeg.kextをLilu.kextと一緒に使います。これを使えば、iGPUがoffでもJPEGファイルクイックルックの問題が発生しません。

www.insanelymac.com

ということで、３番目の方法であるNoVPAJpeg.kextを使えばすべて解決するようです。でも、実のところ私はiGPUを機能させる設定でしばらく使うことにしました。せっかく搭載されているのにiGPUを使わないのはもったいない気がするからです。SafariでAmazon動画を見なければ良いだけですので。

今回紹介した問題は、iGPU, dGPUの切り替えがうまくいっていないことで発生しているように思います。実機でも、GPU切り替えが原因のトラブルが時々話題になっています。Hackintoshの問題ではなくて、どちらかというとmacOSの問題のような気がします。eGPUを公式サポートするようになったのは最近のことなので、今はあまり気にしなくても将来のmacOSで改善されると期待しています。

追記：NoVPAJpeg.kextについて

NoVPAJpeg.kextはWhateverGreen.kextに統合されたようです。

今後はWhateverGreen.kextだけで問題が解決するようです。ただ、それでもJPEGファイルのクイックルックが動かない場合は、ブートオプションに以下を追加すれば良いようです。

shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94

APFSのVolumeを活用する

Fri, 19 Oct 2018 00:30:00 +0900

HFS+から大幅刷新されたAPFS (Apple File System)には色々便利な機能があります。今回は、Hackintoshライフに役立つAPFS Volume機能をご紹介します。

（更新：Catalinaのことを追記しました。2020/3/3）

HFS+のVolume

HFS+でもAPFSでも、アプリケーションから見えるのは最終的にVolumeです。Volumeは物理的にはストレージの一部なのですが、アプリケーションからは

/Volumes/

以下にマウントされ、ディレクトリのように見えます。

物理的なストレージからVolumeに至る階層構造を以下にまとめます。HFS+では、

物理的なドライブ。物理的なSSDやHDDです。本当はファイルではないのですが、システムからは/dev/disk0のように見えます。ファイルのようにも見えますが、実際にはファイルではありません。ストレージの内容を読み書きするデバイスドライバへアクセスする場所として使われます。システムファイルとも呼ばれます。
物理的なパーティション。SSDやHDDを分割した領域です。これも/dev/disk0s1のようなスペシャルファイルとして現れます。
HFS+のVolume。パーティションに名前をつけてHFS+でフォーマットしたもの。/Volumes以下にその名前で現れます。一つのパーティションに一つのVolumeを作ります。

という構造になっています。2個の異なる物理ドライブの2つのパーティションを一つにみなす機能もあって、それでRAID 1ミラーリングやFusion Driveを実現しています。

APFSのVolume

APFSではこの構造に、コンテナという要素が加わります。物理的なストレージからVolumeに至る階層構造はAPFSでは以下になります。物理的な構造であるドライブとパーティションはHFS+と同じです。

物理的なドライブ
物理的なパーティション
コンテナ。通常は1個のパーティションを1つのコンテナにします。2個のパーティションを1つのコンテナにするとFusion Driveになります。
APFSのVolume。コンテナの中にAPFSでフォーマットされたVolumeを作ります。これが/Volumes以下に現れます。容量はコンテナの容量と同じです。1つのコンテナを、複数のVolumeで共有することができます。複数Volumeの場合、容量はどれもコンテナの容量と同じですが、他のVolumeが領域を使用すると、その分空き領域が減ります。

High SierraやMojaveのインストーラはHFS+をAPFSに自動変換してしまいますが、そのとき、パーティション→Volumeの構造を、パーティション→コンテナ→Volumeに変換します。「コンテナが間に挟まってややこしくなってしまった」と感じていたのですが、実は便利だとわかりました。

Fusion Driveがコンテナの機能で実現されることは、以前の記事で紹介しました。

APFSに対応したFusion Driveを作る

以下では、コンテナの中に複数のVolumeが作れる機能を利用して、Hackintoshの保守を簡単にする方法をご紹介します。

HFS+で複数Volumeを使う

HFS+以前は1パーティションが1 Volumeでした。

Hackintoshに限らないのですが、OSをインストールする際に、ストレージを用途ごとにパーティションに分け、別Volumeにする手法が一般的でした。LinuxなどのUnix系OSでは、システムが使用するルート/、利用者がファイルを置くホーム/home、一時ファイルが置かれる/tmpなどなどを、複数のドライブにまたがった複数のパーティションに割り当てます。ファイルシステムにトラブルがあってもパーティションごとに独立していれば被害は少ないし、パーティションごとにフォーマットし直したり、別のドライブに移動するのが容易だという理由です。

そこまで細かく分けなくても、macOSでも、システムと/Users以下を別パーティションにしている人も多いと思います。分けておけば、macOSのメジャーアップデートの時に、システムパーティションをフォーマットして、綺麗さっぱりクリーンインストールすることも容易です（利用者データは別パーティションに残っていますから）。

例えば、1TBのSSDがある場合、システムに120GB、/Usersに880GB割り当てたりします。でもmacOS Mojaveをインストールした直後のサイズは約13GBなので、この割り当てだと最初はシステムパーティションが勿体無いです。一方で、Xcodeなどのサイズの大きなアプリケーションをどんどんインストールしていくと、120GBでは苦しくなります。Disk Utility.appでパーティションサイズを変更できることになってはいます。ただ、制約が大きくて、変更できない状況がほとんどです。パーティションを分けるときに、割り当てサイズをどう決めるかは、いつもいつも難しい問題でした。

APFSで複数Volumeを使う例

APFSでは1パーティションが1コンテナになり、複数Volumeを作れます。

先ほどの例に対して、今度はAPFSコンテナのVolume共有機能を活用します。1TBのSSDを買ってきたら、とりあえず全体をAPFSでフォーマットしてmacOSをインストールします。ここで出来上がったVolumeの名前を例えばmacOSとします。SSD全体に1つのパーティションができて、これに1つのVolumeができるので、サイズは1TBになります。/Volumes/macOSというようにマウントされます。

次に、新しいVolumeを作って、そこにホームディレクトリを移動させてみましょう。デフォルトでは、/Users以下のアカウント名と同じディレクトリがホームディレクトリになっています。以下では、homeというVolumeを作ってその中にホームディレクトリを置くことにします。まず、Disk Utility.appを開いて、現在のコンテナを選択して、「パーティション作成…」ボタンを押します。すると以下の案内が出ます。

1つのコンテナは1つのパーティションを占有し、コンテナ内のストレージ領域はコンテナ内の複数のAPFSボリュームで共有されます。APFSボリュームの追加や削除は、パーティションマップを編集するよりも簡単かつ高速に実行できます。

ここに書いてあるように、新しいVolumeを作るためには、“編集”メニューの“APFSボリュームを追加”コマンドを使用するか、ツールバーの“ボリュームを追加/削除”ボタンを使用しても良いです。本当はそちらの方法が正当で、このメッセージは従来のパーティション作成を試みようとしたユーザにAPFSへの移行を促す目的の案内なのだと思います。

ここで「ボリュームを追加」を選ぶと、このコンテナにVolumeを追加できます。homeという名前のVolumeを追加します。結果を以下に示します。「このMacについて」から見たいストレージの状況です。ここでお詫びです。ここまで1TBのSSDなどと豪勢なことを言っておりましたが、余分な1TB SSDを持っていなかったので打ち捨てられていた160GB HDDを使いました。

/Volumes/macOSも/Volumes/homeも同じ容量であることがわかります。同じ1つのパーティションを共有しているためです。それぞれのVolumeで使った分だけ空き容量が同じように減っていきます。パーティションのサイズで悩む必要がなくなったのです。

ターミナルのdiskutil listコマンドで見ると、以下のようになります。

$ diskutil list
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0:     GUID_partition_scheme *160.0 GB disk1
1:     EFI EFI 209.7 MB disk1s1
2:     Apple_APFS Container disk4 159.7 GB disk1s2

/dev/disk4 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0:   APFS Container Scheme - +159.7 GB disk4
Physical Store disk1s2
1:   APFS Volume macOS 13.3 GB disk4s1
2:   APFS Volume home 57.6 MB disk4s2
3:   APFS Volume Preboot 46.1 MB disk4s3
4:   APFS Volume Recovery 512.4 MB disk4s4
5:   APFS Volume VM 20.5 KB disk4s5

今回作成したコンテナの物理的な実体は、disk1s2にあります。コンテナの中には現在5個のVolumeができていて、コンテナ全体を共有しています。それぞれの使用量は、macOSが13.3GB（これがmacOS Mojaveの本体です）、homeが57.6MB（こちらは/Users以下のサイズです）などとなっています。

こうして作った/Volumes/homeの中にホームディレクトリを移動するには以下のようにします。まずアカウント名と同じ名前で空のディレクトリを作ります。アカウント名が例えばhogeだったら /Volumes/home/hoge を作ります。次にシステム環境設定から「ユーザとグループ」を選び、ウィンドウ左からユーザhogeを選んで、右クリックで「詳細オプション」を選び、ホームディレクトリとして/Volumes/home/hogeを指定します。これで再起動すれば、このディレクトリがホームディレクトリになります。

CatalinaからはmacOS本体の部分が二つに分割されるようになりました。macOSの基本部分は保護されてrootアカウントからも書き込み禁止になりました。別のボリュームの例ですが、以下のようになります。

/dev/disk1 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +249.8 GB disk1
 Physical Store disk0s2
 1: APFS Volume Preboot 127.3 MB disk1s1
 2: APFS Volume Recovery 1.0 GB disk1s2
 3: APFS Volume VM 2.1 GB disk1s3
 4: APFS Volume Macintosh HD - Data 41.7 GB disk1s4
 5: APFS Volume Macintosh HD 11.6 GB disk1s5

ここで Macintosh HDと書かれた部分が保護されたエリアで、Macintosh HD – Dataがそれ以外の書き込み可能な部分です。/Users以下も通常はここに書き込まれます。

OS切り替えにも複数Volumeが便利

APFS Volumeは、簡単に追加したり削除したりできます。ストレージの容量は実際に使用している分だけしか消費しません。Mojaveならたったの13GBです。なので、複数Volumeを用意して、複数のmacOSをインストールしておけば、以下のようなことが可能です。

別バージョンのmacOSに切り替える。例えば別のVolumeにCatalina, Mojave, High Sierraをインストールしておく。
テストバージョンのmacOS、例えばCatalinaを別Volumeにインストールする。古いmacOSは残っていますから、不具合があったらすぐに戻れます。新OSのベータ版を試すような場合にも便利です。
メインで使うVolumeの他に、別 VolumeにもmacOSをインストールしておく。うっかり怪しいアプリやkextをインストールして起動できなくなった場合でも、バックアップから起動して、修正作業ができます。

などの使い方が考えられます。

バニラなインストールをしておけば、macOSは通常のインストールで機能するので、管理が簡単です。

/posts/131/

不具合があっても別のVolumeのmacOSから起動できます。ただし、ESPの部分は同じものを使いますので、こちらもバックアップをしておくと安心です。

ESPをマウントしてついでにバックアップする

Mojaveの「インストーラリソースが見つかりません」問題

Fri, 12 Oct 2018 00:30:00 +0900

Mojaveへの移行は基本的に簡単で、Cloverやkext類が最新なら何の問題もありません。ただ、一部の環境で、macOSインストーラが止まってしまうトラブルがあるようです。手元のマシンでも2台が止まってしまいました。どういうわけか不明です。インストーラの不具合ではないかという説もあります。ただ、世の中ではあまり話題になっていなくて、Hackintoshで主に発生しているようです。

症状

macOS Mojaveインストール.appを起動して、インストールの準備は順調に進みます。その次、1回目の再起動が発生します。ここで、Boot macOS Install from xxxxというエントリーから再起動すればインストーラが立ち上がって問題なく次に進むはずです。

しかしこの時に、「インストーラリソースが見つかりません。」と言われてインストーラが止まってしまうことがあります。再起動しても、またここで止まります。

画面に表示されるメッセージは、日本語では、

コンピュータにmacOSをインストールできませんでした
インストーラリソースが見つかりません。
インストーラを終了してコンピュータを再起動してからやり直してください。

です。英語の環境でインストーラが立ち上がった場合には、

macOS could not be installed on your computer
The installer resources were not found.
Quit the installer to restart your computer and try again.

と表示されます。句読点は表示のままです。

発生する時は、上書きインストールでも、クリーンインストールでも発生します。ファイルシステムがAPFSでもHFS+でも発生します。

解決策

このメッセージで検索しても事例はあまり見つかりません。それでもtonymacx86にはいくつかの報告と解決事例がありました。それによると、

USBに接続したSSDにインストールしようとしたらこうなったので、内部ドライブにインストールしたら成功した
M.2に挿していたNVMeを外したらインストールできた

などとありました。どうも、ストレージを複数接続している場合に発生しやすいようです。とは言え、手元のHDDを多数搭載したマシンでは問題ありませんので、数の問題ではないようです。

いろいろ探していたら、まとめてあるページを発見しました。

‘macOS could not be installed on your computer’ error when installi…

書いてある内容をまとめると、以下になります。

SATAドライブだけの構成の場合は、インストール先以外の全てのドライブを取り外してインストールする
M.2 NVMe SSDにインストールしているときは、M.2を外して、SATAドライブにインストールしてからコピーする

どうもスッキリ解決というわけにはいかないようです。

やってみた

手元で問題を起こしている1台のマシンはM.2 NVMe SSDを搭載しています。M.2 SSDにも、SATAのドライブにもどちらにインストールしようとしても、このエラーメッセージで止まってしまいます。上記のサイトのガイドでは実質的にお手上げのケースです。

M.2 SSDを取り外すのが厄介でしたので、別のマシンで予備のSSDにインストールしました。32GBの2.5インチSSDを外付けUSBケースに入れて、MacBook Proに接続しました。インストール直後のMojaveの容量は14GB以下なので、16GBくらいのUSBメモリでも可能かもしれません。Mojaveインストーラを起動して、USB経由でインストールしました。

2度再起動して、国名を選択する設定画面で、ちょっと乱暴でしたが、電源を切ってSSDをとりはずしました。これを、問題起こしているマシンのUSBに接続します。

M.2 SSDはAPFSでしたのでボリューム作るのが簡単です。クリーンインストール用にボリューム作ります。先ほどのUSB SSDの内容を、新しく作ったボリュームにコピーすれば良いのです。

上記のサイトでは、ここで使うツールとしてCarbon Copy Cloner (CCC)を一例にあげています。CCCに問題がある訳ではありませんが、出来るだけ素朴なツールを使いたい主義なので、まずはDisk Utility.appの復元をためしました。内部では多分ddコマンドが動いていると推測してます。でもエラーで止まってしまいました。

そこでrsyncコマンドをつかってみました。上手くいきました。/Volumesに、コピー元がsource 、コピー先がtargetとマウントされている場合、以下のコマンドでコピー出来ます。

sudo rsync -av /Volumes/source/ /Volumes/target/

次に、M.2 SSDのこの新ボリュームから起動させたところ、インストールの続きが始まり、無事完了しました。

手元でインストーラが止まっているもう一台のマシンにはmSATA SSDとSATAのHDDが接続されています。前述のサイトによると、こちらは使わないドライブを外すだけで良いようです。~~そのうち試して報告します。~~実際にやってみました。HDDを取り外して起動させたところ、このメッセージは出なくなり、無事インストールできました。

eficheckにファームウェアが違うと注意されました

Sun, 07 Oct 2018 15:55:55 +0900

「コンピュータに問題が発生している可能性があることが検出されました」

というダイアログパネルが先週唐突に現れました。Mojaveにアップデートしてからだいたい1週間目のことです。正確には604,800秒後のことです。

Appleのサポートに公式の説明があります。

support.apple.com

このメッセージは、Mac に実際にインストールされているファームウェアと、macOS で必要とされるファームウェアとの間に違いが認められた場合に表示されます。

（略）
macOS High Sierra 10.13 から、Mac はファームウェアが変更されていないか定期的にチェックし、そうした変更点について Apple に情報を送信できるようになりました。

そういえば1年以上前、High Sierraのベータ版が出た頃にこの新機能が話題になっていました。このチェックを定期的に行なっているのはeficheckというプログラムです。本体は、

/usr/libexec/firmwarecheckers/eficheck/eficheck

にあります。

MacのEFIファームウェアのチェックサムを、Apple社の何処かにあるデータベースと比較して、違っている場合には安定性やセキュリティに問題があると判断して、警告を出してくれるプログラムだそうです。Hackintoshの場合は、当然のことながらEFIファームウェアは本物のMacと違うので、警告出まくりになるだろうと、当時は話題になっていました。でも一度も警告は出たことがなく、すっかり忘れていました。ネットで調べても、警告が出たという報告はすごく少ないです。私も初めてです。なんで出たのか不明ですが、Mojaveにアップデートしたことと関係がありそうです。

eficheckの動く仕組み

eficheckはコンピュータに常駐して動き続けるデーモンと呼ばれるタイプのプログラムです。macOSではデーモンの起動と設定を、

/System/Library/LaunchDaemons/

ディレクトリで行います。この中に一つのデーモンを設定する.plistファイルを置くと、Macの起動時に動くようになります。今回のeficheckを設定しているのは、

/System/Library/LaunchDaemons/com.apple.driver.eficheck.plist

というファイルです。書き換えて遊んでみましょう。

ただ、SIPを有効にしている場合、/System以下のファイルはSIPで保護されています。sudoコマンドでも書き換えることができません。その場合は、SIPを無効にしてから作業します。書き換え作業した後はSIPを有効に戻しても大丈夫です。

/posts/132/

com.apple.driver.eficheck.plistの中身を見てみましょう。以下は抜粋です。

<key>ProgramArguments</key>
<array>
<string>/usr/libexec/firmwarecheckers/eficheck/eficheck</string>
<string>--integrity-check-daemon</string>
</array>

略

<key>com.apple.driver.eficheck</key>
<dict>
<key>Interval</key>
<integer>604800</integer>
</dict>

最初の方に、eficheckへのフルパスと、起動の引数が書かれています。真ん中あたりに、間隔が604,800と書かれています。単位は秒です。割り算してみると、ちょうど7日間になります。つまり、1週間ごとにEFIが正しいものであるかどうかをチェックして、警告を出してくれるようです。

1週間待って次の警告が出るかどうか確認するのは大変でしたので、

<key>com.apple.driver.eficheck</key>
<dict>
<key>Interval</key>
<integer>180</integer>
</dict>

と書き換えて再起動してみました。3分くらいで警告が出ました。やはりこのまま毎週警告が出てしまうようです。

eficheckを止める

なんにせよ厄介なので、起動しないようにしてみました。

cd /System/Library/LaunchDaemons/
sudo mv com.apple.driver.eficheck.plist com.apple.driver.eficheck.plist.org

としました。オリジナルというつもりでorgという拡張子に変更しましたが、oldでもbackupでもなんでも好きな名前で良いです。いずれにせよ、plistという拡張子ではなくなったので、多分大丈夫なはずです。結果は来週以降報告します。 plistという拡張子ではなくなったことで起動しなくなります。１週間後、２週間後にも起動しませんでした。

EFICheckDisabler.kextを使う

コメントで紹介していただいた

www.insanelymac.com

でRehabManさんが配布しているEFICheckDisabler.kextを使ってみました。これをESPに入れるだけでも、エラーメッセージは止まりました。

メッセージが出ないこともある

原因は不明ですが、このエラーメッセージが一向に出ないマシンもあります。何が違うのかよくわからないのですが（ご存知でしたらコメントでお知らせください）、メッセージが出ないなら、上記の対応をしなくても良いと思います。

追記：いつからかこの問題は発生しなくなりました。少なくともCatalinaでは経験していません。なので古い情報です。(2020/3)

Mojaveにアップデート

Sat, 29 Sep 2018 11:32:52 +0900

火曜日にmacOS Mojaveが公開されました。Hackintoshをアップデートする時間がなかなか取れなかったのですが、ようやく作業できました。結論としては、ベータ版で確認されていた通りで、今回のアップデートには難しいところは全くありません。

上書きアップデート編

macOSアップデートの一番お手軽な方法は、App Storeからダウンロードして、そのままアップデートする方法です。環境設定も、インストールしたアプリケーションも、ユーザ設定もデータも全部そのまま引き継げますので簡単です。今回のアップデートは、OSの根本に大きな変化が少ないので、上書きアップデートができそうです。今回は、High Sierraが動いている初代NUC, DC3217IYEで試してみました。Ivy Bridgeマシンなので、なんとかギリギリでMojaveに対応しています。

NUCで作る超小型macOSマシン

Clover, KEXTをアップデートしておく

macOSのアップデートが簡単になった舞台裏では、Hackintosh開発者の皆さんの努力があります。ベータ版を元に不具合検証して、多数のアップデートが施されています。感謝です。なのでmacOSアップデート前に、最新版にアップデートしておきましょう。

現時点でのCloverの最新版リビジョンは4674です。古いようでしたらアップデートしておきます。

Kext類のアップデートにはKext Updater.appが便利です。起動すると、Kext Updaterそのものがアップデートされることもあります。最新版kextに関するデータベースが更新されるのだと思いますので、これもやっておきます。

アップデートしたら、もう一度Kext Updaterで最新になっていることを確認しても良いです。ただ、再起動を行わないと、新しいClover, Kextが機能しませんので、再起動してから確認します。

KextをMojaveの場所に複製する

もしKext類をEFI/CLOVER/kexts/10.13/に入れているようでしたら、同じ内容をEFI/CLOVER/kexts/10.14/にもコピーしておきます。これを忘れるとMojaveが起動しません。当たり前のことですがうっかり忘れて慌てた経験が複数回あります。

そういう可能性をなくすために、EFI/CLOVER/kexts/Other/にKextを入れておくのも良いかと思います。CloverはOtherの場所のkextを読み込んだ後で、10.14などの場所のkext類を読み込みます。同じkextがOtherとバージョン番号のフォルダの両方に存在しても、片方しか動かないので問題ありませんが、無駄なのでどちらか片方だけに入れておくのが良いです。

App StoreからMojaveをダウンロードする

App Storeに行くと、今ならバナー広告でmacOS Mojaveが絶賛宣伝中になっている思います。ダウンロードボタンを押してダウンロードします。6.03GBあります。

ダウンロードが終了すると、自動的に起動してインストーラが起動します。これは一旦終了して（しなくても良いですが）、アプリケーションフォルダを見てください。macOS Mojaveインストール.appというアプリケーションがありますので、これをどこかに複製して保存しておきます。バックアップしておかないと、インストール後に消えてしまうことがあります。せっかく時間をかけてダウンロードしたのですから、バックアップしておきましょう。

インストーラを起動する

macOS Mojaveインストール.appを起動すると以下のウィンドウが現れます。

「続ける」をクリックして、あとは指示に従ってどんどんインストールして行くだけです。

インストール途中で再起動する場面があります。この時、「Boot macOS Install from xxxx」という項目が作られていて、それから起動するようになっているはずです。xxxxの部分は、アップデートしようとしているパーティションの名前です。

以上の結果、無事アップデートできました。App Storeからのダウンロードによる上書きアップデートで問題なくMojaveに移行できることが確認できました。

クリーンインストール編

クリーンインストールも試してみました。問題ありません。こちらはタワー型デスクトップのHackintoshで試しました。HDDを多数搭載していて、予備のHDDにもmacOSとCloverがインストールしてあります。

作業の前に、メインのドライブと予備のドライブのESPに入っているCloverとkextを最新版にしておきます。メインのドライブのESPだけを使って以下の作業を行うことは可能ですが、将来、サブのESPを使うことも考えて、ついでにアップデートしておきました。

次に、予備のmacOSで起動して、メインで使っているシステムの入ったパーティションをAPFSでフォーマットしてしまいます。そしてmacOS Mojaveインストール.appを起動し、空になったパーティションにインストールしました。この場合も、インストール途中で1回再起動しますので、Boot macOS Install from …の項目から再起動します。

あと12日！Mojaveの受け入れ準備

Thu, 13 Sep 2018 21:00:00 +0900

Mojaveは9月25日に登場

今朝未明のキーノートは、いつもの秋のイベント同様にiPhoneメインで、ささやかに期待された新型Macの情報は皆無で寂しい限りです。ただ最後の3分を切ったところで、macOS Mojave配布日が発表されました。日本時間で9月25日だそうです。あと12日ですね。それまでのあなたのHackintoshに新バージョンをお迎えする準備をしておきましょう。（去年の状況と同じですね😀あと13日！High Sierraのお迎え準備）

以下はMojaveのベータ版での情報ですが正式版Mojaveでも同様と思われます。

High Sierraからのアップデートは簡単

今現在HackintoshをHigh Sierraで動かしているならアップデートは簡単です。Cloverとkext類を最新にしておけばokです。High Sierraへの移行では、APFS起動に伴いファームウェアアップデートされ、多少の対応が必要でしたが、今回はそれも不要です。

なお、Kext Updater.appを使うと、使用中のkextの最新版をチェックして、ダウンロードしてくれるので楽です。

Mojave移行の注意

Cloverなどを最新版にしておく以外にほとんど問題はないはずです。それでもありえそうな注意事項を列挙して見ます。

kextの格納場所

kextをEFI/CLOVER/kexts/10.13に入れている人は、10.14を新たに作って、全部のkextをコピーしておきます。もしくは、Otherフォルダにコピーしておいても良いです。10.14で起動する場合は、Otherの内容が先に読み込まれ、次に10.14フォルダが読み込まれます。10.13のフォルダの内容は無視されてしまいます。当たり前のことですが、うっかりして失敗した経験が何度かあります。

APFS

High SierraのインストールではAPFSを使わない選択肢がありました。でもMojaveからは必須になったようです。システムドライブをまだHFS+で運用している人は、対応が必要かと思います。ファイルシステムの移行は大事なので、APFS移行でも問題が発生するのではという懸念がありました。しかし、APFS移行問題は、実機でもHackintoshでもほとんど報告されていません。円滑に移行できていると思われます。

High Sierraが出た頃は、macOSからapfs.efiをESPにコピーしていました。その後公開されたApfsDriverLoader-64.efiを入れておけば、macOSに含まれる最新のapfs.efiを使ってくれるようになります。

Clover 4558で登場したApfsDriverLoader.efi

Mojave非対応Mac

公式サイトの情報によるとMojave対応機種は以下です。

MacBook (Early 2015 以降)
MacBook Air (Mid 2012 以降)
MacBook Pro (Mid 2012 以降)
Mac mini (Late 2012 以降)
iMac (Late 2012 以降)
iMac Pro (全モデル)
Mac Pro ( Mid 2010, Mid 2012, Late 2013)

CPU世代でいうとSandybridge以前が非対応になりました。これ以外の機種名をconfig.plistで設定しているHackintoshでは、起動時に禁止マークが出て止まってしまいます。

これを避けるためには、Cloverのブートオプションに

-no_compat_check

を追加します。これで機種チェックを回避できます。例えばconfig.plistに以下のように設定します。

<key>Boot</key>
  <dict>
    <key>Arguments</key>
    <string>-v -no_compat_check</string>

少なくともベータ版では、これでMojaveが起動しました。

Mojave非対応グラフィックス

MojaveからはMetal対応グラフィックスが必須になりました。ただ、今のところは、Metalの機能が無いと全く動かないという状態ではなく、Metal非対応のドライバをmacOSから除外したという状態のようです。なので、古いmacOSからMojaveで削除されたドライバを持って来ればなんとか動くようです。ただ、Metalの機能を使っている部分もあるので、多少の不具合（ぼかしが機能しないなど）はあるようです。

古いグラフィックスドライバを入れたり、また機種名を誤魔化すためのパッチを当てるツールも公開されています。実機向けのツールですが、Hackintoshでも使えると思います。

macOS Mojave Patcher

古いハードウェアがMojaveに対応していないのは実機でも同様のことですので、Hackintoshもハードウェアのアップデートを検討するのが良いと思います。自作機ならアップデートは簡単ですから。

Mojaveへの移行方法

これは実機でも同じですが、新しいOSバージョンへ移行するには、大胆または慎重などの移行方針を選べます。バニラなインストール方法でHackintoshしているなら、実機とほぼ同様の方法でアップデート可能です。

/posts/131/

主ドライブを上書きアップデートする

今動いているHigh SierraからMojaveのアップデータを起動する方法です。実機と同様に、App Storeからダウンロードしたアップデータをそのまま起動すれば、問題なくアップデートされるはずです。Appleお勧めの一番簡単な方法です。ただ、上記で説明したCloverとkext類のアップデートは済ませておきましょう。

別ドライブにインストールする

別ドライブにクリーンインストールする方法です。新OSの動作を確認して、問題がなければ移行しようという慎重な人向けです。自作HackintoshならSSDなどの追加は簡単だと思います。macOSだけならSSDは30GBもあれば十分ですが、現行製品だと120GBか256GBあたりがビット単価からしてお得感があります。直接内蔵しなくても、外付けケースに入れてUSB接続した別ドライブでもokです。

方法は簡単で、今動いているHigh Sierraから別ドライブをフォーマットして、Mojaveのアップデータを起動してインストールすれば良いです。クリーンインストールするために、単体で起動できるUSBメモリを作る方法もありますが、すでに起動できるドライブがあるならその必要はないと思います。インストールの途中で古い環境からの移行をするオプションが現れます。これを使えば、High Sierraでの設定などを移行することも簡単です。

別ドライブにmacOSをインストールしたら、そのドライブのESPにCloverとkext類も入れておきましょう。それで起動できれば、Hackintosh設定で失敗して主ドライブが起動しない時のバックアップになります。

主ドライブにクリーンインストールする

単体で起動できるUSBメモリを作った場合は、主ドライブにクリーンインストールすることもできるでしょう。または、「別ドライブにインストール」した後であれば、それを起動して、主ドライブにクリーンインストールすることもできます。

ユーザデータまでフォーマットすると復帰が大変ですが、/Users以下を別ドライブや別パーティションに入れてあれば、システム部分をフォーマットしてクリーンインストールしてもそれほど手間はかからないと思います。

ESPをマウントしてついでにバックアップする

Sat, 08 Sep 2018 14:23:46 +0900

時々は行ってやらないといけないHackintoshのメンテナンスでは、ESPをマウントする必要があります。またESPのバックアップがあれば、メンテナンスで失敗しても復帰できます。ということで、メンテナンスでESPをマウントするときに、同時にバックアップも行えば、万一メンテナンスで失敗しても、稼働していた最後のESPを取り戻せると考えました。

今までの関連記事

振り返ってみると、ESPをマウントする方法と、ESPをバックアップする方法を色々書いてきました。10.13.6でdiskutil mountコマンドにパスワードが必要になったので、使えなくなった方法もあります。

ESPをマウントするためのシェルスクリプト

ESPを自動バックアップする

10.13.6でESPをマウントする権限が変更される

単にマウントしてバックアップする

今回は、シンプルにマウントしてバックアップするスクリプトを考えました。過去に紹介したスクリプトを足し合わせた内容です。現在はこのスクリプトで、ESPのマウントもバックアップもどちらも行っています。ESPに手を加える直前にバックアップすることになるので、合理的かと思います。

#!/bin/sh
ESPUUID=00000000-0000-0000-0000-000000000000
BACKUP=~/Documents/OSX86/_currentESP/
sudo diskutil mount $ESPUUID
MP=`diskutil info $ESPUUID | grep "Mount Point"`
MP3=`echo $MP |  awk '{print $3}'`
MP4=`echo $MP |  awk '{print $4}'`

if [ -n "$MP4" ]; then
 cd $MP3" "$MP4
 rsync -av --delete $MP3" "$MP4"/" $BACKUP
else
 cd $MP3
 rsync -av --delete $MP3"/" $BACKUP
fi

date > timestamp.txt
cd EFI/CLOVER

過去記事の重複になりますが、各ステップを説明します。

最初に定義した変数、ESPUUIDはESPのUUIDです。例えばESPがdisk0s1に割り当てられた場合、
```
diskutil info disk0s1
```
とすると色々な情報が出てきます。この中に
```
Disk / Partition UUID:  00000000-0000-0000-0000-000000000000
```
というように表示されているのが、ESPのUUIDです。
次に定義した変数、BACKUPはESPの内容をバックアップしたい場所です。最後に/をつけます。これはのちに実行するrsyncコマンドの仕様上、重要です。バックアップ場所としては、iCloudやDropboxなどでクラウドと同期しているディレクトリを指定すると良いと思います。そうしておけば、万一マシンが起動しなくなっても、他のマシンから内容を取り寄せることができます。
diskutil mountの行で、ESPUUIDで指定したESPをマウントします。10.13.6からsuper user権限が必要になったのでsuコマンドをつけています。実行するとパスワードを求められるのでタイプします。
diskutil infoの行で、マウントポイントを得ています。このコマンドでマウントポイントが
```
Mount Point: /Volumes/EFI
```
のように表示されます。この行を取得しています。
次のawkコマンドとif文が続くところで、diskutil infoコマンドで得られる行から、マウントポイントだけを抽出しています。ややこしいですが、マウントポイントは、最初は
```
/Volumes/EFI
```
になるのですが、2個目以降は
```
/Volumes/EFI 1
```
のように、空白＋数字になります。どっちでも対応できるようにif文で対応しています。
cd $MP3″ “$MP4もしくはcd $MP3でESPの場所にカレントディレクトリを移動しています。シェルスクリプトの実行で移動する場合は、このスクリプトに例えばESPBackup.shと名前をつけた場合、
```
. ESPBackup.sh
```
として実行します。.の後には空白を入れます。
rsyncコマンドで、$BACKUPで指定したディレクトリにバックアップしています。更新のあったファイルだけが置き換わります。
dateコマンドでバックアップを取ったタイムスタンプを入れてみました。なくても良いですが、最後にバックアップした時刻がわかるので便利かと思います。
おまけ。本当の最後にCLOVERディレクトリに移動しています。引き続き作業するのに便利かと思いました。

4Kディスプレイを使う

Sun, 19 Aug 2018 18:32:24 +0900

ちかごろ4Kとか8Kとかの高精細な動画やディスプレイが話題です。iMacでも4Kや5Kのディスプレイを搭載して、網膜に匹敵するRetinaディスプレイであることを売りにしています。Hackintoshでも高精細表示はもちろん可能です。今回はHackintoshで4Kディスプレイを使ってみます。実のところ4K, 5Kなんて要らないと思っていましたが、使ってみたら予想以上に快適で手放せません。

ディスプレイの規格・iMacの仕様

現行デジタルテレビ規格ではHDやFull HDが一般的です。このさらに高精細な動画・ディスプレイの規格として、それぞれの面積の4倍、8倍の規格があり、これを表示するためのディスプレイが商品化されています。この一覧でわかるように、なんとかKという表記は、横方向の画素数をキロ単位で表したものです。例えば一般的な4Kディスプレイは3840 x 2160画素です。横方向の画素が大体4,000画素なので4Kと称しています。4,000には足りないのでちょっと詐称かもしれません。

HDは1280 x 720画素 (720p)
2Kは1920 x 1080画素 (Full HD, 1080p)
2.5Kは2560 x 1440画素 (HDの2×2倍)
4Kは3840 x 2160画素 (Ultra HD, Full HDの2×2倍)
5Kは5120 x 2880画素 (HDの4×4倍)
8Kは7680 x 4320画素 (Full HDの4×4倍)

コンピュータ用ディスプレイではFull HDディスプレイが一般的で、お求めやすい価格で多数販売されています。最近では、4Kディスプレイも安くなってきました。一方で我らがiMacではどのような画素数が採用されているかというと、以下のようです。

Retina 5K iMacやiMac Proは27インチ 5120 x 2880画素
Retina 4K iMacは21.5インチで4096 x 2304画素
RetinaではないiMacは21.5インチで1920 x 1080画素

5Kは、720p HDの4×4倍画素のディスプレイです。アップルストアではLG社のLG UltraFine 5K Displayという27インチディスプレイを税別15万円弱で販売していますが、iMacでもおそらく同じパネルを搭載していると思われます。AmazonでLG以外の同等製品を他に探すと、iiyamaのモニタがありました。スペックが似ているのでもしかしたらこれも同じLGのパネルなのかもしれません。価格は8万円台です。

4K iMacは、一般的な4Kディスプレイより画素数が多くて、正しく4Kのようです。あまり見かけない画素数なのですが、これも同じような21.5インチディスプレイがアップルストアで、LG UltraFine 4K Displayとして販売されています。税別8万円弱です。おそらく同じLGパネルがiMacで使用されていると思われます。

4K Displayがおすすめ

Hackintoshで使う高精細度ディスプレイとしてどれを選んだら良いでしょうか。上の調査から、以下の選択肢があると思います。

ほぼ純正のLG UltraFine 5K Display (27インチ)
市販の5K Display (27インチ)
ほぼ純正のLG UltraFine 4K Display (21.5インチ)
市販の4K Display (24, 27, 31.5インチなど機種が豊富)

1.と3.に上げた、ほぼ純正のLG UltraFine Displayは、おそらく品質は良く、またmacOS上で十分にテストされていると思われるので、トラブルも無いでしょう。しかし高価でコストパフォーマンスが悪いです。特に4Kの方は21.6インチなので、24インチくらいのディスプレイに慣れてしまった今時のデスクトップユーザからすると狭いです。この金額を支出するなら、後述する31.5インチ4Kディスプレイを買ったほうが幸福になれます。 2.の市販5K 27インチディスプレイは、選択肢が少ないです。上記のiiyamaの製品はAmazonで買えますが、tonymacx86のBuyer’s Guideで推奨されているDell UP2715Kは品切れです。他のメーカでは相当する5Kディスプレイを販売していません。また5Kディスプレイには、Hackintoshとの互換性の問題もあるようです。例えば以下のスレッドによると、

www.tonymacx86.com

NVIDIAのカードで電源投入時の動作がおかしかったり、マウスポインターが安定しない問題があったようです。macOSがネイティブサポートするRadeon RX 580に交換したところ安定して動くようになったそうです。GPUの選択肢が狭まってしまうのはちょっと嫌です。上記の選択肢の中では、4.の「市販の4K Display」を選ぶのが一番良いと思います。5Kディスプレイに比べて、多数の製品が潤沢に販売されていて、選択肢が多いです。競争があるので価格も手頃で、コストパフォーマンスが良いです。若干の懸念は、純正のiMacでサポートされていない画素数であることですが、ネットの情報では全く問題なく動くようです。こちらのブログの方も、同じような理由で市販のLGの4Kディスプレイを買われたようです。 nop-me.hatenablog.com

選定機種はLGの27インチ

以上のことから、メーカーはLGにしました。iMacで使用されているパネルなので、macOSとの互換性において多少安心できるかと考えました。品数も多く、商品の選択肢も多いです。なかでも27インチは5K iMacと同じサイズで、広くて使いやすい大きさかと思います。amazonで入手できるLGの4K 27インチ現行モデルは、価格の安い順に以下の3機種でした。LGの4Kディスプレイのうちこの３機種だけがHDR対応しているようです。

27UK600-W
27UK650-W
27UK850-W

標準的なモデルは27UK650です。27UK850は、標準モデルに、給電機能を完備したUSB Type-Cポートをつけ、さらにスピーカも搭載したモデルです。MacBookシリーズに接続しつつ充電も行う場合に便利かと思います。一方で、標準モデルから高さ調整機能を省いたのが27UK600のようです。amazon限定モデルです。タイムセールで値引きされていたこともあり、これを購入することにしました。モニターアームを別に購入するつもりでしたので、高さ調節機能がなくても問題ありません。ちなみに本体の重量は実測で4.7kgでした。プラスティックを多用した薄型設計なので、モニターアームへの負担も少ないです。

これ以外のサイズのLG 4Kディスプレイには以下のモデルがあります。上記の27インチモデルに比べて少し古い機種なので、今後HDR対応モデルが出るのかもしれません。24UD58はサイズが小さめですがIPSパネルでお買い得です。32UD59は安いですがVA液晶です。このサイズでIPSの32UD99はそれなりのお値段になりますが、コストパフォーマンスは良いです。

24UD58-B (24インチ)
32UD59-B (31.5インチ)
32UD99-W (31.5インチ)

Hackintoshに接続する

ということで今回は、LG 4Kディスプレイ、27UK600を調達しました。でもせっかく4Kディスプレイを買っても、グラフィックスチップとそのドライバが4K解像度をサポートしていないと意味がありません。

4Kをサポートしていない場合

LG 4Kディスプレイ、27UK600の解像度は3840 x 2160画素です。この解像度に対応していないグラフィックスのマシンに接続すると、4K未満のディスプレイと見なされてしまいます。例えば、Intel HD Graphics 4000を搭載したIvy Bridge NUCにHDMIで接続すると以下のようになります。

Intel HD Graphics 4000は、Mac mini (Late 2012)で使用されています。このMac miniの仕様を見ると、サポートされている解像度は、HDMI接続で1920×1200だそうです。せっかくの4KディスプレイがただのFull HDディスプレイになってしまうのも仕方ないところです。このディスプレイを今度は、デスクトップ用Haswell CPUを使用したHackintoshのマザーボードにあるDisplay Port端子に接続してみました。デスクトップ用Haswell CPUに内蔵されているGPUはIntel HD Graphics 4600です。この場合も4K解像度の3840 x 2160画素表示はできませんでした。最大で2560×1440画素です。

デスクトップ用Haswell CPUを採用したMacはありますが (iMac Late 2014など)、RadeonなどのGPUを別途搭載していて、内蔵GPUであるIntel HD Graphics 4600は表示に使用されていません。でもmacOS搭載のドライバでIntel HD Graphics 4600を使用して表示することが可能です。システム情報–>拡張機能を見ると使用されているドライバがわかります。これによると、

AppleIntelHD5000Graphics.kextが使用されていることがわかります。Intel HD Graphics 5000は、モバイル用Haswell 4260Uなどに採用されているGPUです。同世代なので互換性があるようです。Intel HD Graphics 5000を搭載したiMac (21.5-inch, Mid 2014)の仕様を見ると、最大サポート画素数は2560×1600画素です。使用しているグラフィックスドライバが4Kをサポートしていないので、4Kの解像度が出ないわけです。

4Kをサポートしている場合

一方、4Kの解像度に対応したグラフィックスカード搭載Hackintoshに接続するとRetinaディスプレイとしての解像度選択肢が現れます。以下は、AMD Radeon RX 580に接続した例です。NVIDIAのグラフィックスカードに接続しても同様にRetinaディスプレイとして扱われます。

Retinaディスプレイとして認識されると、解像度の選択が画素数ではなくて、文字・スペースの拡大になります。文字を一番小さく・スペースを一番拡大する右端の選択肢を選ぶと、「擬似解像度」の表示が3840 x 2160になり、画面の解像度と同じになります。この状態では、画面表示の1画素が、ディスプレイの1画素に対応します。なので、メニューやテキストの表示が非常に小さくなります。

一方で文字を一番大きく・スペースを一番縮小する左端の選択肢を選ぶと、「擬似解像度」の表示が1920 x 1080になります。この状態では、画面全体が1920 x 1080画素のディスプレイとしてOSから認識されています。メニューや文字は、27インチのFull HDディスプレイに接続した時と同じ大きさで表示されます。実際にはOSが認識している1画素は、ディスプレイ上で2 x 2画素で構成されています。OSの描画ライブラリは、文字や線の描画を通常の倍の解像度で美しく表示できます。この仕組みはアプリケーションから隠されたOSの奥深い場所で行なっているため、アプリケーションからは通常のFull HD座標系に書き込んでいるつもりでも、自動的に高精細に表示されます。それが「擬似解像度」の意味するところです。

「システム情報」を見ると、ディスプレイが60Hz 4K表示されていて、「UI擬似解像度」が1920 x 1080であることがわかります。

ちなみに、UI擬似解像度と実際の解像度の比率を、整数倍ではなく、中途半端な値にすることも可能です。例えば以下の設定では、画面上の3840画素を3008画素の擬似解像度として使っています。

この場合、擬似解像度から実際の解像度への変換が整数倍ではなくなるので、処理に時間がかかる可能性があるようです。「パフォーマンスに影響する場合があります。」との表示が出ます。ただ、実際に使ってみても、表示が遅くなるような印象はありませんでした。

4Kは美しい

当初はここまでの解像度は不要なのではと懐疑的でしたが、使ってみると意外と差があり、4Kディスプレイから普通のディスプレイには戻れなくなってしまいました。小さな文字の表示では特に顕著です。例えば、電源投入直後に、「再起動後にはApple Watchではロック解除できず、パスワードの入力が必要になる」という内容のメッセージがログイン画面に現れますが、この表示を4K画素と通常画素で比べると以下のようになります。

また、先のディスプレイ設定画面でも、4K画素と通常画素では表示が変わることがわかります。その様子をGIFアニメにしてみました。

GIFに変換したので色がおかしいところがありますがそこはご容赦を。ちなみに文字のサンプルとして書かれている文章は、AppleのThink Different広告キャンペーンで使われた文らしいです。

Think different – Wikipedia

GPU関連kextがWhateverGreen.kext 1.2.0に統合されました

Sun, 05 Aug 2018 17:09:01 +0900

WhateverGreen.kext 1.2.0

GPU関連のkextである

IntelGraphicsFixup
NvidiaGraphicsFixup
Shiki

は、WhateverGreen.kextに統合されました。これからは、GPUがNVIDIAでも、Intelでも、AMD Radeonでも、WhateverGreenだけを使うのが正しいやり方のようです。

https://www.insanelymac.com/forum/topic/325987-whatevergreen-support-topic/?page=20&tab=comments#comment-2625396

の2018年7月12日の投稿によると、

IntelGraphicsFixup, NvidiaGraphicsFixup, Shikiは公式に開発中止になり、WhateverGreenの一部になりました。新しいWhateverGreenにより、インストールが簡単になるだけでなく、互換性と全体としての性能が向上します。

とのことです。

WhateverGreen.kextは元々はAMD RadeonのGPUを動かすためのパッチを提供していて、Radeon RX 570/580などをmacOSで動かすために必要でした。しかし、10.13.4から最新のRadeonがmacOSでネイティブにサポートされるようになり、不要になっていました。今回の統合で、GPU関係はWhateverGreen.kextを入れておけば解決という便利な状態になったと思います。ちなみに、Nvidiaも（Radeonを作っていてAMDに買収された）旧ATIもロゴが緑色なので、どちらの緑にも対応という名前は合っているのではないかと思います。

こちらで紹介したKext Updaterを動かしてみたら、

IntelGraphicsFixup.kextはもう使うのをやめて、WhateverGreen.kextを使いましょうというメッセージが出るようになりました。

ちなみにWhateverGreenは、今回廃止されたkextと同様に、Lilu.kextと一緒に使う必要があります。

/posts/118/

ワンクリックで最新kextに〜Kext Updater.app (Ver. 2)

Sat, 21 Jul 2018 00:30:00 +0900

Kext Updater

古いバージョンの記事です。新しいバージョンに関しては以下をご覧ください。

Boot macOS

Hackintoshで使っているClover, EFIドライバ、kext類は、最新版を使うのが良いです。色々なバグが直されていて、安定しています。また常に最新にしておけば、macOSのバージョンアップにも対応できます。Mojaveに備えていつも最新状態にしておきたいものです。ただ、開発者の方々のページを巡回して最新版をチェックするのも大変です。

Hackintoshで使用中のkext類最新版をチェックして、新バージョンがあった場合にダウンロードしてくれる便利なツールがあります。ドイツのHackintoshフォーラムの人たちが作ってくれているKext Updaterです。以下でソースが公開されています。

コンパイル済みの最新版はこちらからダウンロードできます。

早速起動してみます。ラジオボタンがいくつかありますが、メインの機能は「Check for Updates」のボタンです。これを選択して、「Start」ボタンを押します。すると左のメッセージエリアに以下のような表示が出ます。

使用されているHackintoshのkextを全部調べ上げてくれて、それが最新版であるかどうか判断してくれます。ここではNvidiaGraphicsFixup.kextが最新版より一つ前のバージョンでした。そこで、これが自動的にダウンロードされて、デフォルトでは、デスクトップのKext-Updatesという名前のフォルダに入ります。このフォルダは「Open」ボタンで開けられます。そこで、必要ならば「Mount EFI」ボタンを押してESPをマウントして、ダウンロードした最新版と入れ替えます。

他にもラジオボタンから

基本的なkextをKext-Updatesフォルダにダウンロードする（右のメニューで種類を選べます）
一つのkextをダウンロードする（右のメニューでkextを選べます）
NVIDIA Webドライバをダウンロードする（右のメニューでバージョンを選べます）
Clover最新版をダウンロードする（Nightly Buildにチェックを入れると非公開最新版をダウンロードできます）

このツールにより、最新版をチェックして差し替える作業が大幅に楽になります。

Intel UHD Graphics 630用純正グラフィックスドライバ

Wed, 18 Jul 2018 23:48:53 +0900

先日発売された新MacBook Proには、Coffee Lake-S CPUがいよいよ搭載されました。新製品に搭載された5種類のCPUと内蔵グラフィックスは以下のとおりです。

Intel Core i9-8950HK 2.9 GHz (6 cores) Intel UHD Graphics 630
Intel Core i7-8850H 2.6 GHz (6 cores) Intel UHD Graphics 630
Intel Core i7-8750H 2.2 GHz (6 cores) Intel UHD Graphics 630
Intel Core i7-8559U 2.7 GHz (4 cores) Intel Iris Plus Graphics 655
Intel Core i5-8259U 2.3 GHz (4 cores) Intel Iris Plus Graphics 655

上の3機種が15インチモデル、下の2機種が13インチモデルです。15インチモデル搭載の内蔵グラフィックスには、デスクトップCPUのCoffee Lake-Sシリーズと同じIntel UHD Graphics 630が搭載されています。この新MacBook Proのグラフィックスドライバを入手すれば、8700K自作Hackintoshが安定して、そのグラフィックス性能を引き出せると思われます。

新機種で追加されたハードウェアのドライバを一般のmacOSユーザが入手できる時期は、通常、新機種が出た次のmacOSアップデートになります。今回の新MacBook Pro発表は、macOS 10.13.6が配布された直後なので、アップデートのタイミングを考えると、9月のMojaveでようやく入手できるかと思われます。なのでしばらくは入手不可能なのではと考えていました。ところが5chでこんな情報を教えてもらいました。tonymacx86のスレッドです。

www.tonymacx86.com

リカバリーパーティションで起動して入手する

新MacBook Proに搭載されているのは、App StoreからアップデートできるmacOSと同じ10.13.6です。しかし、App Storeで配布されているのはBuild 17G65なのに対して、新製品にインストールされているBuildは17G2112だそうです。そして、17G2112にしかIntel UHD Graphics 630のドライバは含まれていないようです。

ところが以下の手順で、最新Buildを入手できるそうです。

SMBIOSの設定でHackintoshの機種を新製品に偽装する。15インチモデルはMacBookPro15,215,1で13インチがMacBookPro15,2です。macosx86の人はMacBookPro15,2を使ったようです。
Clover r4651+をhttps://github.com/Dids/clover-builder/releasesから入手して使います。MacBookPro15,1, 15,2のSMBIOS情報が含まれているそうです。（config.plistに書かない情報などを補完してくれるのだと思われます）
リカバリーパーティションで起動します。するとApple社のサーバからmacOSをダウンロードしてインストールできるそうです。

ちなみにUHDグラフィックスドライバは、AppleIntelCFLGraphicsFramebuffer.kextだそうです。

Mojaveまで待てば良いけど

とはいえ9月に出ると思われるMojaveまで待てば、グラフィックスドライバは苦労をしなくても入手できます。また、Mojave Dev Beta 4から、このドライバが含まれているそうです。なので、本日出たMojave Public Beata 3にも、新ドライバが含まれているはずです。Mojaveは安定しているので、さっさとBetaに移行しても良いかもしれません。ただ、Coffee Lake-S自作Hackintoshをしている人が、High Sierraを使いたいと希望する場合には、この方法が良いかと思います。

Mojaveで消えたkext、増えたkext

Wed, 18 Jul 2018 00:30:00 +0900

High SierraとMojaveで/System/Library/Extensions (/S/L/E) の中に含まれるkext類がどう違うのか、調べてみました。

High Sierra 10.13.6をクリーンインストールして、MojaveのPublic Beta 1と比較しました。/S/L/Eの内容をlsしてdiffで比較しました。High Sierra, Mojaveの順にdiff引数を指定したので、行頭に<がついているのがHigh Sierraにのみ存在するkext、行頭に>がついているのがMojaveにのみ存在するkextになります。

消えたkext

High SierraにあったけどMojaveでは消えてしまったkext（アルファベット順）は、以下です。

$ diff HighSierra.text Mojave.text | grep "<"
< AMD2400Controller.kext
< AMD2600Controller.kext
< AMD3800Controller.kext
< AMD4600Controller.kext
< AMD4800Controller.kext
< AMD5000Controller.kext
< AMD6000Controller.kext
< AMDLegacyFramebuffer.kext
< AMDLegacySupport.kext
< AMDRadeonX3000.kext
< AMDRadeonX3000GLDriver.bundle
< ATIRadeonX2000.kext
< ATIRadeonX2000GA.plugin
< ATIRadeonX2000GLDriver.bundle
< ATIRadeonX2000VADriver.bundle
< AppleIntelHD3000Graphics.kext
< AppleIntelHD3000GraphicsGA.plugin
< AppleIntelHD3000GraphicsGLDriver.bundle
< AppleIntelHD3000GraphicsVADriver.bundle
< AppleIntelHDGraphics.kext
< AppleIntelHDGraphicsFB.kext
< AppleIntelHDGraphicsGA.plugin
< AppleIntelHDGraphicsGLDriver.bundle
< AppleIntelHDGraphicsVADriver.bundle
< AppleIntelSNBGraphicsFB.kext
< AppleIntelSNBVA.bundle
< AppleTyMCEDriver.kext
< GeForceGA.bundle
< GeForceTesla.kext
< GeForceTeslaGLDriver.bundle
< GeForceTeslaVADriver.bundle
< NVDANV50HalTesla.kext
< NVDAResmanTesla.kext

最初の方を見ると、AMDの古いドライバがいくつか削除されたようです。Metalに対応していないグラフィックスカードのドライバと思われます。2400, 2600は2007-2008年代のiMacに搭載されたグラフィックスだと思われます。4600, 4800, 5000, 6000は、おそらくiMacや昔のタワー型Mac Proに搭載されたHD 4000/5000/6000シリーズに対応するドライバだと思われます。ただAMDRadeonX4000,5000,6000.kextはMojaveにも存在しているので、HD 4000/5000/6000シリーズはまだ使えるのかもしれません。

タワー型Mac ProにはPCIeスロットがありますが、Mac用のBIOSを搭載したカードでない場合には、起動時の表示が出ません。なので古いMac Proユーザはいまだに古いカードを使っていることも多いのですが、Mojaveでは使えなくなったようです。Hackintoshしている人がこのような古いAMDカードを使っていることは稀だと思いますので、影響は少ないと思われます。

次に、Intel HD Graphics 3000シリーズのドライバと思われるApple Intel HD3000 Graphicsで始まるkext類が削除されています。3000の前には、無印のIntel HD Graphicsという規格がありましたが、Mac製品には搭載されていません。なので、AppleIntelHDGraphicsで始まるkext類も同じく3000シリーズのものと思われます。また、AppleIntelSNBGraphicsで始まるkext類は、検索してみたら、SNBがSaNdy Bridgeの略だそうで、これも3000シリーズのものです。3000シリーズがMetal対応から外されたので、Sandy Bridgeを使っているHackintoshは、PCIeグラフィックスカードを利用するか、CPU/マザーボードアップグレードを検討すべきでしょう。

また、GeForceで始まるkext類も一部削除されています。Mojave対応機種がiMacではLate 2012だそうです。グラフィックスチップは、GT 640M, 650M, 660M, 675MX, 680MXのあたりなら対応しているようです。それ以前のGeForceのドライバが外されたのかもしれません。

グラフィックスドライバ以外では、AppleTyMCEDriver.kextが外されています。検索して見ると、これは ECCメモリに関連する何かのようです。

登場したkext

HighSierraには無くて、Mojaveで新しく登場したkextは以下の5個でした。よくわかりません、すみません。

$ diff HighSierra.text Mojave.text | grep ">"
> AMDRadeonX6000HWServices.kext
> AppleUSBCHCOM.kext
> AppleUSBPLCOM.kext
> AppleUSBRealtek8153Patcher.kext
> CoreTrust.kext

ちなみにRealtek 8153というのはUSB 3.0 – ギガビットEthernetのチップのようです。こんな製品で使われているようです。Appleブランドにはこのようなアダプタが無いので謎です。

/L/Eに置かれたkext

/Library/Extensionsに置かれたkextに変更はありませんでした。

ちなみに以下のkextが/L/Eに置かれています。CalDigitというのはThunderbolt接続周辺機器を作っている会社のようです。HighPointはRocketなんとかシリーズでPCIeスロット搭載RAIDアダプタなどを作っていますね。ATTOはネットワークカードなどを作っていて、Celerityは光ファイバーカードのようです。

ACS6x.kext
ATTOCelerityFC8.kext
ATTOExpressSASHBA2.kext
ATTOExpressSASRAID2.kext
ArcMSR.kext
CalDigitHDProDrv.kext
HighPointIOP.kext
HighPointRR.kext
PromiseSTEX.kext
SoftRAID.kext

Cloverで使うEFIドライバ

Sun, 15 Jul 2018 00:13:48 +0900

（古い情報です。最新情報はこちらをご覧ください。）

CLOVER 4988 でEFIドライバ関連が変更されました

—————

最近のClover*1でEFIドライバ類が色々と変更されている様です。気づいたところをメモしておきます。

64bit移行のためと思われる名称変更

EFIドライバフォルダ名

だいぶまえにdrivers32というフォルダがなくなってdrivers64だけになっていたと思うのですが、最近ではdrivers64UEFIになったようです。新規にインストールするとこれだけになります。drivers64は空になる事もあります。drivers64は手作業で消してしまっても良いようです。

また、Cloverのインストーラは、現在インストールされているドライバを見てチェックマークを更新しているわけでは無いようです。前回、インストールしたログを見て、その記録から更新するドライバを選んでいます。なので、手作業でインストールしたドライバは反映されていません。時々は、インストールされたドライバと照らし合わせて、更新リストに入っているかどうか確認した方が良いかと思います。

末尾が-64のドライバ

最近、全てのドライバのファイル名末尾に-64が付きました。64bitであることを明白にするためなのかと思います。同名のドライバで、末尾が-64で無いバージョンのドライバがESPに入っていると、アップデートで置き換えられない（両方が残ってしまう）ことがありますので、手作業で削除しておきましょう。

（更新：Clover 4988から64の名前が外されました。全て64ビットのみになったためと思われます。2019/7/13）

デフォルトのEFIドライバ

デフォルトでインストールされるEFIドライバは、インストーラで表示されなかったと思うのですが、最近では全部表示されるようになっています。以下の８個がデフォルトでインストールされる設定になっているようです。

デフォルトで選択されているので重要なドライバだとは思います。そのうち調べて、機能をメモしていきたいと思います。

一部はこちらを参考にしました。

github.com

AppleImageCodec/AppleKeyAggregator/AppleUITheme は、FileVault 2 のサポートのために必要なファイルです。FileVault 2のフル機能を使うためには、UsbKbDxe/AptioInputFix/AptioHashServiceFixなども必要です。
DataHubDxe はEFI_DATA_HUB_PROTOCOLを実装します。これはboot.efiが必要とします。これは消してしまっても大丈夫です。というのはほとんどのfirmwareはすでにこのプロトコルを実装しているからです（と書いてありますがすみません、意味がわかりませんでした。ここでのfirmwareというのはboot.efiなどのことを指しているのかな？）
FirmwareVolume はFileVault 2でAppleカーソルイメージを機能させます。
FSInject は、kextを機能させるために必要です。
SMCHelper は、APPLE_SMC_IO_PROTOCOLの実装を追加します。boot.efiが文句を言うのを防ぎます。多分boot.efiがSystem Management Controllerとやり取りできるよう、そのプロトコルを実装しているのだと思います。
VBoxHfs-64は、HFS+をアクセスするためのオープンソースのドライバです。起動ボリュームがHFS+でフォーマットされている場合に、これを使ってブートローダにアクセスします。

ということで、FileVault 2を使用しないのであれば、最初の5個は不要のようです。最低限必要なのは、後半の3個のみということかと思います。

オプションのドライバ

次に、デフォルトでは選択されていないドライバをチェックしていきます。

メモリ確保のドライバ

こちらの説明で、

Cloverインストーラの設定

以下のドライバの役割と、推奨順番を説明しました。推奨順番はこの順番です。

AptioMemoryFix.efi
OsxAptioFix3Drv-64.efi
OsxAptioFix2Drv-64.efi
OsxAptioFixDrv-64.efi
OsxLowMemFixDrv-64.efi

用意されているドライバが、最近では以下に変わっている様です。

AptioMemoryFix-64.efi
OsxAptioFix2Drv-64.efi
OsxAptioFixDrv-64.efi
OsxLowMemFixDrv-64.efi

~~AptioMemoryFixに-64が付いて、3Drvは無くなったようです。理由は不明です。今後、アップデートされないので3Drvは使わない方が良いかもしれません。~~（更新：最新バージョンでは3Drvが復活しています。何れにしても最新のCloverインストーラの選択肢に従うのが良いです。）また、上記のいずれもダメな場合は、 OsxAptioFix2Drv-free2000.efi を試すと良いです。これは最強な感じです。

これらのドライバが働かない場合、Clover選択画面の直後で起動が停止します。-vオプションで、メモリがallocateできないという様なメッセージが出ていたら、このドライバを差し替えてみてください。メモリのallocateはいろんな条件で失敗する様です。kextを入れ替える事で失敗が発生する事もあります。また、大抵は成功するものの、数回に１度ランダムにallocate失敗する事もあります。

ApfsDriverLoader.efi

前に紹介しましたように、apfs.efiをmacOS本体からロードしてくれるドライバがr4558から登場しました。これがあればapfs.efiを本体から持ってくる必要はありません。ただ、環境によっては失敗する事も稀にあるようですので、apfs.efiを手作業でコピーしておいた方が良い事もあります。今後改良されるのだとは思います。

Clover 4558で登場したApfsDriverLoader.efi

その他のドライバ

ApfsDriverLoader-64もそうですが、最近のインストーラで選択できるドライバが増えている気がします。よくわからないファイルもありますが、今後、検索して機能が判明したらまた紹介していきたいと思います。

AptioMemoryFix / OsxAptioFix2Drv / OsxAptioFixDrv / OsxLowMemFixDrvは上で説明したメモリ確保のドライバです。
CsmVideoDxe Cloverが動作している時のビデオ表示のためのドライバだったと思います。これを使うと高解像度で表示できるとか。効果のほどはわかりません、すみません。
EmuVariableUefi はNVRAMの機能をソフト的にエミュレートするドライバです。NVRAMは全てのマザーボードが持っていて、OS起動のためのパラメタなどを保持するのに使われているのですが、Hackintoshと相性が悪くてmacOSから読み込めないマザーボードもあるようです。NVRAMが正しく保存、読み込みできないマザーボードの場合はこれを使います。例えば、NVIDIAのドライバを使うかどうかの設定が保持されない場合などこれが必須です。
EnglishDxe UEFI shellで文字表示するために、一部のマザーボードで必要らしいです。
Fat 不明です。調べて見つかったら加筆します。
HashServiceFix もFileVault 2のために必要なようです。HDPIカーソルの問題を修正するのだそうです。よくわかりません、すみません。
NvmExpressDxe NVMeプロトコルのSSDをサポートします。これがあれば、NVMe SSDにブートローダが入っていても読み込むことができます。現在のマザーボードはその機能をEFIに持っているので不要です。古いマザーボードや、古いタワー型Mac Proなどではこれを使うとNMVe SSDから起動できるようになります。
OsxFatBinaryDrv はFAT EFIバイナリのサポートを追加しますが、今は不要です。古いバージョンのmacOSはFATのboot.efiを持っていました。消してしまっても構いません。
PartitionDxe は、論理BlockIOデバイスをサポートします。現在は El Torito CD-ROM, 古いMBR, GPTパーティションがサポートされています。一部のBIOSで必要です。
Ps2MouseDxe PS2接続のマウスを読み取れるようにします。ノートPCなどのポインティングデバイスがPS2接続のこともあります。その場合には必要です。
UsbKbDxe / UsbMouseDxe USBキーボード/マウスを使えるようにするのだと思います。普通のマザーボードは使えるので不要だと思いますが、FileVault 2では必要になるようです。
VBoxExt2 / VBoxExt4 / VBoxIso9660 名前からして、Ext2, Ex4, ISO9660のファイルシステムにアクセスするためのドライバだと思われます。DVDから起動するにはVBoxIso9660が必要ということかなと想像します。

EFIドライバを整理してみる

こうして見ると、結構不要なEFIドライバも多いようです。特にFileVault 2を使わないなら、かなりのドライバを省いても良いことになりそうです。今、このマシンのESPのdrivers64UEFIの中に入れてあるEFIドライバは、以下の10個です。

ApfsDriverLoader-64.efi
AppleImageCodec-64.efi
AppleKeyAggregator-64.efi
AppleUITheme-64.efi
AptioMemoryFix-64.efi
DataHubDxe-64.efi
FirmwareVolume-64.efi
FSInject-64.efi
SMCHelper-64.efi
VBoxHfs-64.efi

上の情報によると、FileVault 2を使わないならば、以下の5個は不要のようです。

AppleImageCodec-64.efi
AppleKeyAggregator-64.efi
AppleUITheme-64.efi
DataHubDxe-64.efi
FirmwareVolume-64.efi

FileVault 2は使っていませんので、これらを除いて起動を試しました。なんの問題もなく起動しました。使っているのは以下の5個です。

ApfsDriverLoader-64.efi
AptioMemoryFix-64.efi
FSInject-64.efi
SMCHelper-64.efi
VBoxHfs-64.efi

かなりシンプルになりました。

*1:執筆時点のv2.4k r4586より少し前くらい

10.13.6でESPをマウントする権限が変更される

Tue, 10 Jul 2018 21:37:37 +0900

更新：古い情報です。こちらの方法が良いと思います。(2018/9/8)

昨夜、おそらく最後のHigh Sierraになる10.13.6が配布されました。すでに配布されているMojave Public Betaを使っていて気づいた変更点が、早々と10.13.6で導入されていました。大したことではないのですが、ESPパーティションをdiskutil mountコマンドでマウントする場合に管理者権限のパスワードが必要になりました。例えば、今までは、disk0s1にあるESPは、diskutil mount /dev/disk0s1 でマウントすることができました。しかし10.13.6で同じコマンドを実行すると、

$ diskutil mount /dev/disk0s1
Volume on disk1s1 failed to mount
If the volume is damaged, try the "readOnly" option

のようにエラーが出てしまいます。readOnlyでマウントしても同様です。

$ sudo diskutil mount /dev/disk0s1

として、この後、パスワードを入力する必要があります。

ESPをマウントするためのシェルスクリプト（改訂版）

以前、ESPをマウントするためのシェルスクリプトを紹介しました。

ESPをマウントするためのシェルスクリプト

上記で紹介したスクリプトのdiskutil mountの行を、sudoで実行するように以下のように変更する必要があります。

sudo diskutil mount /dev/disk${DRIVE}s1

ESPを自動バックアップする方法（改訂版）

やはり、以前、ESPを自動でバックアップする方法を紹介しました。これも、パスワードが必要になったことで対応する必要があります。

ESPを自動バックアップする

この方式は、ログインするときにAutometorで作ったアプリケーションを起動する方法でした。これもパスワードに対応していないので、動かなくなってしまいました。パスワードを求めるように変更するのも良いのですが、いちいち、ログインするごとに、パスワードを入力するのは面倒です。

そこで、macOSが起動した直後に、root権限でESPをバックアップする方法に変更することにしました。Launchd (ローンチデーモン)を使います。

Launchdを使う

以下のサイトなどでLaunchdの説明がされています。

qiita.com

コンピュータが起動したときに特定のプログラムを自動的に実行させる仕組みに、Linuxだとrcスクリプトがあります。大昔のDOSにはautoexec.batというのがありました。また、UNIX系OSでは、ある時間になったら特定のプログラムを自動的に実行させる仕組みにcronがあります。

このような仕組みを実現するために、macOSにはLaunchdがあります。これでrcスクリプトとcronの両方の機能を実現しています。ちなみに、cronはmacOSにも搭載されています。特定日時、時間、時間間隔でプログラムを実行させたい場合には、Launchdの他にcronも使うことができます。

Launchdでは、動かそうとするプログラム1つに対して、設定ファイルを1個用意します。これは、 launchd.plist と呼ばれる各種 XML ファイルです。以下に説明がありました。

ka-zoo.net

launchd.plistは、以下のいずれかの場所に置きます。

/System/Library/LaunchAgents/
/System/Library/LaunchDaemons/
/Library/LaunchAgents/
/Library/LaunchDaemons/
~/Library/LaunchAgents/

/System以下はmacOSが必要とするサーバなどのプログラムを置く場所であり、触らない方が良いでしょう。そもそもSIPで保護されているので簡単には変更できません。

なので、自作プログラムの設定ファイルを置くとしたら、/LIbrary以下か、もしくは~/Library以下になります。LaunchAgentsとLaunchDaemonsフォルダの違いは次のようです。

LaunchDaemonsフォルダに設定ファイルを置くプログラムは、サーバや常駐プログラムのようなデーモンであり、これはroot権限で機能します。
LaunchAgentsフォルダに設定ファイルを置くプログラムは、ログインしたユーザごとに、ユーザの権限で起動されます。/Library/LaunchAgents/には、全ユーザ共通で起動したいプログラムを、~/Library/LaunchAgents/には、特定ユーザのみで動作するプログラムの情報を書きます。

launchd.plistを作る

今回のESPバックアッププログラムは、macOSが起動した時点で、root権限で一回だけ起動させたいと考えました。root権限で起動すれば、diskutil mountでのパスワード入力も不要なはずです。ということで、/Library/LaunchDaemons/に設定ファイルを入れることにしました。

そこで、以下のようなXMLファイルを作成して、/Library/LaunchDaemons/に置きます。このディレクトリにはすでに他のplistファイルが置かれているかもしれません。それを参考にしても良いです。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
<string>com.bootmacos.ESPbackup</string>
        <key>Program</key>
        <string> /Users/bootmacos/Documents/Hackintosh/backup_scripts/ESPBackupZ97A.command
        </string>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

このplistにはいくつかのキーを設定できますが、今回は、最小限の3個だけ使いました。

Labelはこのプログラムを特定するための名前です。名前の作り方は全く自由ですが、他のファイルの例を見ると、開発者のURLを逆に書くことで、特定が簡単になる工夫をしているようです。それに倣って、このブログのURLに機能名を加えて命名しました。
Programキーは、プログラムの場所です。ここはフルパスで書いておきます。起動時にはパスが張られていない可能性がありますので、エラーを引き起こさないために全部書いて置くのが良いです。
RunAtLoadは、Launchdがこのプログラムをロードしたときに実行するかどうかを決めます。

この他、常駐させるかどうかのキーもありますが、デフォルトで常駐しない設定なので、省略しました。この内容を、

$ cd /Library/LaunchDaemons/
$ sudo vi com.bootmacos.ESPbackup.plist

として、/Library/LaunchDaemons/以下に作ります。ファイルの名前も自由なのですが、これも特定しやすいように、URLを逆にして命名するのが一般的のようです。

バックアップスクリプトを用意する

次に、実際にESPのバックアップを行うスクリプトを作成します。保存場所と名前は、上で作成したlaunchd.plistの内容に合わせます。スクリプトの内容は、Automatorで使ったものとほぼ同じです。パーティションUUIDの探し方は、以前の記事をみてください。

#!/bin/sh
ESPUUID=00000000-0000-0000-0000-000000000000
BACKUP=/Users/bootmacos/Documents/Hackintosh/currentConfig/MSIZ97AG7/
diskutil unmount $ESPUUID
diskutil mount $ESPUUID
rsync -av --delete --exclude '.*' /Volumes/EFI/ $BACKUP
diskutil unmount $ESPUUID

最初のdiskutil unmountのコマンドは本来なら不要です。ただ、これが無い状態では、次のdiskutil mountコマンドがtimed outというエラーを表示して、うまく動作しないことがありました。ネット上で調べたら念のためにunmountしておくとエラーが出ないとあり、それを真似ました。快調に動いています。

また、rsyncのパラメータに–excludeを追加しました。ピリオドで始まる隠しディレクトリは不要なので、バックアップから外しました。

ここでは、root権限で起動するのでsudoをしていません。これでパスワードの入力をすることなく、ESPパーティションをマウントして、バックアップできるようになりました。

完成したら実行可能に設定しておきます。

$ chmod a+x ESPBackupZ97A.command

Launchd.plistの内容

今回、以下のディレクトリを見たところ、意外なファイルが入っていました。

/Library/LaunchDaemons/
/Library/LaunchAgents/
~/Library/LaunchAgents/

すでに使っていないドライバやアプリに関するplistや、心当たりがあまり無いplistなどです。macOSをクリーンインストールすると、これらのディレクトリは全て空です。なので、何かが入っているとしたら、アプリケーションのインストーラなどにより後から入れられたものです。特に、/Library/LaunchDaemons/はマシンが起動したら必ず起動して、しかもroot権限で動くプログラムです。時々はチェックして、起動するプログラムを把握して、おかしな設定が残っていたら削除するのが良いかと思います。

もうmacOSベータ版は要らないと思ったあなたに

Fri, 06 Jul 2018 00:30:00 +0900

Public Betaが出たのでMojaveを試してみたけど問題なく動いたのでひとまず安心。新機能も気に入ったけど、日常的に使うのは、9月の正式発表の時まで楽しみに待っていても良いかな。と、思ったあなた。例年ですとこの後、数回のアップデートが配信されるはずです。さらにはMojave体験希望者にはもれなく10.13.6 Public Betaも配信されています。

正式版になってから受け取りたい、もうベータ版は要らないと思ったのに、アップデートはどんどんやってきます。他のアップデートと混じってわかりにくいです。うっかりクリックしたらインストールが始まってしまいます。そこで今回はmacOSベータ版の配信を止める方法の紹介です。

そもそもなぜベータ版が来るようになったのか

もちろん私がお願いしたからです。Public Beta参加のページからmacOSPublicBetaAccessUtilityというパッケージをダウンロードして、これをインストールしました。

すると、すぐにApp Storeが開いて、Mojaveがインストールできるようになったのです。その後、アップデートも送られるようになりました。

App Storeの環境設定で止める

ベータ版の配信を止めるメニューはApp Storeの「環境設定…」の中にあります。ここに、「お使いのコンピュータは、ベータ・ソフトウェア・アップデートを受信するように設定されています」という項目があります。この右にある「変更…」のボタンを押すと、「App Storeでベータ・ソフトウェア・アップデートを表示するのを停止しますか？」というダイアログが出ます。ここで「ベータ・ソフトウェア・アップデートを表示しない」ボタンを押せば、アップデートが来ても表示されなくなります。

ただしこの作業をしてしまうと、ベータ・ソフトウェア・アップデートに関するメニューは現れなくなってしまいます。配信中止ボタンを押したら後戻りはできません。再び配信して欲しいと思う場合は、もう一度macOSPublicBetaAccessUtilityを起動して、配信を開始してもらう事になります。

Hackintosh英和辞典

Wed, 23 May 2018 00:30:00 +0900

Hackintoshの情報は海外のサイトやフォーラムに多く掲載されていて、英語で読んだり質問する必要があります。そこで、Hackintosh関連でよく使われる英語表現をいくつかご紹介します。他にもたくさんあると思いますので、気づいたら追加して行きたいと思います。みなさんからの情報もお待ちしています。では辞典っぽくアルファベット順で：

artifact

もとの意味は人工物ということですが、コンピュータ関連の文脈では、画面・画像に現われる人工的な乱れやノイズを指します。自然な画像ではない、人工物的で無機質で異様な物体というニュアンスだと思います。プログラムやグラフィックスドライバの不具合で、ランダムなパターンが表示されてしまうことがあります。例えば、画面表示用に割り当てられたメモリーの一部に、プログラムの不具合で画像とは関係ないデータを書き込んでしまったりするとそのような症状が出ます。そのような不具合をartifactが出現するというように表現します。

atm

~~at this time のことだと思います。~~ at the momentの略らしいです。「今のところ新CPUではmacOSが起動しない」というような文の冒頭で、atmって書かれてます。

blackout

停電とか一時的な意識喪失・視力喪失というのが一般的な意味ですが、コンピュータ関連では、画面が真っ暗になり何も表示されないことを指します。Hackintoshだとグラフィックスドライバの不調で画面が出ない状況です。フレームバッファの指定が間違っていたり、その端子（HDMIとかDPとかDVIとか）に信号が供給されていない状況です。画面共有を設定しておけば他のコンピュータから接続できることがあります。また、ディスプレイ端子をつなぎ変えて別の端子を試して見るのも良いです。

cross your fingers

中指を曲げて人差し指の上に重ねて十字架のような形を作る仕草のことで、成功を祈る・神頼みする意味です。「ドライバをインストールして、設定を変更して、再起動してあとはcross your fingers」というように、手順の説明などでよく現れる表現です。keep your fingers crossed という言い方もするようです。

glitch

たまに現れる機械の誤動作、電流や信号の異常というような意味です。もともとは電流が異常に急増するような状況 (a sudden surge of current) を指すようです。不具合や故障を意味する1960年頃の宇宙飛行士のスラングだったとか。

コンピュータ関連では、こちらもartifactと同じく、画面が時々乱れたり、ノイズが発生したりする状況を表すために使われます。『シュガー・ラッシュ』（原題：Wreck-It Ralph）というディズニーのアニメ映画があります。コンピュータゲームのキャラクタ達が活躍する映画なのですが、前半ではそのヒロインがglitchと呼ばれていじめられています。プログラムの不具合で、ヒロインの顔や体の一部に時々ノイズが発生するからです。あえて区別すると、glitchは一時的に発生する画面のノイズで、artifactは、一時的なものに加えて、持続的に表示し続けるノイズも含めているように思います。

IMHO

コンピュータ関連のフォーラムで時々見かける用語です。in my humble opinion (私のつまらない意見だけど)という意味で、文の書き出しで謙遜する場面で使われます。そこまで謙遜しない場合は、IMO (私の意見では)という言い方もします。

in the same boat

I am (We are) in the same boat. というように使います。直訳では「私も同じ船に乗っています」ですが、相手と同じ問題を抱えたり、同じような苦労をして共感できる気持ちを表します。例えばHackintoshのトラブル相談の投稿に対して「こちらでも同じ構成で、同じ問題が発生しているので私も解決策を知りたい」というような返答で使われます。

like a charm

It worked like a charm. というと魔法のように効いて治った、という意味です。Hackintoshの不具合があったけど、助言に従って設定を少し直したら、効果抜群であっけなく治ってしまった、というような場合に使われます。charm (魔法、呪文) という言葉を使っていることから、「どういう理由で治ったのか仕組みが理解できないけど動くようになった」というニュアンスがあるように思います。

LOL

これは一般的なネットスラングで、lots of laughs や laughing out loud の略で「爆笑」という意味です。爆笑とまでいかなくても、日本語で笑とかwとか書く感じで使われている気がします。

mod

たぶんmodifyとかmodificationのことです。PC case modといえば、PCケースを改造することです。こうして作ったPCをmod PCとも言うようです。オリジナルのMacケースを流用して作るHackintoshもmod PCの一つです。

Apple純正ケースで作るHackintosh

mobo

マザーボード (motherboard) の略。長いので略すことが多いみたいです。日本語でも「マザボ」と言ったりしますよね。ちなみに中国語だと「母板」とも言うみたいです。

No entry sign

進入禁止マーク。macOSが正しく起動できない場合に、画面に表示されるアイコンです。厳密に言うと、交通標識の「進入禁止」ではなくて、「車両通行止め」に相当するマークです（海外でも車両進入禁止マークは、日本と同じく、丸い赤地に白い横長矩形です）。禁止マークというのが正しい気もします。このマークの裏には、起動できない状況のエラーが表示されています。Cloverの起動オプションに-vを追加すると、エラーの状況が文字で表示されます。エラー表示がされていたり、カーネルパニックの状況が表示されているはずです。これを手掛かりに、起動できない問題を解決します。

noob

初心者という意味。new boyなどが語源では無いかと言われています。昔は新入りを馬鹿にするような意味合いだったそうですが、今は、投稿の書き出しに「初心者なのでよくわからないのですが、」と謙遜して使ったり、「初心者向けガイド」で使ったりと、特に悪口という意味合いはないようです。

of death

コンピュータが動かなくなった状態を大げさに「死の〜」といいます。いろんなバージョンがあって、ポインタが虹色の円盤になったまま回復しないbeachball of death、またはspinning (pin) wheel of deathとか、画面が青い（黒い、灰色の）表示になって止まってしまうblue (black, gray) screen of deathなどがあります。BSOD/GSODなどと略すこともあるようです。Windowsだと青い背景に白い文字でエラーが表示されるブルースクリーンが有名ですね。BSODに相当する日本語の略だとブルースクリーンを縮めたブルスクかも。macOSだと、上述の禁止マークのような黒い背景 (black screen of death) や、これがグレーの背景に出るgray screen of deathになるかと思います。ブルースクリーンは出ないですね。

ちなみにアプリケーションが停止したときに出現する円盤ポインタは、光磁気ディスクが回転している様子を表したものです。初代のNeXTコンピュータでは、起動ディスク・システムディスクに光磁気ディスクという書き込み可能なDVDみたいな光ディスクを使っていました。これからデータを読み込み中のときに、光ディスクが回転する様子をポインタで表現していたのです。初代NeXTのディスプレイはグレースケールだったので、円盤ポインタもモノクロでしたが、のちにカラー化されて虹色になりました。光磁気ディスクの表面では、DVDやCDと同じように光が干渉するので虹色に見えます。それがmacOSでも引き継がれています。なので、あれをビーチボールと表現するのは間違っていると思います。

昔話ついでに。昔のMacでは、起動時のハードウェアチェックでメモリーエラーなどが発生すると、悲しげなアルペジオが鳴り、画面にサッドマックアイコンが表示されました。あれは、死のチャイムchimes of deathとか死のアルペジオarpeggio of deathと呼ばれます。この機能は1998年のiMacから廃止されたようです。

off the shelf

既製品なのですぐに手に入る、というような意味です。お店の棚にあるので、棚から手にとってすぐに入手できるという意味だと思います。特殊なパーツで一般には売られていないとか、古い製品なので中古屋とかeBayなどでしか手に入らないというような状況ではないということです。似た英語でon the shelfってのがありますが、これは棚上げされているという意味になるそうです。

OOB

out of the boxの略です。元々は、独創的で形にとらわれないという意味らしいです。箱に入りきらないという意味かな。コンピュータ関係の掲示板では、「箱から出したらすぐに使える: It works OOB.」という意味で使われています。パーツを買ってきて、箱から出して、コンピュータに取り付ければ、あとは、追加で色々設定することなく、すぐに使えるという意味です。Hackintoshで言えば、BCM20702を使ったUSB Bluetoothドングルとか、AMD Radeon RX-580などは、接続すればそのままmacOSで使えるのでOOBです。

quirk

OpenCoreのconfig.plistの設定にquirksという設定項目がたくさん登場します。主に、特定の現象に対応するために、パッチや対応を有効にするかどうかの項目です。辞書によるとquirksは、予想外の曲がり、ひねり、気まぐれのような意味だそうです。Ubuntu wikiの記載によると、ハードウェアのバグを回避するためのソフトウェア手法というような意味だそうです。そんな箇所は、多分、ソースコードを読んでプログラムの流れを追っていくと、「なんでこんなことやっているんだろう」と不思議に思えると思います。それで不具合を回避するための（それだけ見ると）意味不明なプログラムの流れということから、予想外に曲折した状態というニュアンスで使われているのではと思います。

vanilla

バニラアイスクリームのように素材のままという意味です。 Hackintoshでは、macOSのkextやディレクトリ構成に手を加えずにオリジナルのままに保ってインストールすることを、バニラなインストール手法と呼んでいます。OSアップデートのたびにパッチを当てる必要が無いので、メンテナンスが楽です。

/posts/131/

Apple純正ケースで作るHackintosh

Thu, 03 May 2018 11:03:40 +0900

自作PCの楽しみ方の一つにcase mod (ケースモッド：PCケースの自作改造) があります。ゼロからケースを自作したり、市販のケースをもとに芸術的もしくはオタクな装飾を加えて改造することです。また、かっこいいメーカー製デスクトップ筐体を利用してそこに標準的なマザーボードを組み込む楽しみ方もあります。「かっこいいメーカー製筐体」といえばApple製品が代表的なので、古いMacを改造して最新のPCに作り変える例が、ネットで多数紹介されています。こうして古いMacに組み込んだ最新マザーボードで、Hackintoshを動かす人も多いです。

古いMacを改造してHackintoshすることのメリットになるのかどうかわかりませんが、よく議論されるのがライセンスの話です。ご存知のようにmacOSの使用許諾書（EULA: End User License Agreement) には「macOSはApple製のMacにのみインストールできる」と書かれています。これに同意しながらHackintoshすることはApple社との契約違反になります。一方でMacのケースにATX基板を入れれば、Apple製コンピュータを最新の部品に交換しただけと主張できなくもないです。その主張が通るのかどうかわかりませんが、100%他社製品でHackintoshするよりも契約違反の度合いが少ないのは確かです。

デザイン重視Macを改造

Hackintoshをしている人たちの大多数は、MacのハードウェアやmacOSを非常に気に入っているものの、デスクトップ製品のラインナップに不満を持っています。Mac miniとMac Proの中間のデスクトップが欲しいとか、ディスプレイ無しのiMacが欲しいとか考えています。また、新しいCPU/GPUに世代交代しても一向に新製品が出ず、かといって最新の部品に交換したり拡張する手段が無いことにも不満を感じています。Macの外観を持ったままで、最新のハードウェアで作り直すことができれば理想的です。ということでtonymacx86でも、Macを改造してHackintoshしたという投稿が多数あります。そのために、case modのコーナも用意されています。

ここでは様々なMacがHackintoshに改造されています。Macの歴史の中でも、デザインが秀逸で人気のあるモデルの一つがPower Mac G4 Cubeです。多くの人が、G4 Cubeの改造を手がけています。この筐体は、Mac Pro 2013と同様に、筐体の中央が放熱板になっていて、下から上に煙突のように空気が流れる構造です。コンピュータの中身をスライドして取り出せる機構もあり、改造には高度な工作技術が必要です。多くの例では、mini ITX基板に交換しています。標準的な基板を搭載できるよう改造することで、いつでも最新のCPU、チップセット、メモリを使用した高性能なmacOSマシンになります。

G4 Cubeにmini ITX基板を取り付ける様子を紹介した日本語動画もあります。

Mac G4 Cubeで自作がしたい！#1 分解＆筐体加工 ★ I want to make my own with M…

歴代Macの中で、おそらく一番奇抜なデザインだったのが、最初の液晶ディスプレイ (LCD) 搭載iMacです。白い半球型の本体、自在に動かせるアーム、このアームに取り付けられたLCDの構成です。この改造も難易度は高いです。LCDからのケーブルを配線し直してDVIにします。本体部分は、非常にコンパクトなので、NUCが使われます。

Mac Pro/PowerMac G5ケース

一方で筐体の大きなデスクトップ機を使えば、改造はずっと簡単です。大型のデスクトップMacには、Power Macintoshシリーズ、Power Mac G3/G4/G5、タワー型のMac Proがあります。Power Macintoshシリーズは、古くて中古市場にあまり出回っていないことと、Apple暗黒時代の凡庸なデザインなので、これをmodする例はほとんどありません。一方、Jobsが復帰してからのPower Mac G3/G4は、ポリタンクと言われた独特の形状と透明感のある外観で、いまだに人気があります。modのためのキットも売られています。ただ、筐体表面はポリカーボネートですが、筐体内部が硬い鉄製であることと、光学ドライブが標準マザーボードと干渉しやすい構造なので、工作が大変です。

これに対して、Power Mac G5と、その形状を引き継いだタワー型Mac Proは、大型で内部空間に余裕があり、素材が柔らかいアルミニウムです。そのため加工が容易で、標準mATX/ATXマザーボードを組み込みやすいです。改造してHackintoshにするには最適な機種です。

G5とMac Proのどちらが改造に適しているか

もしMacのケースにATXマザーボードを組み込むなら、Power Mac G5とタワー型Mac Proのどちらを改造したらよいでしょうか。結論としてG5の方が適しています。

まず、G5の方が安価です。タワー型Mac Proは、設計が色々と古くなってしまってはいますが、インテルCPUを使用していますし、拡張の余地があるためにまだ実用性があります。CPUを差し替えて性能向上させる人も多いです。そのため中古市場やオークションでもある程度の価格がついています。一方でG5は、流石に古くて、なおかつCPUが古いPower PCであるため、ほとんどがジャンク品として売られています。ケースだけを利用して改造する場合には、中身に価値を求めませんのでG5で十分です。

改造にG5が適している理由は、価格以外にもあります。一見すると、G5もタワー型Mac Proも穴が多数開いたパンチングパネルの似たような筐体ですが、レイアウトがかなり違います。こちらに比較があります。

Mac Pro vs. PowerMac G5 – Apple’s Mac Pro – A True PowerMac Successor

正面から見た一番の違いは、光学ドライブの個数です。G5は一台を搭載しますが、Mac Proは2台搭載可能です。でも今時、光学ドライブは1台あれば十分です。不要と思う人も多いくらいです。3.5 インチドライブに関しては、G5は2台、Mac Proは4台内蔵可能です。でも最近は2.5 インチやm.2のSSDを多数使うことが多くなりました。またMac Proの3.5 inchベイは特殊な配置で、標準マザーボードを搭載した時に利用し難いです。光学ドライブや3.5インチドライブが衰退しつつある今から見ると、皮肉なことに、古いG5の方が新しいProよりも現状に即した設計だと言えます。

内部の違いも見てみましょう。下の写真は、左がG5で、右がProです。

どちらも、水平の仕切り板が1枚、棚板のようにあり、上部と下部に分かれています。G5は、上部に光学ドライブが1台、3.5インチHDDが2台配置されています。Proは上部に光学ドライブが2台、電源が配置されています。仕切板上部空間は、G5の方が狭いです。そのためG5の方が、仕切板下のメイン部分が大きいです。メイン部分が大きいG5の方が、部品配置を柔軟に行えるので有利です。

G5とProでは拡張スロットの数も違います。G5は4本で、Proは5本です。micro ATXのスロット数は4本なので、G5ケースを使うとそのまま全部有効利用できます。Proを使うとスペースが余って無駄が出ます。もっとも、スロット数の多い標準ATXを使う場合は、どちらも加工が必要です。

Proの電源は、標準的なATX電源に近いサイズなので、改造する場合にオリジナルの場所に電源を設置しやすいのではないかと思われるかもしれません。しかし、タワー型マシンで使うような容量の大きいATX電源は、上部もしくは下部に大型のファンがあり、そこから吸気します。Proの電源設置場所は、上下に開口部がありませんので、電源のエアフローが不利です。筐体上部に穴を開けてしまえばよいのですが、見た目が気になります。

G5の電源は、写真ではわかりにくいのですが、最下部にあります。平たい特殊な形をしています。元の形状を尊重してcase modする人は、標準ATX電源をバラして、平らに配置し直して、G5の電源部分に収納している人もいます。ただ、G5の電源は取り払ってしまって、そこに通常のATX電源をおくことも可能です。メイン部分が広いことのメリットです。

ということで、Macのタワー型アルミニウム筐体をHackintoshに改造するなら、Mac Proよりは、Power Mac G5の方がおすすめかと思います。こちらのブログでは、Power Mac G5やMac Proの改造が紹介されています。日本語の情報は少ないので、参考になります。

またYoutubeで”G5 mod”のようなキーワードで検索すると、参考になる動画が多数見つかります。

https://www.youtube.com/results?search_query=g5+mod

tonymacx86では最新のCoffee Lakeで作った例も紹介されています。

Laser Hiveの改造キット

Macの筐体を改造する場合に苦労する点は、オリジナルとは形状の違うマザーボードの取り付け方法と、そのバックパネルの加工です。こちらのサイトでは、MacケースにATXマザーボードを搭載するためのキットを販売しています。Power Mac G3/G4/G5とMac Pro用のキットを販売しています。

これらのキットを使わなくても改造は可能です。特に、Power Mac G5とMac Proは、アルミニウム製で加工が簡単なので、キットを使わなくても改造できなくはないですが、キットを使えば楽になります。上で紹介したサイトでも、Laser Hiveのキットを使った例が紹介されています。

Power Mac G5とMac Pro向けに、Laser HiveではATXマザーボードとmicro ATX (mATX)マザーボードを取り付けるためのキットをそれぞれ販売しています。Power Mac G5向けには、

オリジナル92mmファンx2を使ったmATXボードキット
120mmファンx1を使うmATXボードキット
オリジナル92mmファンx2を使ったATXボードキット
120mmファンx1を使うATXボードキット

があります。

G5にはもともと4本の拡張スロットがあり、これはmATXの拡張スロット本数と同じです。なので、mATXボードキットは、オリジナルの拡張スロットをそのまま活かすことができます。また、オリジナルの92mmファンを使用するキットでは、元々あるファン取り付けプラスティック部品や、ファンの排気カバーなどを再利用します。なので、Macの元々の形をできるだけ残したい場合には、「92mmx2ファン＋mATXキット」が適しています。一方、mATXマザーボードは製品の種類が少ないので、それが気になる人は標準ATXのキットが良いと思います。

G5改造の手順

Laser HiveのmATXキットを使って、壊れて廃棄されたG5を改造したことがあります。大した作業ではないのですが、予想以上に手間がかかりました。市販のPCケースを買ってきて組む方が圧倒的に簡単です。手作りする楽しさはありますが、それ以上に、G5の外観を生かしたマシンを作りたいという強い思いが必要です。手順は、以下のようになります。

ジャンクのG5をバラして掃除します。CPUカバーだけは1本の樹脂製ピンを壊さないと取り外せません。他は、破壊せずに分解できます。サイドパネルをロックする機構の分解には、知恵の輪を解くような根気が必要です。でもこれが外せないと棚板、HDD冷却ファン、HDD取り付けケージを外せません。埃を払って綺麗にします。
利用できるパーツを残して、不要なパーツは捨てます。ロジックボードなども捨てることになります。ファン取り付け部品、HDD取り付け部品、スイッチ類、ケーブル類、電源ケーブルソケット、カバー類などを上手に利用できれば、オリジナルの雰囲気をより活かせます。
ロジックボードを取り付けていたスペーサのうち、不要のものは取り外します。スペーサは溶接されたようにケースに固定されていますが、ハンマーで叩くと、簡単に外せます。ただしLaser Hiveのマザーボードトレイを取り付けるために使用するスペーサは、外さず残します。
裏側パンチングメタルを切り取ります。Laser Hiveのバックパネルの形に合わせて切り取ります。アルミなので、加工は楽です。
Laser Hiveのマザーボードトレイとバックパネルを取り付けます。
マザーボード、ファン、電源、HDDを取り付けて配線します。

手作りのPCケースですので、市販のPCケースに比べると保守やアップグレードが面倒です。でも実機と同じ見た目の美しいHackintoshを作り上げる満足感があります。

Apple Watchでログイン

Tue, 24 Apr 2018 00:30:00 +0900

以下で、Hackintosh向けのWiFi / Bluetoothアダプタについて紹介しました。

/posts/138/

実機で使われているBroadcom社のチップセット、

BCM94360CD (2013年採用)
BCM943602CS (2015年採用)

を搭載したアダプタがお勧めです。これらを使うと、Hackintoshに取り付けるだけで、何の設定もせずにそのまま動いて、本物のMacintoshと同じくContinuity連携ができます。

今回は、Apple WatchでMacのロックを解除する機能をHackintoshで試してみます。使ったHackintoshにはBCM94360CDを使用した無線アダプタを搭載しています。このHackintoshと、Apple WatchをペアリングしたiPhoneとのContinuityが確立されている状態で、「システム環境設定」「セキュリティとプライバシー」「一般」を開くと、「Apple WatchでこのMacのロックを解除できるようにする」という項目が選択できるようになっています。これにチェックを入れれば準備完了です。

この設定を行い、Apple Watchを装着していると、いつものログイン画面に、「Apple Watchでロック解除中…」の表示が出ます。これでパスワード入力を省略してMacにログインできます。

Apple Watchを手首に着けていなかったり、Bluetooth圏外（3m程度）だったり、Apple Watchがロックされていたりすると使えません。なので万一放置したApple Watchを他人に使われても、解除される心配はありません。また、Apple WatchとペアリングしているiPhoneがその場に無くても、その電源がoffになっていても自動解除が機能します。Apple WatchとのBluetooth通信だけで解除機能が完結しているようです。

ThunderboltとHackintosh

Mon, 16 Apr 2018 00:30:00 +0900

本物のMacと同じように機能させるのがHackintoshの目的なので、コミュニティの皆さんは日々ハッキングしています。その結果、ほぼ、本物と遜色ない機能を実現していますが、中にはあまり成功していない機能もあります。その一つが、Thunderboltではないかと思います。Thunderboltはそこそこ動きます。でも完璧ではありません。次のような問題があり、解決できていません。

Hot plugが効かない。起動時に接続されているThunderbolt機器はPCIe接続機器として認識されて機能するけど、起動後に接続した機器は認識されない。
スリープからの復帰で、認識されていた機器も見失うなどの問題が発生する。

それでもどうしてもThunderbolt機器を使いたい分野もあるようで（特にサウンド関係かな？）、hot plugを諦め、スリープさせない使い方をしているユーザも多いようです。

Thunderbolt (初代)

実は私がHackintoshで試したことのあるThunderboltは初代・無印のものだけです。インテルNUCの初代モデルDC3217BYに搭載されていたThunderboltです。これに、Apple社のThunderbolt-Ethernetアダプタや、市販のThunderbolt接続HDDを接続してみました。いずれも、起動時に接続してあれば、何の問題もなく機能しました。しかし、起動後に接続した場合は認識されません。また、スリープ復帰後は機能しませんでした。

Thunderbolt 2

80シリーズマザーボードあたりから、Thunderbolt 2を搭載したマザーボードが登場しました。Macと同じThunderboltチップを使用していたこともあり、コミュニティでの期待が高まりましたが、当初は全く使用できませんでした。皆が試行錯誤し、苦戦しているときに、とある人が「WindowsでThunderbolt 2を使用した後、macOSで起動したら使えるようになった」と報告しました。信じられない現象でしたが、次々と成功例が報告されました。でも、Hot plugが効かない問題、スリープ復帰の問題はそのままでした。

Thunderbolt 3

Thunderbolt 3になると、マザーボード上に実装した製品はほとんど見当たらなくなりました。その代わり、どうしても必要な人には、アダプターカードが供給されるようになりました。Thunderboltに対する熱気が冷めたような気がします。

Hackintoshの対応状況も改善されていません。hot plug問題も、そのまま引き継がれていますし、Windowsで一回動かさないとダメな状況も同じです。おそらく、USB 3.0がそうでしたが、インテルのチップセットにThunderbolt機能が組み込まれて、実際のMacがそれをサポートするまでは、完璧な互換性が得られないような気がします。

最近のHackintosher.comにThunderbolt 3のまとめ記事が掲載されましたので紹介します。

hackintosher.com

以下はHackintosher.comの抄訳です

現行のASUS製品ではASUS Prime Z370-Aマザーボードと、ThunderboltEX 3 PCIeカードの組み合わせでThunderbolt 3を実現しています。このカードに対応するASUSのZ170とZ270マザーボードもあります。
Gigabyteは多数のThunderbolt対応マザーボードを揃えていますが、Hackintosher.comでの推奨はGigabyte Z370 AORUS Gaming 5です。これに対応するThunderboltカードは、Gigabyte GC-ALPINE RIDGE Thunderbolt 3 カードです。このほか、Z370 AORUS Gaming 7, Z370 AORUS Gaming 3, Z370XP SLI, Z370 AORUS Ultra Gaming, Z370 AORUS Gaming WIFIマザーボードなどがThunderbolt 3カードをサポートしてます。
ASROCKは、スリープ関係の問題が発生する可能性が報告されているので、ASUSかGigabyteがおすすめです。ASROCKの場合は、ASROCK Z370 Taichi, Z370 SLI/ac, Z370 K6, Z370 Extreme4, Z370 Pro4, Z370 Pro i7マザーボードと、ASROCK THUNDERBOLT 3 AICカードを組み合わせます。

Thunderboltカードを設定するには、

Windowsを起動してThunderbolt 3カードをアップデートします。これで最新のマザーボードでカードを使えるようになります。ASUSの場合は「ThunderboltEX 3 firmware update tool」で、Gigabyteの場合は「Thunderbolt FW Update Tool」という名前です。
BIOSでthunderboltをenableにします。

また、Hackintoshでは、hot plugの問題があります。

（ASUSのカードは、マーケットプレイスからの出品しかありませんでした。）

Bluetooth電波を改善する

Mon, 09 Apr 2018 00:30:00 +0900

Hackintoshを使っていて、Bluetoothキーボードからの入力が途切れたり、逆にキー入力が連打状態になって誤った入力がされたりする経験がありました。Bluetoothのマウスやトラックパッドの入力が不安定になって、ポインターが飛び飛びに移動することもありました。Hackintoshをしていると、どんな不具合でもHackintoshのせいだと思いがちですが、そうでは無いことも多いです。この不具合は以下のようにして解決しましたが、その経緯からしてBluetoothの電波状況が問題だったようです。

Bluetoothは、古い世代のWiFiと同じく2.4GHz帯の無線を使っています。2.4GHz帯は、色々な用途に使われているので影響も受けやすいです。特に問題なのが電子レンジです。加熱のために強力な2.4GHz帯電波を使用しますので、電子レンジが稼働すると、BluetoothやWiFiが不調になることが多いです。また、高速になったUSB 3.0が2.4GHz帯に近いノイズを発生することがあり、シールドが不十分なUSB機器やケーブルが原因で、Bluetooth/WiFiが不調になることがあります。最新のWiFi機器なら5GHz帯の電波を利用することで、これらの問題は回避できます。でも、2.4GHz帯だけを使用するBluetoothでは別の周波数に逃げることができません。WiFiとBluetoothでは電波強度も違います。WiFi電波は100mくらいの距離でも到達します。これに対して、もともと近距離の配線を無線化することが目的だったBluetoothは、到達距離が10m程度です。電波出力が弱い事もノイズにも弱い理由です。

Bluetooth接続が不安定なことには、Hackintoshならではの事情もあります。互換性の高いHackintoshを実現するために、Macで使われているのと同じ無線モジュールを使います。こちらで無線モジュールの選び方を解説してあります。

/posts/138/

自作PCでは、この無線モジュールを、下のようなPCIeアダプタに載せて、これをPCIeスロットに挿して使うことが一般的です。そうすると、筐体の後ろ側にアンテナを立てて使用することになります。

このような設定だと、机に載せたキーボードやトラックパッドから、筐体のアンテナまでの距離が長くなってしまったり、金属筐体で遮蔽されてしまったりして、電波状況が悪くなることが予想されます。一方で、実際の Mac、例えばiMacでは、画面の周囲にアンテナが配置されているので、机の上のBluetooth機器からの距離は近く、見通しも良いです。

アンテナを机の上に持ってくる

解決方法の一つは、Bluetoothアンテナを机の上に持ってくることです。アンテナをキーボードやトラックパッドに近づければ、安定した無線通信を実現できます。そのために、下のような延長ケーブル付きアンテナ台を使うと良いです。台にはマグネットが入っているので、金属部分に固定することもできます。

まずは、PCIeスロット背面やPCケースのアンテナから、Bluetoothアンテナを外します。例えばBCM94360CDには4本のアンテナがあり、J0, J1, J3, J2の順に印がついています。このうちの端から2番目のJ3（コネクタの切り欠きのある側から2番目に遠いアンテナ）がBluetoothのアンテナで、残りの3本はWiFiです。下の写真では上から2番目のアンテナ端子がBluetooth用です。

他の無線モジュールにも、複数のアンテナ端子が付いていますが、そのうち1本がBluetoothです。どれがBluetoothなのかは、ネットで調べると書いてあることもあります。アンテナを外して感度が下がることで確認しても良いです。

次に、外したコネクタ端子に、上記のアンテナ台の延長ケーブルを接続します。アンテナ台を机の上に置いて、外したアンテナをアンテナ台に接続すれば完了です。この結果、Bluetoothの電波状況が改善したのか、冒頭に書いたようなキーボード、トラックパッドの不具合が一切発生しなくなりました。

上で、iMacは画面上部にBluetoothアンテナがあるから問題発生しにくいと書きましたが、ネット掲示板を見ていると、Bluetoothキーボードやトラックパッドの入力が不安定で困っている人が結構いるようです。特に、画面が大きいiMacではアンテナまでが遠いので、ノイズの多い環境では不安定になることもあるようです。アンテナを延長する方法ならば、キーボード・トラックパッドのすぐ脇にアンテナを置くこともできます。Bluetoothアンテナを延長することは実際のMacでは困難ですので、Hackintoshならではの柔軟性が発揮できる方法かと思います。

HackintoshでSiriを使う

Sun, 25 Mar 2018 00:30:00 +0900

macOS Sierraから音声アシスタントのSiriが使えるようになっています。HackintoshでもSiriを使うことができます。ただ、一体型のMacにはSiriに適したマイクロフォンが内蔵されていますが、自作PCで作ったHackintoshでは別途用意する必要があります。

マザーボード搭載のオーディオチップが使えるように設定してあれば、マザーボードのジャックにアナログマイクロフォンを接続すれば使えます。でも、Webカメラ内蔵のマイクロフォンを使うのが安価、高性能で簡単だと思います。Webカメラがあれば、FaceTimeやSkypeやそのほかのテレビ電話・会議システムで使えます。USB接続のWebカメラなら、Hackintoshでも特別なドライバのインストールなしで、画像入力・音声入力をそのまま使用することができます。Webカメラは多数販売されています。例えばLogicoolのC270は、HD 720pですがテレビ電話・会議に十分な画質で価格も安いです。マイクロフォンも優秀です。LogicoolのWebカメラを接続すると、内蔵マイクロフォンが、「システム環境設定」の「サウンド」「入力」にUnknown USB Audio Deviceとして表示されていますので、これを選択します。

iPhoneなどで使用するBluetoothイヤフォンの多くにも、通話のためのマイクロフォンが内蔵されています。これもHackintoshのSiriで使用することができます。Bluetooth接続すると、「システム環境設定」「サウンド」「入力」にBluetoothに分類される入力装置が現れるのでこれを選択します。

入力装置の設定が終わったら、「コマンドキー」「スペースキー」の長押しで、Siriが応答します。色々試してみましょう。なお、macOS High Sierraからは、「システム環境設定」「アクセシビリティ」「Siri」から「”Siriにタイプ入力”を有効にする」項目が用意されていて、これをチェックすると音声だけでなくテキスト入力によりSiri利用が可能になります。

Alexaも使ってみる

AppleのスマートスピーカHomePodが米国などで発売されていますが、日本はまだです。Siriベースで、Macとの親和性の高いHomePodは楽しみです。一方、スマートスピーカとしては、GoogleのGoogle HomeとAmazonのAmazon Echoがすでに先行しています。

Amazon Echoの音声アシスタントであるAlexaもmacOSで使うことができます。App Storeで配布されている以下のアプリケーションをインストールするだけで利用できます。Siriと同様に、HackintoshでもWebカメラやBluetoothイヤフォンのマイクを使ってアクセスできます。

Reverb for Amazon Alexa

Rain
仕事効率化
無料

アプリケーションが起動すると、EchoのLEDのようなリングが表示されて、これを長押ししている間、音声認識します。

Amazon Echoを使えば、Amazonのサービスで使えるコンテンツにアクセスできるのですが、残念ながらこのプログラムは音楽再生に対応していません。でもニュースなどを再生してくれます。また、iCloudとも連携できるので、カレンダー.appで管理しているスケジュールも教えてくれます。Amazon Echoで制御できる照明器具やスイッチなどが販売されていますが、このアプリケーションを使うと、HackintoshからEcho対応照明をon/offすることもできました。

OK Googleも使えるはず

Google Homeの音声アシスタントもmacOSで使えるようです。以下の記事に詳しく書かれています（この関連記事でmacOS用Alexaのことも知りました）。

news.mynavi.jp

ただ、設定が大変な上に英語にしか対応していないようです。また、Googleのエコシステムを前提としているので、iCloudのカレンダーを利用することはできません。ということでこちらは試していません。macOSにはGoogle HomeよりもAmazon Echoの方が親和性が高いようです。

Hackintoshで確定申告(e-Tax)

Sun, 11 Mar 2018 23:19:31 +0900

Hackintoshでe-Tax（確定申告）してみました。ちゃんとできました。マイナンバーカードも読めて、手続き出来ました。普通のMacでもできることなので、当然と言えば当然です。

整理が下手で控除書類が年末調整時に見つからなくて、確定申告をしています。例年は「確定申告書等作成コーナ」というページから書面提出をしていたのですが、今年は、マイナンバーカードを使用して、初めてe-Taxしてみました。今年からいくつかの提出書類が省略できるようになったこともあり、郵送する手間なく、オンラインで全て完了できました。

e-Taxするには、住民基本台帳カードもしくはマイナンバーカードと、これを読み取るための「公的個人認証サービス対応ICカードリーダライタ」が必要です。今回は、SCR3310-NTTComというカードリーダを使いました。これはすでに販売終了になった古い製品です。だいぶ前に、秋葉原のジャンク屋さんに積み上げられていたのを、使う当てもなく買ったものです。これが発掘されたのも、今回e-Taxしてみようという動機の一つです。

今は後継機種が販売されているようです。

これらのリーダはUSBで接続します。一般にUSB接続周辺機器は高度に標準化されているため、Hackintoshでも本物のMacでも同様に動く傾向があります。今回も動きました。なお、このリーダのためにドライバが配布されていますが、e-Taxを行う際にはドライバをインストールする必要はありません。むしろ、標準のドライバを消してしまう問題もあるそうで、インストールしてはいけないようです。

e-Taxのサイトを見てすぐ気になったのがソフトウエア動作環境です。国税庁で動作を確認した推奨環境は、macOS 10.12とSafari 10.1です。これに対して、手元のHackintoshは、いつも最新にしているのでmacOS 10.13.3とSafari 11.0.3です。でも、結論として、問題ありませんでした。国税庁にもぜひHigh Sierraを導入して動作確認してもらいたいところです。

問題なく作業できたとはいえ、色々大変でした。Java Runtime Environmentをインストールする必要があります。また、SafariでJavaの動作を許可してあげる必要があります。e-TaxのサイトにはSafari環境設定での方法が書いてありますが、実際には違ってました。サイトには「セキュリティ」のアイコンから設定することになっていますが、Safari 11.0.3では「Webサイト」のアイコンから設定します。Safariのバージョンが変わって、設定場所が移動したようです。ここの設定では、オプション＋クリックで現れる隠しメニュー項目の「安全なモードで実行」するというチェックマークを解除します。この後、警告マークが出続けますので、かなり危ない設定なのだと思います。WebブラウザでのJava利用もあまり行われなくなっていますし、e-Taxの実行環境ももう少し現代風に更新してほしい気がしました。

とは言え、なんとか終了しました。完了した後で、はてなのブログにe-Taxのやり方が書いてあるのを発見しました。後の祭りですが、だいたい問題なかったです。こちらのブログに書いてあることを全部実施する必要はありませんでした。e-Taxのヘルプページは良く書かれているので、エラーコードを頼りに見ていけば、必要な作業がわかりました。

d.hatena.ne.jp

電池を搭載してないことをOSに知らせる

Sat, 24 Feb 2018 12:54:47 +0900

デスクトップマシンなのに、「システム環境設定…」「省エネルギー」の設定で、「電源アダプタ」と「バッテリー」の2つのタブが表示されることがあります。MacBook Airとして機種設定したNUCがそうでした。「電源アダプタ」タブがデフォルトで表示されるので、こちらで設定しておけば問題ありません。ちなみに、「バッテリー」の項目はどれを設定しても機能しません。

バッテリー関連機能が応答しないのは、実際にバッテリーが搭載されていないので当然です。しかし、存在しないバッテリー管理チップにOSがアクセスしようとしているわけで、システムの安定性に影響を与える可能性もあります。とはいえMacBook Airの設定にしたのだから仕方ないと思い、放置してきました。

ところが最近のredditで、「Mac miniの設定でバッテリー表示が出るのでなんとかしたい」という相談が上がり、解決策がわかりました。簡単でした。

www.reddit.com

config.plistのSMBIOSセクションに、Mobileという項目があります。これがtrueになっていると、バッテリ搭載機だと見なされるようです。

<key>Mobile</key>
<ture/>

これをfalseにしてみました。

<key>Mobile</key>
<false/>

その結果、機種設定はMacBook Airのままですが、「省エネルギー設定」にバッテリーの設定が現れなくなりました。

Hackintoshでマイニング（本気編）

Thu, 08 Feb 2018 00:30:00 +0900

前回は、寒いから暖を取ろうといういい加減な動機で仮想通貨のマイニングに手を出してみました。でも性能はイマイチでした。マイナーの数が圧倒的に多くてサポートの手厚いWindowsに性能で負ける結果も仕方ないと思いましたが、残念でした。

/posts/85/

そこで今回は本気を出して、性能アップを目指します。

前回のあらすじ

macOS (Darwin) をサポートしてくれているGPU採掘ソフトウェアは、どうやらethminerしかないようです。そこで、このサイト

Releases · ethereum-mining/ethminer

からDarwin用にコンパイルされたethminerをダウンロードして、Ethereumを採掘してみました。その結果、RX 580を使った場合、macOSで4.3MH/s (メガハッシュ毎秒) でした。その後、同じハードウェアでWindowsを起動し、ethminerを使ってみたところ16MH/sでした。

NVIDIAでも試してみた

NVIDIAのGeForce GTX 1080Tiでethminerを試す機会がありました。思いのほか性能が出なくて、Ethereumの採掘がmacOSでもWindowsでもどちらも1.5MH/sくらいでした。検索してみると、本当は32MH/sくらいは出るものらしいです。

ベンチマークで分かる、イーサリアムのマイニングに最適なGPUまとめ | ちもろぐ

Windowsの世界には、もっと色々なツールがあるようなので、そういうのを使わないと性能が上がらないのかと思い、しばらくは放置していました。

少し気になっていたのは、ethminerでOpenCLモードを使っていたことです。OpenCLはアップル社が提唱した並列コンピューティングのためのフレームワークで、AMDとNVIDIAの両方のグラフィックスカードでサポートされています。一方で、CUDAはNVIDIAが提唱する並列コンピューティング機能です。なので、NVIDIAをCUDAで使えばもっと性能が上がる可能性があります。NVIDIAでCUDAを使用するには、NVIDIAのWeb driverとは別に、CUDAのドライバもインストールする必要があります。CUDAドライバは以下から入手できます。

MAC アーカイブ用CUDA ドライバ|NVIDIA

etherminerではコマンドオプション (-Gもしくは-U) の指定で、OpenCLとCUDAを切り替えて利用できることになっています。例えば、

./ethminer -G -S eth.pool.minergate.com:xxxxx -O xxxx@xxxx.com

のように-GオプションでOpenCLを使います。ここを-UにするとCUDAを使うことになっています。しかし、上記のサイトで配布されているコンパイル済みバイナリーで-Uオプションを使うと、

./ethminer -U -S eth.pool.minergate.com:xxxxx -O xxxx@xxxx.com
CUDA support disabled. Configure project build with -DETHASHCUDA=ON

というメッセージが出て動作しません。どうやら、配布されているバイナリーは、CUDAサポートをOFFにしてコンパイルされているようです。ソースを入手してコンパイルし直す必要があります。

ethminerをコンパイルする

そこで、ethminerのソースからコンパイルしてみました。コンパイルするときにCUDAサポートをONにすれば良いのです。上記のサイトからソースコード一式をダウンロードすることができます。実はOpenCLだけをサポートするコンパイルは割と簡単です。OpenCLは、多分Appleが標準でサポートしているためだと思います。でもCUDAは、NVIDIAから開発キットをダウンロードする必要がありました。やった手順を以下に書いていきます。

Xcode.appをインストールする

macOSでコンパイルするならXcode.appは必須です。App Storeから無料で購入してインストールします。

Xcode Command Line Toolsをインストールする

ターミナルからの操作でXcodeの開発ツールを利用するためのツールを入手します。この手順は、Xcodeのバージョンごとに変わっているようで、ネット上の情報も混乱しています。昔は手作業でインストールしていたのですが、こちらに書いてあるように、今は最初から入っているようです。この手順で確認してください。

Mac での Xcode コマンドラインツールのインストール – RAD Studio

でも、なんかそれだけではダメだったようです。色々やっているうちに、App StoreからCommand Line Toolsの最新版を取り寄せることになりました。

また、ターミナルから、

xcode-select --install

をタイプして、Command line developer toolsというもののインストールダイアログを表示させて、インストールする必要がありました。これをやらないと、コンパイル中に、string.hファイルが見つからないと言われました。

CUDA Toolkitをインストールする

このページからCUDA Toolkitをダウンロードします。サイズは1.5GBくらいあります。

CUDA Toolkit 9.1 Download | NVIDIA Developer

ダウンロードしたイメージの中にあるインストーラを起動します。

インストールするパッケージを選びます。NVIDIAの通常のドライバ配布サイトでは、おそらくこの1番目のCUDA Driverが配布されているだけだと思います。今回は、2番目のToolkitが必要になります。3番目のSamplesは不要ですが、サイズも小さいので、全部入れてみました。

この作業でインストールされるライブラリ、ヘッダファイル、サンプルなどは、

/Developer/NVIDIA/CUDA-9.1

の場所に保存されるようです。コンパイルなどで必要と思われるパスは自動的に張ってくれているようで、特に設定する必要はなかったです。

Homebrewをインストールする

HomebrewはmacOS用のパッケージマネージャの一つです。UNIX系の色々なコマンド、ツール、アプリケーションをインストールしてくれる便利なツールです。下のページに書いてある一行をターミナルにコピペして実行するとインストールできます。

macOSのパッケージマネージャとしては、他にmacportsが有名ですが、Homebrewの方がシンプルで高速で便利だと思います。

homebrewとは何者か。仕組みについて調べてみた - Qiita

なぜHomebrewが必要かというと、この後で使用するcmakeというコマンドを使えるようにするためです。今回はそれだけのためにHomebrewをインストールするのですが、将来も使うと思いますので、入れておいて損はないです。

cmakeをインストールする

Homebrewがインストールできたら、ターミナルから、

brew install cmake

とタイプします。これでcmakeコマンドが使用できるようになります。

ethminerのソースを入手する

すでに紹介したサイトですが、随分と上の方に行ってしまったので、再掲します。このサイトからソースコード一式をダウンロードします。

Releases · ethereum-mining/ethminer

これでダウンロードしたethminer-0.13.0というような名前のフォルダに、必要なファイル一式が入っています。

cmakeする

ターミナルからcdコマンドで、ダウンロードしたソースコードフォルダに移動します。そのフォルダには、CMakeList.txtという設定ファイルがあるはずです。このファイルにコンパイルやリンクの設定やオプションが書かれています。

CMakeList.txtをテキストエディタで開くと、

option(ETHASHCL "Build with OpenCL mining" ON)
option(ETHASHCUDA "Build with CUDA mining" OFF)

という記述があります。これでOpenCLとCUDAのサポートを指定しています。ここでわかるように、配布されている状態ではCUDAがOFFになっています。そこで、

option(ETHASHCL "Build with OpenCL mining" ON)
option(ETHASHCUDA "Build with CUDA mining" ON)

このように、OpenCLもCUDAも両方ともONになるように書き換えます。（CUDAだけをONにして、OpenCLをOFFにしてももちろん良いと思います。）次に、以下のコマンドでcmakeします。

cmake .

cmakeのあとは、空白＋ピリオドです。これでcmakeが、カレントディレクトリの設定を使って、Makefileを作ってくれます。

makeする

cmakeはmakeという名前がついていますがMakefileを作ってくれるだけでコンパイルやリンクはしません。そこで

make

とタイプして、makeします。エラーが出ずに、コンパイル、リンクが進めば、ethminerというフォルダの中に、ethminerというファイルができています。これが完成したアプリケーションです。

CUDAの結果は？

こうして作成したethminerで使用可能になった-Uオプションを使って、まずはグラフィックスカードの状況を確認してみます。

./ethminer -U --list-devices
Listing CUDA devices.
FORMAT: [deviceID] deviceName
[0] GeForce GTX 1080 Ti
Compute version: 6.1
cudaDeviceProp::totalGlobalMem: 11810832384
Pci: 0000:01:00

グラフィックスカードがCUDAデバイスとして認識されているようです。そこでいよいよ、以下のようにCUDAを指定してEthereumを採掘してみました。

./ethminer -U -S eth.pool.minergate.com:xxxxx -O xxxx@xxxx.com

今回は、エラーを出さずに、採掘を開始してくれました。そして、なんと32MH/sのハッシュレートを達成しました！ということでめでたくWindows並みの性能が得られるようになりました。

以上、HackintoshでEthereumを採掘する場合、

NVIDIAをCUDAで使えばOpenCLの20倍の採掘性能が得られる
その結果macOSでもWindows並みの採掘性能が得られる
macOSで採掘するならAMDよりNVIDIAの方が良い

という結論でした。

SSDのTRIMを有効にする

Thu, 01 Feb 2018 23:39:45 +0900

HDD/SSDの読み書き

HDDやSSDは、大容量のデータを低価格で管理するために、一定のかたまり単位でデータの読み書きを提供しています。このかたまりは、HDDではセクターと呼ばれ、SSDではページと呼んでいます。HDDにはセクターサイズが512バイトと4kBのものがあり、SSDのページは一般的には2kBです。これを、以下ではページと統一して呼ぶことにします。

新しいファイルは、新しいページから書き始めます。ページを使い切らなくても、そのページは全部そのファイルのものです。例えば以下のようにすると、Aという文字が書かれたファイルができます。ダンプしてみると文字と改行コードの2バイトの大きさのファイルだということがわかります。

echo A > tako
hexdump tako

このように小さなファイルでも、HDD/SSD上では1ページを使用します。（実際のHFS+では複数ページをまとめた4kBのサイズが最小単位です）

1ページに収まらないファイルは、複数ページに書き込まれます。どのファイルがどのページに書かれて、続きはどのページなのかを管理するのがファイルシステムです。その情報(目次に相当する情報)は特別なページに書いて管理しています。ページの情報が不要になっても、ページの内容をわざわざ消すことはしません。不要になったページ番号を、目次から削除するだけです。

SSDのデータ書込手順

HDDは、円板に塗布した磁性体に微小な磁石を多数作成して、これの磁極を変更してビットを記録します。磁極は磁場を加えると反転するので、上書きが容易です。例えば、ページにAという情報を書き込んだ後からBを書くと、それだけでAがBに書き変わってくれます。

一方SSDは、絶縁された微小な領域に電子を閉じ込める事でビットを記録します。電子を加えるのは比較的に簡単なのですが、取り除くのは手間がかかります。例えると、紙にインクで文字を書くようなものです。とあるページにインクで書かれているAの代わりに、新たにBを書くためには、手間をかけてAの文字を消さないといけません。漂白剤でまっさらな紙に戻してから書き込む必要があります。その上、SSDではページ単位での消去はできません。標準的なSSDでは64ページをまとめてブロックと呼んでいて、消去できるのはこのブロック単位です。いわば、64ページのノートブックになっていて、冊子ごと漂白剤に突っ込んでインクを消さないといけない状況です。

なのでOSから、例えばとある冊子(ブロック)の10ページ目に新たな情報を書き込んでくれと依頼されたSSDコントローラは、次のような作業をします。10ページ目以外の他のページに情報が書かれていたら、その内容を作業用メモリにバックアップします。次に、この冊子全体を漂白します。最後に、バックアップした情報を書き戻し、10ページ目に依頼された情報を書き込みます。かなり面倒な処理です。一方で、これが初めて使う冊子なら、バックアップは不要です。ですからSSDの書き込み速度は色々な要素で変動しますし、一般的にはSSDを使い込んでいくと書き込み速度が低下していきます。

TRIMの役割

SSDの書き込み速度を低下させる原因の一つが、HDDのことしか考えないで設計されたOSです。先に述べたように、OSは不要になったページをいちいち消去することはせず、目次から削除するだけです。ですが、目次がどのページに書かれているかとか、目次のデータ構造がどう決められているかは、HDD/SSDのコントローラにはわかりません。もしOSが、不要になったページ番号だけでもSSDコントローラに教えてくれれば、そのページを無駄にバックアップしたり、書き戻さないですむでしょう。SSDのメモリー素子は書き込むごとに疲弊して、故障の原因になると言われています。なので、不要な書き戻しは避けたいところです。また、一回のブロック消去で真っさらなページを多く用意できれば、次回の書き込みが高速になると期待できます。

このように、使用しなくなったページをSSDコントローラに知らせる機能がTRIMです。TRIMはSSDのために追加された拡張機能です。不要になった葉っぱ（ページ）を刈り取る (trimする) という意味から名付けられたのだと思います。

macOSのTRIM機能

SSDには是非とも欲しいTRIM機能ですが、macOSでは、Macに最初から搭載されているSSDにだけ機能します。なので、本物のMacであっても、ユーザが蓋を開けて交換した市販のSSDでは、TRIM機能が効きません。残念な状況ですが、あらゆるSSDでの動作を保証できないと考えて、そうしているのかと思われます。

Apple非純正のSSDに交換した場合は、macOSに標準で搭載されているtrimforceコマンドを使うと良いです。ターミナルから、

sudo trimforce enable

と打ち込んで、パスワードなどを入力すると、しばらく処理が行われた後、自動的に再起動して、搭載された全てのSSDでTRIMが機能するようになります。

実際はちょっと違います

というような説明がネット上にはあります。が、実際にはそんなに単純ではないです。実際には、

Apple非純正のSSDでも何もせずにTRIMが機能することがあります。
一方でtrimforceコマンドでTRIMが有効にならないSSDもあります。
そんな場合はIOAHCIBlockStorage.kextにパッチを当てれば良いです。

という状況です。

HackintoshでTRIMを有効化

HackintoshではApple純正SSDなどはまず使いませんので、そのままではTRIMが機能しない可能性が高いです。でも、非純正SSDでもTRIMが機能することもあります。ということでまずは状況を確認しましょう。それで機能していなければ対策をしましょう。

Step 1. TRIMが有効になっているかどうか確認する

リンゴマーク–>このMacについて–>システムレポート…–>ハードウェアから、SATA/SATA ExpressやNVMExpressの項目を見て、接続されているSSDを選択します。この中に、TRIMサポート：という項目があります。これが「はい」ならTRIMが機能しています。手元のマシンでは、M.2ソケット接続のSamsungのNVMe SSDは、バニラなmacOSでTRIMサポートされていました。TRIMサポートが「いいえ」なら次のステップに進みます。

Step 2. trimforceコマンドを試す

以前のmacOSではtrimforceがよく機能したものの、最近のmacOSではあまり当てにならない気がしています。でも機能することもあります。OS標準機能なので、一度は試しておきましょう。保証はしないよという警告が出ますが、実行してしまいます。再起動した後で、また「システム情報」でTRIMサポートを確認します。手元のSATA接続SanDiskの2.5インチSSDは、trimforceコマンドでもTRIM有効化できませんでした。

でも、AliExpressで買ったmSATA接続SSDはTRIM有効化できました。

Step 3. IOAHCIBlockStorage.kextにパッチを当てる

これは確実です。本物のMacを対象としたネット上の情報でも、パッチを当てる方法が紹介されています。でも、結構面倒ですし、SIPを無効にする必要がありますし、OSがバニラな状態ではなくなってしまいます。OSのアップデートごとに、同じパッチ当てをする必要があるでしょう。でもCloverを使ったHackintoshなら、config.plistで設定するだけで、起動時に動的にパッチを当てます。OS本体は手つかずのままパッチを当ててくれます。素晴らしいです。config.plistのKextsToPatchにセクションに以下のように書き込みます。

<key>KextsToPatch</key>
<array>
 <dict>
 <key>Name</key>
 <string>IOAHCIBlockStorage</string>
 <key>Find</key>
 <data>
 AEFQUExFIFNTRAA=
 </data>
 <key>Replace</key>
 <data>
 AAAAAAAAAAAAAAA=
 </data>
 <key>Comment</key>
 <string>TRIM Enabler</string>
 </dict>
</array>

このパッチでは、Base64表記でAEFQUExFIFNTRAA=というデータを、AAAAというAの羅列データに置き換えています。16進数で表すと

004150504c452053534400

というデータを

0000000000000000000000

で置き換えていることになります（Base64ではAが数値の0です）。元のデータは、最初と最後の0x00を除くと、真ん中はASCIIコードになっていて、APPLE SSDという文字列です。

004150504c452053534400
 A P P L E S S D

おそらくApple社のSSDに限定している場所を、0で消しているようです。この結果、手元のSanDisk 2.5インチSSDでもTRIMが有効になりました。

ESPを自動バックアップする

Sun, 28 Jan 2018 17:18:13 +0900

Hackintoshを作る際に、macOSをバニラな状態でインストールすれば、Hackintoshで加える変更は全てESP (EFI System Partition)の中だけです。

/posts/131/

なので、Hackintoshの設定を変えたことが原因で起動しなくなっても、正しく動いているESPさえバックアップされていれば、それを使って起動することができます。ということを以下に書きました。

起動失敗に備えてバックアップ

今回は、そのESPをどこに、どうやってバックアップしたら良いかについて考えてみました。

ESPをTime Machineにバックアップする

macOSを使うならTime Machineを使わない手はないです。

Time Machineは良いです

Time MachineでESPをバックアップしておけば、差分バックアップ機能により、過去の設定に戻すこともできます。ESPの設定を変えて、一見正しく動いているように見えたけど、しばらくしたら不具合に気づいたという場合がたまにあります。そんな時も、変更前の過去の設定に簡単に戻せるので便利です。やり方は、ESPの内容を、書類フォルダや、そのほかの、Time Machineの対象にしているフォルダにコピーしておくだけです。あとはTime Machineが個々のファイルの更新状態を確認して、自動的にバックアップしてくれます。

ESPをクラウドファイルサーバにバックアップする

クラウドファイルサーバと同期しているフォルダにESPをバックアップしておけば、他のマシンやWebから参照できます。Hackintoshが起動しなくなっても、他のマシンでESPを使って起動USBメモリを作り、救済することができます。

iCloud Driveを使っていれば書類フォルダをクラウドにバックアップできます。無料アカウントだと容量が少なく書類フォルダをiCloud Driveに置けないかもしれません。その場合は、iCloud Driveの同期対象フォルダの中に専用のフォルダを作っても良いでしょう。iCloud Driveの同期対象フォルダは

~/Library/Mobile Documents

です。もちろん、Dropbox, Google Drive, One Driveなどのサードパーティのクラウドサービスでも良いです。

また、これらの同期対象フォルダを、Time Machine対象にもしておけば、前述のように、過去の設定に戻すことも可能です。

シェルスクリプトでESPバックアップする

ということで、ESP全体をTime Machineバックアップ対象で、さらにクラウド同期対象のフォルダにコピーすれば良いわけです。そのためには、

ESPをマウントする
内容をコピーする
ESPをアンマウントする

手順が必要です。ESPをマウントしっぱなしにすれば手間は減りますが、誤操作やセキュリティのことを考えると、不要な時はマウントしない方が良いと考えます。ではこの手順をシェルスクリプトで自動化してみましょう。

ターミナルから

diskutil list

コマンドすれば、SSD/HDDの一覧を見ることができます。複数のSSD/HDDが搭載されていると、/dev/disk0、disk1、disk2と複数のボリュームを確認できます。このドライブ番号の割り当ては起動するごとに変化します。なのでESPのある起動ボリュームの番号も、毎回変動します。一方で、ボリュームやパーティションにはUUID (Universally Unique Identifier)が割り当てられていて、こちらは不変です。

ESPのUUIDは次のコマンドで知ることができます。例えばESPが、disk0s1に割り当てられている場合、

diskutil info disk0s1

とすると、いろいろな情報が出てきます。この中に、

Disk / Partition UUID:    9FXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

というように表示されているのが、ESPのUUIDです。

UUIDがわかれば、次のようなスクリプトで、ESPをマウントして、コピーして、アンマウントできます。

#!/bin/sh
ESPUUID=9FXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
BACKUP=~/Documents/Hackintosh/_currentConfig/Z97A/
diskutil mount $ESPUUID
rsync -av --delete /Volumes/EFI/ $BACKUP
diskutil unmount $ESPUUID

ここでは、書類フォルダの中のHackintosh/_currentConfig/Z97A/の中に、ESPの内容をコピーしています。rsyncコマンドは、-aオプションつけることでバックアップに使えます。更新のあったファイルだけがコピーされます。-vは進行状況を詳しく表示するオプションです。動作確認には便利ですが、後で自動化するときには不要かもしれません。また–deleteは、オリジナルファイルが消去された場合に、バックアップ先でも消去するというオプションです。

ログイン項目に設定する

このシェルスクリプトをログインするたびに動かせば、最新のESPをバックアップしておけます。そこで、「システム環境設定」「ユーザとグループ」からログイン項目に追加してみます。起動に失敗したらスクリプトは動かないので、必ず動く状態のESPがバックアップされます。バックアップ先がTime Machineの対象なら過去に遡って設定を復元できますし、クラウド同期対象なら他のマシンから見ることができます。

なお、シェルスクリプトをログイン項目に追加する場合には、拡張子をcommandにしておく必要があります。commandの場合は、ファインダからの起動でTerminal.appが起動するからです。

Automatorでアプリケーションにする

これまでの方法で、全く問題なくバックアップできるのですが、ログイン直後にTerminal.appが起動したままになるのがちょっと邪魔です。この問題は、シェルスクリプトをアプリケーションにすれば解決します。

macOSには、シェルスクリプトをmacOSのアプリケーションにしてしまう、便利なツールがあります。Automator.appです。これを使えば、通常のアプリケーションと同様に、アイコンをダブルクリックすると単体で起動するようになります。今回は使いませんが、ドラッグ&ドロップも機能します。

Automator.appを起動し、アプリケーションを選び、アクションから「シェルスクリプトを実行」をドラッグもしくはダブルクリックで選びます。右に出たウィンドウに、先ほどのシェルスクリプトをコピー&ペーストします。

これを保存すれば、シェルスクリプトがmacOSアプリケーションになります。

これをログイン項目に登録すれば、バックアップが実行された後、痕跡なく終了します。

Windowsと同居する

Sun, 14 Jan 2018 14:48:50 +0900

Hackintoshで使うコンピュータはもともとWindowsをインストールする前提で作られているので、当然ながらWindowsも走ります。本物のMacでは、Boot CampというツールでWindowsを動かすようにしますが、その必要はありません（そもそもBoot Campは使えません）。今回は、macOSとWindowsのマルチブートを設定するときの注意事項を書いてみました。

別ドライブにインストールするのが楽

WindowsとmacOSを同一の物理ドライブの別パーティションにインストールすることは可能ではあります。でも色々面倒なので、できれば別の物理ドライブに、macOSとWindowsを分けてインストールするのが簡単です。デスクトップPCなら複数ドライブ搭載は簡単だと思います。

同一のドライブの別パーティションにmacOSとWindowsをインストールしようとすると、それぞれがESPを書き換えることになります。Cloverで設定したものが、Windowsをインストールすると動かなくなります。もう一度、設定すれば良いのですが、かなり面倒です。このような問題は、ESP以前のMBR（マスターブートレコード）を使っていた時代からありました。物理的に別のドライブにインストールすれば、それぞれのESPに個別に起動項目が書き込まれるので、干渉しません。別のドライブにインストールされたWindowsは、UEFI/BIOSの起動メニューで選択することもできますし、Cloverの起動選択画面からも起動できます。

最近の経験では、そもそもパーティションスキームが違ってインストールできないこともありました。特にAPFSになって採用された新しい論理パーティションなどは、Windowsインストーラから使えません。なので同じドライブにインストールしようとする場合は、パーティション分けの方法も面倒になり、試行錯誤が必要になると思います。

インストールに関係ないドライブを外す

Windowsをあまり使わないこともありますが、Windowsインストーラの挙動は、いまだに謎です。インストール対象のドライブ以外のドライブがコンピュータに多数接続されていると、インストールできないことがあります。もしかしたら接続されているドライブがmacOS用にパーティション分けされていたのがいけないのかもしれません。関係ないドライブは外しておいた方が良いです。

先日、m.2 SSDを外すのが面倒だったので接続したまま別ドライブにインストールを試みたら、m.2 SSDのESPに起動ファイルが書き込まれてCloverが起動しなくなってしまいました。Windowsインストーラは、インストール先として指定しないドライブを書き換えることもあるようです。面倒でもm.2 SSDを外すか、せめてUEFI/BIOSでm.2を読めないように設定して、Windowsインストールするのが良いと思いました。

時刻を合わせる

macOSとWindowsを切り替えて使用すると、時刻が合いません。9時間だけずれます。macOSはUTC (協定世界時: Coordinated Universal Time, 昔はグリニッジ標準時GMTと呼ばれていた時刻）を使っているのに対して、Windowsは現地時間を使っているからです。

コンピュータは、ファイル作成時刻などを管理するために、時計機能を備えています。マザーボードにはRTC（リアルタイムクロック）というチップが搭載されていて、電源が切れている時も、ボタン電池で時刻を刻んでいます。時差の違う場所に置かれたコンピュータ同士をネットワーク接続で使うことを考えると、コンピュータの時刻はどれか一つの基準時間を使うべきです。そうするとUTCを使用するのが順当です。ということで、macOSやLinuxなどのUNIX系のOSでは、UTCで時刻を管理して、必要に応じて現地時間に換算して表示しています。

UNIX系OSは専門家が使う高価で大掛かりなコンピュータのためのOSとして開発されました。一方、Windowsの先祖は、単独で動く簡素な個人用コンピュータ（マイクロコンピュータ、マイコン）で使われたOSです。昔のコンピュータには電池バックアップのRTCなどなかったので、起動時に時刻を入力させられました。個人ユーザがいちいちUTCと時差を入力するのは面倒なので、マイコンの時計は現地時間に設定することになっていました。それでWindowsは今でもRTCを現地時間に設定していて、UTCが必要な場合には、現地時間から換算しています。

RTCがUTCでも現地時間でも、必要に応じて換算すれば良いので問題はありません。でも、macOSとWindowsで同一のRTCを共有すると、OSを切り替えるたびに時間がずれてしまいます。Boot Campではこの問題を解決するドライバが用意されています。Hackintoshでは、当然ながらそういう配慮はありませんので、自力で解決することになります。

WindowsをUTCにする

WindowsとmacOSのどちらを相手に合わせても良いのですが、歴史的な経緯で仕方なく(?)現地時間を使っているWindowsを正統なUTCに切り替える方が簡単です。これにはレジストリを書き換えます。Windowsでregedit.exeを実行するとレジストリエディタが起動します。

左の階層から、コンピュータ、HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Control, TimeZoneInformationと辿っていきます。TimeZoneInformationで右ボタンクリックでコンテクストメニューを呼び出し、「新規 (N)」「DWORD (32ビット) 値(D)」を選択します。

ここで、RealTimeIsUniversalという値を作り、この名前をダブルクリックして設定ウィンドウを開き、値を1に設定します。このあとWindowsをシャットダウンし、一旦macOSを起動して、またWindowsに戻ってくると、Windowsの時刻がmacOSと一致します。

コマンドプロンプトで設定する

フォーラムで教えていただきましたが、レジストリエディタを使う代わりに、Windowsのコマンドプロンプトから設定することも可能のようです。以下のようにタイプします。

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

CPU不具合対応10.13.2追加アップデートで性能低下する？

Tue, 09 Jan 2018 23:52:06 +0900

CPUのMeltdownとSpectreという脆弱性が話題になっていて、これに対応したmacOS 10.13.2 Supplemental Updateが早速公開されました。これによりmacOSのbuildは17C88から17C205になります。アップデートは、App Storeからダウンロードしてそのまま自動実行するだけでした。再起動時のClover起動パーティション選択画面でも、Boot macOS Install from …の項目が自動的に選択されましたので、ノータッチでアップデートします。OSでサポートされているグラフィックスカード(Radeon RX 580)でしたので、アップデート後も問題なく画面表示しました。www.tonymacx86.com

この脆弱性自体はCPU固有のもので、OSからは影響を緩和することしかできないとも言われています。とはいえ、そんなに心配するものでもないようです。

support.apple.com

ただ、Windowsで対応アップデートをした結果30%程度性能が低下したという話題もあって、気になるところでした。ということで、今回のアップデートを当てる前と、当てた後でベンチマークをとってみました。結論から言うと、性能低下はありませんでした。使用したCPUはCore i7-4790Kです。

CINEBENCH R15

アップデートを当てる前のCPUスコアは833cbだったのに対して、アップデート後は831cbでした。測定ごとにもっと変動しますので、この差異は測定誤差内です。

Geekbench 4.0.4 Tryout

こちらはスコアが上がりました。アップデートを当てる前のMulti-Core Scoreは14537だったのに対して、アップデート後は15337でした。

メモリへのアクセスが低下するという情報もありましたが、メモリスコアも上がりました。Multi-Core PerformanceのMemory Scoreは、アップデートを当てる前が4572だったのに対して、アップデート後は5124になりました。

ということで、10.13.2 Supplemental UpdateでCPU性能が低下する心配はないようです。

追記

10.13.2追加アップデートに対応するNVIDIA Webドライバも出たようです。いつも通りのアップデート方法で、NVIDIAグラフィックスカードを使っているマシンが高解像度表示が可能になりました。NVIDIAの中の人は、いつもながらドライバのアップデートが早くてありがたいです。

www.insanelymac.com

起動失敗に備えてバックアップ

Wed, 03 Jan 2018 12:01:34 +0900

Hackintoshでkextを入れ替えたり、config.plistを書き換えたりなど、色々実験していると、起動しなくなる状況に遭遇することがあります。そんな場合に対処できるように、起動可能なパーティションのバックアップを持つことは、Hackintoshを使う上での必須の習慣だと思います。

バニラなインストールをすると、SSD/HDDの本体パーティションにmacOSが入り、macOSでは使用しないEFI System Partition (ESP)にClover bootloaderやkext類がインストールされます。

/posts/131/

Hackintoshが動かなくなったことに備え、バックアップする対象は、以下のいずれかになります。

ESPとmacOSインストーラ
ESPとmacOS
ESPのみ

それぞれについて、以下で説明します。

1. 導入用USBメモリを残しておく

一番普通の方法かもしれません。一般的な手順では、USBメモリにmacOSインストーラを作り、これにCloverをインストールします。このUSBメモリを大事に保存しておけば、本体が起動しなくなった場合に利用できます。これがあれば、一切を消去してもう一度インストールし直すことができます。でも、そこまでやらなくても、macOSインストーラで起動できれば、ターミナル.appを起動することができるので、かなりの作業が可能です。起動失敗を引き起こしたkextを取り除いたり、config.plistを元に戻したりできます。

またバニラなインストールがされていれば、ESP部分を書き損じても、macOS本体は正しく残っている可能性が高いです。USBメモリのCloverで起動して、起動しなくなったドライブのmacOSから起動できれば、修復作業が容易です。

この方式の難点は、非常用のUSBメモリは滅多に使わないので、失くしてしまいやすいことです。手元にあるとついつい他の用途に使ってしまいます。気軽に使えないようにPCケースの中に入れておくのも良いかもしれないです。

2. CloverとmacOSを複製しておく

バニラなインストールをしていれば、macOS本体に手を入れることはないので、Hackintoshの不具合でmacOS本体を壊す危険はありません。でも、macOSのバージョンアップ、特に年に一回のメジャーバージョンアップに備えて、CloverとmacOSの両方をインストールして、バックアップとしておくのが良いです。

バックアップのためには、いつも使うSSD/HDDとは別のドライブに、macOSとCloverをインストールします。通常のインストールと同様に、インストール用のUSBメモリから起動して、対象とするドライブのパーティションをフォーマットして、macOSとCloverをインストールしても良いです。でも、すでに起動できるmacOSドライブがあってこれをバックアップするならもっと簡単です。以下のようにできます。

App StoreからダウンロードするmacOSインストーラを起動して、対象とするパーティションにmacOSをインストールします。
必要ならば移行アシスタントを使って現在の設定とアプリケーションもバックアップします。
対象とするドライブのESPに、現在起動しているESPの内容をコピーします。（Cloverインストーラを起動しても良いですが、ファインダによるドラッグ&ドロップだけでもバックアップできます）

もしマシンに複数のHDDを接続していて、その一部をデータ用やTimemachine用にしているような場合、そのHDDの最初に60GBくらいのパーティションを用意します。そしてこのパーティションとESPそれぞれに、上記の手順でmacOSとCloverを入れておくと良いです。macOS自体は30GB弱あればインストールできます。60GBあれば必須のアプリケーションと多少の作業は可能です。内蔵HDDにバックアップを用意しておけば、USBメモリと違って紛失する心配もありません。

3. ESPを複製しておく

バニラなインストールをしておけば、Hackintoshに必要なものは全てESPに入っています。設定を変えて起動しなくなる場合も、ほとんどの場合がESPの内容を書き換えてしまったことが原因です。そこで、ESPだけをバックアップしておけば、大抵の場合は、これから起動することで復帰できます。ESPは容量も少ないですので、バックアップも容易です。データ用のHDDやUSBメモリでは使われていない領域ですので、あちこちにバックアップしておくと良いです。内蔵SSD/HDDにも、空のESPがあったら、今使っているESPの内容をコピーしておきましょう。

ESPにあるファイルだけを、ファイルサーバやクラウドに保存しておいても良いと思います。これまでの説明で用意したバックアップのSSD/HDD/USBメモリが全て無くなってしまっても、ESPの内容さえ持って入れば、手元のSSD/HDD/USBメモリのESPにコピーして起動させることができます。

4. ESPを自動バックアップする

**追記：**ESPを自動的にバックアップする方法をこちらに書きました。

ESPを自動バックアップする

Cloverから季節のご挨拶

Wed, 27 Dec 2017 10:07:02 +0900

（更新：2017.1.2 新年の起動画面を追加）

クリスマスになってCloverの起動画面がクリスマス仕様になりました。最初にこれを見た年はびっくりしたので、今年からHackintosh始めた人は新鮮だったのではないでしょうか。ちなみに、新年になったら今度はしばらくの間、新年仕様に変わるはずです。旧漢字TalkとかMac OSでは新年になると「あけましておめでとうございます」表示が起動画面に出てました。Macintoshはそういうのを楽しむ文化なんですね。

とはいえ、複数の設定切り替えを、テーマの切り替えで確認していた人には、全部がクリスマス／新年になってしまうので厄介です。年末年始はHackしないでゆっくり休みなさいという意味かもしれませんが。また、もしかしたらクリスチャンじゃ無いからクリスマスは要らないという人もいるかもしれません。この機能を消して、通常の、設定済み起動画面に戻すのは簡単です。

ご挨拶の消し方

起動画面を定義するCloverの設定フォルダであるthemesにchristmasもしくはnewyearという名前のフォルダが入っているかと思います。これらはCloverのインストーラがデフォルトでインストールしますので、大抵はあるはずです。バニラなインストールでCloverをESPに入れてあるなら、christmasやnewyearは、EFI/CLOVER/themes/の中にあります。これらの名前のフォルダがあると、年末年始に自動的に切り替わります。そこでフォルダ名を別の名前に変更する（例えばchristmasをchristmas2などに変える）と、「季節のご挨拶」機能は効かなくなります。

新年のご挨拶

新年になりました。Cloverの起動画面も新年バージョンになりました。今年もよろしくお願いします。本物のMacで新年が祝われなくなってしまって、祝ってもらえるのはいまやHackintoshだけというのが面白いですね。以前から疑問なのですが、クリスマスツリーのような門松飾りのようなイラストは何なのでしょうか。Clover開発チームの居るロシアでの新年モニュメントなのかもしれないです。ご存知の方いらしたらよろしく。

HackintoshのOSアップデートは難しい？

Sun, 24 Dec 2017 16:34:39 +0900

「Hackintoshは最初は動いてもmacOSのアップデートのたびに大変なトラブルに陥る」というイメージがあるかもしれません。Apple社がちゃんとサポートしてくれている実機に比べたら面倒なのは確かですが、それほど変わらないと思います。macOSが好きで、動かないコンピュータを動かすことが趣味な人間が言うことですので、あまり当てにはなりませんが、

マイナーアップデートは楽勝

です。例えば10.13.1から10.13.2へのアップデートのように、年に数回行われるマイナーアップデートは実機と同じくらいのお手軽さです。少なくともここ2-3年の状況では、Cloverとkextを最新に保っておけば、App Storeからのアップデートをそのまま受け入れて、macOSアップデートしてもまず問題は起こりません。

NVIDIAのグラフィックスカードでWeb driverを使っている人は、新しいmacOSに対応したドライバが配布されるまで高解像度表示ができなくなるかもしれません。でもNVIDIAの対応はいつも敏速で、ほぼ24時間以内に新しいドライバを配布しています。Mac Proのユーザも多いのでしょうが、Hackintoshユーザからしたらありがたいメーカーです。

メジャーアップデートは少し大変

ここのところ年に一度、9月にあるメジャーアップデート（例えば10.12から10.13へのアップデート）は少し面倒な作業が伴います。それも年に一度のお祭りとして楽しんでいただければ良いと思います。

最近の出来事ですと、10.11でUSBの個数制限が行われて使用可能なUSBポートの数が、コントローラ当たり15までと制限されました。この制限を解除したり、制限の枠の中で使用するポートを指定する作業が必要でした。

USBポートを設定する

10.11ではSIPも導入されました。/S/L/Eや/L/Eにkextを置く場合ではSIPを無効にする設定が必要になりました。バニラなインストールをすればSIPはデフォルトでも大丈夫です。

/posts/132/

10.13ではAPFSが導入され、実機でファームウェアアップデートが行われました。それに合わせて、HackintoshでもSMBIOSの変更が必要でした。APFSボリュームから起動するためにはドライバも入れておかねばなりません。

HackintoshをHigh Sierraにする

このようにメジャーアップデートでは予期しない課題が発生する可能性がありますので、古いmacOSはそのまま残して、予備のSSD/HDDにシステムを作って動作を確認した方が良いと思います。パブリックベータが配布されている時期か試しておけば、正式リリースの時にいち早く導入できるかと思います。

アップデートは面倒なことだけではなく、新しいCPUへの対応、NVMe SSDの対応、ビデオカードの対応など、新しい技術の恩恵にあずかれるチャンスですので、積極的に受け入れていきたいと思います。

10.13.2へのマイナーアップデートで躓く

マイナーアップデートは楽勝と書きましたが、最近、躓いたことを書いておきます。メインで使用しているHackintoshで10.13.1から10.13.2へのアップデートをしたのですが、これはApp Storeからのダウンロードだけで簡単に終了しました。10.13.2でスリープが効かなくなったとかの噂も聞くのですが、全く問題ありません。

ところが、サブで使っているマシンでアップデートしようとしたら、インストールのための再起動で失敗しました。Boot macOS Install from xxxxが選択された、起動しようとするところで失敗し、再び再起動を無限に繰り返すようになりました。

たまにしか使わないサブのマシンでしたので、しばらくはあきらめて10.13.1の古いままで使っていました。このところ時間もできたのでじっくりと原因を探して見たら、なんとkextの一つ、Lilu.kextが古いだけでした。Lilu.kextは10.13.2のベータ版に合わせて11月上旬に1.2.1に更新されています。メインのマシンでは早々と更新していたのですが、サブマシンでは1.2.0のままでした。とほほな単純ミスでした。

ということで、最初にも書きましたが、Cloverとkext類は最新に保っておきましょう。

Hackintoshでマイニング（入門編）

Wed, 20 Dec 2017 01:22:37 +0900

寒いですね。寒いのでオイルヒーターをつけようとしたのですが、キロワット級の電力を熱に変えるのなら、目の前にある自作PCにやってもらおうと思いつきました。ついでに仮想通貨を採掘すれば電気代の節約にもなります。そこでHackintosh でマイニングしてみました。なお、マイニングは全くの初心者ですので、いい加減なことを書いていると思います。ご容赦ください。

色々検索したところ、 MinerGate.comというところに行けば簡単に採掘を始められると書いてありました。

minergate.com

Hackintoshのtonymacx86.comみたいなところでしょうか。メールアドレスでアカウントを作って、パスワードを作って、採掘ツールをダウンロードします。意外だったことに採掘ツールにはmacOS版もあるのですね。検索したところ、macOSで採掘したという人もたくさんいました。

ということで当然ながらmacOS版の採掘ツールをダウンロードしました。採掘ツールは、こんなアイコンのMinerGate.appというアプリケーションです。

起動すると、今一番レートの良いお薦めの通貨の採掘ページが出ます。いまはMonero（通貨単位はXMR）というのがお薦めのようです。CPUマイニングのボタンを押すと、早速開始します。コア数を、いくつ使用するかを決めることもできます。4790Kの全8コア総出の設定で動かしたところ、180 H/s (ハッシュ毎秒）程度でした。

聞いたことのあるEthereumという通貨（単位はETH）を試してみたら650kH/s程度でした。

CPUマイニングボタンの隣にはGPUマイニングのボタンもあります。しかし残念ながらmac版ではサポートされてないようです。強力なグラボを何枚も搭載できるHackintosh なら是非ともGPUマイニングを試したいところです。

EthereumのGPU採掘を行うツールは多数開発されていて、ほんの一部ではmacOSでも動くようです。MinerGate.comのこのページでリンクが案内されています。

minergate.com

また、上で紹介されているethminerというツールをmacOSで使うにあたっての簡潔な使い方説明が、以下にあります。

steemit.com

このサイトで紹介されている下記のサイトからethminerのバイナリをダウンロードしてみました。

github.com

グラフィックスカードが認識されているかどうかは、以下のオプションで確認できます。

$ ./ethminer -G --list-devices

OpenCLではなくてNVIDIAのCUDAを使う場合は、-Gのところを-Uにするようですが、上記のサイトからリンクされているバイナリーはCUDAに対応していないようです。コンパイルのオプションで対応できるようなので、ソースからコンパイルすれば可能なのかもしれません。

その結果、手元のマシンでは、搭載しているAMD Radeon RX 580と、Haswell CPUの内蔵GPUが表示されました。RX 580はメモリーサイズなども正しく認識されているようですが、Intel HD GraphicsはなぜかIris Proになっています。

Listing OpenCL devices.
FORMAT: [platformID] [deviceID] deviceName
[0] [0] AMD Radeon RX 580 Compute Engine
 CL_DEVICE_TYPE: GPU
 CL_DEVICE_GLOBAL_MEM_SIZE: 8589934592
 CL_DEVICE_MAX_MEM_ALLOC_SIZE: 2147483648
 CL_DEVICE_MAX_WORK_GROUP_SIZE: 256
[0] [1] Iris Pro
 CL_DEVICE_TYPE: GPU
 CL_DEVICE_GLOBAL_MEM_SIZE: 1610612736
 CL_DEVICE_MAX_MEM_ALLOC_SIZE: 402653184
 CL_DEVICE_MAX_WORK_GROUP_SIZE: 512

採掘を行うためのコマンドオプションも上記のページで紹介されています。以下は、登録したeメールアドレスが例えばsiroanko@icloud.comの場合の例です。$ ./ethminer -G -S eth.pool.minergate.com:45791 -O siroanko@icloud.com結果は以下のようになりました。4.3MH/sくらい出ているようです。4790KによるCPUマイニングに比べるとRX 580によるGPUは7倍くらいの性能が出るようです。

さて4.3MH/sというのが、いくらくらいの収益になるのか気になるところです。以下のサイトで、調べることができます。

www.cryptocompare.com

それによると4.3MH/sで採掘すると1ヶ月あたり$14.6の収益のようです。電気代を1kWhあたり$0.2とした場合、200Wの電力を1ヶ月消費すると$28.8のようです。なので、稼ぐ金額の倍の電力を使ってしまう計算になります。

でも、Hackintoshをオイルヒータの代わりに使うと、同じ暖かさを得るのに半分の電力で済むという計算です。これはすごいのではないでしょうか。

おまけ

このハードウェア構成で、信者としてはあまり動かしたくないWindowsを起動して、Windows版のMinerGateアプリを動かしてみました。GPUマイニングは10.6MH/s程度でした。CPUはあまり変わりません。GPUの利用に関してはWindowsのアプリの方が最適化されているようです。この性能なら、先ほどの電気代がかかっても月に$7くらいのギリギリの黒字になります。電気代がゼロもしくはマイナスで、暖房できるのはやはり凄いです。

本気編に続きます。

Hackintoshでマイニング（本気編）

ネットワーク経由で操作する

Sun, 10 Dec 2017 12:38:08 +0900

Hackintoshをインストールするときに、すぐに稼動できることは稀で、色々な状況で起動できないことがあります。起動プロセスが停止してしまったり、カーネルパニックを引き起こすこともあります。場合によっては、グラフィックスの設定が悪くて表示が出ていないだけで、OSは起動していることがあります。その場合は、ネットワーク経由で他のコンピュータから接続して、設定をやり直すことが可能です。なので、macOSをインストールしたらすぐにリモートログインと画面共有を有効にしておくと良いです。

リモートログイン(ssh)を設定する

システム環境設定–>共有のサービスリストからリモートログインをオンにしておきます。そうすると「このコンピュータにリモートからログインするには、’ssh xxx@192.168.0.xxx’と入力してください。」という表示が出ます。IPアドレスはDHCPにしている場合が多いと思いますが、それほど頻繁に変わらないので、メモしておくと良いです。

sshでログインできれば、ターミナルから設定できることは全てできます。

画面共有(vnc)を設定する

macOSに限らずUNIX系のOSは（多分Windowsも）、ターミナルのような文字操作で全ての基本操作ができるものです。同じことをGUIからも簡単に操作できるようにしているだけです。なのでsshでログインできればかなりのことに対応できますが、画面共有ができればもっと楽です。

システム環境設定–>共有のサービスリストから画面共有をオンにすると、「ほかのユーザは、vnc://192.168.0.xxx/でこのコンピュータの画面にアクセスしたり、Finderのサイドバーで’xxxx’を検索したりできます。」という表示が出ます。Finderで検索できるので、IPアドレスがわからなくても接続できます。

Terminalから画面共有をon/offする

sshで接続はできるけど、画面共有 (vnc)がオフになっていたことがあります。マシンは生きていて接続できるのに、細かい操作ができなくてもどかしい思いをしました。画面共有は実はターミナルからオンにすることも可能です。なので、このような場合は、sshから以下のように入力します。（改行されているように見えますが1行で入力します）

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -clientopts -setvnclegacy -vnclegacy yes -clientopts -setvncpw -vncpw mypasswd -restart -agent -privs -all

こうしてonになった画面共有は、システム環境設定でのオン・オフと違うようで、システム環境設定画面には反映されないです。これをオフにするには、以下のようにします。

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -configure -access -off

HackintoshでmacOS Serverを運用

Sun, 03 Dec 2017 22:42:38 +0900

更新：MojaveになってmacOS Serverからほとんどのサーバ機能が廃止されてしまいました。廃止された機能の多くはmacOSに移行されたので、macOSでサーバを立上げるメリットはまだあると思います。

macOSは基礎がUNIXなのでWindowsに比べてネットワークやサーバ関連のツールが充実しています。最初からApacheやsshdやPHPなどが搭載されています。なのでサーバとして使うのにも適しています。

Server.appを購入する

Server.appというアプリケーションはApp Storeで購入できます。これをインストールするとmacOS Serverになります。macOSは無料なのですが、Serverは2,400円します。しかし、昔はユーザ数無制限のMac OS X Serverが10万円くらいしたことを考えると、夢のような価格です。

もっとも、現在のServer.appは、OSそのものではなくて、すでに搭載されているサーバ機能をonにしたり、設定を管理するユーティリティです。昔のようにOSをインストールする手間に比べると、今のmacOS Serverは気軽に導入できるかと思います。

HackintoshでServerするメリット

HackintoshでServerするメリットは多いと考えています。Hackintoshで比較的難しい課題は、iMessageなどのiCloud関連のアプリケーションをちゃんと動かす、iOSやwatchOSとの連携をする、グラフィックスを正しく動かす、スリープを機能させるなどです。どちらかというとクライアントとして使う上での課題です。一方で、24時間稼働させるサーバならば、スリープなどの電源管理はあまり重要ではないです。ディスプレイやキーボード無しで運営するなら、グラフィックス機能は不要です。ssh接続や画面共有で設定すれば良いからです。なので、ちゃんと動くサーバを作ることは、完璧に動くデスクトップマシンを作るよりずっと簡単です。

また、必要とするサーバに特化したハードウェア構成が自由に選べるのもHackintoshのメリットです。

大きなPCケースを選んで、大容量のHDDを多数搭載したサーバを作ることもできます。複数のHDDをRAID 1構成にして、HDD障害に敏速に対応する体制を作ることもできます。また、大容量のHDDを搭載して、TimeMachineサーバを作ることもできます。TimeMachine機能を使って、大容量HDDにサーバー自身のバックアップを作っておくことも簡単です。

このような重量級サーバが作れる一方で、NUCなどを使えば、低消費電力のサーバを作ることもできます。NUCはMacBook Airなどで搭載するモバイル用の低消費電力CPUを搭載しているにも関わらず、メモリやストレージなどは簡単に増設できます。家庭で24時間稼働させる小型の省電力サーバを作るのには最適かと思います。

（NUC消費電力の例）

macOS Serverで何ができる

ではmacOS Serverで何ができるかというと、実のところ多少微妙なところはあります。例えば、Linuxでサーバを作る方が、多彩なサーバを作ることができます。様々な構成を自作できるメリットはHackintoshと同じです。macOSも、土台がUNIXなので、様々なサーバ機能をLinuxと同じく手作業で設定することももちろん可能です。ただ、これらの設定は、OSのバージョンアップで動かなくなる可能性があります。また、運用しているユーザも少ないので、情報が得られにくいです。macOS Serverが提供している機能だけを素直に使用するのが簡単だと思います。

一方、macOS Serverは、できることが限られていますが、サーバとしては比較的簡単に設定して、管理することができます。代表的な機能は、Webサーバ、VPNサーバ、メールサーバ、DHCPサーバ、DNSサーバ、カレンダ、メッセージ、連絡先などのサーバがあります。あまり使わないかもしれませんが、プロファイルマネージャサーバ、Netinstallサーバ、Xsanサーバがあります。VPNは、当然ですがmacOSクライアントと相性が良いので、設定が楽です。ちなみに、ファイルサーバ機能は、macOS通常版で提供されていて、macOS Serverには特に機能がありません。また、コンテンツキャッシュ（ソフトウェアアップデートやiCloudのキャッシュ）とTimeMachineサーバの機能は、High Sierra Server機能ではなくなり、High Sierra通常版で提供されるようになりました。コンテンツキャッシュはiCloudデータをキャッシュしてくれるので、自宅と職場で同期するなどの場合に、遅延の少ない確実な同期を期待できます。TimeMachineと共に、便利な機能なので、クライアントmacOSの機能に格上げされたのだと思います。

macOSが提供するサーバ機能の多くは、QNAPやSynologyなどのNAS製品を使えば、使いやすいインタフェースで構築可能です。でも、外部から接続できる常時稼働macOSマシンがあると、いろいろな場面で便利かと思います。

Clover画面から不要項目を除外

Fri, 10 Nov 2017 13:33:52 +0900

Cloverの起動画面には、起動選択項目がアイコンで並んでいます。この項目に、選んでも何もおきない項目が現れることがあります。その理由と、不要な起動項目を消す方法を書いておきます。

Boot macOS Install from xxxの項目を消す

macOSのインストールの過程でこの項目が出るようになります。

正常にインストールが終了するとこの項目は自動的に消えるのですが、何かの手違いがあると残ってしまいます。インストール途中だと判断されてこれがデフォルトで選択されてしまうこともあります。また、次に上書きインストールをすると、これが多数現れることになり、どれが本物か分からなくなります。ターミナルから以下のようにタイプすると消えます。

sudo rm -R /Volumes/xxx/.IABootFiles

.IABootFilesは.で始まる隠しディレクトリなので、ls -aじゃないと見つかりません。このディレクトリの中のcom.apple.Boot.plistを見るとインストールのために使用するInstallESD.dmgとかBaseSystem.dmgへのパスが書いてあります。大昔にインストールした名残だとすると、その場所にはもう無いので当然のことながら起動に失敗します。

Boot macOS install from xxx – Dataの項目を消す

Catalinaからメインの起動ボリュームが2個の論理ボリュームに分割されて、xxx – Dataというボリュームが追加されました。xxxはMacintosh HDのような起動ボリューム名です。- Dataの方には、変更できる内容が入り、従来の- Dataが付かない方には書き換えては困るシステムのデータが入っています。

この方式では、インストール用のデータはxxx – Dataの方にはいるようで、インストールに失敗するとBoot macOS install from xxx – Dataという項目が居残ってしまいます。これの消去方法をコメントでSuperBypassさんから教えていただきましたので以下に追記しておきます。つまり、/System/Volumes/Dataの中にmacOS Install Dataというディレクトリがあるので、これを消去すれば良いようです。こちらが参考になるそうです。

ただ、この中にあるLocked FilesというディレクトリがSIPでアクセス禁止されていますので、SIPを解除して、sudoで/System/Volumes/Data/macOS Install Dataを消去します。

xxx from Prebootの項目を消す

こちらは単なる見た目の問題です。

APFSになってから、Recoveryに加えて、Prebootというパーティションが起動項目に新たに加わって煩雑になりました。下の例は、メインのSSDに加えて、バックアップ用のHDDを接続したマシンのClover起動画面です。SSDにはAPFSフォーマットでMacintosh SSDというパーティションが作ってあり、High Sierraがインストールされています。メインのSSDに関係する起動選択肢は右の4個です。

4個の起動項目には、以下の名前が付いています。

Boot FileVault Prebooter from Preboot
Boot macOS Installer Prebooter from Preboot
Boot macOS from Macintosh SSD
Boot Recovery from Recovery

APFSになってから、Recoveryに加えて、Prebootという選択肢が起動項目に新たに加わって煩雑になりました。

追記：最近、FileVault関係の起動メニューは現れていません。CloverのFileVault関連のEFIドライバを入れないことにしているのが関係しているかもしれません（2018/12/15)

diskutil listコマンドでこのSSDを見ると次のようになっています。

/dev/disk1 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +500.0 GB disk1
 Physical Store disk0s2
 1: APFS Volume Macintosh SSD 331.6 GB disk1s1
 2: APFS Volume Preboot 46.0 MB disk1s2
 3: APFS Volume Recovery 517.0 MB disk1s3
 4: APFS Volume VM 20.5 KB disk1s4

PrebootというAPFSボリュームができているようです。APFSボリュームは、物理的なボリュームではなく、APFSコンテナの中に作られた仮想的なボリュームで、それぞれが記憶領域を共有していて追加・削除が簡単です。

APFSのVolumeを活用する

PrebootというAPFSボリュームは起動時の作業に使用するボリュームのようです。Prebootの名前のついた起動メニューを選択して起動しても、結局は本体のシステムが起動するようです。選択肢に表示される意味がないので、非表示にしてみましょう。

使わない起動選択肢を非表示にして、起動画面をスッキリさせることは、config.plistの記述で簡単に行えます。config.plistのGUIセクションに、Hideというキーを用意して、

        <key>GUI</key>
        <dict>
                <key>Hide</key>
                <array>
                        <string>Preboot</string>
                </array>

とすれば、Prebootボリュームに含まれる起動オプションは表示されなくなります。（1項目だけなのでarrayにする必要はないかもしれませんが、サンプルがarrayでしたし、将来増やしたいときのためにarrayにしておきました。) 結果がこれです。

必要な選択肢だけが表示されるようになりました。他にも表示から外したい選択肢があったらconfig.plistのHideの項にで挟んで追記していけば良いです。Hideの項で消してしまった項目を選択したくなった場合は、Clover選択画面でF3キーを押します。隠されたボリュームも表示されるようになります。

更新：Prebootボリュームを削除する手法を削除しました。(2018/12/15)

パワーマネジメントを設定する

Wed, 01 Nov 2017 14:02:02 +0900

MacintoshのCPUには電力管理(パワーマネージメント)の機構が搭載されていて、CPUの負荷が下がるとクロック周波数を下げて、消費電力を削減します。Intel Power Gadgetでその様子を確認できます。大抵のマシンでは、特段の設定をしなくても、クロック周波数が変動して電力管理が実施されます。

Intel Power Gadget

以下は、初代Intel NUCのDC3217IYEでの例です。CPUはIvyBridgeのCore i3モデル、3217Uです。真ん中のグラフがクロック周波数です。電力管理がされていないために、クロック周波数が定格近くの1.7GHzに張り付いて一定になっています。車に例えたらアクセル踏みっぱなしのフルスロットルで運転しているような状態です。

デスクトップ向けのCPUで自作すると、特別な処置をしなくても大抵は正しく電力管理されていて、クロック周波数のグラフは負荷に応じて変動することが多いです。実機ではこのCPUシリーズのi5モデルである3317UがMacBookAir5,1で採用されてますが、i3 3217Uを採用した機種はありません。その関係でCPU情報がOSに登録されてなく、電力管理が効いていないと思われます。

そんな時はPikeさんが作ってくれたスクリプトを動かしてSSDT.amlファイルを作ると改善することがあります。

GitHub - Piker-Alpha/ssdtPRGen.sh: Script to generate a SSDT for Power Manage…

まずは、ここからssdtPRGen.shというスクリプトをダウンロードします。そしてこれをターミナルで実行します。すると、~/Library/ssdtPRGen/にSSDT.amlができています。これをEFI/CLOVER/ACPI/patched に入れて再起動します。

DSDTについてはこちらで説明しましたが、

DSDTを編集する

SSDTはDSDTの補足ファイル、サブセットのような位置付けです。DSDTの一部を補足したり、書き換えたりする内容のようです。Pikeさんのスクリプトは、使用しているCPUに合わせて、電力管理に関する記述を作ってくれます。

この結果、Power Gadgetの様子は、以下のようになりました。

真ん中のグラフが示すように、CPUのクロック周波数が、負荷により変化して、省電力を実現しています。電力消費のグラフは一番上です。3.9WだったCPU消費電力が2.8Wに下がっています。クロック周波数が減少しているので、その分、省電力が達成できています。一番下のグラフに表示されている温度も、7度近く下がりました。

IEEE 1394 (FireWire) を使う

Mon, 23 Oct 2017 13:26:32 +0900

IEEE 1394は昔のシリアルバスの規格です。元々はAppleがFireWireという名前で開発した規格なので、一昔のMacintoshには必ず搭載されていました。Windowsマシンにもだいたい搭載されていました。AV機器でも採用されて、ソニーはi.LINKと呼んでいました。IEEE 1394を搭載したマザーボードもあったのですが、今はありません。

現行のMacintoshでIEEE 1394を使おうとすると、Apple Thunderbolt FireWire アダプタを購入するくらいしか手段はありません。PCIeスロットのついた自作Hackintoshなら、拡張カードで対応できます。

IEEE 1394 PCIeカード

今回は、以下の玄人志向のインタフェースカードを使いました。

Ti社製のXIO2213というチップセットを搭載しています。このカードは、PCIeスロットに挿すだけでmacOS High Sierraで機能しました。他社のカードも、だいたいこのチップセットを使っているようなので、どれでも大抵動くのではないかと思います。玄人志向の製品には、古いPCIe 1.0a対応の製品もあるようですが、Amazonのコメントによると最近のマザーボードとの互換性に問題があるので、この製品の方が良いようです。

大昔のiPodを使ってみる

ずーっと引き出しに眠っていたFireWire時代のiPodをmacOS High Sierraマシンに接続してみました。認識されてなんとiTunesが起動しました。

「システム情報」を見ると、正しく認識されているようです。

i.LINKデバイスを接続してみる

大昔のSONYのminiDVビデオカメラを接続してみました。i.LINKなので電源ピンのない、4ピンのケーブルが必要です。iMovieを起動してみると、ちゃんと認識されて、カメラ入力が可能です。ビデオテープを入れると、再生、一旦停止、早送り、巻き戻しのコントロールも可能です。iMovieに動画を取り込むこともできました。これで大昔のビデオテープを取り込めます。

DSDTを変更してUSBポートを選別する

Sat, 21 Oct 2017 13:19:56 +0900

追記：DSDTの編集例としてのUSB個数制限の回避を説明します。USB個数制限を回避するには、こちらの方法をお薦めします。

15個制限を回避するUSBInjectAll.kextの役割と使用法

DSDTの役割、取得方法、コンパイルの方法、更新方法をこちらで紹介しました。

DSDTを編集する

今回は、簡単な例でDSDTを書き換えるハッキングを試してみます。機能を追加したり、修正するのは難しいですが、機能を削るのなら簡単です。

USBポートを設定する

上の記事では、必要なUSBポートを機能させるために、不使用のUSBポートを除外する方法を説明しました。この記事では、DSDTを書き換えて同じことを実現してみます。

稼働USBポートを確認する

手元にZ97チップセットのマザーボードがあります。Z97は、8本のUSB 2.0と6本のUSB 3.0（最近の表記ではUSB 3.1 gen 1）をサポートしています。USB 3.xには互換性のためにUSB 2.0の線も含まれているので、実際には、USB 2.0が14本、USB 3が6本あることになります。

このマザーボードでmacOSを動かして、IORegistryExplorer.appで認識されたUSB一覧を見てみます。すると、機能しているUSBポートは、以下の通りでした。HSはHigh Speed、SSPはSuper Speed PlusでそれぞれUSBの速度のモードです。HSがUSB 2.0で、SSPはUSB 3です。

つまり、USB 2.0が14本、USB 3が1本見えています。USBの本数が15本と言う制限があり、2.0から先に稼働した結果です。先の記事では、USBInjectAll.kextを使って、不使用のポートを除外して、必要なポートを生かしました。これをDSDTの書き換えでやってみます。

未使用のUSBをDSDTから削除する

USBの使用状況を調べたところ、HS04はどのコネクタにも接続されていませんでした。チップセットには搭載されているけど、配線されていないようです。そこでこれをDSDTから除外してみます。DSDTのソースを見て、HS04で検索します。するとDeviceの記述でアドレスを定義しているらしい箇所が見つかりました。まずはこれをコメントアウトしてみます。

コンパイルしたらエラーが出ました。

ScopeにもHS04に関する記述があるようです。これもコメントアウトします。長いのですが、/**/を使って自動コメントされた箇所があるので、頑張って行頭の//でコメントアウトします。

コンパイルしたら、成功しました。これで作成したDSDT.amlをEFI/CLOVER/ACPI/patchedに入れて、使用して、起動してみます。結果はこうなりました。

無事、未使用のHS04がリストから除外されているのが確認できます。また、15個制限の1個が空いたので、USB 3のポートの一つ、SSP2が新たに有効になりました。

この方法を、他にも使用していないポートに対して実施していけば、15個制限の中に、実際に使用しているポートを全て含めることができます。USBInjectAll.kextなどの追加のkextや、config.plistへのパッチが不要です。ある意味、一番根本的な解決方法です。

DSDTを編集する

Sun, 15 Oct 2017 00:26:18 +0900

DSDT (Differentiated System Description Table) はマザーボードがOSに対して提供するACPI規格に基づく情報です。これを通して、マザーボードの電源イベントに関する情報や、マザーボードが備えている機能、構成部品などの情報を提供します。このテーブルは、メーカーによってマザーボードのファームウェア上に用意されています。

Linux で ACPI の機能が使えないというのはよくある問題です。例えば、ファンが稼働しない、フタを閉じたときに画面がオフにならない、などの問題が発生します。これらの問題は DSDT が Windows しか考えずに作成されているのが原因で、インストール後にDSDTを書き直して（パッチを当てて）修正できます。

Hackintoshの場合、マザーボードがUEFIになってからは、MacintoshのEFIとの差が少なくなったのか、DSDTを改変しなくても動作するようになりました。ただ、ノートPCなどのパワーマネージメントが特殊なハードウェアの場合は、まだDSDT改変が必要です。また、DSDTを書き換えることで、macOSの動作を調整することも可能です。ということで、DSDTの改変のための基本的な手順を紹介します。有用な改変例は、折に触れて、紹介していければ良いかと思っています。

DSDT情報の差し替え手順

DSDTはAML (ACPI Machine Language)というプログラムのようなデータ形式で記述されます。通常は、マザーボードがAMLをOSに提供します。マザーボードとOSの中間に割り込んだCloverは、マザーボードに代わって、本来あるものとは別のAMLをmacOSに渡すことができます。config.plistで

<key>DSDT</key>
  <dict>
      <key>Name</key>
      <string>DSDT.aml</string>
  </dict>

と設定してあれば、

EFI/CLOVER/ACPI/patched/DSDT.aml

の場所・名前のファイルに記述されたAMLがmacOSに渡されます。

DSDTを改変する基本的な手順は、以下です。

マザーボードが提供しているDSDTをDSDT.amlファイルとして入手する
これを逆コンパイルしてDSDT.dslというテキストファイルを作る
DSDT.dslに変更を加える
DSDT.dslをコンパイルしてDSDT.amlを作る
DSDT.amlをEFI/CLOVER/ACPI/patchedに置き再起動する

以下で、この手順の詳細を説明します。

バニラなDSDTを入手する

HackintoshでmacOSが動いている状態では、CloverやHackintosh用kextがすでにDSDTを改変している可能性があります。この状態のDSDTを元に改変を進めると、将来のバージョンのCloverやkextで問題が生じる可能性が高いです。トラブルがあった場合の原因の切り分けも困難になります。そこで、マザーボードが提供しているそのままの（バニラな）DSDTを元に、改変を加えるのが良いです。

Cloverやkextが動く前のDSDTを入手するためには、いくつかの方法があります。シンプルなLinux起動DVDや、MS-DOS起動USBメモリを使って起動して、DSDT.aml取得プログラムを動かして入手することもできます。でも、最近のCloverには、DSDT.aml取得機能がありますので、これを使うのが一番簡単です。Cloverの起動ドライブ選択画面で、F1を押すとヘルプが出ます。

これにあるようにF4を押すと、EFI/CLOVER/ACPI/origin/にDSDTを取得してくれます。実際に実行すると、25種類のファイルがここに保存されます。この中の、DSDT.amlが必要とするファイルです。

MaciASL.appで逆コンパイルする

DSDT.amlは、インテルが提供しているASLコンパイラでコンパイルできます。このコンパイラの機能をGUIから操作して、逆コンパイル、編集、コンパイルなどの機能を全部やってくれる便利なツール（シンプルなIDE: 統合開発環境）がいくつか提供されています。定番は、MaciASL.appです。最新版はこちらで入手できます。

Releases · acidanthera/MaciASL

MaciASLを起動すると、いきなり.dslの情報が表示されます。これは、現在macOSが動いている状態でのDSDTです。なのでCloverなどがすでに改変した後のDSDTです。そこで、前の節で入手したバニラなDSDT.amlを読み込ませます。すると、これを逆コンパイルして人が読める形になった.dsl形式のテキストが表示されます。

MaciASL.appでコンパイルする

改変する前に、逆コンパイルされた.dslのテキストが、正しくコンパイルできることを確認します。逆コンパイルしたものを、そのままコンパイルするのですが、大抵の場合は、エラーが出ます。逆コンパイルが完璧でないことが原因のようです。エラーの一覧が表示されるので、それをクリックするとエラーの箇所を示してくれます。

私の手元の環境では、こんな2個のエラーが出ました。最初のエラーをクリックすると、Zeroという変数の行でした。

プログラムの流れと関係なく唐突に0という変数が出てきたので、エラーを出しているようです。おそらく、元のデータの余白に0が埋め込まれていて、それがそのまま逆コンパイルされたのではないかと思います。

この行だけをコメントアウトすると次の行で同じエラーが出ます。Zeroはかなりの数、続いています。そこでこれを全部コメントアウトします。

2個目のエラーも、Arg0という変数が唐突に現れたことが原因のようです。これもなんかの事情で埋め込まれた意味のない0のようです。

これも（こちらは1行だけでした）

// Arg0

などとしてコメントアウトします。Returnの後の行なので、絶対に到達しない部分ですので、削除して構わないはずです。

その結果エラーはゼロになりました。警告が多数出ていますが、これは無視して大丈夫です。めでたくコンパイルできました。コンパイルエラーは、マザーボードによって違うと思います。でもソースを見ていれば、なんとなく対処法がわかるかと思います。

ファイルメニューから、「Save As…」などを選び、現れるファイルダイアログで、ASLとAMLで保存できます。AMLファイルが、最終的に必要とするファイルですし、次回もこれから逆コンパイルして作業することができます。ただ、コメントなどは消えてしまうので、ASL形式でも保存しておくと良いです。

MaciASL.appで編集する

ASLが表示されているメイン領域で、自由に編集できます。結構使いやすいです。また、パッチするための手順だけが配布されていることがあるのですが、それを読み込む機能などがあります。

DSDT改変で、実際にどんなことができるのかは、今後の記事で、試しながら紹介していきたいと思います。

例えば以下ではUSBの項目を削除してみました。

DSDTを変更してUSBポートを選別する

macOSでRAIDを組む

Thu, 12 Oct 2017 22:19:01 +0900

macOSには、ミラーリング、ストライピング、単純な合算の3通りのRAIDを作る機能が備わっています。RAIDはもともと、安価なディスク(Inexpensive Disks)をたくさん使って冗長なディスクアレイ(Redundant Array)を作って信頼性をあげようという目的で考えられました。なので、ミラーリングを行うRAID 1が本来の姿です。本家のMacintoshで複数のHDDを内蔵できる機種は一部のMac miniだけです（それもSSDを搭載しようとすると、HDDは1台です）。一方でHackintoshなら、大容量のHDDを何台でも内蔵することが可能です。Fusion Driveもそうでしたが、RAIDも、Hackintoshならではのメリットを生かせる機能と言えます。

RAIDはディスクユーティリティ.appからGUI操作で作成することができます。El Capitanの時にRAID作成機能がディスクユーティリティ.appから削除されたことがあります。しかしGUI機能はSierraから復活して、High Sierraでも使うことができます。ディスクユーティリティ.appは、diskutilコマンドを呼び出しているだけですので、GUIで作れなくてもdiskutilコマンドで作ることにできます。

ここでは、ディスクユーティリティ.appを使ってRAID 1を作ってみます。

ディスクユーティリティでRAIDを作る

まずは手元にある古いHDDを2台、Hackintoshに接続しました。そこでディスクユーティリティを起動します。

ファイルメニューからRAIDアシスタントを起動します。ここでRAID 1を選択します。

次のダイアログで、RAIDにするHDDを選択し、次に名前をつけます。RaidOneという名前にしてみました。

これで完成です。

ファインダには、通常のHDDのようにマウントされています。

diskutil listコマンドで確認してみると、/dev/disk1と/dev/disk6に実際のハードディスクがマウントされていて、RAIDのドライブは/dev/disk7にマウントされています。

$ diskutil list
/dev/disk1 (internal, physical):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   GUID_partition_scheme                     *80.0 GB    disk1
   1:                     EFI EFI                  209.7 MB   disk1s1
   2:              Apple_RAID                      79.7 GB    disk1s2
   3:              Apple_Boot Boot OS X            134.2 MB   disk1s3

/dev/disk6 (internal, physical):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   GUID_partition_scheme                     *80.0 GB    disk6
   1:                     EFI EFI                  209.7 MB   disk6s1
   2:              Apple_RAID                      79.7 GB    disk6s2
   3:              Apple_Boot Boot OS X            134.2 MB   disk6s3

/dev/disk7 (internal, virtual):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:               Apple_HFS RaidOne             +79.7 GB    disk7

RAIDのドライブはHFS+でフォーマット済みです。これはAPFSでフォーマットし直すことも可能です。APFSでフォーマットすると、/dev/disk7にはAPFS Containerができて、実際の中身は/dev/disk8にマウントされました。

/dev/disk7 (internal, virtual):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:              Apple_APFS                     +79.7 GB    disk7
/dev/disk8 (synthesized):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   APFS Container Scheme -                   +79.7 GB    disk8
                                 Physical Store disk7
   1:             APFS Volume RaidOne              938.0 KB   disk8s1

RAIDを使ってみる

今回使用した2台のHDDは同じもので、Blackmagic Disk Speed Testで計測するとReadが42MB/sでWriteが44MB/sでした。RAIDを構成した場合は、Readは変わらず42MB/sでWriteが56MB/sでした。ほとんど変わらないばかりか、むしろWriteは高速化されていました。RAIDにすることでの速度低下は無いと言えます。

ディスクユーティリティでRAIDの状態を知ることができます。同じことは、diskutil appleRAID listコマンドでも行えます。（ディスクユーティリティの応答が悪かったりする場合があり、diskutilコマンドの方が確実でした。なので以下でも対応するdiskutilコマンドも書いていきます）

HDDが壊れた状況を作り出す

ミラーリングなので、どちらかが故障した時にどう対処できるか試してみました。そこで、電源が入ったまま片方のHDDを引き抜いてみました。

抜いた方のディスクが「見つからない/破損」の表示になりました。diskutil appleRAID listでは、Missing/Damagedと表示されます。

壊れたHDDをRAIDから除外する

壊れた（抜いたのですが）HDDをRAIDから切り離してみます。これには、対象のドライブを選択して、マイナスボタンを押します。

ターミナルからは、

diskutil appleRAID remove XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX disk7

というコマンドを打ちます。HDDを指定するにはいろいろな方法が提供されています。
diskutil appleRAID removeとだけタイプすると説明が出ます。ここでは、listコマンドで出てきたUUIDを使って指定してみました（XXXXの部分が壊れたHDDに相当するUUIDです。またdisk7はRAIDのマウント位置です）。

こんな感じでRAID 1の片方が解除されました。

交換のHDDを取り付ける

次に別のHDDを差し込んで、これをRAIDに追加しました。上の画面の「+」ボタンを押して、「メンバーを追加…」を選び、HDDを選択します。

もしくは、ターミナルから、

diskutil ar add member disk2 /Volumes/RaidOne

をタイプします。これは交換のHDDが/dev/disk2としてマウントされた場合の例です。この後、rebuild（再構成）が開始されて、1時間後くらいに2台のミラーリングとして復帰しました。再構成の進捗はdiskutil appleRAID listコマンドで確認できます。

ミラーリングの利点

ミラーリングによりHDDの一台が故障してもデータを失わないで済みます。ということで、バックアップできることはメリットなのですが、バックアップだけが目的ならTimemachineでも良いです。むしろ過去の状況に戻ることで、操作ミスによるデータ損失まで復帰できるので、Timemachineの方が優れています。

ミラーリングのメリットは、バックアップ機能そのものよりも、システムを停止しないでバックアップからの復帰ができることだと思います。HDDをいきなり引っこ抜いて故障状況を作り出して、新しいHDDと交換する作業を上記に示しましたが、この復旧作業中にもかかわらず、RAIDディスクにはずっとアクセス可能でした。rebuildには時間がかかりますが、その間もアクセス可能です。

ということで、ミラーリングとTimemachineを組み合わせたら、最強のバックアップになると思います。HDDをたくさん組み込めるマシンを作ったら、HackintoshでしかできないmacOSのRAID機能を活用してはどうでしょう。

APFSに対応したFusion Driveを作る

Mon, 09 Oct 2017 10:44:44 +0900

macOSでは、高速なSSDと大容量のHDDを組み合わせてFusion Driveを構成することができます。実際のMacintoshと全く同じく、Hackintoshでも、ターミナル上でdiskutilコマンドを使ってFusion Driveを作れます。今でしたら、ビット単価の安い240GB程度のm.2のNVMe SSDと、3TB~4TB程度の3.5インチHDDを組み合わせることで、高速で大容量のドライブを作ることができます。本家のMacintoshでは、市販のm.2 SSDや大容量3.5インチHDDは内蔵できませんので、Hackintoshのメリットを生かせる機能と言えます。

Fusion Driveは従来はcoreStorageという枠組みを使って構成していました。ところが、APFSになって導入されたAPFS Containerを用いることで、APFS対応のFusion Driveが作れるようです。そこで今回は、APFS ContainerによるFusion Driveを作ってみました。

APFS Container

ターミナルから、diskutilとだけタイプすると簡単なコマンドリストが出てきます。（詳細はman diskutilで出ます）コマンドリストの最後に、

appleRAID
coreStorage
apfs

の3つのサブコマンドがあります。appleRAIDはソフトウェアRAIDを作る機能で、ミラーリング、ストライピング、単純な合算の3通りのRAIDを作ってくれます。coreStorageというのは、Macintoshでサポートされている論理ディスクの仕組みです。coreStorageには、性能の異なるディスクをまとめ上げた場合、性能の良い方を優先して使う機能があります。こうして作られていたのが従来型のFusion Driveです。coreStorageはAPFSに対応していません。

最後のapfsは、新しく追加されたAPFSに関する機能を使うコマンドです。diskutil apfsとタイプすると、apfsサブコマンドで実行できる内容が一覧表示されます。このうちAPFS Containerに関するコマンドには、

createContainer (新しい空のAPFS Containerを作る)
deleteContainer (APFS Containerを消して構成ディスクをHFSでフォーマット)
resizeContainer (APFS Containerのサイズを変更)
addVolume (APFS VolumeをAPFS Containerに追加する)
deleteVolume (APFS ContainerからAPFS Volumeを削除する)

があります。ここでdiskutil apfs createContainerとタイプするとヘルプが表示されます。

$ diskutil apfs createContainer
Usage:  diskutil apfs createContainer []
        diskutil apfs createContainer -main [-secondary ]
        where = MountPoint|DiskIdentifier|DeviceNode

Create an empty APFS Container. You can then add APFS Volumes with the diskutil apfs addVolume verb. If you specify two disks, then a "Fusion" Container is created, with the performance roles assigned automatically unless you use the -main and -secondary options, in which case, the secondary disk is assumed to be on "slower" hardware which is preferably not solid solid state, usually larger, and often used to store associated "auxiliary" data such as the Windows partition(s) for Boot Camp Assistant. Ownership of any affected disks is required.

Example:  diskutil apfs createContainer disk0s2

ここに書いてあるように、createContainerコマンドで、2つのディスクを指定すると、Fusion方式のAPFS Containerが生成されます。2つのディスクのうち、高速なディスクの方が、自動的にメインのディスク（高速な方のディスク。HDDとSSDを組み合わせた場合のSSD側）になります。-mainと-secondaryオプションでメインのディスクをマニュアルで指定することもできます。

Fusion Driveを組んでみる

実際にAPFSでFusion Driveを構成してみます。まずはマシンにssdとhdd（手元にあった古い64GBと160GBのものを使いました）を接続して、番号をdiskutil listで調べておきます。ここではHDDが/dev/disk0に、SSDが/dev/disk3に割り当てられました。

APFS Containerはボリュームが出来ていないと構成できないようです。そこで、シンプルにジャーナル付HFS+でフォーマットしました。APFSでフォーマットすると自動的にAPFS Containerが作られてしまうので、この後のステップでcreateContainerコマンドを実行するときに邪魔になるようです。ディスクユーティリティ.appでフォーマットしても良かったと思いますが、コマンドラインでやってみました。

$ diskutil eraseDisk JHFS+ HDD160GB disk0
$ diskutil eraseDisk JHFS+ SSD64GB disk3

それぞれの名前をHDD160GBとSSD64GBとしました。$ diskutil listで見てみると：

/dev/disk0 (internal, physical):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   GUID_partition_scheme                     *160.0 GB   disk0
   1:                     EFI EFI                  209.7 MB   disk0s1
   2:               Apple_HFS HDD160GB             159.7 GB   disk0s2

/dev/disk3 (internal, physical):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   GUID_partition_scheme                     *64.0 GB    disk3
   1:                     EFI EFI                  209.7 MB   disk3s1
   2:               Apple_HFS SSD64GB              63.7 GB    disk3s2

となっていました。ここで

$ diskutil apfs createContainer disk0s2 disk3s2

とすると、APFS Containerが作られます。フォーマットも自動的にAPFSに変更されます。再び

$ diskutil list

で見ると：

$ diskutil list
/dev/disk0 (internal, physical):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   GUID_partition_scheme                     *160.0 GB   disk0
   1:                     EFI EFI                  209.7 MB   disk0s1
   2:              Apple_APFS Container disk7      159.8 GB   disk0s2
/dev/disk3 (internal, physical):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   GUID_partition_scheme                     *64.0 GB    disk3
   1:                     EFI EFI                  209.7 MB   disk3s1
   2:              Apple_APFS Container disk7      63.8 GB    disk3s2
/dev/disk7 (synthesized):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   APFS Container Scheme -                   +223.6 GB   disk7
                              Physical Stores disk0s2, disk3s2

/dev/disk7というドライブが出来上がっていました（disk4,5,6は実ドライブが搭載されていたので7番になりました）。この状態では、入れ物ができた段階で、まだフォーマットされていません。そこで、例えば

$ diskutil apfs addVolume disk7 APFS Fusion

としてフォーマットします。APFSはファイルフォーマットの指定です。でもAPFS以外は指定できないようです。最後のオプションはボリュームの名前です。わかりやすいようにFusionにしてみました。

Fusion Driveを使ってみる

こうして作成したFusion Driveを使ってみました。まずはdiskutil listしてみると、

/dev/disk7 (synthesized):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   APFS Container Scheme -                   +223.6 GB   disk7
                                 Physical Stores disk0s2, disk3s2
   1:             APFS Volume Fusion               880.6 KB   disk7s1

というようにFusionドライブができていることがわかります。ボリュームサイズが880KBと、とても小さいのですが、これは動的に拡張されていくようです。実際に3GB以上のサイズのファイルを入れてみたら、それに合わせてサイズが増えていました。addVolumeコマンドの-reserveオプションで最低サイズを指定したり、-quotaオプションで最大サイズを指定することもできるようです。

/dev/disk7 (synthesized):
   #:                    TYPE NAME                SIZE     IDENTIFIER
   0:   APFS Container Scheme -                  +223.6 GB   disk7
                                 Physical Stores disk2s2, disk3s2
   1:             APFS Volume Fusion              3.1 GB     disk7s1

この段階で、Fusionという名前のボリュームが自動的にマウントされています。ここでのサイズ表示はSSDとHDDの合計になっています。Blackmagicで読み書き速度を測ってみたら、SSDの速度とほぼ同じでした。ほとんど空の状態なのでSSDだけが仕事をしていたのだと思います。

このドライブにHigh Sierraをインストールしてみようとしたところ、APFSを止めてHFS+にするよう指示が出てしまいました。APFS ContainerのFusion Driveであっても、今のHigh SierraではAPFS未対応のようです。

Intel Power Gadget

Sun, 08 Oct 2017 12:26:33 +0900

Intelが、CPUと内蔵GPUの消費電力、動作クロック、温度が測定できるアプリケーション、Intel Power Gadgetを以下のサイトで配布しています。

Intel® Power Gadget

実際のMacintosh以外のハードウェアでmacOSを動かす場合、ハードウェア構成がOSに正しく伝わることが重要です。ハードウェア構成が正しく伝わっていないと、ハードウェアを効果的に、効率的に動かすことができません。今のCPUは省電力のために様々な仕組みを提供しています。多くのCPUは基本的な省電力機能として、負荷が小さい時には動作クロック周波数を下げて省電力を図り、負荷が大きい場合には、動作クロック周波数を上げて処理能力を向上させる機能を持っています。Intel Power Gadgetは、消費電力、クロック周波数、温度をモニターできるので、macOSがCPUの電力制御機能を利用できているかどうか、確認することができます。

macOS 10.13をインストールしたCore i5-4250U搭載NUCで動かした様子を上に示します。上から、

Power（消費電力）：大きい値がCPU全体、IAがコアの消費電力
Frequency（動作周波数）：IAがCPUコアの、GTが内蔵GPUのクロック周波数
Temperature（温度）：CPUパッケージの温度

です。Core i5-4250UはMacBook Air Mid 2013にも搭載されているCPUで、モバイル用の低消費電力モデルです。仕様によるとTDPが15Wです。なので15Wのところに線が引かれているのだと思います。ベース周波数が1.3GHz, ターボブースト最大が2.6GHzだそうで、だいたいその間でクロック数が変動していることがわかります。グラフィックスは、ベース周波数が200MHz, 最大が1GHzだそうです。ベース周波数でだいたい動いていることがわかります。コンピュータを操作したり、逆に放置したりすると、周波数や消費電力が変動します。実際のMacBook Airと同じような動作をしていますので、macOSがCPUの電力制御を正しく行えていると判断できます。

補足：High Sierraへのインストール

High Sierraから、署名されたkextに対しても確認が必要になったようです。クリーンインストールしたシステムにIntel Power Gadgetをインストールすると、下のようなダイアログが出ます。「システム環境設定・セキュリティとプライバシー」から許可をすると動くようになります。

Magic Trackpad 2は良いです

Sat, 07 Oct 2017 15:36:19 +0900

macOSを使う上でぜひ用意して欲しいのがApple Magic Trackpad 2です。マルチタッチ機能を利用したスワイプ、回転、ピンチなどのジェスチャを用いた、直感的な画面操作が可能になります。これ無しでは、macOSの直接操作を全て活用することができません。macOSの一部と言っても良いと思います。ただ、マウスに慣れきった体で移行した直後は、少し指がつる思いをするかも知れません。でも2-3日すれば慣れます。使いやすさを知ってしまったら、マウスには戻れないと思います。

一般的なマウスに比べたら高価ですが、無料でmacOSを使わせていただいて安いハードウェアを利用しているので、これくらいは買ってアップル社に還元しても良いかと思います。さらにはApple Magic Keyboardを並べて使うと、さらに高価になりますが、キートップの高さとトラックパッドの高さが揃って、美しいです。

Apple Magic Trackpad 2は本家アップルストアでは￥12,800 (税別)です。Amazonの方が高い時もあり、安い時もあるようですが、この記事の執筆時点ではAmazonの方が少しだけ安いようです。Apple Magic Keyboardも、本家では￥10,800 (税別)なので、現在はAmazonの方が多少お安いようです。

USBポートを設定する

Sat, 30 Sep 2017 22:25:18 +0900

追記：この記事ではUSBの15個制限を簡易的に回避します。本気で対応するには、この記事の方法よりも、以下をお薦めします。

15個制限を回避するUSBInjectAll.kextの役割と使用法

この記事の結論を先に書いておきます。

15個の制限を外すパッチとUSBInjectAll.kextを併用すると全てのUSBポートが使えるようになる (tonymacx86のMultiBeast方式)
15個制限解除パッチを使用せずに、USBInjectAll.kextのみを使って、実際に使用するポートを15個まで選択できる (お勧めの方式)

El Capitanから使用可能なUSBポートの数が、コントローラ当たり15までと制限されました。その後のSierraでもHigh Sierraでも同じです。理由は不明です。15ポートもあれば十分と思われるかもしれませんが、そうでもありません。まず、USB 3ポートは、互換性のためにUSB 2.0の端子も持っています。なので、2ポート分としてカウントされます。また、USB 2.0の端子から先にアサインされるので、USB 3の端子が使えず、USB 3のポートがUSB 2.0相当になってしまうこともあります。その対策について説明します。

何も対策しない場合のUSB構成

まずは、何も対策しないとどうなるかを見て見ましょう。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。ちなみに表示される情報は、Cloverのパッチや各種kextが機能した後の結果で、マザーボードのUEFIが提示しているオリジナルの構成ではありません。

mac.softpedia.com

IORegistryExplorer.appを起動して、右上の虫眼鏡アイコンのところに、xhcと入力します。するとXHC関係の情報が現れます。XHCの下にHS01やSSP1と見えているのが、現在OSが認識しているUSBポートです。HSはHigh Speed、SSPはSuper Speed PlusでそれぞれUSBの速度のモードです。HSがUSB 2.0で、SSPはUSB 3です。

全く対策しない状態の手元のマザーボード(MSI Z97A Gaming 7)では、以下のような結果になりました。

USB 2.0がHS01からHS14までの14本あり、USB 3がSSP1の1本あるという結果です。このマザーボードには、実際には他にもSSP2からSSP6の5本のUSB 3があるのですが、15本の制限を超えてしまったので、見えなくなっています。そのポート、例えばSSP6に接続しているUSBポートにUSB 3のUSBメモリを挿しても読み書きできません。（ちなみに、そのポートにUSB 2.0のUSBメモリを挿すと、2.0の端子はHS10に接続されているので、読み書きできます。）

解決策1：15個の制限を取り払う

解決策の一つは、上限15個の制限を外すパッチを当てることです。次の手順で15個の制限を外して、チップセットに接続された全てのUSBポートを使用できます。

config.plistにポート数を増やすパッチを当てる
USBInjectAll.kextを使用する
2.の両方を実施する必要があります。片方だけではダメです。この解決策の問題点は、パッチパターンがmacOSのバージョンごとに異なることです。パッチは、macOSの該当するバージョンにしか効きません。今使っているmacOS用のパッチが見つからない場合は、解決策2に進んでください。

ポート数を増やすパッチ

まずは、AppleUSBXHCIPCI.kextに以下のパッチを当てます（ New USB Raise Port Limit Patch for High Sierra | tonymacx86.com より）。

<dict>
<key>Comment</key>
<string>Change 15 port limit to 24 in XHCI</string>
<key>Find</key>
<data>g32MEA==</data>
<key>Name</key>
<string>AppleUSBXHCIPCI</string>
<key>Replace</key>
<data>g32MGw==</data>
</dict>

これは10.13 PB1をインストールした100シリーズマザーボード用のパッチと書いてありましたが、正式版10.13でZ97チップマザーボードでも動きました。

一方で、10.13.4からは違うパッチを当てないといけないようです。

www.insanelymac.com

後にも書きましたが、ポート数を増やすパッチはmacOSのマイナーバージョンごとに違っています。マイナーアップデートの都度対応する必要があり、お勧めの方法ではないです。

USBInjectAll.kextを使用

次にUSBInjectAll.kextをEFI/CLOVER/kexts/Otherもしくはバージョン番号のフォルダに入れます。

RehabMan / OS-X-USB-Inject-All / Downloads — Bitbucket

このkextは、チップセットで用意されているUSBポートの全てをmacOSから参照できるように設定する機能があります。Z97チップセットのUSBは、PCIeのvender-id/device-idが8086/8cb1に割り当てられています（IORegistryExplorer.appで見ることができます）。USBInjectAll.kextの中のInfo.plistの8086_8xxxというキーを見ると、HS01からHS14とSSP1からSSP6までの20のポートがあることがわかります。

config.plistへのパッチ当てとUSBInjectAll.kextを使った結果を以下に示します。

このように、全てのUSBポートが使えるようになっていることがわかります。これで、順番の最後尾に並んでいたUSB 3も全て機能します。簡単に全USBを使えるように設定できました。tonymacx86で配布しているMultiBeastというインストールツールは、この手法を使っています。

実際に使っているUSBポートを特定する

上記の解決策で、全部のUSBが使えるようになります。簡単ですが、多少問題があります。まずは、そもそもmacOSが何らかの理由で15個に制限しているのに、その上限を増やしてしまって大丈夫なのかという懸念です。今のところ問題点は報告されていませんが、将来、何らかの副作用が出てくる可能性は否定できません。もう一つは、パッチの内容が、OSのバージョンやチップセットによって変わるらしいことです。今回のHigh Sierraへの移行にあたっても、パッチが更新されました。Sierraの時のパッチでは、上限を回避できないようです。この先のバージョンアップでも対応が必要になると思われます。

一方、USBInjectAll.kextは、名前は、「全てのUSBポートをインジェクトする」ですが、実際には、一部のUSBポートを遮断する機能があります。たとえば、もともとある20個のポートのうち、任意のポートを指定して、使用しないよう設定することができます。実際に使用しているポートだけを15個選んで設定すれば、15個の上限を外す必要は無くなります。そうすればconfig.plistに素性の良くないパッチを書き込む必要がなくなります。USBInjectAll.kextの方は、RehabManさんによってこまめに更新されているので、今後も安心して使用できます。

使用しないポートを除外するためには、実際に使っているUSBポートを特定する必要があります。ちょっと大変な作業ですが、マザーボードの構成を把握できるので、達成感はあります。それぞれのポートの番号は、

それぞれのポートにUSB機器を接続し、
IORegistryExplorer.app の表示の変化を確認する

ことで、特定できます。下の例は、とあるUSB 3ポートにUSB 3.0メモリを挿入してみたところです。SSP5のport-statusが、最初は0x0だったのですが、下の図のように0x1400に変化しました。（kUSBBusCurrentAllocationの値も変化しました。）これで、このポートはSSP5だということがわかります。このポートに、USB 2.0のデバイスを接続すれば、USB 2.0端子の番号もわかります。

こうして手元のマザーボードを調べて見ました。各ポートの番号は以下のようになっていました。

HS01 基板上のUSB 3の2.0端子 (フロントパネルで使用)
HS02 基板上のUSB 3の2.0端子 (フロントパネルで使用)
HS03 バックパネルのUSB 3の2.0端子
HS04 不明
HS05 バックパネルのUSB 2.0
HS06 バックパネルのUSB 2.0
HS07 不明
HS08 不明
HS09 バックパネルのUSB 3の2.0端子
HS10 バックパネルのUSB 3の2.0端子
HS11 基板上のUSB 2.0 (フロントパネルで使用)
HS12 基板上のUSB 2.0 (未使用)
HS13 基板上のUSB 2.0 (未使用)
HS14 基板上のUSB 2.0 (Bluetoothで使用)
SSP1 基板上のUSB 3 (フロントパネルで使用)
SSP2 基板上のUSB 3 (フロントパネルで使用)
SSP3 バックパネルのUSB 3
SSP4 不明
SSP5 バックパネルのUSB 3
SSP6 バックパネルのUSB 3

HS01,02,03,09,10は、それぞれSSP1,2,3,5,6のUSB 3ポートに含まれているUSB 2.0端子です。HS14はBluetoothモジュールに接続しているので、これを無効にするとキーボードもトラックパッドも使えなくなります。不明とあるポートは発見できませんでした。マザーボード上で配線されていないのかもしれません。

解決策2：使うポートを15個以下に選別する

行方不明のポートを使うことはありませんし、マザーボード上で接続していない端子のポートも当分は使いません。これを考えるとUSBポートを15個以下に絞り込むことができます。上の例では、HS04, HS07, HS08, HS12, HS13, SSP4は除外して良いです。

USBInjectAll.kextに除外するポートを伝える方法は、いくつかあるようですが、最も簡単なのは、Cloverのブートオプションで伝える方法です。HS04, HS07, HS08, HS12, HS13, SSP4を除外したい場合は、config.plistのBootキーの中にあるArgumentsキーに、

<key>Boot</key>
<dict>
 <key>Arguments</key>
 <string>uia_exclude=HS04;HS07;HS08;HS12;HS13;SSP4</string>

と書いておけば良いです。もしもすでに他のオプションが書いてあったら、空白で区切って追記します。例えば-vが書いてあって

<string>-v</string>

これを残したかったら、以下のようにします。

<string>-v uia_exclude=HS04;HS07;HS08;HS12;HS13;SSP4</string>

このconfig.plistで起動した結果を以下に示します。使用している14個のポート、HS01, 02, 03, 05, 06, 09, 10, 11, 14およびSSP1, 2, 3, 5, 6が機能していることがわかります。これなら15個未満ですので、config.plistへのパッチは不要です。

解決策3：DSDTを変更してUSBポートを選別する

こちらの記事でDSDTの変更でUSBポートを選別する方法を書いておきました。

DSDTを変更してUSBポートを選別する

iMessageを動かす

Thu, 28 Sep 2017 23:11:19 +0900

Hackintoshの完成度を評価する目安は色々あります。例えば、起動するかどうか、画面が出るか、音が出るか、LANに接続できるか、WiFiが動くか、iPhoneと連携できるかなどあります。中でも、iMessageが動くかどうかは機種情報が正しく設定できていることの目安になります。

iMessage騒動

2014年の8月に、多くのHackintoshが、iMessageに繋がらなくなりました。「カスタマーコード」が表示され、iMessageサポートに連絡せよというダイアログが出て、締め出されて（ロックアウト）しまったのです。サーバ管理者側でセキュリティポリシーが変更されたことなので、具体的にどうなったのか知る由もありません。でもHackintoshコミュニティが手探りで試し尽くしたところ、機種ID、ロムとメインロジックボードのシリアル番号情報が、接続ごとに変動したり、フォーマットが正しくない場合に接続できないらしいとわかりました。

2014年のセキュリティ強化はあまりに過激すぎたのか、Appleサポート掲示板を見ると、本物のMacユーザにも支障が出ていたようです。セキュリティはその後、緩んだり厳しくなったりして、11月頃には、とうとう実機のシリアル番号じゃないと接続できなくなったこともありました。でも2015年の2月のバレンタインデーに、突如チェックが緩和され、ロックアウトが発生しなくなりました。それでも、シリアル番号やボードシリアル番号などは、設定機種に合った正しいフォーマットのデータを継続的に使用することが良いとされています。間違った設定を行っても、ロックアウトには至らなくなりましたが、接続できない問題が発生するようです。

en0に設定する

iMessageに限らず、Appleのネットサービスを利用するためには、EthernetもしくはWi-FiのBSD装置名がen0である必要があります。実機がそうなっているからです。en0になっていないと、iMessageは使えませんし、App Storeへの接続でもエラーが出ます。

以下の記事でも紹介していますが、

Ethernetを設定する

以下のファイルを消して再起動すれば良いです。

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
/Library/Preferences/SystemConfiguration/Preferences.plist

また、en0があってもこれの状態がBuiltinになっていないと接続できないことがあるようです。コメントで教えていただきました。こちらに説明があります。これの対処法も、上記のファイルを消して再起動すれば良いようです。

シリアル番号類を正しいフォーマットで設定する

先のiMessage騒動の時に、iMessageに認められる正しいシリアル番号のフォーマットが、コミュニティの協力で調べられました。その結果が、Clover Configuratorの自動生成機能に組み込まれています。なので、これを利用して、正しい情報を設定しておけば良いです。以下の記事で紹介しておきました。

正しく機種設定する (SMBIOSの設定)

注意すべき点は、一回設定したら、継続して使い続けることです。iMessageにログインするたびに機種情報が変動すると、不正な利用とみなされて接続できなくなる場合があるようです。

iMessageへの接続失敗を無かったことにする

以前にiMessageにログインしようとして失敗したことを無かったことにするためには、以下のファイル/ディレクトリを消して再起動すると良いそうです。

~/Library/Caches/com.apple.Messages*
~/Library/Caches/com.apple.imfoundation*
~/Library/Preferences/com.apple.iChat*
~/Library/Preferences/com.apple.imagent*
~/Library/Preferences/com.apple.imessage*
~/Library/Preferences/com.apple.imservice* ~/Library/Messages

ただし、ロックアウトが発生していた時は、ローカルの記録をいくら消去しても無駄でした。失敗した記録は当然ですがサーバ側にも残っているようです。

そのほかの条件

大抵の場合は、en0にすることと、SMBIOSで機種情報を正しく設定することで、iMessageを利用できます。それでも、接続がうまくいかなくて苦労している人もいるようです。ネット上にはたくさんの対処法が紹介されています。わかりやすいガイドには以下があります。

www.tonymacx86.com

www.youtube.com

iMessageのメッセージが届かないとか、遅延するなどの問題も報告されますが、実機を使っても、同様なことが発生します。なので、実はHackintoshの問題ではなく、iCloud / AppleID自体のトラブルである可能性も高いです。

また、古くからのApple IDユーザのアカウントであったり、クレジットカードを登録しているアカウントは問題を起こしにくいという噂もあります。本当かもしれませんし、都市伝説みたいなものかもしれません。さらには、最近はApple IDが2ファクタ認証に移行しつつあります。2ファクタ認証しているApple IDは従来よりセキュアなので、その結果ロックアウトされにくいように思います。何れにしても、サーバ側でどのように運営しているかは謎ですし、そのポリシーも変化していると思われます。

HackintoshをHigh Sierraにする

Tue, 26 Sep 2017 12:18:21 +0900

Sierraで動いているHackintoshなら移行は簡単

High Sierraが出ました。HackintoshはOSのバージョンアップの時に設定がダメになって苦労する、と思い込んでいる人も多いかもしれません。でも、最近はとても簡単になりました。マイナーバージョンアップ（例えば10.12.5から10.12.6へのバージョンアップ）なんて、App Storeからダウンロードしてクリックするだけです。実機と同じです。今回のようなメジャーアップデート（10.12から10.13）は、いろいろと対応する必要がある場合もあります。でも、今年は楽勝の部類でした。

ということで、すでにSierraで動いているHackintoshをHigh Sierraにアップデートする方法を書いておきます。ここで紹介する手順は、別ドライブを用意してそこにHigh Sierraをインストールする手順です。

Sierra版の現状のHackintoshを最新版にアップデートしておく(Step 1~2)
別ドライブを用意してそこにHigh Sierraをインストールする(Step 3)
APFS起動に必要なapfs.efiをHigh Sierraから手に入れる(Step 4)
High SierraドライブにCloverを仮インストールする(Step 5)
現状のSierra HackintoshのESPをHigh Sierraドライブにコピー(Step 6)

別ドライブでちゃんと起動したら、あとはゆっくり、メインドライブのHigh Sierra移行にとりかかってください。

Step 0: macOSをバニラな状態にしておく

簡単に移行するための前提です。こちらで解説して置きましたのでごらんください。

/posts/131/

つまり、macOSが入っているパーティションの内容には一切手を加えないで、実機と全く同じ状態にしておけば、アップデートは簡単になるということです。

Step 1: 旧バージョンSierraのHackintoshを最新にしておく

ここからが作業本番です。Hackintoshコミュニティのハッカーの方々は、High Sierraに向けて更新してくれています。なので、移行前に、最新にしておきましょう。最新にすることでSierraが動かなくなることはありません。最新にしてもSierraがちゃんと動くことを確認してきましょう。

まずはCloverを最新にします。今日現在ではリビジョン4220が最新のようです。システム環境設定に登録してある場合は、「更新を確認」するだけです。
kextを最新にします。kextの名前でGoogle検索すると配布サイトが出てきますので、最新版に差し替えておきましょう。
kextをEFI/CLOVER/kexts/10.12に入れている人は、10.13を新たに作ってコピーするか、Otherフォルダにコピーしておきます。

詳しくはこちらをご覧ください。

あと13日！High Sierraのお迎え準備

Step 2: config.plistのSMBIOS情報を最新にしておく

OSとしてのHigh Sierraの一番の変更点は、ファイルシステムがHFS+からAPFSに移行することです。High Sierraのアップデートでは、APFSでも起動できるようにファームウェアもアップデートされます。Hackintoshにとっては関係のないことですが、ファームウェアが対応版にアップデートされていないと判断されると、インストールが止まってしまうようです。そこでconfig.plistのSMBIOSセクションのBIOSバージョンの記述を、最新版ファームウェアと同じバージョン番号に書き換えます。

詳しい手順は、これもこちらをご覧下さい。

あと13日！High Sierraのお迎え準備

Step 3: High Sierraを別ドライブにインストールする

ここまでのステップで準備がしっかりできたので、ここから先は簡単です。

High Sierraをインストールするドライブを接続します。SSDでもHDDでも良いです。USB接続でも良いです。自作の人なら、余っているドライブをSATAケーブルでマザーボードに接続しても良いですね。

このドライブをディスクユーティリティでフォーマットします。フォーマットは、GUIDパーティションマップとHFS+ (Mac OS拡張ジャーナリング）とします。SierraのディスクユーティリティではAPFSを選択できません。が、ここでHFS+でフォーマットしても、SSDの場合は、この後のインストールで自動的にAPFSに変換されます。

Apple App StoreからHigh Sierraインストーラをダウンロードして、このドライブにインストールします。インストール途中で再起動することがあります。その場合は、現行のドライブで起動して、Cloverのメニューからインストール途中と思われるドライブを選択します。「Boot macOS Install from XXXX」というのがインストール途中にだけ現れるボリュームで、これを選択します。

途中の起動回数は、いつもは1回の気がしましたが、今回は2回のようでした。たまたまかもしれませんが、もしかしたらファームウェアをアップデートする作業（Hackintoshでは無駄な作業ですが）があったのかもしれません。もしくは、APFS変換の関係なのかもしれません。

インストールが終了したら、やはり、再起動します。インストール途中の再起動なのか、インストールが終了した後の再起動なのかは、先ほどの「Boot macOS Install from XXXX」というボリュームの有無で判断できます。Cloverの選択画面にこれがなくなっていれば、インストールは終了しています。

インストーラがHFS+でHigh Sierraをインストールした場合、Cloverのボリューム選択にHigh Sierraが現れていると思います。High Sierraを起動しても良いのですが、ここは、ぐっと我慢して次のステップに行きましょう。APFSに変換された場合は、High Sierraが現れていないと思います。次のステップで対応します。

次のステップでは、まずは古いSierraのドライブを選択して起動します。

Step 4: 最新版のAPFSドライバapfs.efiをESPに入れる

2018/06/19更新：Clover 4558からApfsDriverLoader.efiというドライバができて、apfs.efiの機能を自動的にロードしてくれるようになりました。なので、 /usr/standalone/i386/ からapfs.efiを取り寄せてESPに置く以下の作業は不要になりました。記録のために残しておきます。

High Sierra Public Betaの初期のバージョンでは、HFS+でのインストールがメニュー選択で可能でした。しかし、正式版をSSDにインストールする場合は、自動的にAPFSフォーマットに変換されるようです。HDDやFusion driveの場合はHFS+のままのようです。

Clover、というか一般にブートローダは、OSが起動する前に、ドライブからブートのためのファイル（例えばカーネルなど）を読み込む必要があります。なので、ファイルシステムにアクセスできる必要があります。この機能は、High Sierraの

/usr/standalone/i386/apfs.efi

で行えます。そこで、このファイルを、CloverのESPにコピーします。それを行わないと、APFSでフォーマットされたHigh Sierraを起動できません。そこで、APFSブートには以下のステップが必須です。

APFSでインストールしたHigh Sierraの起動はひとまずお預けにして、今まで通りHFS+の古いSierraを選択して起動します。この時High Sierraを選択したくてもAPFSなので選択画面に現れていないはずです。
CloverのESPをマウントします。
High Sierraの中のapfs.efiをEFI/CLOVER/drivers64UEFIの中にコピーします。
再びSierraのボリュームで起動すると、今度はAPFSのHigh SierraがClover選択画面に見えているはずです。これを選択して起動します。

ベータ版時代のバージョンアップでapfs.efiは度々更新されていました。初期のベータ版から入手したapfs.efiで、後期のHigh Sierraが起動できなかったこともあります。apfs.efiがネットに落ちていることもありますが、公開版High Sierraに入っている最新版を使うのが良いでしょう。

High Sierraは起動しましたでしょうか？うまく起動すれば、ユーザ設定などの画面に進み、ログインできます。ここまでくればもう安心です。

Step 5: High SierraのドライブにCloverをインストールする

このステップは飛ばしても良いです。

現行のドライブのCloverからHigh Sierraのドライブが無事起動できて、アカウントなどの設定が終わったら、Cloverのインストーラを起動して、新しいドライブにCloverを入れます。このとき、ESPにインストールするよう指定します。

Step 6: 現行のESPからファイルをHigh SierraのESPにコピーする

High SierraのESPには、とりあえずインストールしたClover関連のディレクトリができているはずです。前のステップを省略すると、できていないかもしれません。何れにしても、古いSierraのドライブのESPの内容を、新しいHigh SierraのESPにコピーして、同じ内容にします。ファインダーからのドラッグ&ドロップで作業しても問題ありません。これで、High Sierraのドライブを起動ディスクにしても、ちゃんとHigh Sierraが起動するはずです。

次のStep: メインドライブのアップデート

これで無事、別ドライブで起動できましたでしょうか。問題なければメインドライブもアップデートしましょう。このステップと同様に、今度は、High Sierraのドライブから、メインドライブにインストールしていけば良いです。上書きインストールでも、いっそすっきりとフォーマットしてのクリーンインストールでもどちらでも良いと思います。Time Machineでバックアップとってあれば、クリーンインストールの後で移行することもできます。

補足

SMBIOSのデフォルト設定

Clover r4179以降では、config.plistで以下の値：

BiosReleaseDate
BiosVersion
FirmwareFeatures
FirmwareFeaturesMask

を指定しなくても、機種モデルの最新の値がデフォルトで設定されるようになったという情報もあります。実際にBiosVersionを削除して見たところ、それでも最新の値が使われていました。Step 2の作業の代わりに、これらの指定を単に削除して、Cloverのデフォルトに任せるのも可能かと思われます。

http://www.insanelymac.com/forum/topic/304530-clover-change-explanations/page-4#entry2482211

apfs.efiを入手するもう一つの方法

上記の説明では、High Sierraをインストールした後で、apfs.efiを入手しています。インストールする以前の、Install macOS High Sierra.app (日本語名は macOS High Sierraインストール.app)から取り出すこともできます。.appの中の

Install\ macOS\ High\ Sierra.app/Contents/SharedSupport/BaseSystem.dmg

にあるBaseSystem.dmgを開いてマウントします。次に、

/Volumes/OS X Base System/usr/standalone/i386/apfs.efi

の場所にあるapfs.efiを手に入れます。これで、Step 3の段階でapfs.efiを入手してESPに入れることができ、すぐにHigh Sierraから起動できます。

パッチを当てるkext: Lilu.kext

Sat, 23 Sep 2017 23:09:00 +0900

Lilu.kextはkext (カーネル拡張)にパッチを当てる仕組みを提供するkextです。ライブラリやプログラムにもパッチを当てられるようですが、kextにパッチを当てるために便利に用いられています。今年になってから登場した新しいkextです。元々は、サウンドを提供するkextであるAppleALC.kextを開発していた人が、パッチ当ての部分を分離して公開してくれたものです。なので、現在のAppleALC.kextもLilu.kextを使っています。

Releases · acidanthera/Lilu

Lilu.kextはパッチを当てるkextと一緒に使います。バニラな構成ならば、それぞれをEFI/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。Cloverもconfig.plistのKextsToPatchセクションの記述でkextにパッチを当ててくれます。この記述は簡単なのですが、kext本体のバイナリーファイルにしかパッチを当てられません。Lilu.kextは、パッチ方法を指定するkextを開発する必要がありますが、kext本体以外の様々なファイルや設定にパッチを当てられるようです。

以下で、Lilu.kextと一緒に使うためのkextを紹介します。

AppleALC

macOSのHD audio機能を使って音を出すためのパッチ。こちらで説明しました。

/posts/120/

古いバージョンは単独で動きますが、パッチ当て機能をLilu.kextに分離した後のバージョンは、Lilu.kextと一緒に使います。

Releases · acidanthera/AppleALC

WhateverGreen

~~10.12.6からRX480/580などのAMDグラフィックスカードがサポートされました。しかし、メインディスプレイにはならず、起動時にはCPU内蔵GPUなどの補助GPUが必要でした。これを解決するのがWhateverGreen.kextです。Radeonを使う人には必須です。~~以前はAMDグラフィックスカードの不具合に対応するkextでした。それでAMDカラーのgreenという名前が付いています。今は、

IntelGraphicsFixup
NvidiaGraphicsFixup
Shiki

の機能を統合し、ディスプレイに関係するパッチ機能をすべて盛り込んだkextになりました。詳しくは以下をご覧ください。これを入れれば統合されてしまったkextは使う必要がありません。

NvidiaGraphicsFixup

このkextはWhateverGreenに統合されました。

NVIDIAのGPUをiMac15,1 iMac17,1 MacPro 6,1のシステム設定で使おうとすると、ブート後に画面が黒くなって起動しなかったり、画面がスリープしたりする問題が発生します。 WebドライバだけでなくmacOS標準のドライバでも発生します。 iMacのレティナディスプレイやProのデュアルグラフィックスカードハードウェアを前提とした macOSの設定が、この問題を引き起こしているようで、black screen問題と呼ばれています。このkextを使うと、black screenを回避できます。

Releases · lvs1974/NvidiaGraphicsFixup

IntelGraphicsFixup

このkextはWhateverGreenに統合されました。

~~Intel HD Graphicsを使う場合に発生する以下の不具合を解決します。~~

~~Intel Graphics HD4000以降のブートロゴ表示の乱れ~~
~~Intel Azul Graphics (HD4400, HD4600)におけるPAVPフリーズ問題~~

ブートロゴの乱れは、起動時のアップルロゴとプログレスバーが表示される場面の後半で、表示が8個に分裂してストライプ状になる現象です。起動時だけのことで、無視しても良いくらいの問題ですがこれが解決されます。もう一つのPAVPフリーズ問題はもっと深刻で、一部の動画サイトをSafariで閲覧する場合や、iTunesでiTunes Storeの予告編を見る場面で、動画再生が滞ったり、場合によってはOSがフリーズする問題です。

Releases · lvs1974/IntelGraphicsFixup

Shiki

このkextはWhateverGreenに統合されました。

iTunesにあるDRM保護されているビデオはivy bridge以降で再生できない問題があります。購入した映画や、その予告編を再生しようとすると、映像が出ないとか、音だけしか出ない状態です。これを回避します。

Releases · acidanthera/Shiki

NightShiftUnlocker

10.12.4から導入されたNight Shift機能ですが、これにはMacBookPro9,x iMac13,x Macmini6,x MacBookAir5,x MacPro6,x MacBook8,x以降の機種が対応しています。これより古い機種でNight Shiftを動かすためのkextです。

Releases · 0xFireWolf/NightShiftUnlocker

そのほか

用途・効果を理解できていないのですが、Lilu.kextのサイトによると、このほかにも以下のようないろいろなパッチがあるようです。

AirportBrcmFixup Broadcom Airport Wi-Fi cardsへのパッチ

AzulPatcher4600 Intel HD 4600 へのパッチ

CoreDisplayFixup 非Iris Intel graphicsの高解像度サポート

CPUFriend 動的なパワーマネージメント

EnableLidWake ラップトップで蓋を開けた時のIntel Graphicsスリープ解除対応

HibernationFixup 3モードと25モードのハイバネーション対応

config.plistの実例紹介

Thu, 21 Sep 2017 22:07:11 +0900

長ったらしくてわかりにくいconfig.plistの書き方を、簡単に説明してみます。config.plistはCloverの設定をxml形式で書いたテキストファイルです。そのマニュアルは、Clover Wikiで公開されています。

https://clover-wiki.zetam.org/Configuration#Config.plist-structure

ただ、ここで十分に説明し尽くされていない項目も多く、分かりにくいです。Cloverは、長い間、様々な世代のCPU、チップセット、GPU、周辺機器をサポートしてきて、それに対応した機能を提供してきました。それらを全てconfig.plistで設定しているので、わかりにくくなるのも仕方ありません。古いシステムに関連している設定項目などは、もはやそれが実装された経緯を知らない人も多いはずです。

ということで、実際に動いているconfig.plistを例に、最新のハードウェアに関した項目だけに絞って説明してみます。下に示したconfig.plistの例はMSI Z97Aマザーボードで動いている設定です。デフォルトの設定、最新ハードウェアには無関係な部分などを削除しているので、割と短くてわかりやすいかと思います。9シリーズチップセットのマザーボードの例ですが、UEFIのマザーボードならこのconfig.plistでだいたい動くと思います。

https://pastebin.com/FkCTZEvq

以下でセクションごとに説明していきます。

ACPI

config.plistの冒頭に書かれているのはACPIセクションです。ACPIはAdvanced Configuration and Power Interfaceの略で、マザーボードの電源機能と構成要素を列挙し管理する統一された枠組です。DSDT (Differentiated System Description Table) は、マザーボードごとに固有の電源管理と構成を記述したデータです。SSDT (Secondary System Description Table)は、DSDTの補足データで、DSDTの一部を記述したデータです。SSDTには、DSDTの一部の記述をして、DSDTの内容を上書きします。

DSDTは全てのマザーボードが持っています。Hackintoshのコミュニティによって、DSDTに足りない記述を書き足したり、書き換えたりして、macOSを動かす努力が長年されてきました。昔のBIOSベースのマザーボードの時代には、それぞれのマザーボードBIOSバージョンごとに、改変されたSSDTが作られて、それを使ってmacOSをインストールしていました。config.plistのACPIセクションのDSDTとSSDTは、マザーボードが持っているACPI情報をどのように改変すべきかを書いた場所です。動的にパッチを当てるCloverの重要機能を指定しています。

MSI Z97Aマザーボードで動かすconfig.plistのACPIセクションを下に示します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Name</key>
 <string>DSDT.aml</string>
 </dict>
 <key>SSDT</key>
 <dict>
 <key>Generate</key>
 <dict>
 <key>CStates</key>
 <true/>
 <key>PStates</key>
 <true/>
 </dict>
 </dict>
 </dict>

重要機能の割には、シンプルです。というのも、UEFIマザーボードの時代になって以来、DSDTを変更しなくても、ほとんどそのままで動くようになったからです。なのでDSDTへのパッチ当ての指示は全て削除することができます。Nameでは、将来、手作業でDSDTにパッチ当てをしたいときに備えて、パッチを当てたDSDTファイルの名前を入れてあるだけです。なので、この記述も実は不要です。ちなみに、パッチを当てたDSDTファイルは、CloverのACPI/patchedディレクトリに入れます。

Generateでは、CPUの電源制御のCステートとPステートを用意するよう指定しました。これが必要なのかどうかよくわかっていませんが、多くのconfig.plistでこの指定がしてあるので、ここでも使いました。

またDSDT項目名を変更するパッチも必要に応じて書きます。こちらで説明しておきました。

config.plistでDSDT項目名を変更するパッチ

Boot

Bootの設定です。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string></string>
 <key>DefaultVolume</key>
 <string>Macintosh HD</string>
 <key>Timeout</key>
 <integer>1</integer>
 <key>XMPDetection</key>
 <string>NO</string>
 </dict>

Argumentsは、Cloverがブートするときのオプションです。-vとか-xとか色々あります。また、kextが引き取ってくれるオプションもここに書きます。普通の起動にはオプション不要なので、この項目も不要です。でも、将来何か指定したいときのために、空のstringを書いておきました。

DefaultVolumeは、起動ボリューム名です。Timeoutは、Cloverのメニューが出てからユーザ入力を待つ時間です。この指定では、1秒後に自動的に起動します。XMPDetectionは、よくわかりません。eXtreme Memory Profileという機能を使うかどうかの設定です。使わないことにしています。

Devices

 <key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>Inject</key>
 <string>1</string>
 </dict>
 <key>UseIntelHDMI</key>
 <false/>
 </dict>

Audioでは、オーディオチップのレイアウトの1番を使うよう指定しました。AppleALC.kextがこの値を使います。詳しくはこちらをご覧下さい。

/posts/120/

HDMIは使っていないのでUseIntelHDMIは、無しでも良いのですが、将来のためにfalseを入れておきました。

GUI

Cloverの起動画面の設定です。

 <key>GUI</key>
 <dict>
 <key>Language</key>
 <string>en:0</string>
 <key>Scan</key>
 <dict>
 <key>Entries</key>
 <true/>
 <key>Tool</key>
 <true/>
 </dict>
 <key>ScreenResolution</key>
 <string>1920x1200</string>
 <key>Theme</key>
 <string>Minimalism</string>
 </dict>

Scanは、ボリュームやUEFIツールのスキャンをするかどうか。Themeは、画面表示の色やアイコンなどの見た目の選択です。Cloverのthemesフォルダの中から、使用したいテーマのディレクトリ名を指定します。

Graphics

AMD, Intel, NVIDIAのGraphicsに関する指定です。

 <key>Graphics</key>
 <dict>
 <key>Inject</key>
 <dict>
 <key>ATI</key>
 <false/>
 <key>Intel</key>
 <true/>
 <key>NVidia</key>
 <false/>
 </dict>
 </dict>

AMDは使っていないのでfalseに、またNVIDIAの最近のモデルはfalseで良いとのことでそうしました。
デフォルトでは3社ともtrueだそうですが、必要に応じて自動設定されるそうなので、ここでは何も書かなくても良かったのかもしれません。

KernelAndKextPatches

Kernelとkextへのパッチ指定です。起動時に動的にパッチを当ててくれます。これもCloverの重要機能です。

 <key>KernelAndKextPatches</key>
 <dict>
 <key>AppleRTC</key>
 <true/>
 <key>KernelPm</key>
 <true/>
 <key>KextsToPatch</key>
 <array>
 
(省略)
 
 </array>
 </dict>

AppleRTCを当てないと、スリープでUEFI設定が消えてしまいます。KernelPmはHaswellの電力制御のパッチです。不要かもしれないけど、Z97チップセットマザーボードなので、念のために入れておきました。以上は定番のパッチです。

パッチ作業を具体的に指定したパッチを記述することもできます。それがKextsToPatchのセクションです。そういうものが必要ならば（省略）と書いた部分に書きます。以下に光ドライブのスリープ対応のパッチを紹介しました。参考にしてください。

光学ドライブを使う

RtVariables

Runtime 変数というセクションです。Cloverの機能を指定するパラメータを書くところのようです。あまり使い道がありません。

 <key>RtVariables</key>
 <dict>
 <key>CsrActiveConfig</key>
 <string>0x0</string>
 </dict>

ここではSIPを有効にするよう指定しています。多分デフォルトで有効だと思いますので、この記述は不要だと思います。でも、将来、無効にしたいときのために書いておきました。SIPとCsrActiveConfigの値については、こちらをご覧下さい。

/posts/132/

siroanko.hatenablog.com

SMBIOS

機種固有情報を書くセクションです。40行以上あるので省略しました。シリアル番号、ファームウェアのバージョン番号などを書きます。

 <key>SMBIOS</key>
 <dict>
(省略)
 </dict>

Clover configuratorを使うと、機種に合わせた値を生成してくれます。それのSMBIOSセクションをここにコピーペーストすれば良いです。詳しくは、こちらをご覧下さい。

正しく機種設定する (SMBIOSの設定)

SystemParameters

最近追加されたセクションです。

 <key>SystemParameters</key>
 <dict>
 <key>InjectKexts</key>
 <string>YES</string>
 <key>NvidiaWeb</key>
 <true/>
 </dict>
</dict>
</plist>

InjectKextsは、/EFI/CLOVER/kexts/に置いたkextを使うかどうかの指定です。自動的に検出するDetectという指定も可能ですが、明示的に指定した方が安心です。

NvidiaWebは、NVIDIAが配布しているドライバを使用するかどうかの指定です。昔は、ブートオプションで指定していましたが、Sierraからここで指定することになりました。

音を出す

Wed, 20 Sep 2017 20:05:42 +0900

Hackintoshで音を出すためのアプローチは、いくつかありますが、ここでは、一般的で簡単な3つの方法を難易度の低い順に紹介します。それぞれの作業量は、

何もしない
kextを1個入れる
kextを2個入れてconfig.plistを1項目追加する

です。

USBオーディオを使う

マザーボード搭載のオーディオチップを利用せずに、外付けの音源でデジタルアナログ変換するアプローチです。USB接続のDAC (デジタルアナログ変換器)を搭載した、スピーカ、アンプ、アダプターなどを接続するだけです。USBの標準的なオーディオ再生プロファイルを使うので、OSレベルでサポートされています。なので、特別のドライバーは不要で、何の手を加えなくても、音が出ます。ちなみに、Bluetoothスピーカも同様な仕組みで音が出ますので実機と同様に動きます。

USBオーディオ製品には、USBポート直結の安いDACがあります。手軽に試せて、実現できます。いくつか購入しましたが、どれもHackintoshで問題なく使用できました。ただスリープ復帰時にボツッというポップノイズが出る製品もありました。手元の環境でたまたま調子の良かったのは、この1,000円未満の製品でした。

USB DAC内蔵スピーカーも各種あります。これもいくつか購入しましたが、中でもこちらの製品は価格の割に良い音でした。

さらに手軽な値段のDAC内蔵アンプも多数あります。これをちゃんとしたスピーカに接続したらかなり良いオーディオ環境を実現できます。ピュアオーディオマニアが使うようなもっともっと高価な機器も使えます。

VoodooHDA.kextを使う

VoodooHDA.kextは、AppleのオーディオドライバであるAppleHDA.kextを置き換えることを目的に開発されているオープンソースのオーディオドライバです。これ単体で機能するドライバで、設定などがほとんど不要で、自動的にオーディオチップを検出してくれてすぐに機能します。一時は、クラッシュを引き起こすとか、音質が悪いとか言われていましたが、最近使ったところでは安定しているし、気になるような音質の問題もありませんでした。JeffさんのビデオでもVoodooHDA.kextを使っています。

**追記：**とあるマシンでVooDooHDA.kextを使っていると音割れがひどいことに気づきました。調整をしてくれるアプリケーションなどもあるので、それで頑張ると良いのかもしれません。でも次節で紹介するAppleALC.kextに替えたら音割れは起きなくなりました。VooDooは簡単ですが環境によっては合わない場合があるようです。(2018/6)

/posts/121/

VoodooHDA.kextをダウンロードして、ESPにあるCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。これだけで機能します。ESPに入れることでmacOSをバニラなままに保てます。

AppleALC.kextとLilu.kextを使う

3番目の方法は、昔から行われている伝統的な方法で、AppleHDA.kextに何とかオーディオチップを認識させようという方法です。そのために、AppleHDA.kextにパッチを当てたり、config.plistに必要な設定を書き込んだり、インジェクターkextを作ったり、こういう作業を自動化してくれるシェルスクリプトを走らせたり、など色々な手法があります。

このアプローチを格段に簡単にしてくれるのがAppleALC.kextです。これは、AppleHDA.kextにパッチを当ててくれるkextです。この開発者が、最近パッチを当てる機能を分離して、Lilu.kextという拡張機能を作りました。現在のバージョンのAppleALC.kextはLilu.kextと一緒に使います。この両方のkextをCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。AppleHDA.kextにパッチを当てないので、macOSをバニラなまま保つことができます。

こちらにAppleALC.kextがサポートしているチップ一覧があります。最近のマザーボードで一般的なRealtek以外に、Creative, CirrusLogic, AnalogDevices, Conexant, IDT, VIA, Intelをサポートしています。 IntelはHDグラフィックスのHDMI出力をサポートしています。

github.com

ここに書いてあるどのlayoutを使うかをconfig.plistに記載する必要があります。 Realtekの場合、だいたいは1で良いようです。以下に例を示します。

<key>Devices</key>
<dict>
        <key>Audio</key>
        <dict>
                <key>Inject</key>
                <integer>1</integer>
        </dict>

SATA接続HDD/SSDのホットプラグ

Sun, 17 Sep 2017 12:18:24 +0900

5.25インチベイに取り付ける取り外し可能なHDDケース

今のMacintosh製品には5.25インチベイが無いです。最近の自作PCケースも、5.25インチベイの無い製品が増えていますが、あれば色々便利です。中でも、簡単に5.25/2.5インチドライブを取り付け・取り外しできるリムーバブルディスクケースは便利だと思います。自作していれば、小容量の古いHDD/SSDが余ってしまいがちです。それが簡単に取り付けられるリムーバブルケースがあれば、大容量のデータを高速にコピーして持ち運ぶとか、新しいバージョンのOSを実験的にインストールするとか、いろいろな場面で便利に使えます。

市販の製品

5.25インチベイ自体が廃れ始めているので、製品もひところに比べたら少ないですが、いくつかあるようです。5.25インチと2.5インチの両方が入る製品が多いようです。隙間にUSBコネクタを装備している製品とか、光学ドライブも入れられる製品もあります。ちなみに、大は小を兼ねるので、5.25インチが一台だけしか入らないケースも、工夫すれば2.5インチもなんとかなります。

HDD/SSDのSATAコネクタは、なんども抜き差しする前提で設計されていないので、壊れやすいと言われています。ちゃんとしたサーバで使うホットプラグケースでは、強度の高いコネクタ付きトレイを用意してHDDをネジ止めする構造になっています。でも、素人がちょっとした実験で抜き差しするくらいなら、全然問題ありません。ねじ止めしなくても取り付けられるケースが楽です。

またこれらの製品は、ホットプラグ対応を謳っています。電源を入れたまま、HDD/SSDを抜き差しできるという意味です。ただし、これは電気的に問題を起こさないという意味であって、マウントしたままいきなり取り外すと当然ですがデータが損傷する可能性があります。非マウント状態にしてから抜き差しする必要があります。

ホットプラグなドライブアイコン

ドライブはmacOSでいろいろなアイコンで表示されます。一般的なHDD/SSDは銀色のアイコンです。ちょっと古い感じのハードディスクの形です。USBメモリーは白いアイコンで表示されます。スリットがあるので、光学ドライブの絵なのかもしれません。また、取り外し可能なHDDなどはオレンジ色のアイコンで表示されます。取り外し可能なドライブアイコンの隣には、イジェクトアイコンが表示されていて、これを押すとアンマウントされます。

上で紹介したリムーバブルケースは、取り外し可能なディスクなので、イジェクトマークのあるアイコンになるべきです。でも、USB接続と違い、リムーバブルケースからマザーボードへは内蔵ドライブと同じSATAケーブルで接続します。マザーボードから見たら、SATAコネクタが内部のHDDに接続されているか、もしくはリムーバブルHDDケースに接続されているのかの区別はつきません。人手で指定する必要があります。

いくつかのマザーボードではデフォルト設定として、インテルのチップセットに接続されたドライブを内部ドライブ（銀色アイコン）にしています。一方で、チップセットのSATAに加えて追加SATAチップを搭載して、SATAの数を増やしている場合、追加のSATAチップに接続されたドライブはリムーバブルボリュームに設定されていることが一般的です。でも全てをホットプラグ対象とみなすマザーボードも中にはあります。こうした割り当てで、内蔵ドライブがオレンジ色のアイコンになってしまうことがあります。それが嫌な人のために、 AHCI_3rdParty_eSATA.kextや AHCI_Intel_Generic_SATA.kextといったkextが用意されていました。これらのkextの主な目的は、オレンジ色のアイコンを銀色に戻すことです。ただ、これらのkextは最近のmacOSでは機能しないことが多いので、あまり使われなくなりました。

BIOSでホットプラグを設定

マザーボード搭載のSATAに接続したドライブがリムーバブル（ホットプラグ）なのかどうかは、BIOS設定で指定します。下はMSIのマザーボードの例です。

この機能で、それぞれのSATAコネクタに接続されているドライブが、固定ドライブなのか、ホットプラグさせるドライブなのかを設定します。これが一番理想的ですね。この方式ならば、オレンジアイコンの割り当てを正しく行うことができます。ただし、後述するように、BIOSでホットプラグに設定しても、macOSで必ずしもオレンジアイコン表示にはならない場合もあるようです。

なお銀色アイコンで、イジェクトマークがついていないドライブでも、ゴミ箱方向へドラッグ&ドロップすればアンマウントできます。また、ディスクユーティリティを使ってもアンマウントできます。ターミナルから、diskutil unmount /dev/disk… としてもアンマウントできます。

ただ、銀色アイコンとして認識されているSATAドライブは、起動時に接続されていなければ認識されません。macOS起動後に接続しても認識されません。また、起動時に接続されてマウントされても、その後で一旦アンマウントしたら、もう一度接続しても認識されません。なので、リムーバブルケースで接続する場合は、オレンジ色のアイコンで認識されないととても不便です。

macOSでホットプラグ

BIOSレベルでホットプラグに設定しても、macOSでオレンジアイコンにならない場合があります。銀色アイコンの状態では、起動時にはマウントしますが、ホットプラグによりマウントしてくれない状態になります。SATAチップの種類、マザーボード、macOSのバージョンなどで対応が異なるようです。

Z97マザーボード＋Sierra以前

この記事を最初に書いた時点では、MSIのZ97チップセットマザーボードでSierraで動かしていました。BIOSのホットプラグ設定をすると、macOSでもオレンジアイコンになりホットプラグでマウントされ、安定に動作していました。

Z97マザーボード＋High Sierra以降

不安定です。High Sierraになった時点で、BIOSで設定しても銀色アイコンのままのこともあり、動くこともあるようです。ASUS ROG MAXIMUS XI HERO (Z390)マザーボード＋Catalinaの組み合わせでは、BIOS設定のホットプラグが正しくオレンジアイコンに表示されることも何度かありました。その時は、スリープしても問題ありません。でも何度も起動して確認すると、マウントされないこともあります。

PCIe拡張SATAカード + Catalina

以前、macOSと互換性のあるPCIe拡張SATAカードをご紹介しました。

PCIe拡張カードでSATAを増設する

追記：以下の方法では、マウントする際にBig Surが落ちることがありました。後述する長いパターンのパッチを当ててください。ASMediaやMarvellのチップでもホットプラグ可能です。

~~これらのカードの場合、こちらで紹介されているように、~~

Find --> 40600200
Replace --> 00000000
AppleAHCIPort

というパッチを当てれば、ASMediaやMarvellのチップでホットスワップできるようです。元のサイトの説明では、SATAポートデュプリケータの不具合に対応するパッチらしいですが、ホットプラグ問題も解決するようです。具体的には、config.plistに

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>ALPM IO Error AppleAHCIPort</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>QGACAA==</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>AAAAAA==</data>
 </dict>
 </array>

を追加します。QGACAA==が40600200で、AAAAAA==は00000000です。これでホットスワップが動くようになり、スリープしても大丈夫でした。Marvell 88SE9230チップセットによるカードと、ASMedia ASM1061チップセットカードの両方で動作を確認しました。

Z390 + Catalinaのパッチ

コメントでまっくぷろさんからいただいた情報によると、こちらで紹介されているパッチもしくはその変形を使うと、Z390チップセットのSATAをホットプラグ対応にできるようです。

Find --> 89C82540 6002003D 40200000 750C81E1 BF7FFFFF 898B5101 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

または、

Find --> 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

のようです。これに対するBase64文字列を、上で紹介したように、config.plistのKextsToPatchセクションに書き込んでおけば良いようです。

このパッチのいずれでも動かないようでしたら（もしくは将来のmacOSバージョンで動かなくなったら）、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをバイナリーサーチして40200000を検索して、その前後から上記のようなパッチを作れば良いようです。例えば以下のようにします。10.15.3での実施例です。まずはバイナリーをhexdumpしました。

hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less

lessの中で、サーチコマンド

/40 20 00 00

をタイプし、40 20 00 00を探します。

00029a0 73 0e 81 ca 40 80 00 00 89 d1 89 93 69 01 00 00
00029b0 89 ca 81 e2 40 60 02 00 81 fa 40 20 00 00 75 0c
00029c0 81 e1 bf 7f ff ff 89 8b 69 01 00 00 f6 c1 40 74
00029d0 7e 3d 09 01 01 00 72 77 44 89 fa c1 ea 0a 81 e2

この方法では、運悪く改行にかかっているとデータ列が見つからない可能性はありますが、首尾よく発見できました。他には存在していないようです。ということで、まっくぷろさんの情報と同じく、40 20 00 00を挟んだデータ列をNOP (90) に置き換える

Find --> 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

というパッチで良いようです。base 64に変換します。詳しくはこちらをご覧ください。

echo -n "\x81\xE2\x40\x60\x02\x00\x81\xFA\x40\x20\x00\x00\x75\x0C\x81\xE1\xBF\x7F\xFF\xFF\x89\x8B\x69\x01\x00\x00" | base64
geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=

ちなみにNOPコマンド列である9090…の方は、

echo -n "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" | base64
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=

です。なのでconfig.plistには

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>

を追加します。これでBIOSでホットスワップ指定したチップセットSATA接続ドライブがオレンジ色アイコンになり、随時マウント・アンマウントできるようになりました。またスリープしても問題ありませんでした。

つづき

上記のパッチをOpenCoreのconfig.plistで当てる方法を以下で紹介しました。

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

また、Big Sur対応のパッチを以下で紹介しました。

リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)

結論

ホットプラグできるリムーバブルベイは便利です。チップセットSATAの場合は、BIOSでホットプラグを設定します。それでもmacOSにホットプラグ対応と認識されない場合は、AppleAHCIPort.kextにconfig.plistでパッチを当てます。手元の環境 (ASUS Z390 + Catalina) では、MarvellのSATA拡張カードを使っているので、拡張カード用のパッチを当てることにしました。

Ethernetを設定する

Sat, 16 Sep 2017 21:59:36 +0900

Ethernetを動かすkext

マザーボード搭載やPCIeカード搭載のEthernetチップは大体がサポートされています。Linux用のドライバを元に移植されているようです。最近のマザーボードでは、IntelかAtherosのチップが多いです。マザーボードを購入する場合は、以下のkextがサポートしているEthernetチップを、そのマザーボードが搭載していることを確認すると良いです。

Qualcomm Atheros

Miezeさんが作っているAtherosE2200Ethernet.kextを使います。最近のマザーボードに搭載されているKiller E2500がサポートされています。AR816x, AR817x, Killer E220x, Killer E2400, Killer E2500が動きます。

Intel

最近のマザーボードでは、Intel i219-VやIntel I211ATが搭載されています。いくつかのドライバが用意されています。調子よく動くものを使用すれば良いと思いますが、IntelMausi.kextが一般的に使われていてお勧めです。

AppleIntelE1000e.kext hnakさんが開発しています。Intel 825xx シリーズをサポートしています。

AppleIGB.kext これもhnakさん。Intel 82575, 82576, 82580, dh89xxcc, i350, i210, i211をサポートします。

IntelMausi.kext Miezeさんのドライバで200シリーズに対応しています。オリジナルを、RehabManさん、acidantheraさんらがforkして開発しています。 82578LM, 82578LC, 82578DM, 82578DC, 82579LM, 82579V, I217LM, I217V, I218LM, I218V, I218LM2, I218V2, I218LM3, I219V, I219LM, I219V2, I219LM2, I219LM3をサポートしているとのことです。もともとはIntelMausiEthernet.kextという名前で配布されていましたが、それから枝分かれしてIntelMausi.kextができました。IntelMausi.kextのほうがサポート継続されているらしく、おすすめのようです。

Realtek

Miezeさんが作っているRealtekRTL8111.kextを使います。最近のマザーボードに搭載されている8111Hがサポートされています。

Ethernetの設定

上記のkextが対応しているEthernetチップなら、kextをCloverのkextsディレクトリに入れておくだけで機能します。

もう一つ注意しておくべき設定があります。それはEthernetがen0に割り当てられる必要があることです。Unixマシンは、ネットワークアダプタにen0, en1, en2と番号を振って管理しています。macOSではOSが発見した順番にen0から番号づけられています。実際のMacintoshでEthernetを持っている機種はEthernetがen0です。WiFiだけの機種はWiFiがen0です。このように割り振られていない場合に、Apple App Storeに接続できなかったり、iMessageが使えなかったりします。

他のネットワークアダプタが有効になった後で、Ethernetのkextをインストールして動かした場合などは、Ethernetがen0以外の番号に割り振られてしまいます。なので、「リンゴマーク」「このMacについて」「システムレポート」で開くシステム情報の、「ネットワーク」リストを選んで、Ethernetがen0であることを確認しましょう。

もしen0では無い場合は、以下のファイルを消して、再起動すればen0になります。(もしくはこの中にあるenXという文字をすべてen0にしても良いです。)

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
/Library/Preferences/SystemConfiguration/preferences.plist

Hackintoshのためのkext入門

Fri, 15 Sep 2017 23:23:26 +0900

改定：2018/9/15

kextとは

kextとはKernel EXTension（カーネル拡張）の略で、カーネルと呼ばれるOSの本体を拡張する一連のファイルです。OSに必要とされる機能が増加し、いちいちカーネルに組み込んでいると管理が大変になったので、別ファイルにして必要に応じて組み込むことになりました。macOSに限らず、多くのOSで一般的な方式です。ネットワーク、グラフィックス、サウンドなどのハードウェアを動かすデバイスドライバの機能も、kextとして提供されています。

Hackintoshのためには、Hackintoshを実現するためにmacOSの機能に手を加えるkextや、実機でサポートされていないハードウェアを動かすためのkextなどが開発されて、配布されています。必要なものを集めてHackintoshにインストールします。

kextの置き場所〜macOSの場合

macOSでは、kextを/System/Library/Extensions/ (/S/L/Eと略されます）もしくは、/Library/Extensions/に置きます。/S/L/Eに置くkextは、SIPで署名チェックされます。なので、当然ながら署名のないHackintosh用のkextを加える場合、SIPをdisableにする必要があります。

/posts/132/

kextは、実はファイルではなくてディレクトリです。macOSのファインダーからファイルのように見えているだけで、中には、多数のファイルが含まれています*1。これらのファイルの全てがカーネルから実行できるように、パーミッションが正しく設定されている必要があります。また、kextを起動のたびにkextファイルから読むと時間がかかってしまいます。そこで、キャッシュして高速化を図っています。なので、新しいkextを加えるためには、単にディレクトリにコピーするだけでなく、中身のすべてのファイルのパーミッションを正しく設定して、キャッシュを作り直さないといけません。この作業をGUIで実行するツールも配布されています。

kextの置き場所〜Cloverの場合

kextの追加をCloverにお任せすれば、前節のややこしそうなkextインストールの手間は無関係です。EFI/CLOVER/kextsの中にkextを入れておくとCloverが追加してくれます。SIPはenableのままで大丈夫です。またパーミッション設定もキャッシュ作り直しも不要です。ディレクトリに入れるだけです。以前は、kextによっては（例えばLANのkext）/S/L/Eに入れないと機能しないこともありましたが、最近では、ほとんどのkextがCloverのディレクトリに置いても問題なく機能します。それでも依然として、/S/L/Eに置かないと機能しないkextも稀にありますので、その場合は試行錯誤して確認してください。

EFI/CLOVER/kextsは、macOSのルート、もしくはボリュームのESPのどちらかにあります。デフォルトはmacOSのルートですが、その場合、macOSをまっさらに入れ替えると消えてしまいます。ESPにおいてあれば、アップデートで変更されないので管理が容易です。ESPにCloverをインストールする方法は、バニラインストールとも言われます。以下で説明してあります。

/posts/131/

EFI/CLOVER/kextsの中には、macOSのバージョン番号のディレクトリと、Otherという名前のディレクトリがあります。Cloverは、

まず、Otherに入っているkext
次に、該当するバージョン番号のディレクトリに入っているkext

の順番で、kextをインストールします。この後はmacOSに引き継がれて、/L/E、/S/L/Eの順にkextがインストールされます。同じ名前のkextがあったとしたら、後からインストールされた方が優先します。

kextは、該当するバージョン番号のディレクトリに入れておいても良いです。もしくは、バージョン番号のディレクトリは使わない（空にしておく、もしくはそもそもディレクトリを作らない）でOtherに全部入れておいても良いです。両方に入れても良いですが、混乱しやすいかもしれません。皆さんのやりやすい方法で管理すれば良いです。

FakeSMC.kext

kextはたくさんありますが、FakeSMC.kextは、Hackintoshするために唯一で必須のkextです。SMCはSystem Management Controller（システム管理コントローラ）の略です。昔は、PMU (Power Management Unit)と呼ばれていました。Macintoshの電力をコントロールしたり、ハードウェアをコントロールするサブシステムです。メインのCPUとは別に、SMCと呼ばれるマイクロコンピュータが内蔵されていて、それがハードウェアの管理を仕切っています。Macintosh独自のもので、ATXマザーボードには（もちろん近いものは搭載されていますが、同一のものは）搭載されていません。でもmacOSはSMCがあるものと思って働きかけてきます。そこで、SMCのふりをするフェイクのSMCを実現するのがFakeSMC.kextです。

NullPowerManagement.kext

現代のCPUは、負荷によって動作周波数を変更したり、スリープをしたりして、消費電力を制御しています。この結果、省電力を実現し、発熱量を減らしています。搭載しているCPUがどのように電力制御を行うかの情報は、マザーボードからACPIテーブルを介してOSに伝えられます。ただ一般のマザーボード使用を想定していないmacOSには、この情報が正しく伝わらないことがあります。そもそも実機で採用されていないCPUの場合には、macOSで対応することができないこともあります。CPUの電力制御が正しく行えない場合、macOSがカーネルパニックを引き起こして起動しないこともあります。

macOSでCPUの電力制御を担当しているkextは、AppleIntelCPUPowerManagement.kextです。NullPowerManagement.kextはこのkextを無効にします。その結果、電力制御関連の設定が正しく行われていなくても、とりあえずはHackintoshが起動するようになります。なので、tonymacx86で配布されているインストール用USBメモリ (UniBeast)などのインストーラではこのkextが使われます。

起動してくれるのはありがたいのですが、電力制御が行われないので、CPUは最大出力で稼働し続けます。そこで、DSDT, SSDT, config.plistなどを正しく設定してこのkextがなくても起動するように調整することが、Hackintosh作りの一つの目標になります。

このほかのkext

このほかの主なkextには、

Ethernetを動かすためのkext
サウンド関係のkext
USB関係のkext
グラフィックス関係のkext

などがあります。これらは、該当するハードウェアを機能させるためのkextです。そのハードウェアが原因のトラブルを解消する機能を持ったkextもあります。FakeSMC.kext以外のkextは、絶対に必要というものではなくて、必要に応じてインストールすれば良いものです。それぞれのハードウェアの話題のところで説明していこうと思います。

kextの探し方

Hackintoshに必要なkextは、その名前で検索すると開発サイトや配布サイトが見つかります。また、KextUpdater.appを使うと、現在使用しているkextの最新版をチェックしてダウンロードしてくれます。また主要なkextを個別にダウンロードすることも可能です。

*1:macOSのアプリケーション、.appも同様にファイルではなくてディレクトリです。