古い情報 on Boot macOS

ASRock Z590マザーボード搭載ALC1220で音を出す (その1)

Mon, 29 Mar 2021 19:57:47 +0900

（こちらは古い情報です。最新のAppleALC.kextを使うことで、ここで行った手順は不要になりました。こちらをご覧ください。2021/4/10）

ASRock Z590 Extremeに搭載されたサウンドチップRealtek ALC1220から音が出るようにしました。Z490のマザーボードを最初に使った時と同様に、FakePCIID.kextを使いIDを偽装します。近い将来、Z490の時と同様に、AppleALC.kextとOpenCoreがZ590チップセットに対応すれば、このような工夫なしで動くようになるのではと期待しています。

Z590マザーボードのサウンド

前の記事で、ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。

ASRock Z590マザーボードでmacOSを起動する

この結果、有線と無線のネットワークが動いています。USBは未調整ですがキーボード、Bluetooth関係は動いてます。でもマザーボードに搭載されたサウンドチップであるRealtek ALC1220から音が出ていませんでした。今回は、このサウンドチップを動かします。

Realtek ALC1220は、300シリーズチップセットから搭載されているサウンドチップです。AppleALC.kextで長らくサポートされているので、互換性は高いと思っていました。でもZ590マザーボードでは、AppleALC.kextを入れるだけでは動きませんでした。

一方、一部のZ590マザーボードでは、新しいサウンドチップのRealtek ALC4080 が搭載されています。新しいので互換性が心配でしたが、実はALC4080はUSB接続で動いていて、USBオーディオとして機能するのでドライバの心配がいらないという報告がいくつか上がっています。オンボードサウンドのことだけを考えたら、ALC1220よりも、新しいALC4080が搭載されたマザボの方が面倒がなくて良いかもしれません。

PCIIDを偽装する

まずは、ALC1220がサポートするlayout-idをいくつか試してみましたが、音は出ませんでした。ALC1220の場合、使用できるlayout-idは、1, 2, 3, 5, 7, 11, 13, 15, 16, 21, 27, 28, 29, 30, 34だそうです。layout-idは多少違っていても大抵は音が出るので、全く動かない場合は、layout-idの問題ではないと思われます。

他の方法を検索しましたが、結局、以前、Z490マザーボードが出始めた時に使った方法が有効でした。サウンドチップのPCIIDを偽装する方法です。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

この方法に従って、以下のkext、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を追加し、config.plistのDevicePropertiesに以下を追加しました。PciRoot(0x0)/Pci(0x1F,0x3)はALC1220のデバイスパスです。これのdevice-idをA348に、layout-idを1にする設定です。

Z590マザーボードに搭載されたALC1220には、ベンダー：デバイスIDとして、8086:F0C8が割り当てられています。このIDが、現在のバージョンのOpenCore/AppleALCには登録されていないようで、Hackintool.appで調べると、Device Nameが???という表示になります。

そこで、上記の内容をconfig.plistに加えることで、このIDが8086:A348になります。このIDはCannon LakeのALC1220のdevice-idと同じ値なので、下記のようにCannon Lakeの名前が表示されるようになります。

以上の作業を行うことで、無事、オンボードサウンドが出るようになりました。

まとめ

Z590マザーボードのオンボードサウンドチップであるRealtek ALC1220から音が出るように設定しました。以前のZ490の時もそうでしたが、OpenCore/AppleALCがZ590搭載のALC 1220に対応してくれれば、この作業は不要になると期待しています。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

次の作業はUSBの15個制限の調整です。ぼちぼち対処していきます。

使用する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ポートが使えるようになりました。

9900KマシンをmacOS 10.14.5に更新する

Wed, 15 May 2019 23:51:27 +0900

（Cloverが対応したので古い情報です。）

第9世代CPUに対応した公開版macOSである10.14.5が配布されました。更新したところCPUが「不明」の表記が改まりました。ただしCore i7になっているのでconfig.plistでCPU Typeを指定してCore i9と表示されるようにしました。

新iMac対応Mojaveが公開される

第8, 9世代CPUに対応したiMacが出た時点のmacOSは10.14.4でした。ただ対応したmacOSは製品に搭載されるだけで、他の機種IDのマシンでは入手できませんでした。先日(2019/5/14)ようやく10.14.5が公開され、最新CPUに正式対応したmacOSが入手できるようになりました。早速、9900Kマシンをアップデートしました。問題なく動きます。

10.14.5から署名のないkextが除外されるという噂もありましたが、問題ありません。バニラなインストールをして、SIPも実機と同じく有効にしているから問題が無いのかもしれません。

CPUの名称表示を改善する

10.14.4ではCPUが「不明」

「このMacについて…」や「システム情報」を見るとCPU名が表示されます。しかし10.14.4では、以下のようにCPUが「不明」になっていました。

第9世代CPUを搭載したMacを対象にしていないバージョンでしたので、表示の用意がなかったと思われます。でもsysctlで確認すると、ちゃんと9900Kだと認識されています。

sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz

10.14.5ではCPUが「Core i7」

10.14.5にアップデートしたところ、これがかなり改善されました。「このMacについて…」では以下のように表示されます。「不明」の表示は出なくなりました。でもなぜかCore i7の表示になります。

良いところまで来たのに、今一歩足りない感じです。そこでこちらで頂いたコメントを元に、こちらからCPU情報を確認して、CPU Typeに0x1009を設定しました。config.plistの最上位dictの中に、以下のようにkeyとdictを追加すれば良いようです。

追記：コメントいただいたように実機では0x1005だったという情報があります。0x1005の方が良いかと思い、以下も変更しました。

<?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>CPU</key>
	<dict>
		<key>Type</key>
		<string>0x01005</string>
	</dict>
</dict>
</plist>

この結果、Core i9と表示されるようになりました。（もしかしたら10.14.4でもCPU Type指定でこのようにできたのかもしれません）見た目だけなのかもしれませんが、CPU名が正しく表示されるようになると気分が良いです。

10.14.5 + Clover 4934ではCPUが「Core i9」

追記：Cloverをリビジョン4934に更新したらconfig.plistでCPU Typeに0x1009を設定しなくても（上記の記述を全部削除しても）正しく3.9 GHz Intel Core i9と表示されるようになりました。ということで、Cloverが面倒を見てくれるようになったようですので、config.plistではCPU Typeを記載しないことにしました。ただ、「Clover 4934でiMac19,1にSMBIOS設定すると、i7 9700Kでもi9にされてしまう。」という報告が5chにありました。今後改善されると思います。

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を活用する

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になる。

9900Kのsleep問題〜原因はiGPUのデバイスID

Wed, 06 Mar 2019 21:10:29 +0900

更新：ここで紹介した対策は10.14.4で不要になりました。以下は10.14.3以前の情報です。不要になった理由は、9900K CPUがmacOSでサポートされるようになったからだと思われます。10.14.4以降では、以下で説明しているデバイスIDも9900Kの本来の値で問題ありません。本来の値はWhateverGreen.kextが自動で設定してくれますので、config.plistにデバイスIDを書く必要がありません。

ASUSのZ390マザーボードで作ったHackintoshのその後の報告です。sleep/shutdownが全て完璧に動くようになりました。最初の記事はこちらです。（今回の対策を追記してあります）

9900K搭載Z390マザーボードでHackintoshを作る

その後、シャットダウンが不完全な問題を解決すべく試行錯誤したところで、EmuVariableUefi-64.efiを使うことで解決しました。

ASUS Z390マザーボードのshutdown/sleep対応

sleepがまだ不完全

一時はこれで解決したかに見えたのですが、sleepからの復帰がおかしいです。iGPUを使うと、sleepで画面が消えた後、キーボード押下で画面が復帰します。ただし、画面が消えるだけで、CPUファンは回転し続けています。一方、グラフィックスカード(dGPU)を使うと、sleepで画面が消えた後、しばらくはキーボード押下で画面復帰するのですが、15秒くらい経つと画面が復帰しなくなります。さらに放置するとCPUファンの回転も中止しますが、やはり復帰しません。また、この状態ですとJPEGファイルのクイックルックも効かないようです。

という状態で、しばらく頓挫していたのですが、ようやく解決したので報告します。たまたま hackintosher.comで紹介されていたconfig.plistを使ってみたらsleepが機能するようになったので、それと、問題を引き起こしているconfig.plistとの比較からの結論です。

UHD Graphics 630のデバイスID

Intel UHD グラフィックス630は、MacBook Pro 2018やMac mini 2018で使用されています。なのでmacOSの標準ドライバーでサポートされています。でも、UHD 630のデバイスIDはCPUごとに微妙に違います。例えばMacBook Pro 2018で使用される8750HのUHD 630のデバイスIDは0x3E9Bです。Mac mini 2018で使用される8700BのUHD 630デバイスIDも同じく0x3E9Bです。ところが今回使用している9900KのUHD 630のデバイスIDは微妙に違っていて0x3E98なのです。このデバイスIDの不一致が、sleep問題の原因のようでした。

i3-8100でも対応必要

Intel UHDグラフィックス630のデバイスIDの違いは、他のCPUでも問題を引き起こすようです。こちらの記事

corpnewtさんのバニラガイド~Coffee Lake用config.plist

で紹介しましたが、Core i3-8100のUHD 630もデバイスIDが異なっていて(0x3E92および0x3E91)、対応が必要だそうです。結果として今回も同じ問題のようです。

9900KのデバイスID対応

上記の記事では、8700K搭載UHD 630のデバイスIDの指定方法が書いてあります。この方法に従うと、デバイスIDを逆順に（little endian方式に）並べた数値に、0x0000を付け加えた値をconfig.plistで指定すれば良いようです。

ただ、上記のサイトでは、「実際のデバイスIDをconfig.plistに書く」とありますが、今回の解決策は、「Macで使われているデバイスIDをconfig.plistに書く」という方法でした。逆のようです。9900KのデバイスIDは先に述べたように0x3E98ですが、これをconfig.plistに書くのではなく、Macで使われているiGPUのデバイスIDである0x3E9Bをconfig.plistで指定するようです。そこで、まずは0x3E9Bの順番を入れ替え、ゼロを追加します。つまり、0x9B3E0000を指定すれば良いことになります。config.plistではBase64で記述するので、変換します。ターミナルコマンドbase64で0x9B3E0000をBase64変換するには以下のようにタイプします。

echo -ne "\x9B\x3e\x00\x00" | base64

この結果

mz4AAA==

が得られます。この値を、Devicesの中のPropertiesにdevice-idキーとして追加します。

<key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 AwCSPg==
 </data>
 <key>device-id</key>
 <data>
 mz4AAA==
 </data>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 </dict>
 </dict>

この結果、sleepが完璧に動くようになりました。つまり、sleepになるよう設定した時間になると、画面が消え、数秒してCPUファンが停止します。その後、キーボード押下などにより、元どおりの画面に復帰します。

今回のconfig.plistの全体を以下に置いておきます。シリアル番号などは伏せ字になっています。

config.plist for 9900K w/o iGPU display - Pastebin.com

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)

Hackintoshのパーツ選び【その3：グラフィックス編】10.13.4以降版

Sun, 26 Aug 2018 22:10:42 +0900

このページは古い情報です。macOS 10.14以降で使うGPUの情報は以下をご覧ください。

HACKINTOSHのパーツ選び【その3：グラフィックス編】10.14以降版

Hackintosh自作に適したグラフィックスカードを紹介します。10.13.4以降の最新macOSでHackintoshする人向けに、最新情報のみをまとめました。それ以前のmacOSの情報を含む詳しい経緯は、以下をご覧ください。2018年7月17日

/posts/139/

Hackintoshグラフィックスの選択肢

一般的な自作PCと同じ状況なのですが、現在のコンピュータグラフィックスチップは、Intel, AMD, NVIDIAの3社でほぼ独占されています。この中から選ぶことになります。Hackintoshで使うことを検討する場合、

IntelのCPU内蔵グラフィックス
ノートPCに内蔵されたモバイル用AMDもしくはNVIDIAグラフィックス
PCIeスロット用AMDグラフィックス
PCIeスロット用NVIDIAグラフィックス

のいずれかになると思います。このうち2番目の、ノートPCに内蔵されたモバイル用AMDもしくはNVIDIAグラフィックスは、Hackintoshでは使えません。Macと全く同一のチップを搭載したアップル社製品以外のノートPCが存在していないためです。それ以外のモバイル用グラフィックスチップに対して、macOS用のグラフィックスドライバは提供されていません。なので、ノートPCでHackintoshする場合は、Intel CPU内蔵グラフィックスのみが利用可能です。他の3個の選択肢は、Hackintoshで動きます。ただ、macOS Mojave 10.14からはMetal非対応のドライバが削除されたので、Metal対応モデルを使う必要があります。また、10.13.4からAMDグラフィックスの互換性が向上し、macOSに最初から搭載されたドライバでRadeon製品の一部がそのまま動くようになりました。このような状況からHackintoshするグラフィックスのお薦め順位は、

PCIeスロット用AMDグラフィックス
PCIeスロット用NVIDIAグラフィックス
IntelのCPU内蔵グラフィックス

になると思います。PCIeスロットに搭載するグラフィックスカードは、互換性のあるものを選べば安定して稼働します。おすすめです。Intel CPU内蔵グラフィックスも安定して動きますが、場合によっては多少のノイズが発生することもあります。以下で1. 2. 3. のそれぞれについて説明します。

AMDグラフィックス

10.13.4以降のmacOSでは、AMDグラフィックスがお薦めです。AMD Radeon RX 470/480/570/580およびVEGA 56/64の4モデルならば取り付けるだけでそのまま動きます。10.13.4からThunderbolt 3接続の外付けGPUボックスがmacOSで正式にサポートされ、AMDのグラフィックスカードをApple社が推奨したからです。

Apple推奨グラフィックスカード

これによると、Polaris, Vega 56, Vega 64の3種類のアーキテクチャがサポートされているようです。具体的なチップは、以下です。

AMD Radeon RX 470, RX 480, RX 570, RX 580, Radeon Pro WX 7100
AMD Radeon RX Vega 56
AMD Radeon RX Vega 64, Frontier Edition Air, Radeon Pro WX 9100

Sonnet社も、10.13.4に対応して、詳細な互換性リストを発表しました。AMDグラフィックスカードを購入する場合は、以下の記事で紹介したSonnetのPDF資料に、互換性があると記されているカードを購入すると良いです。

Sonnetの互換GPUリスト (10.13.4以降)

ということで、AppleやSonnetが推奨するAMD GPUを使えば、簡単にHackintoshできるので、お勧めです。このうち、Pro WXシリーズは高価なので一般的なHackintoshからは除外できるかもしれません。また、RX 470/480はすでに廃盤の製品で、後継の570/580はこのクロックアップバージョンにすぎません。なので実質的には、

AMD Radeon RX 570
AMD Radeon RX 580
AMD Radeon RX Vega 56
AMD Radeon RX Vega 64

から選択することになると思います。先述のSonnetのリストによると、ブランドはどこでも同じようです。マザーボードとデザインを合わせるなど、好みのブランドを選べば良いようです。もっと低価格のRX 560でも動くという報告も多数あります。ただ、Appleは560を推奨リストに挙げていませんし、Sonnetは非互換とマークしています。スリープ復帰などに問題があるという報告もありますので、多少の苦労が発生するかもしれません。 Vegaでは搭載空冷ファンのコントロールが効かず最大スピードになるという報告もあります。それも直せたという報告もありますので、対応可能なようです。 RX 580を使った経験では、しばらく使用すると性能（具体的にはGeekbenchのスコア）が低下する現象がありました。これはCPUの内蔵グラフィックスをonにすると解決しました。　（この性能低下問題はMojaveでは発生しなくなりました。しかし内蔵グラフィックスを無効にするとJPEGファイルがクイックルックやプレビューで開けないようです。内蔵グラフィックスは有効にしておくのが良いようです。）一般的な自作PCの世界では、AMDの製品は、NVIDIAと比較して上位機種の性能、性能あたりの消費電力で未だに劣っていると言われています。ただ、これはWindowsで使うことを前提にした話です。macOSで使う場合、AMDはOSで正式にサポートされているアーキテクチャなので、色々と最適化されています。例えば、Final Cut Pro Xなどを使って性能比較すると、同じ性能ランクのNVIDIAよりも良いスコアを叩き出します。

NVIDIA

NVIDIAは、独自でmacOS用のドライバを開発して配布してくれています。なので、これ（NVIDIAのWebページで配布されていて、Webという名前の含まれるkext群で構成されるのでWeb driverと呼ばれます）を使えば、1080Tiなどの最近のPascalアーキテクチャモデルが問題なく動きます。それ以前のモデルもサポートされています。AMDではmacOSがサポートしてくれるモデルに制限がありますが、Web driverはNVIDIAのほとんどのモデルに対応しています。 Web driverをインストールする作業も簡単です。Web driverはmacOSのバージョンごとに配布されています。機能はそれほど変わらないようですが、macOSのバージョンチェックをして、合致しないビルド番号では起動しません。以下のサイトで、それぞれのビルド番号に合ったドライバのダウンロードURLがまとめて整理されています。 www.macvidcards.com macOSのビルド番号は、「リンゴマーク」「このMacについて」のOSバージョンの文字をクリックすると、その横に表示されます。下の例では17E202です。
NVIDIAを選ぶメリットは、Web driverが現行製品のほとんどに対応しているので、高性能なモデルから、安価なモデルまで、選択肢が多いことです。例えば、PC自作ユーザ向けの最上位機種、GeForce GTX 1080Tiはとても強力で、性能あたりの消費電力も低いです。その一つ下のモデルのGTX 1080でも十分強力です。最近発売されたAMDのVega 64でも、性能は1080にある程度追いついたものの、価格と消費電力で負けているようです。特に、Windowsと併用するとか、Windowsでグラフィックス性能を必要とするゲームをするなどの場合は、NVIDIAを選ぶことにメリットがあります。

グラフィックス性能は不要という人も多いと思います。普通にGUI操作したり動画を見る程度では、グラフィックス性能は問題にならないのも事実です。現行のNVIDIA製品の最下位GT 1030を使用するのも良いでしょう。ファンレスモデルもあります。

1030はローコストだけど性能は高いようです。 androgamer.net Web driverのおかげでNVIDIAならどれを選んでもだいたい大丈夫ですが、中には多少相性の悪いモデルもあるようです。例えば、GTX 1060はスリープからの復帰でノイズが出る問題が指摘されています。 https://www.tonymacx86.com/threads/05-02-added-temporary-fix-pascal-gtx-1060-glitching-after-waking-from-sleep.220670/page-8 今後、すぐに対応されるとは思いますが、その上位・下位の別モデル、1050tiや1070を購入した方が良いかもしれません。

Keplerアーキテクチャ

NVIDIAでもKeplerアーキテクチャとそれ以前の古いカードになると、Web driverなしでも動くモデルがあります。昔のmacOSではNVIDIAを採用していたので、Web driverを入れなくても（入れても機能します）macOSの標準ドライバだけで動きます。OSのバージョンアップに伴う新Web driverの発表を待つ必要もありません。（もっともNVIDIAの対応はとても早くて、24時間くらいで新OSに対応してくれますが）ただ、Mojaveが対応しているiMacに搭載されているNVIDIA GPUがGT 640M/650Mあたりの型番なので、Keplerアーキテクチャ世代にしておいたほうが無難です。できるだけ安く探すとなるとGT 710とかGT 730あたりでしょうか。

Intel CPU内蔵GPUは使えるか？

MacintoshでIntel CPU内蔵GPU (iGPU) を使っている機種は多数あります。これらと同じGPUは問題なく使用できると考えて良いです。純正Macで採用されていないIntel GPUも、近いモデルならば動くことがあります。 MojaveからはMetal対応のGPUのみがサポートされるようになります。Sandy Bridge以前のIntel CPU内蔵GPUは、Metalに対応していません。Ivy Bridge以降のCPUならば大丈夫です。ちなみにMojaveをサポートしているiMacが搭載しているデスクトップ向けIntel HD Graphicsは

Intel HD Graphics 4000
Intel HD Graphics 5000
Intel HD Graphics 6000
Intel HD Graphics 530
Intel HD Graphics 630
Intel UHD Graphics 630

です。Intel UHD GraphicsはMojaveからサポートされています。ただCPU内蔵グラフィックスは、時々画面が乱れるとか、スリープからの復帰に失敗してハングするなどの問題も報告されています。互換性のあるPCIeのグラフィックスカードの方が安定しています。もともと、Intelのデスクトップ用CPUの内蔵GPUはモバイル用に比べて非力です。トラブルに遭遇したら「モバイル機種に負けるようなグラフィックスは使わない」と考えてPCIeグラフィックスカードを検討するのが良いと思います。

ワンクリックで最新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にチェックを入れると非公開最新版をダウンロードできます）

このツールにより、最新版をチェックして差し替える作業が大幅に楽になります。

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権限で動くプログラムです。時々はチェックして、起動するプログラムを把握して、おかしな設定が残っていたら削除するのが良いかと思います。

Sonnetの互換GPUリスト (10.13.4以降)

Tue, 17 Apr 2018 00:30:00 +0900

更新：macOS 10.15.1以降の情報はこちらをご覧ください。(2019/11/4)

Sonnetの互換GPUリスト (10.15.1以降)

macOSで使えるGPU

MacのThunderbolt 3コネクタに接続する外部GPUボックス

を販売しているSonnet社が、macOS 10.13.4以降と互換性のあるグラフィックスカードの一覧を公開しています。 eGFX Breakaway Box for AMD and NVIDIA GPUs | Sonnet 各ブランドごとの多数のモデルを掲載しています。Sonnetの外部GPUボックスは、AppleのExternal Graphics Development Kitにも採用されているほぼ純正みたいな存在です。なので、このリストで互換性があるとされたグラフィックスカードは、Hackintoshで、そのまま動くカードと考えて良いです。互換表のPDFファイルは以下から入手できます。市場に出回っている多数の製品に対して互換性がチェックされているようですので、Hackintosh用グラフィックスカード購入の際は、これで確認しておきましょう。 http://www.sonnettech.com/support/downloads/manuals/Compatibility_Graphics_Cards.pdf これを見ると、例えば、AMDリファレンス（ファンデーション）バージョンでは、以下の機種（Mがマークされた機種）がmacOSと互換のようです。また、ブランドごとの差は無いようです。GPUチップによってのみ互換・非互換が決定するようです。まとめると以下のようになります。

RX 470, RX 480, RX 570, RX 580はどのブランドも互換性あり
RX Vega 56/64はどのブランドも互換性あり
RX 460/550/560は互換性なし
R9 NANO/FURY は互換性なし
WX 5100は非互換で、WX 7100, WX 9100は互換性あり
NVIDIA GeForce は互換性なし

外部GPUを使えるMac

前述のサイトでは、SonnetのThunderbolt 3接続eGPUボックスのマニュアルも公開されています。 http://www.sonnettech.com/support/downloads/manuals/macos_egpu_info.pdf 以前、こちらで紹介したマニュアルの改訂版です。

Sonnetの互換GPUリスト (10.13.2以降)

以前のマニュアルではThunderbolt 2搭載Macの一部もサポートすると書いてありましたが、新しい版では、Thunderbolt 3搭載Macに限定されたようです。具体的には、

2016年以降のMacBook Pro
2017年以降のiMac
iMac Pro

です。この構成でHackintoshすればかなり安心です。ただ、このリストは、Thunderbolt 3が搭載されていることが条件になっていると思われますので、PCIeで接続するHackintoshでは、これ以外の構成でもまず大丈夫です。実際、手元ではiMac15,1で構成したHackintoshでRadeon RX 580が何の問題もなく動いています。ただ、Sonnetの上記の古い方の資料によると、Thunderbolt 2搭載Macのうち、IntelのiGPUを使わない・搭載しないMac Proなどが互換リストから外されていました。iGPUを動かさないとAMDグラフィックスカードのGeekBenchスコアが低下する現象

/posts/62/

もありますので、それと関係があるのかもしれません。

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アプリケーションになります。

これをログイン項目に登録すれば、バックアップが実行された後、痕跡なく終了します。

Sonnetの互換GPUリスト (10.13.2以降)

Fri, 15 Dec 2017 12:45:42 +0900

更新：これはmacOS 10.13.2と10.13.3のための情報です。macOS 10.13.4以降の情報はこちらをご覧ください。(2018/4/17)

Sonnetの互換GPUリスト (10.13.4以降)

SonnetはThunderbolt経由でMacintoshに接続する外部GPUボックスを販売しています。 Breakaway PuckとBreakaway Boxという製品です。

Breakaway Puckは小型の外付けボックスで、RX 560/570が組み込まれた2種類のバリエーションがあるようです。Breakaway BoxはPCIeスロットを内蔵していて、グラフィックスカード無しのモデル、Sapphire Radeon PULSE RX 580搭載モデル、電源容量が350/550Wのモデルのバリエーションがあるようです。Sapphire Radeon PULSE RX 580搭載モデルは、Apple External Graphics Development Kitとしてアップル社の開発者向けサイトで販売されています。
External Graphics Development Kit – Apple Developer

これらの製品のマニュアルはネット上で閲覧できます。このマニュアルの中で、

AMDグラフィックスカードと互換性のあるMacintosh
macOSと互換性のあるAMDグラフィックスカード

が紹介されています。Hackintoshの機種設定と、AMDグラフィックスカードを選ぶ参考になると思いますので、この内容を見てみます。なお、10.13.2が出てからこの書類は更新されています(2017.12.7バージョンになっています)。

http://www.sonnettech.com/support/downloads/manuals/egfx_macos_high_sierra_ug.pdf

以下はこのマニュアルの翻訳です

**追記：**なんとこのPDFがSonnetのサイトから削除されてしまったようです。ダウンロードしておけばよかった。と言うことで、以下の翻訳しか手元にありません。

macOS High Sierraにおける外部AMDグラフィックス

macOS High Sierraにおける外部AMDグラフィックスのサポートは、公式には2018年春までベータ版状態です。現在では、外部グラフィックスによる内部ビデオの高速化は提供されていません。Sonnetがもっとも正確な情報と考えている内容を、このマニュアルでまとめておきます。なお、外部グラフィックスに関して、現時点では、アップルからもAMDからもサポートを得られないことに注意してください。Sonnet社製品を使ってなんらかの問題があったら、Sonnetの顧客サービス、support@sonnettech.comに連絡してください。その際にはSystem Reportを添付してください。

互換性のあるMac

お使いのMacintoshで外部AMDグラフィックスがベータ版サポートされていることを確認してください。Thunderbolt 3を備えたMacは全て互換性があります。

iMac 2017モデル iMac18,1-18,3
MacBook Pro 2016モデル MacBookPro 13,1-13,3
MacBook Pro 2017モデル MacBookPro 14,1-14,3

macOS 10.13.2では多くのThunderbolt 2とThunderbolt搭載Macで、外部AMDグラフィックスが動きます。これらの機種では、Thunderboltケーブルと、Apple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapterが必要です。

iMac Mid 2011 iMac12,1–12,2 (with AMD Graphics) 未検証
iMac Late 2013-Late 2015 iMac14,1–17,1 (with Intel or AMD Graphics) 互換
iMac Late 2012-Late 2013 (with NVIDIA Graphics) iMac13,1–14,2 非互換
Mac mini Mid 2011–Late 2015 (with Intel Graphics) Macmini5,1– 7,1 互換
Mac mini Mid 2011 (with AMD HD 6630M Graphics) Macmini5,1– 5,2 非互換
Mac Pro Late 2013 MacPro6,1 非互換
MacBook Pro Early 2011–Early 2015 (with Intel or AMD Graphics) MacBookPro8,1–12,1 互換
MacBook Pro Mid 2012–Late 2013 MacBookPro9,2–11,3 (with NVIDIA Graphics) 非互換

**訳注：**互換性があるとされた機種は全てIntel Graphicsからの映像出力を提供しています。Intel Graphicsをenableにしないと性能低下が発生することを確認していますので、それと関係があるのかもしれません。Thunderboltを搭載しているにも関わらずMacPro6,1が非互換なのもiGPUが無いためかと思われます。

互換性のあるAMDグラフィックス

macOS High Sierraと互換性のあるAMDグラフィックスカードを持っていることを確認してください。以下の構成は、macOS High Sierra 10.13.2でプラグアンドプレイの互換性があります。

Radeon RX 570を搭載したBreakaway Puck (RX 560搭載モデルは非互換)
Radeon RX 470, 480, 570, 580を搭載したBreakaway Box 350
Sapphire Radeon PULSE RX 580を搭載したBreakaway Box 350 Developer Edition (**訳注：**Appleの開発キットです)
Radeon RX 470, 480, 570, 580, Vega 56を搭載したBreakaway Box 550
Radeon Vega 64またはAMD WX9100を搭載し電源を650Wに強化したBreakaway Box (どのモデルも可)
水冷Radeon Vega 64を搭載し電源を650Wに強化したBreakaway Box 350

訳注：****RX 470, 480, 570, 580, Vega 56, Vega 64およびAMD WX9100が使えるということです。

セットアップ

もしBreakaway Boxを持っているなら、ボックスに互換性のあるグラフィックスカードを差して、補助電源を接続して、ボックスを閉じて下さい。
Breakaway Boxまたは Puckに電源ケーブルをつなぎます。電源スイッチのあるBreakaway Boxの場合は、オンにします。 BoxとPuckは、Thunderbolt 3によりコンピュータ接続されるまでオンになりません。Breakaway BoxまたはPuckをコンピュータにThunderbolt接続し、macOSを起動します。通常の起動より時間がかかるかもしれません。
モニターに配線します。（内部ビデオは外部グラフィックスカードで高速化されません）ゲームや他のアプリケーションでグラフィックス高速化の効果を得るために、外部モニターをメインモニターにしてください。システム環境を選んで、配置を選んで、メニューバーを外部モニタにドラッグします。物理的な位置関係に合わせて、モニタ位置関係を調整してください。

制約や注意事項など

外部グラフィックスはiMacやMacBook Proの内部ディスプレイを高速化しません。
AMD外部グラフィックスカード名は、システムに正しく表示されないかもしれません。Developer EditionのBreakaway Box 350に組み込まれたSapphire PULSE Radeon RX 580はmacOSで「Radeon RX 580」と正しく識別されます。他のGPUは正しく認識されず、「AMD R9 XXX」のような表示になります。
外部グラフィックスはミラーリングをサポートしません。
起動・再起動するときに外部グラフィックスが接続されていると、オートログインが機能しません。
外部グラフィックスをホットプラグ・アンプラグする場合は、ログイン画面に戻る必要があります。
外部グラフィックスには最大4個のモニターが接続できます。
ブートキャンプはサポートされていません。
FacebookページのBreakaway Boxブログ https://www.facebook.com/SonnetTech/ で使用体験をシェアしてください。

**訳注：**名前の表示を正しくする方法はこちらに書いておきました。

/posts/90/

トラブルシューティング

Breakaway Boxでグラフィックスカードが認識されない 外部電源を接続したかどうか確認してください。
モニターの最高画素が選択肢に出ない システム環境設定：ディスプレイを開いて、変更ボタンをオプションクリックしてください。可能な画素数が現れます。
外部モニターが暗いまま、またはマルチモニタに表示が出ない ログアウトしてログインしてください。それで表示が出ない場合はNVRAMをリセットしてください。

SAPPHIRE NITRO+ RADEON RX 580を使う (10.13.3以前)

Fri, 01 Dec 2017 00:00:00 +0900

ご案内：この記事は10.13.2および10.13.3を対象に書かれたものです。10.13.4では、Radeon搭載のThunderbolt 3接続外部GPUボックスが正式サポートされたことにより、ずっと簡単になりました。この記事の**「方法1」「方法2」「方法3」****「モデル名の修正」は不要**になりました。改訂版は以下です。(2018/4/3)

/posts/62/

Radeon RX 580を使ってみました。簡単で性能も良いです。

/posts/139/

Hackintoshのためのグラフィックスカード選び方に関して上の記事で紹介しました。AMDのデスクトップ向けグラフィックスカードは、最近のmacOSのバージョン(10.12.6以降) で互換性が上がり、使いやすくなってきていました。また、最近のCloverではRadeonのイニシャライズに手を加える機能が搭載されて、パッチやkextを使用せずに使えるようになりました。RX 580の供給と価格も、マイニング騒ぎが収束してきたのか落ち着いてきたように思います。今回試したのは、SAPPHIRE NITRO+ RADEON RX 580です。Amazonでは他のブランドと比べてSapphireのRX 580 8Gが最安でした。SapphireはAppleが販売しているVR開発者用キットであるExternal Graphics Development Kit に搭載されているブランドなので、安心感があります。

NVIDIAから乗り換え
RADEONを動かす方法
方法1: 内蔵GPUをプライマリにする
方法2: WhateverGreen.kextを使う
方法3: CloverのRadeonDeInit機能を使う
動作を確認
モデル名の修正
おまけ：現行macOSがサポートするAMDグラフィックスカード

NVIDIAから乗り換え

今まではNvidia Geforceを使っていました。大昔はAMDを使っていましたが、macOSとの互換性が悪くなって、最近は、ずっとNvidiaでした。ということで、NVIDIAが正常に動いているmacOS 10.13.1 からの引越しです。

まずはNVIDIAのために入れていたWebドライバやkextやconfig.plistの設定を外します。/Library/Extensions/に導入されたWebドライバをアンインストールします。iMacのretinaディスプレイの回路を回避してブラックスクリーン発生を防いでくれる機能があるNvidiaGraphicsFixup.kextを入れていたのですが、これも外します。config.plistでNvidiaWebドライバを有効にしていたのですが、これもfalseにしました。

        <key>SystemParameters</key>
        <dict>
                <key>NvidiaWeb</key>
                <false/>
        </dict>

RADEONを動かす方法

ここでシステム終了して、NVIDIAのグラフィックスカードを外し、Radeon RX 580に差し替えます。でもこのまま起動しても画面は出ません。画面が出ないだけで、macOSは起動していますので、sshサーバや画面共有サーバをonにして、他のマシンからアクセスできるようにしておくと良いでしょう。

画面が出ない問題は、Radeon RX 580がプライマリの状態では、グラフィックスカードのBIOSが初期化を正しく実行しないために引き起こされているようです。macOSが正しく初期化しようとするタイミングでは、すでに初期化が終了しているため、macOSによる初期化が実行されないらしいです。これを回避するために、いくつかの方法が知られています。

Radeonカードをセカンダリで起動する。例えば内蔵GPUをプライマリにする。マルチスクリーン環境が前提。
kextやDSDTにパッチを当てて初期化をさせないようにする。
これに相当する作業をWhateverGreen.kextとLilu.kextの組み合わせで実施する。
CloverのRadeonDeInit機能で初期化を阻止する

ここでは、以下のように、1番目、3番目、4番目の方法を紹介します。

方法1: 内蔵GPUをプライマリにする
方法2: WhateverGreen.kextを使う
方法3: CloverのRadeonDeInit機能を使う

方法3がおすすめです。

方法1: 内蔵GPUをプライマリにする

内蔵GPUをプライマリグラフィックスに、Radeon RX 580をセカンダリーグラフィックスに設定します。Radeonグラフィックスチップを搭載した実機や、Apple External Graphics Development Kitを接続した実機と同様の、一番実機に近い設定です。

これを行うためには、BIOS/UEFI設定で内蔵GPUをプライマリに設定します。

この設定をして、RX 580のみをディスプレイに接続すると、起動時のBIOS/UEFI画面やCloverの起動画面は表示されず、ディスプレイが真っ暗なままです。ただ、macOSのログイン画面まで来ると、ディスプレイに表示されます。

起動画面が表示されないので、ある意味、本物のMacのような感じはしますが、BIOSやCloverの操作はできません。通常はこのまま使って、必要な時に、マザーボードのディスプレイ端子にディスプレイを接続するのも良いかと思います。マルチディスプレイ環境や、ディスプレイに複数入力端子があるなら、RX 580とマザーボードの両方に接続しておけば、設定変更も容易になります。

BIOSの設定だけでRadeonが使えるようになりますが、ちょっと不自由な方法です。

方法2: WhateverGreen.kextを使う

WhateverGreen.kextはRadeonグラフィックスカードをプライマリグラフィックスとして使うためのパッチを当ててくれるkextです。Lilu.kextと一緒に使います。両方を/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。これだけでRadeon RX 580が使用できるようになります。

/posts/118/

方法3: CloverのRadeonDeInit機能を使う

もう一つの方法は、Cloverが提供しているRadeonDeInitの機能を使う方法です。この機能は、Clover 4296あたりからサポートされたばかりの新機能で、kext不要です。今後もClover開発者によりメンテナンスされることを考えると安心です。Radeonカードをサポートする機能を作り込むあたりに、Clover開発者の人たちのRadeonへの愛が感じられなくもないです。

この機能を設定しないで起動してしまい、Radeonからの画面が出なくなってしまっても、Cloverの起動画面からClover Boot Optionsを選ぶことで対処できます。この中から、起動画面からGraphics Injectorを選びます。するとこの中に、DeInitという項目があります。これがRadeonの初期化を無効にするオプションです。これにチェックマークを入れます。

これだけの操作で、Radeon RX 580は無事起動します。

config.plistにRadeonDeInitキーを追加して、これをにしておけば、次回の起動から、DeInitの項目を選択した状態になります。

        <key>Graphics</key>
        <dict>
                <key>Inject</key>
                <dict>
                        <key>ATI</key>
                        <false/>
                        <key>Intel</key>
                        <true/>
                        <key>NVidia</key>
                        <false/>
                </dict>
                <key>RadeonDeInit</key>
                <true/>
        </dict>

動作を確認

上で説明した3つの方法を全部試して見ました。どれも問題なく動きましたので、一番シンプルなRadeonDeInitを使う方法で動かすことにしました。

「システム情報」でチェックしてみると、正しく認識されているようです。Metalにも対応しています。Geekbench 4でのOpenCL Scoreは145000前後でした。他でも報告されている程度の妥当な成績なので、正しく設定できていると思います。

なお、しばらく使用していると性能が低下して、ベンチマークスコアが50000くらいになってしまうことがありました。色々試して見たところ、Intel CPU内蔵GPUをマザーボードの設定で無効にしていると性能低下が発生するようです。内蔵GPUはセカンダリーに設定して使用しない場合でも、有効にしておくのが良いようです。

一方、SafariでYoutubeなどの動画を再生すると、再生がカクカクして滞ったり、場合によってはハングすることが発生しました。Google Chromeでは問題が出ません。以前、Intel HD Graphicsを使って同様な不具合が発生した経験があり、その時は、IntelGraphicsFixup.kextとLilu.kextの組み合わせで解消しました。今回も、これで改善しました。ただし、IntelGraphicsFixup.kextとLilu.kextは最新版を使うのが良いです。古いバージョンだと改善しません。この不具合は、CPU内蔵GPUを無効にしても、同様に解決しますが、上記で述べたような性能低下が発生します。

ということで、正しく動作させるために

Intel CPU内蔵GPUは有効にしておく
IntelGraphicsFixup.kextを使う

のが良いようです。

モデル名の修正

「システム情報」や「このMacについて」を見て、ちょっとだけ気になるところがあります。モデル名が実際のカードと違うことです。例えば、RadeonDeInitを使った場合、AMD R9 xxxとなりました。他の方法の場合や、別のブランドのRX 580では別のモデル名になることもあるようです。AppleのExternal Graphics Development Kit に搭載されているのと同じSAPPHIRE PULSE RADEON RX 580を使えば、Radeon RX 580という表示になるという情報もあります。

でも、これは見た目だけの問題で、気にしなければどうでも良いことのようです。どうしても直したかったら、担当しているドライバにパッチを当てます。以下でも紹介した手法でパッチを当てます。

光学ドライブを使う

AMD R9 xxxを担当しているドライバは、AMD9500Controller.kextで、/System/Library/Extensionsにあります。kextの本体は、/System/Library/Extensions/AMD9500Controller.kext/Contents/MacOS/AMD9500Controllerで、これをhexdump -Cすると確かにAMD R9 xxxという文字列が見つかります。これを望みの文字列に書き換えれば良いわけです。AMD R9 xxxという文字列は、Base64変換するとQU1EIFI5IHh4eA==です。これをAMD RX 580に書き換えたかったら、そのBase64に相当するQU1EIFJYIDU4MA==に書き換えるよう、config.plistのKextsToPatchセクションに書き込みます。例えば、以下のようになります。

                <key>KextsToPatch</key>
                <array>
                <dict>
                        <key>Comment</key>
                        <string>Rename AMD R9 xxx</string>
                        <key>Find</key>
                        <data>QU1EIFI5IHh4eA==</data>
                        <key>Name</key>
                        <string>AMD9500Controller</string>
                        <key>Replace</key>
                        <data>QU1EIFJYIDU4MA==</data>
                </dict>
                </array>

ちなみに文字列をBase64へ変換するには、ターミナルで次のようにすれば良いです。

$ echo -n "AMD R9 xxx" | base64
QU1EIFI5IHh4eA==
$ echo -n "AMD RX 580" | base64
QU1EIFJYIDU4MA==

これでモデル名がそれっぽく表示されるようになりました。

おまけ：現行macOSがサポートするAMDグラフィックスカード

Sonnetが販売しているThunderbolt接続外付けGPUユニットのマニュアルによると、macOS 10.13.2でSonnetのユニットに内蔵できるグラフィックスカードは、Radeon RX 470, 480, 570, 580, Vega 56, Vega 64およびAMD WX9100だそうです。外付けGPUとして使えるということは、HackintoshのPCIeスロットに接続してセカンダリーGPUとして使えるということで、また、この記事で紹介したようにCloverの設定でプライマリGPUとして使えると思われます。

Sonnetの互換GPUリスト (10.13.2以降)

Hackintoshの作り方（総集編:10.13版）

Sun, 26 Nov 2017 20:16:38 +0900

macOSをインストールする方法をご紹介してきたのですが、多数の記事に分散してしまっています。そこで、macOS 10.13 High Sierraをインストールする際に参考になる記事へのポインタをまとめた総集編を作ってみました。10.14 Mojaveについては以下をご覧ください。

Hackintoshの作り方（総集編:10.14版）

手順の概要を把握する

こちらは9TO5MacのライターのJeffさんのビデオです。テンポよく紹介されていますので、全体の流れを確認するのに良いと思います。

/posts/121/

macOSインストールのアプローチはたくさんありますが、一番おすすめなのは、Cloverを使ってバニラなインストールをすることだと思います。そのことを説明しています。

/posts/131/

ハードウェアを用意する

Hackintoshを作るためには、互換性のあるハードウェアを自由に選んで組み合わせられる自作PCが、問題が少なく楽です。ノートPCなども可能ではありますが、上級者向けだと思います。CPUは、今の最新Mac実機が採用しているKaby Lakeもしくは

Hackintoshのパーツ選び【その1：CPU編】

発売されたばかりの最新のCoffee Lakeが良いと思います。多少、チャレンジングですが、将来のことを考えたら最新Coffee Lakeで組んでおくのが良いと思います。

Coffee Lake-SでmacOS

そうすると、マザーボードは、CPUに合わせて200シリーズか300シリーズを選ぶことになります。

Hackintoshのパーツ選び【その2：マザーボード編】

/posts/97/

グラフィックスカードはNVIDIAかAMDでしょうが、どちらも長短あります。少し前は、互換性、ドライバの提供、性能の点からNVIDIAがお勧めだったのですが、最近のmacOSではAMDの互換性が上がっています。詳しくは以下を参考にしてください。

HACKINTOSHのパーツ選び【その3：グラフィックス編】10.14以降版

/posts/36/

/posts/90/

無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。

/posts/138/

Hackintoshのパーツ選び【その5：SSD】

Hackintoshのパーツ選び【その6：その他】

マザーボードのBIOS/UEFIを設定する

インストール先のコンピュータを組み上げたら、macOSが稼働するようにBIOS/UEFIを設定しておきます。この設定が間違っていると、それだけで起動しない場合もあります。

マザーボード (BIOS) 設定

必要なソフトウェアを入手する

Hackintoshするには、macOS本体以外にオープンソースで有志が開発しているソフトウェアがいくつか必要です。必要なソフトウェアの名前で検索すれば、大抵の場合、ダウンロード先が見つかります。オープンソースのソフトウェアは、オリジナルを作った人の他に、いろいろな人がソースコードを引き継いで分岐（フォーク）して、開発を行なっている場合もあります。中には元祖の開発者が放置して、開発が止まっていることもあります。なので、検索して、現在一番活発に利用されているバージョンを使うのが良いです。ということで、古いハウツー情報のダウンロード先から入手するよりも、検索をして探すのがおすすめです。

Clover EFI bootloaderとefiドライバー

“Clover EFI bootloader”で検索します。以下が本家かと思われます。

https://sourceforge.net/projects/cloverefiboot/

こちらでも最新版が配布されています。

github.com

Cloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。

kext類

FakeSMCをはじめとしたkext （カーネル拡張）が必要です。名前で検索します。例えば、FakeSMC.kextならば、”FakeSMC.kext”で検索すると、こちらで入手可能なことがわかります。

RehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket

Mac上で導入用のUSBメモリを作る

次に、macOSを入手して、インストール用のUSBメモリを作ります。これは実際のMacで作業します。ついでに、実際のMacでこのUSBメモリが起動することを確認しておきましょう。次に、インストール対象のマシンで起動できるように、Cloverのインストールと設定も行っておきます。

/posts/93/

Cloverインストールの手順はこちらにも書いてあります。

Cloverインストーラの設定

config.plistの例を示して、説明しました。

config.plistの実例紹介

config.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。

正しく機種設定する (SMBIOSの設定)

対象マシンをUSBメモリで起動してmacOSを導入する

このUSBメモリを、インストール先のマシンに挿して起動させます。起動しない場合は、Cloverの設定やkextの選定を確認します。

USB 3.0/3.1のUSBメモリを使った場合、Cloverの選択画面は現れるけど、そのあとのプロセスで失敗することがあります。macOSにはUSBの個数に制限があり、3.0/3.1のポートが2.0としてしか動かない場合があるからです。対応方法は以下の記事の「ポートを増やすパッチ」をご覧ください。

USBポートを設定する

ただ、USB 2.0でしたら確実に起動しますので、

USB 2.0のUSBメモリを使う
マザーボードのUSB 2.0専用ポートを使用する（全部が3.0/3.1の最近のマザーボードではこの手法は使えないです）
USB 2.0ハブを経由して無理やり2.0にする

などで対応するのが簡単です。2.0なのでインストールに時間がかかる欠点はあります。

無事起動したら、インストール先のSSD/HDDをGUIDパーティションとHFSジャーナリングでフォーマットします。次に、macOSインストーラを起動して、High Sierraをインストールします。インストール先ボリュームがSSDの場合は、ファイルシステムが自動的にAPFSに変更されるかもしれません。

macOSのインストール途中で、何度か再起動することがあります。その場合は、USBメモリから起動して、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。

対象マシンにCloverを導入する

インストールが終了したら、またUSBメモリのESPから起動して、Cloverの選択画面でインストール先のmacOSを選択して起動します。この後、Cloverインストーラを起動して、インストール先にCloverを入れます。この手順は、先のUSBメモリにCloverを入れたのと同じ作業です。すでに動いているUSBメモリのESPをコピーしても良いです。SierraのHackintoshをHigh Sierraにアップデートする方法をこちらに書いておきましたので、ESPのコピーを行う方法の参考になるかと思います。

HackintoshをHigh Sierraにする

macOS環境を整える

USBに入れたCloverとkextで、最低限の起動は行えるようになっているはずです。さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。

/posts/90/

Ethernetを設定する

/posts/120/

High Sierra導入用USBメモリ作成方法

Fri, 24 Nov 2017 14:10:36 +0900

このページは古いmacOS用の情報です。有用ではありますが、最新macOSに関する情報は以下をご覧ください。

Catalina導入用USBメモリーを作成する

今一番よく使われるHackintoshの作成方法は、以下のステップです。

Step 1: Mac上でmacOSインストール用のUSBメモリーを作成する
Step 2: USBメモリーにCloverをインストールする
Step 3: USBメモリーで対象マシンを起動してmacOSをインストールする
Step 4: 対象マシンにCloverをインストールする

Step 1, 2は本物のMacintosh (以下、実機)で行います。一方、Step 3, 4はインストール先のマシンで行います。Step 2とStep 4では、USBメモリとインストール先マシンのそれぞれにCloverをインストールしています。

よく紹介される手法では以下のような戦略でCloverをインストールしています。つまり、Step 2のUSBメモリへのインストールでは、できるだけ汎用性を持たせた設定にして幅広いマシンで起動できるようにします。一方、Step 4では、対象マシンに合わせたチューニングを施して性能を引き出します。

例えば、Tonymacx86で配布されているUniBeastは、Step 1, 2を自動化するツールですが、緩いチューニングで多くのハードウェアでとりあえず起動させることを目指しています。そのあと、インストール対象マシン上でMultiBeastツールを動かして、細かいチューニングをする手順を採用しています。この過程で、起動しなくなることも多いです。インストール対象マシンで試行錯誤を繰り返す手法では、起動不能になった場合、USBインストーラのESPからmacOSを再起動し、インストール先のESPの修正を行い、修正したESPを用いて起動する作業を繰り返します。修正と再試行のために、合計2回、macOSを起動し直すには時間がかかります。またとりあえず起動できるだけのmacOSでは画面が低解像度だったりネットに接続できないなどの不便さもあります。

そこで、Step 2の段階でインストール先マシンに合わせたチューニングを行うことを考えました。Step 2のインストールでチューニングを行えば、起動失敗したらUSBメモリーを実機に戻して修正すれば、再起動の手間は半減します。また、実機の整った環境で効率よく作業できます。ということで、Macintosh信者らしく実機を活用して、ある程度ちゃんとしたチューニングを目指したmacOSインストール用USBメモリーを作ってみます。

(1) App StoreからHigh Sierraを購入する

無料です。ダウンロードするとインストーラが起動しますが、これは中断します。/Applicationsの中にmacOS High Sierraインストール.appというアプリケーションができているはずです。5GB以上のサイズです。

(2) USBメモリを用意してフォーマットする

USBメモリーを用意します。容量は最低で8GB必要です。でも8GBと表記されている製品でも、ギリギリ足りないこともあります。その上の16GBにしておけば確実です。さらに上の32GBくらいになると、インストーラじゃなくてmacOSそのものをインストールできます。ただしUSB 2.0の速度で起動すると、かなり時間がかかります。

ディスクユーティリティ.appを起動して、USBメモリを、GUIDパーティションマップで、Mac OS拡張（ジャーナリング）フォーマットで初期化します。名前は、後で自動的に改名されてしまうので、ここでは適当で構いません。ここではUSBとしました。

(3) macOSインストーラをUSBメモリに入れる

macOSをクリーンインストールするために、インストール用ドライブを作成する機能, createinstallmediaが用意されています。ターミナルから、以下のようにタイプします。

$ sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/USB

これはUSBメモリがUSBという名前でマウントされている場合の例です。確認のプロンプトの後、しばらく時間がかかってインストール用USBメモリーが出来上がります。

名前もInstall macOS High Sierraに変わっています。ここで作成したUSBメモリーは、実機で起動して、macOSのクリーンインストールに使用することができます。オプションキーを押しながら実機を起動して、このUSBメモリで正しく起動できることを試しておきましょう。ここまでの手順はAppleのサポートページでも紹介されています。

macOS の起動可能なインストーラを作成する方法

(4) 必要なファイルを入手する

Cloverとkextファイルを入手しておきます。いずれも、その名前を使って検索すると、ダウンロードサイトが見つかります。kextについては、こちらの記事を参考にしてください。

/posts/126/

Clover EFI Bootloader

macOSを起動するブートローダです。

sourceforge.net

FakeSMC.kext

必須のkextです。MacにはSystem Management Controllerというサブシステムがあり、これのふりをしてくれるのがFakeSMC.kextです。RehabManさんがメンテナンスしてくれているダウンロードサイトです。

RehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket

Lilu.kext

これを使ってパッチを当てるkextを使う場合に必要なkextです。以下で解説しておきました。ダウンロード先も以下をご覧ください。

/posts/118/

グラフィックスkext (Intel用)

CPU内蔵のiGPU (Intel HD Graphics) を使う場合には、IntelGraphicsFixup.kextを使います。必須ではありませんが、いくつかの不具合を直してくれます。Lilu.kextが必要です。

sourceforge.net

グラフィックスkext (NVIDIA用)

NVIDIAのGeforceを使う場合には、NvidiaGraphicsFixup.kextを使います。SMBIOSで設定する機種によってはこれがないとブラックスクリーンになってしまい、表示が出ません。Lilu.kextが必要です。

sourceforge.net

グラフィックスkext (AMD用)

**追記：**10.13.4から、Appleの外部GPUボックス推奨のAMDグラフィックスカードを使う場合は、何もせずそのまま使えるようになりました。なので、以下に紹介したWhateverGreen.kextも不要です。(2018/4/12)

AMDのRadeonを使う場合には、WhateverGreen.kextを使います。これを使わないとプライマリディスプレイにならず、ブラックスクリーンになります。Lilu.kextが必要です。

github.com

そのほかのkext

必須ではありませんが、LAN用のkext, オーディオ用のkext, USB設定のためのkextがあっても良いです。後から用意しても良いですが、LAN用は早い段階で欲しいかもしれません。

Ethernetを設定する

/posts/120/

USBポートを設定する

(5) Cloverをインストールする

こちらに詳細に説明しておきました。

Cloverインストーラの設定

この手順でインストールを行います。選択する項目は以下です。

インストールボタンを押せばインストールが終了します。

インストールが終了した段階で、EFIという名前のボリュームがマウントされています。その中の、CLOVERフォルダに、先ほど指定したOsxAptioFix2Drv-64.efiなどが入っています。

Cloverインストール直後は、EFIがマウントされています。しかしEFIボリュームは通常はマウントされないので、手動でマウントする必要があります。こちらで説明しておきました。

ESPをマウントするためのシェルスクリプト

(6) kextをUSBメモリに入れる

用意したkextをUSBメモリのESP (EFI System Partition) に入れます。CLOVERの中のkextsというフォルダに、バージョン番号のディレクトリがあります。使いたいmacOSのバージョンに合わせたフォルダに入れます。Otherフォルダに入れたkextは、いずれのバージョンでも使われます。通常は、数字の方か、Otherかのいずれかを使います。

ここでは、macOS High Sierra用に10.13フォルダにkextを入れてみました。AMDグラフィックス搭載マシンを想定してWhateverGreen.kextが入っています。

(7) apfs.efiを入手してUSBメモリに入れる

macOS High Sierraからシステムのファイルシステムが、従来のHFS+からAPFSに変更されました。インストール先がUSBメモリだったりHDDだとHFS+のままですが、SSDだと自動的にAPFSに変換されます。USBメモリ内のインストーラを起動するだけなら関係ないですが、SSDにインストールされたmacOSを起動する場合はAPFSにアクセスできる機能が必要になります。Clover、というか一般にブートローダは、OSが起動する前に、ドライブからブートのためのファイル（例えばカーネルなど）を読み込む必要があるからです。この機能は、High Sierraに入っているapfs.efi で行えます。

まずはHigh Sierraインストーラの中にあるBaseSystem.dmgをマウントして、その中のusr/standalone/i386を開きます。

$ open /Applications/Install\ macOS\ High\ Sierra.app/Contents/SharedSupport/BaseSystem.dmg

$ open /Volumes/OS\ X\ Base\ System/usr/standalone/i386/

この中にapfs.efiがあるので、これをUSBメモリのCLOVERのdrivers64UEFIにコピーします。

(8) config.plistを編集する

ESPのCLOVERの中には、デフォルトで作成されたconfig.plistが入っています。これをconfig_def.plistのようにコピーしておきます。ちなみに、Cloverの起動画面で、configXXXX.plistのような名前のファイルから起動に使うファイルを選ぶことができます。config.plistについてはこちらで解説しておきました。

config.plistの実例紹介

デフォルトのconfig.plistはこんな感じになっています。

[XML] Clover config.plist – Pastebin.com

結構ややこしくて長ったらしいです。多くはコメントアウトされた記述です。XMLのコメントアウトは書きにくいのか、ここではkeyの名前に#をつけています。#をつけて、ありえない名前にすることで、無視されるようにしているようです。例えば、DisableDriversと書くべき以下の部分を、

DisableDrivers
CsmVideoDxe
VBoxExt4

#DisableDriversと以下のように書くことで、

#DisableDrivers
CsmVideoDxe
VBoxExt4

この部分をコメントアウトするのと同等の記述をしています。後からこの記述が必要になった時は、#を外せば良いのです。ただ、このようにコメントアウトされている箇所は、必要性の低い場所です。なのでほとんど削除することができます。

また、他にも必要性の低い場所があります。昔のマザーボードやハードウェアで必要とされていたものの、現在のマザーボードなどではほとんど不要であったり、むしろ不具合を引き起こしたりする記述が多くあります。それらを削除すると簡単になります。

(9) SMBIOSを設定する

デフォルトのconfig.plistでの機種設定は暫定的な設定です。実際には、インストール先のマシンに合わせて、しっかりと設定する必要があります。こちらに詳しい内容を説明しておきました。

正しく機種設定する (SMBIOSの設定)

こうして、コメントアウトされた部分を消して、不要な設定を消して、SMBIOSを設定した例を以下に示します。

[XML] Customized config.plist – Pastebin.com

(10) USBメモリで起動する

このUSBメモリをインストール対象マザーボードにさして、UEFIで起動ドライブに設定して、起動させます。以下のようなCloverの画面が出てくるはずです。デフォルトはクリスマスになっていました。ここまでは、Cloverをインストールすれば問題なく行き着くはずです。

なお、USBメモリが3.0である場合（多分、この容量のメモリはほとんど3.0じゃないでしょうか）USB 2.0のポートを使うと安全です。というのはUSBの個数制限で、macOSの起動後にUSB 3.0がアクセスできなくなり、止まってしまう可能性があるからです。2.0は遅いですが仕方ないです。生きている3.0もあるはずなので、ポートを抜き差しして、それを探しても良いです。USBの個数制限に関してはこちらの記事を見てください。

DSDTを変更してUSBポートを選別する

(11) macOSを対象マシンで起動することを確認する

この後、macOSのインストーラの起動が始まります。macOSのインストーラ画面が出れば無事終了です。現実には、途中で止まってしまうことも多いかと思います。その場合は、ブートオプションに-vをつけてエラーメッセージをみてください。Couldn’t allocate runtime areaというエラーを出して停止している場合は、OsxAptioFix…を別のものに差し替えてみてください。ここで何度か試行錯誤の作業が必要になるかと思います。とても運が良ければ、一回で起動できるかもしれません。

この先は、通常の実機でのmacOSクリーンインストールと同じ手順です。すなわち、インストール先のドライブをディスクユーティリティでフォーマットし、macOSをインストールします。何度か再起動することがありますが、その場合は、Cloverのブートドライブ選択画面でBoot macOS Install from…という項目を選びます。

macOSのインストールが終了したら、一旦はUSBメモリで起動して、起動項目でインストールしたばかりのmacOSドライブを選択します。そしてCloverをインストールし、USBメモリのESPの内容を、新しいmacOSドライブのESPにそのままコピーすれば、Hackintoshが完成です。

Hackintoshのパーツ選び【その3：グラフィックス編】

Sun, 10 Sep 2017 12:15:51 +0900

このページは古い情報です。最新の情報はこちらをご覧ください。

/posts/36/

【2018年4月2日改訂：10.13.4以降のRadeonの近況を追記しました。】
【2017年12月17日改訂：Radeonの近況を追記しました。】
【2017年12月1日改訂：CloverのRadeon対応を追記しました。】

Hackintosh自作に適したグラフィックスカードを紹介します。

NVIDIAかAMD(ATI)か

グラフィックスカードの2大メーカが、NVIDIAとAMDで、自作する人たちの中では、どっちが良いのかという議論で盛り上がることも度々です。歴代のMacintoshはそのどちらも使っていましたが、最近はAMD派です。ならばHackintoshもAMDが良い、と単純に決まりそうですが、そうでもありません。tonymacx86の推奨パーツのサイトでは、長らくNVIDIAのグラフィックスカードだけが推奨リストに挙げられていました。でも最近では、AMDのグラフィックスカードも少しずつ推奨されています。

www.tonymacx86.com

では、実際のところどうなんでしょうか。結論を先に書いておくと、それぞれメリット、デメリットがあります。ただ、10.13.4になってからAMDが優勢です。

NVIDIAを選ぶメリット

AMDに比べてハイエンドモデルのグラフィックス性能が高くて性能あたりの消費電力が少ない
NVIDIAがmacOS用のドライバ(Web driver)を供給している。更新は早い
Kepler (GTX 600シリーズと700の一部)以前ならmacOS標準ドライバだけで動く

AMDを選ぶメリット

Final Cut Pro Xなどが最適化されているのでNVIDIAより高速に動く
macOSにドライバが含まれているのでメーカ供給のドライバに頼らなくて良い
macOS 10.13.4から外部GPUがサポートされて一部のモデルは接続するだけでそのまま使える

AMD

最近のMacintoshではAMDを採用しています。なのでHackintoshでもAMDが最適の選択のように思えるかもしれません。

macOS 10.12.5以前

しかし、Hackintoshのグラフィックスカードとしては、AMDは問題の多い選択肢でした。macOSにはAMDのドライバーが含まれているものの、実際にはモバイルバージョンばかりが採用されています。そこでデスクトップ用グラフィックスカードとの互換性が低かったのです。頑張ってカーネル拡張(kext)にパッチしても、スリープからの復帰が不安定だったり、起動時に画面が出なかったりしました。なのでtonymacx86のガイドでもAMDは推奨されていませんでした。

macOS 10.12.6 ~ 10.13.3

ところがSierraバージョン10.12.6で事情が激変して、AMDが一気に魅力的な選択肢になりました。きっかけは、2017年のWWDCでThunderbolt接続の外付けGPUサポートが発表されたことです。開発キットとしてアップルが販売開始した外付けGPUボックス（External Graphics Development Kit）にはAMDのRadeon RX 580が内蔵されていました。そこで、AMDの現行モデルの一部が、macOSのドライバで正式にサポートされたのです。AppleのExternal Graphics Development Kit はSonnet社の製品を使っています。そのマニュアルをこちらで紹介しましたのでご覧ください。

Sonnetの互換GPUリスト (10.13.2以降)

これによると、macOS 10.13.2で挿すだけで動くグラフィックスカードは、

Radeon RX 470/480/570/580（特にSapphire Radeon PULSE RX580が良い）
Radeon Vega 56/64
AMD WX 9100

とのことです。ThunderboltはPCIeの信号をシリアル化して外部に引っ張り出したものなので、HackintoshでPCIe接続する場合においても、これらのカードを使うのが良いと思われます。

macOS 10.13.4 以降

10.13.4では外付けGPUボックスがいよいよ正式にサポートされました。その結果、10.13.3以前にあった問題点が全て解決されました。Apple社からも公式にサポートするグラフィックスカードが紹介されています。

Apple推奨グラフィックスカード

これによると、Polaris, Vega 56, Vega 64の3種類のアーキテクチャがサポートされているようです。具体的なチップは、以下です。

AMD Radeon RX 470, RX 480, RX 570, RX 580, Radeon Pro WX 7100
AMD Radeon RX Vega 56
AMD Radeon RX Vega 64, Frontier Edition Air, Radeon Pro WX 9100

Sonnetの互換GPUリスト (10.13.4以降)

ということで、AppleやSonnetが推奨するAMD GPUを使えば、簡単にHackintoshできるので、お勧めです。このリストには比較的高価なGPUが多いのですが、お手軽なところではRX 570, RX 580でしょうか。

その一方、AMDの製品は、NVIDIAと比較して上位機種の性能、性能あたりの消費電力で未だに劣っています。ただ、macOSで使うことを前提にすると、OSで正式にサポートされているアーキテクチャなので、色々と最適化されています。例えば、Final Cut Pro Xなどを使って性能比較すると、NVIDIAよりも圧倒的に良いスコアを叩き出します。

OSが標準でサポートしてくれていることは、将来にわたって安心感があります。NVIDIAのWeb driverは、OSのバージョンアップにいまのところ敏速に対応してくれていますが、将来にわたって期待できる保証はありません。一方で、macOSが一旦サポートしたハードウェアは、NVIDIAの古いモデルと同様に、今後も機能し続けることが確実です。

AppleのExternal Graphics Development Kit には、SAPPHIRE PULSE Radeon RX 580が搭載されています。他のブランドでも問題ないと思いますが、SAPPHIREが少しは安心かもしれません。他社ブランドと比べても安価な部類のようです。ちなみにPULSEは代理店の扱いが終了してしまったようで今は入手困難です。現在はクロック数が上がり、放熱部品やコンデンサ部品が強化された上位モデルのNITRO+がSAPPHIREの主流商品です。こちらでこの製品を使用した結果を紹介しています。

/posts/62/

NVIDIA Pascal, Maxwell

MacintoshがこのところAMDだけを採用しているにもかかわらず、HackintoshではずっとNVIDIAが定番でした。昔、NVIDIAが採用されていた名残で、未だにドライバがOSに含まれていて、そのまま動いたからです。ただその魔法も、新しいアーキテクチャになると効かなくなりました。現行のPascalとその前のMaxwellアーキテクチャを採用したグラフィックスカードは、macOSの標準ドライバでは動きません。

一方でNVIDIAは、独自でmacOS用のドライバを開発して配布してくれています。なので、これ（NVIDIAのWebページで配布されていて、Webという名前の含まれるkext群で構成されるのでWeb driverと呼ばれます）を使えば、最新のPascalアーキテクチャモデルが問題なく動きます。もちろん、それ以前のモデルもサポートされています。AMDではmacOSがサポートしてくれるモデルに制限があったのに対して、NVIDIAではメーカーが配布してくれるWeb driverをインストールするだけなので、とても簡単です。Web driverはmacOSのバージョンごとに配布されています。機能はそれほど変わらないようですが、macOSのバージョンチェックをして、合致しないビルド番号では起動しません。以下のサイトで、それぞれのビルド番号に合ったドライバのダウンロードURLがまとめて整理されています。

www.macvidcards.com

macOSのビルド番号は、「リンゴマーク」「このMacについて」のOSバージョンの文字をクリックすると、その横に表示されます。下の例では17E202です。

PC自作ユーザ向けの最上位機種、GeForce GTX 1080Tiはとても強力で、性能あたりの消費電力も低いです。その一つ下のモデルのGTX 1080でも十分強力です。最近発売されたAMDのVega 64でも、性能は1080にある程度追いついたものの、価格と消費電力で負けているようです。なので、グラフィックス性能を重視したらNVIDIAが良いと思います。特に、Windowsと併用するとか、グラフィックス性能を必要とするゲームをするなどの場合は、NVIDIAを選ぶことにメリットがあります。

グラフィックス性能は不要という人も多いと思います。普通にGUI操作したり動画を見る程度では、グラフィックス性能は問題にならないのも事実です。現行のNVIDIA製品の最下位GT 1030を使用するのも良いでしょう。8,000円程度です。ファンレスモデルもあります。

1030はローコストだけど性能は高いようです。

androgamer.net

Web driverのおかげでNVIDIAならどれを選んでもだいたい大丈夫ですが、中には多少相性の悪いモデルもあるようです。例えば、GTX 1060はスリープからの復帰でノイズが出る問題が指摘されています。

https://www.tonymacx86.com/threads/05-02-added-temporary-fix-pascal-gtx-1060-glitching-after-waking-from-sleep.220670/page-8

今後、すぐに対応されるとは思いますが、その上位・下位の別モデル、1050tiや1070を購入した方が良いかもしれません。

NVIDIA Kepler以前

Keplerアーキテクチャとそれ以前の古いカードも良いです。というのは、これらはWeb driverを入れなくても（入れても機能します）macOSの標準ドライバだけで動くからです。OSのバージョンアップに伴う新Web driverの発表を待つ必要もありません。（もっともNVIDIAの対応はとても早くて、24時間くらいで新OSに対応してくれますが）

macOSの標準ドライバだけで動く古いNVIDIAカードはたくさんあります。例えば以下のような製品が手に入るなら、安価に使えるようです。

nvidia gt 9400
nvidia gt 9500
nvidia gt 210
nvidia gt 220
nvidia gt 9600
nvidia gt 240
nvidia gts 250
nvidia gt 610
nvidia gt 630
nvidia gt 640
nvidia gt 710
nvidia gt 730

**追記：**High SierraではKeplerは動くけど、それより古いFermiは動かなかったという報告があるようです。あまり古いものは避けて、Keplerのモデルにしておいたほうが無難かもしれません。できるだけ安く探すとなるとGT 710とかGT 730あたりでしょうか。

Intel CPU内蔵GPUは使えるか？

現行のMacintoshでもIntel CPU内蔵GPU (iGPU) を使っている機種はあります。が、それらはMacBookシリーズやMac miniで、モバイル用のCPUを使っていて、iGPUのモデルがデスクトップ用CPUと違います。でも、違うとは言っても、ある程度の互換性はあるようで、デスクトップ用CPU iGPUはHackintoshで「なんとなく動く」のが実情です。「なんとなく」というのは、時々画面が乱れるけど大体使える、とか、スリープからの復帰に失敗してハングする、とか、そういう状態です。iMacではAMDのGPUとデスクトップ用CPU iGPUが併用されることもありますが、使い方が違うのか、だからと言ってすんなり動くわけではないようです。ここで紹介したAMDかNVIDIAのグラフィックスカードを使用するのが良いと思います。

ということで、Kaby Lake, Skylake世代のiGPUは実用的ではないと思います。サーバにして画面はネット越しにしか見ないとか、スリープはさせないとかの使い方ならよいかもしれません。これに対して、Haswellでは、内蔵GPUがちゃんと使えました。Hackintosh界隈では、Haswellは良かったという声が聞こえます。もともと、Intelのデスクトップ用CPUの内蔵GPUはモバイル用に比べて非力です。モバイル機種に負けるようなグラフィックスは諦めて使わない、と考えるのが良いです。

古い情報 on Boot macOS

ASRock Z590マザーボード搭載ALC1220で音を出す (その1)

Z590マザーボードのサウンド

PCIIDを偽装する

まとめ

使用するUSBポートを15個指定する (OpenCore編)

OpenCoreで15個制限を全撤廃

OpenCoreで使用する15個を指定する

まとめ

9900KマシンをmacOS 10.14.5に更新する

新iMac対応Mojaveが公開される

CPUの名称表示を改善する

10.14.4ではCPUが「不明」

10.14.5ではCPUが「Core i7」

10.14.5 + Clover 4934ではCPUが「Core i9」

Hackintoshが起動しなくなる前にやっておくこと

動作するconfig.plistをバックアップしておく

ESP全体をクラウドにバックアップしておく

訓練：バックアップESPから復旧する

画面共有・sshサーバを起動しておく

APFSコンテナにボリュームを作っておく

9900KのためにmacOS 10.14.4 (18E2034) を入手する

新iMac対応Mojaveが欲しい

iMac19,1の設定でMojaveを入手

18E2034はEarly 2019限定？

手順のまとめ

9900Kのsleep問題〜原因はiGPUのデバイスID

sleepがまだ不完全

UHD Graphics 630のデバイスID

i3-8100でも対応必要

9900KのデバイスID対応

eficheckにファームウェアが違うと注意されました

eficheckの動く仕組み

eficheckを止める

EFICheckDisabler.kextを使う

メッセージが出ないこともある

Hackintoshのパーツ選び 【その3：グラフィックス編】10.13.4以降版

Hackintoshグラフィックスの選択肢

AMDグラフィックス

NVIDIA

Keplerアーキテクチャ

Intel CPU内蔵GPUは使えるか？

ワンクリックで最新kextに〜Kext Updater.app (Ver. 2)

Cloverで使うEFIドライバ

64bit移行のためと思われる名称変更

EFIドライバフォルダ名

末尾が-64のドライバ

デフォルトのEFIドライバ

オプションのドライバ

メモリ確保のドライバ

ApfsDriverLoader.efi

その他のドライバ

EFIドライバを整理してみる

10.13.6でESPをマウントする権限が変更される

ESPをマウントするためのシェルスクリプト（改訂版）

ESPを自動バックアップする方法（改訂版）

Launchdを使う

launchd.plistを作る

バックアップスクリプトを用意する

Launchd.plistの内容

Sonnetの互換GPUリスト (10.13.4以降)

macOSで使えるGPU

外部GPUを使えるMac

ESPを自動バックアップする

ESPをTime Machineにバックアップする

ESPをクラウドファイルサーバにバックアップする

シェルスクリプトでESPバックアップする

ログイン項目に設定する

Automatorでアプリケーションにする

Sonnetの互換GPUリスト (10.13.2以降)

macOS High Sierraにおける外部AMDグラフィックス

互換性のあるMac

互換性のあるAMDグラフィックス

セットアップ

トラブルシューティング

SAPPHIRE NITRO+ RADEON RX 580を使う (10.13.3以前)

NVIDIAから乗り換え

RADEONを動かす方法

方法1: 内蔵GPUをプライマリにする

方法2: WhateverGreen.kextを使う

Hackintoshのパーツ選び【その3：グラフィックス編】10.13.4以降版

Hackintoshのパーツ選び【その3：グラフィックス編】