ストレージ on Boot macOS

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と同じ転送速度が達成されていることを確認しました。

リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)

Sun, 15 Nov 2020 01:10:14 +0900

抜き挿し可能なリムーバブルSATAドライブベイで、HDD/SSDのホットプラグを可能にするパッチを以前ご紹介しました。Big Surでパッチパターンが変わったので、これに対応しました。

5.25インチベイ用リムーバブルHDDラック

上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでホットプラグが機能するようにconfig.plistにkextパッチを当て、対応していました。

SATA接続HDD/SSDのホットプラグ

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

このパッチが効くと、マザーボードのチップセットが持っているSATA端子以外、つまり、マザーボード上にSATAチップを追加して増設したSATA端子が、リムーバブルドライブとして扱われるようになります。チップセットがサポートするSATAは通常6個ですので、8個のSATAを持っているマザーボードは、最後の2個が対象になります。また、PCIeスロットにSATAアダプターカードを挿してSATA端子を増設した場合も、そこに接続されるドライブがリムーバブルになります。例えば以下のような、Marvell 88SE9230チップセットや、ASMedia ASM1061チップセットを搭載したカードです。

ところが、Big Surにバージョンアップしたら、このパッチが効かなくなったようで、ホットプラグが機能しなくなりました。調べたところパッチパターンが変わっていたようです。

パッチの方法

パッチは、/System/Library/ExtensionsにあるAppleAHCIPort.kextのバイナリファイルの該当部分を、0x90 (マシンコードでNOP, No OPerationに相当します) に置き換えるものです。置き換える範囲は、ファイルの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。この26バイトのパターンが、Big Surになって変わっていたようで、パッチが効かなくなっていました。

そこで、Big Surのkextの中で0x40200000を探して、書き換えるべきデータ列を調べなおすことにしました。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpして、lessコマンドで表示を一旦停止しておきます。

% 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が続く場所はありません。もしもこれで見つからなければ、他の場所に改行が入っているかもしれませんので、

/20 00 00

で探せば良いと思います。

今回、発見できた場所の前後のデータは以下です。

0003da0 01 00 00 89 d1 81 e1 40 60 02 00 81 f9 40 20 00
0003db0 00 75 0c 81 e2 bf 7f ff ff 89 93 69 01 00 00 f6
0003dc0 c2 40 74 7e 3d 09 01 01 00 72 77 44 89 fe c1 ee
0003dd0 0a 81 e6 80 00 00 00 81 e2 7f ff ff ff 89 d1 09

ここで発見した0x40200000の4バイト、その前8バイト、その後14バイトの、合計26バイトをNOP (90) に置き換えるパッチを作ります。つまり、

Find --> 81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

というパッチを作ります。前回のパッチパターンに類似していますのでおそらく合っていると思います。

config.plistをテキストエディタで編集する場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。

% echo -en "\x81\xE1\x40\x60\x02\x00\x81\xF9\x40\x20\x00\x00\x75\x0C\x81\xE2\xBF\x7F\xFF\xFF\x89\x93\x69\x01\x00\x00" | base64 
geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=

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の場合

最近Cloverは使っていないので検証できませんが、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>geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>

OpenCoreの場合

OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーは以下です。

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

であることがわかります。これはBig Surになっても変更はありませんでした。そこで、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>geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>
</dict>

ProperTreeやPlistEDPlusなどのアプリケーションで設定するなら、16進数でそのまま書けます。ProperTreeでは16進数のデータの8バイトごとにスペースを入れる流儀のようですが、

81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000

PlistEDPlusではスペースを入れないようです。

81E14060020081F940200000750C81E2BF7FFFFF899369010000

以下はPlistEDPlusの例です。Item番号はたまたま7番目になっていますが、何番目でも大丈夫です。

動作確認

パッチをOpenCore 0.6.3のconfig.plistに追加したところ、Big Surでもこのホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた3.5インチHDDです。

補足

最初の記事、

では、

Find --> 40600200
Replace --> 00000000
AppleAHCIPort

というパッチを当てれば、ASMediaやMarvellのチップでホットプラグが可能になるという情報を紹介しました。今回、Big Surで試したところ、マウントする際にシステムが落ちてしまう現象が発生しました。PCIeに挿すASMediaやMarvellのSATAカードでも、ここで紹介した長いパッチは安定して動きますので、この記事の方式を使ってください。

まとめ

リムーバブルドライブベイのホットプラグを可能にするパッチを、Big Sur用に書き換えて動作を確認しました。これからも、しばらくはBig Surへの対応作業を楽しめそうです。

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にすれば良いと思われます。

リムーバブル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版)

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に移行して、動作を確認していこうと考えています。

SATA接続HDD/SSDのホットプラグ（改訂版）

Tue, 11 Feb 2020 17:15:22 +0900

SATA接続HDD/SSDのホットプラグに関する以下の記事をアップデートしました。最近のmacOSバージョンでホットプラグが効かなくなっていたのですが、コメントでパッチを教えていただき、快調に動くようになりました。

SATA接続HDD/SSDのホットプラグ

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を利用できます。

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本来の性能を活かせているようです。

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) のチップセットを使っています。

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にも使えるカードだと思います。

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に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に問題なく移行できました。

M.2のソケット

Wed, 02 Jan 2019 21:44:50 +0900

現行マザーボードに必ず付いているM.2のソケットについて、Hackintoshに必要な知識をまとめてみました。

M.2はWiFi/Bluetoothの無線ユニットやSSDなどの拡張カードを取り付けるソケットです。M.2では、拡張カードの形状と端子が規格化されています。昔はNGFF（Next Generation Form Factor）と呼ばれていたので、今でもそう併記されることもあります。えむどっとつーと呼ぶのが一般的で、Mは大文字のようです。これ以前に、mini PCI Express, Mini-SATA, mSATAという形のソケットがありましたが、これを小型化してPCIeのレーン数を増やした後継規格です。少し前のマザーボードにはmPCIe, mSATAのソケットがついていましたが、今はM.2です。例えば、古いIntel NUCではmPCIe, mSATAが付いていますが、現行モデルはM.2です。

M.2の形と端子

形

サイズが決められています。Wikipediaによると、幅は12、16、22、30mmの4種、長さは16、26、30、38、42、60、80、110mmの8種類だそうです。でも実際に売られている製品は、幅が22mmで、長さが30、42、60、80mmのものが一般的です。それぞれ、2230, 2242, 2260, 2280というような名前がついています。

端子

端子には、PCIe が最大4レーン、SATA、USB 2.0, USB 3.0, I2C, オーディオなどが出ています。このうち一般に使われているのはPCIe, SATA, USBです。さらに全てが使えるわけではなく、バリエーションがいくつか用意されています。その違いをわかりやすくして、間違って使用されないように、端子に切り欠きが入っています。ソケットの方にも切り欠きに合わせた仕切りが作ってあり、間違ったカードが挿さらないようになっています。

現在のマザーボードには、主に以下の二種類のソケットがついています。

E key: 24-31番ピンの場所が切り欠きになっています。PCIeが2レーン、USB 2.0などが使えます。
M key: 59-66番ピンの場所が切り欠きになっています。PCIeが4レーンとSATAが使えます。SATAが使えないものもあります。

一方で、よく見かけるM.2用カードは、以下の四種類です。

E key: 24-31番ピンの場所が切り欠きになっています。
A-E key: 8-15番ピンと24-31番ピンの場所が切り欠きになっています。
M key: 59-66番ピンの場所が切り欠きになっています。
B-M key: 12-19番ピンと59-66番ピンの場所が切り欠きになっています。

ソケットの方は仕切り板で、カードの方は切り欠きなので、ソケットの仕切り板の位置さえあっていれば、物理的には挿すことができます。なので、

A-E keyとE keyのカードはE key用ソケットに挿さります。
B-M keyとM keyのカードはM key用ソケットに挿さります。

左がE keyソケットとA-E keyカードの例、右がM keyソケットとB-M keyの例です。どちらも挿さります。ただし挿さっても動作するとは限りません。

M.2カードの使い道

何にでも使える規格ですが、現在一般的に使われているのが、WiFi/Bluetoothの無線カードと、SSDカードです。無線カードは、E keyソケットに、SSDはM keyソケットに挿して使います。

無線カード

一般的なM.2用無線カードは、A-E keyもしくはE keyです。どちらもE keyのソケットに刺さります。E keyには2レーンのPCIeと、USB 2.0の端子があります。WiFiのチップはPCIeに接続して動作し、BluetoothのチップはUSB 2.0に接続します。無線カードはそれほど高速ではないので、PCIeは1レーンで十分です。M keyだとUSBが配線されていないので、Bluetoothが使えません。という理由でE keyなのです。

macOSで使えるM.2無線カードの種類は、それほど多くないです。こちら

Hackintoshのパーツ選び【その4：無線編】

でも紹介しましたが、macOSでOOBで動作するM.2 WiFi/Bluetoothカードは、BCM94360NGです。

Dell DW1830 (BCM943602BAED)はより高速で高価ですが、多少互換性が落ちます。こちらの情報のよると、

WifiはOOBで動く
WiFiのパフォーマンスはFakePCIID Kextで改善できる
Bluetoothを動かすためにはkextが必要

だそうです。

予算が限られているならDell DW1560 (BCM4352)も選択肢になります。DW1830よりは安いです。4個のkextが必要です。詳細はこちらをご覧ください。

純正無線カード変換器

HackintoshでWiFi/Bluetoothカードを使う場合、Macで使われている純正の無線カード、BCM94360CD BCM943602CS BCM94360CSなどを使うと互換性が高く、そのままで問題なく使用できます。純正無線カードは、特殊なピン構成ですが、PCIeとUSBに接続されています。そこで、E keyのPCIeとUSBに変換するアダプタが売られています。

最初からE key用に設計されたカードと違い、アダプタを使用すると長くなってしまいます。厚みも増えます。マザーボードによっては、他の部品と干渉して取り付けられない場合もあります。シールド用の金属カバーを外せばなんとかなる場合もあります。余裕があっても取り付けネジ位置が合わない場合もあります。ネジだけの問題なら、両面テープで貼り付ければなんとかなります。

A-E keyもしくはE keyのM.2用ソケットを延長するアダプターもあります。こういう製品を使えば、小型のインテル製無線カードが入っているソケットから、延長して外に引き出して、macOS純正のBroadcom製カードを取り付けることができると思います。

M.2用の無線カードは通常はE keyソケットに挿しますが、M keyで無線カードを使うことも可能ではあります。Macで使用されている純正無線カードを、E keyではなく、M keyに変換するアダプターを使えば可能です。ただし、M keyにはUSBは配線されていないので、ケーブルでマザーボード上のUSBコネクタに配線することになります。

SSD カード

M.2 SSDカードは、通常M keyソケットに取り付けます。E keyにもPCIeが2レーン来ているので、速度低下の懸念はあるものの接続可能と思うのですが、そのような製品は無いです。

M.2 SSDカードには、配線の種類でSATA接続のものとPCIe接続のものがあります。また、データ転送のプロトコル（手順）にAHCIとNVMeのものがあります。NVMeが新しいプロトコルでSSDに特化していて高速です。High Sierraからネイティブにサポートされています。macOSの起動も可能です。

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

SATAまたはPCIeと、AHCIまたはNVMeで4通りの組み合わせがありますが、現在販売されているのは、

SATAでAHCIのもの
PCIeでNVMeのもの

がほとんどです。SATAでNVMeという製品はありません。PCIeでAHCIという製品はNVMeが一般的になる前は一時ありました。中古で出回っているかもしれませんが互換性が心配ですので避けた方が良いと思います。

SATA SSD

SATAで接続する場合はPCIeは不要ですのでPCIeが2レーンになるB keyが最適です。でもM keyのソケットにも挿さるように、M keyも切り欠いてあるB-M keyの製品がほとんどです。なので2箇所切り欠きがあるのはSATAだと考えて良いです。こんな感じです。

NVMeの方がベンチマークでははるかに高速ですが、使ってみて差を感じる場面はありません。その上、現状ではSATAの方が半額くらいですので、SATA SSDを使っても良いと思います。

B-M key SATA SSDはM keyも切り欠いてあるので、M keyソケットに挿すことができます。しかし必ず使えるわけではありません。SATA接続も可能なM keyソケットである必要があります。例えばASUSのZ390チップマザーボードであるROG MAXIMUS XIにはM keyソケットが2本ありますが、マニュアルの記述によるとSATAをサポートしているのはそのうちの1本だけです。SATA SSDをM keyソケットに挿す場合は、SATAがサポートされているかどうか確認する必要があります。

PCIe NVMe SSD

一方でPCIe接続のNVMe SSDは高速データ転送を実現するためにPCIeを4レーン使います。そこでPCIeが4レーンあるM keyの構成で使います。なので切り欠きが一つしかないSSDはPCIe接続のNVMe SSDだと考えて良いです。こんな感じです。現状ではSATAタイプの倍くらいの価格ですが、本来のM.2の速度を得たいのでしたらこちらが良いかと思います。

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を新規インストールする場合に、既存のボリュームを消去せず、それを残したまま新規にボリュームを追加しても良いかと思います。

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をマウントしてついでにバックアップする

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ディレクトリに移動しています。引き続き作業するのに便利かと思いました。

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が有効になりました。

起動失敗に備えてバックアップ

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を自動バックアップする

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未対応のようです。

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拡張カードを使っているので、拡張カード用のパッチを当てることにしました。

Time Machineは良いです

Thu, 14 Sep 2017 23:46:39 +0900

macOSの良いところはたくさんあります。インクリメンタルバックアップのTime Machineが、OS標準でサポートされていることも、他のOSにない、大きなメリットです。Time Machineのおかげで何度も助けられました。

スタイリッシュなMacintoshと違って、いくらでもHDDを内蔵できる無骨な自作Hackintoshなのですから、是非ともTime Machine専用のドライブを搭載して、Time Machineを動かすべきです。内蔵ドライブにバックアップすれば、ネット越しよりも高速にバックアップできます。なので、OSがバックアップ作業をしていることに気づくことは滅多にありません。快適です。

今だと、3TBの3.5インチHDDが一番お得な製品です。これを1台内蔵して、全部をバックアップ領域にしてはどうでしょうか。バックアップメディアが大きいほど、過去のデータに戻れます。目安としてはオリジナルデータの2-4倍あると良いらしいです。

Time Machine用ドライブの活用

単純に全部をバックアップ領域にしても良いです。

3TBの3.5インチHDDの全体をTime Machine領域にする

でも、3TB HDDのESP領域は何にも使われていません。それなら、このHDDのESPにCloverとkextなど、メインボリュームのESPと同じものを入れるのも良いと思います。Hackintoshしていると、「メインボリュームのESPに手を入れていたら、起動しなくなってしまった」というピンチを一度は経験します。間違った設定を元に戻したくても、起動しないので作業ができないという状況です。ESPのバックアップがあれば、そんな時にもあわてなくてすみます。マザーボードのUEFI設定で起動ドライブをTime Machineのドライブにすれば良いのです。

3TBの3.5インチHDDのESPにメインのESPをバックアップする
残りの領域をTime Machine領域にする

ESPは、内蔵HDDだけでなく、当然ながら外付けのHDDやUSBメモリにもバックアップしておけます。でも内蔵ドライブにバックアップしておくと、紛失する心配がありません。間違いなく必ず筐体の中にあって、どこかに行ってしまうことはありませんから。

また、3TB HDDに60GBくらいのパーティションを作って、ここにmacOSもバックアップして置くと、さらに安心です。

3TBの3.5インチHDDのESPにメインのESPをバックアップする
頭に60GBくらいのパーティションを作ってここにmacOSをバックアップする
残りの領域をTime Machine領域にする

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

Mon, 11 Sep 2017 22:12:40 +0900

5回目はストレージについてです。結論を箇条書きすると：

SATAケーブルで接続する2.5インチSSD/HDD、3.5インチHDD、5.25インチCD-ROM/DVD/Blu-rayドライブは、どのバージョンのmacOSでも動きます。
High Sierra以降ならばM.2 NVMe SSDが使用可能です。ただ相性があるようなのでパーツ選びに注意してください。
AHCIプロトコルのM.2もしくはmSATAのSSDはそれより古いmacOSでも動きます。

SATAケーブルで接続するストレージ、ドライブは、どれも問題もないです。好きなものを選んでください。ちょっとだけややこしいのは、マザーボードなどのソケット（mSATAとM.2）に挿すカード型SSDの類です。

用語の整理

マザーボードなどに挿すカード型のSSDは色々な種類があります。まずはソケットの形で分類できます。最近のマザーボードについているSSD用ソケットの形状は、次の2種類です。

一つは、mini SATA (略してmSATA )と呼ばれる形のソケットです。mini PCI Expressというソケットもありますが、形は同じです（これもまたややこしい）。
もう一つ、最近流行りなのがM.2と呼ばれる形のソケットです。さらに小さくて、細長い形状のカードが多いです。

ちなみに実際のMacに内蔵されているカード型SSDは、このどちらでもない、Apple独自規格のソケットです。

マザーボードソケットに接続される信号線で分類すると、次の2種類があります。

一つはSATAです。2.5/3.5インチのドライブに接続しているものと同じ信号です。
もう一つはPCIeです。マザーボードのPCIeスロットに出ているのと同じ種類の信号です。

さらに、この信号に流れるプロトコルで分類すると、次の2種類があります。

一つはAHCIです。2.5/3.5インチのSATAコネクタのドライブで使われているプロトコルです。
もう一つはNVMeです。SSDに適した命令体系になっていて高速です。

この2x2x2=8通りの組み合わせは、さすがにありませんが、色々な組み合わせがあるので注意が必要です。例えば、

mini SATAでSATA接続でAHCIプロトコルとか、
M.2でSATA接続でAHCIプロトコルとか、
M.2でPCIe接続でAHCIプロトコルとか、
M.2でPCIe接続でNVMeプロトコルとか、

いろいろあります。

このうち、macOSのどのバージョンでもサポートしているのが、AHCIプロトコルのSSDです。ソケット形状やSATA/PCIeの違いは問題になりません。OSから見たらそのレベルのハードウェアは抽象化されているので、大丈夫なのです。

High Sierraで完全サポートされたNVMe

問題は、NVMeです。NVMeはEl Capitanのあたりで一般的に流通し始めました。MacBookシリーズには、他のプラットフォームに先駆けて、NVMe登場の早い段階で採用されました。ただし、これはMacintoshの歴史でよくあることですが、一般に売られているNVMe SSDとは互換性のないSSDが使われていました。ソケット形状も独自ですし、データのブロックサイズも違うようです。そのため、一般に販売されているm.2 NVMe SSDは簡単には使えませんでした。

El Capitanの時には、NVMeGeneric.kextというカーネル拡張がwww.macvidcards.comから配布されて、これで市販のM.2 NVMe SSDが使えました。しかし、Sierraで動かなくなりました。今は配布もされていないようです。

Sierraでは、市販のM.2 NVMe SSDを動かす長い長いパッチが公開されて、config.plistに組み込んで使うことは可能でした。手間が面倒でした。

その苦労は、High Sierraで終わりました。High Sierraでは市販のNVMe SSDがサポートされるようになります。今時は、M.2 SSDはどれも高速なNVMeになり、低速のAHCIのモデルは品薄で割高です。とても助かります。

NVMeのM.2 SSDの製品は増えています。どれもHigh Sierra以降で問題なく使えるはずと思うのですが、ネット上の情報によるとmacOSと相性の悪いものがあるようです。注意が必要です。フォーラムでも貴重な情報をいただいています。それによると：

Samsung 970 EVO Plus と Samsung PM981 は互換性に問題がある
次のSSDは問題なし：
Samsung 970 EVO Pro
Samsung 970 EVO
Samsung PM961
Samsung PM951
WD SN750

私もSamsungの古いSSDとWDのSN750を使っていますが、どちらも問題なく動いています。SamsungのSSDは使用されるコントローラチップの一部がmacOSと相性が悪いようです。M.2 SSDは発展途上の製品なので今後は問題なくなると思いますが、現状ではWDの方が安心できるかもしれません。

追記：Samsung SSDのファームウェア更新

Samsungの一部のM.2 SSDがmacOSと相性が悪い問題ですが、フォーラムにいただいた情報によるとファームウェア更新で解決するようです。macOSで不安定だった970 evo plus がまともに動くようになったそうです。やはり何か問題があったんですね。こちらがtonymacx86の情報のページだそうです。

光学ドライブを使う

Mon, 11 Sep 2017 13:57:04 +0900

現行のMacintoshからはすっかり駆逐されてしまった光学ドライブですが、Hackintoshなら5.25インチベイ搭載ケースを使っていくらでも復活できます。CD-ROMでもDVDでもokです。実機にはついぞ搭載されなかったBlu-rayドライブも搭載可能です。1台だけでなく2台3台と搭載することだって可能です。読み出すだけじゃなくて書き込むこともできます。搭載するに当たって、特に難しいことはありません。SATAケーブルと電源を配線するだけです。

「可能な場合でもハードディスクをスリープさせない」

簡単、かんたん、a piece of cakeだと思っていたら、「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Pioneerのドライブで発生するような気がします。

一部の光学ドライブは、スリープコマンドを送りつけて動作を止めると、次にアクセスした時に復帰できないようです。にもかかわらず、macOSの省エネルギー設定では、「可能な場合はハードディスクをスリープさせる」ことがデフォルト設定になってます。これがトラブルの原因です。なので、この問題は、「システム環境設定」の「可能な場合はハードディスクをスリープさせる」のチェックを外すことで解決します。

カーネル拡張(kext)にパッチを当てる

上記の方法だと、当然ですがハードディスクはスリープしなくなります。また、私は経験したことがありませんが、この方法でも解決しないという報告もあるようです。そこで正攻法で根本的解決方法、つまりシステムにパッチを当てる方法を紹介します。

アップル社は対策済み

アップル社もこの問題はよ〜く分かっていて、旧型Mac Proに搭載されているPioneerの光学ドライブに対して対策をしています。PioneerSuperDrive.kextの中で、Pioneerの光学ドライブの型番を指定して、このドライブだけはスリープさせないようにという設定がされているようです。その型番とは、

DVD-RW DVR-105

です。この対策を担当しているkextは、PioneerSuperDrive.kextです。試しに、

/System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/MacOS/PioneerSuperDrive

をhexdump -Cしてみると、

00000fb0  70 6c 65 5f 64 72 69 76  65 72 5f 50 69 6f 6e 65  |ple_driver_Pione|

00000fc0  65 72 53 75 70 65 72 44  72 69 76 65 00 44 56 44  |erSuperDrive.DVD|

00000fd0  2d 52 57 20 20 44 56 52  2d 31 30 34 00 31 2e 31  |-RW  DVR-104.1.1|

00000fe0  30 00 44 56 44 2d 52 57  20 20 44 56 52 2d 31 30  |0.DVD-RW  DVR-10|

00000ff0  35 00 4e 6f 20 53 6c 65  65 70 00 54 72 75 65 00  |5.No Sleep.True.|

と書いてあります。DVD-RW DVR-105をNo Sleepにするって書いてあるように見えます。DVR-104も対策済みみたいにも見えます。運良く、これらの型番のドライブをHackintoshに搭載した人は、きっとこの問題に遭遇しないのでしょう。そうでない人は、ファイルに書かれた型番を、実際に使っているドライブの型番に書き換えればよいわけです。

光学ドライブの型番を知る

光学ドライブの型番は、「リンゴマーク」「このMacについて」「システムレポート（システム情報）」「ハードウェア」「SATA/SATA Express」とだどっていけば、見つかります。手元の例ではPIONEERという表記を除いて、

BD-RW   BDR-205

でした。スペースの数（3個あります）も重要で、全部で15文字のはずです。

Cloverのconfig.plistでパッチを当てる

古代の手法では、 PioneerSuperDrive.kextの該当ファイルをバイナリーエディタで開いて、データを書き換えていました。これは色々問題があります。特に、OSのバージョンアップのたびに同じことをやらなければならないのが面倒です。現代風の方法では、Cloverの動的パッチ機能を使います。起動するタイミングでパッチを当ててくれる機能です。

設定ファイルconfig.plistにパッチ情報を書き込むのですが、この時、バイナリーデータを文字に対応させて変換するBase64という方式を使います。Base64への変換は、ターミナルのbase64コマンドで可能です。例えば、DVD-RW DVR-105（スペースは2個）とBD-RW BDR-205（スペースは3個）の文字列をBase64に変換するには、ターミナルで以下のようにタイプすれば良いです。

$ echo -n "DVD-RW DVR-105" | base64
RFZELVJXICBEVlItMTA1
$ echo -n "BD-RW BDR-205" | base64
QkQtUlcgICBCRFItMjA1

変換前後の文字列のBase64表記がわかりましたので、いよいよconfig.plistを開いて、KextsToPatchセクションに以下を追加します。

 <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>

なんとなくわかると思いますが、PioneerSuperDrive.kextの、RFZELVJXICBEVlItMTA1というデータを検索して、QkQtUlcgICBCRFItMjA1に置き換えてくださいという指示です。これでめでたくスリープ問題が根本的に解決されるはずです。

OpenCoreのconfig.plistでパッチを当てる

OpenCoreでも同様に、config.pistの指定で動的にパッチ当てが可能です。以下にその方法を紹介しておきました。

Pioneer光学ドライブのパッチをOpenCoreに適用する

キーボードから開閉したい

ご存知のようにアップルの純正キーボードには光学ドライブをイジェクトするキーがついています。今風のMacintoshでは使いようのない無駄なキーですが、光学ドライブを搭載したHackintoshなら有効に使ってあげられます。と、思ったら、これが効かないこともありました。

解決策がこちら、

www.tonymacx86.com

で紹介されています。AHCI_3rdParty_SATA.kextに手を加えて使用する方法です。日本語で紹介された解説が、こちらにあります。

www.reddit.com

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

Sun, 10 Sep 2017 23:43:45 +0900

EFIシステムパーティション(頭文字を並べてESP)には、Cloverブートローダとかconfig.plistとかkextファイルなどが置かれてます。ESPは通常はマウントされていませんので、これをメンテするときに、マウントする必要があります。例えば、ESPが/dev/disk0s1にある場合は、ターミナルから

diskutil mount /dev/disk0s1

とすればマウントできます。すると/Volumes/EFI以下にマウントされます。必要ならばここにcdしたり、これをファインダーに表示させます。

でもこの一連の作業が面倒なので、こんなシェルスクリプトを作って使っています。マウントしたESPは、マウントした順番に/Volumes/EFI, /Volumes/EFI 1, /Volumes/EFI 2のマウントポイントに割り当てられます。このスクリプトでは、マウントした後にCLOVERのディレクトリにcdしています。この後、open .などすればファインダに表示することもできます。

#!/bin/sh
if [ $# -eq 0 ]; then
DRIVE="0"
else
DRIVE=$1
fi
diskutil mount /dev/disk${DRIVE}s1 
MP=`diskutil info disk${DRIVE}s1 | grep "Mount Point"`
MP3=`echo $MP |  awk '{print $3}'`
MP4=`echo $MP |  awk '{print $4}'`
if [  -n "$MP4"  ]; then
cd $MP3" "$MP4"/EFI/CLOVER"
else
cd $MP3"/EFI/CLOVER"
fi

これをファイルにして、名前をつけて、実行可能にします。例えば、mountESPという名前のファイルにした場合、

/dev/disk2s1 をマウントしたいならば、ターミナルから以下のようにタイプします。

. mountESP 2

引数を省略すると/dev/disk0s1がマウントされます。ドライブが1個しかないマシンでは、必ず/dev/disk0に割り当てられるので、番号を省略できると便利と考えました。

. mountESP

ちなみに冒頭のピリオド空白(. )は重要です。通常よくやるように./mountESPとすると、最後のcdコマンドが効きません。実際には効いているのですが、シェルスクリプト実行環境の中で効いているので、ターミナルのプロンプトに戻ると元のディレクトリに帰って来てしまいます。ピリオド空白(. )は、ターミナルの実行環境のままで、キー入力そのもののようにスクリプトを実行するという意味だそうです。

追記：10.13.6からESPをマウントするのに管理者パスワードが必要になりました。なので、上記のスクリプトも、diskutil mountの行を、以下に変更する必要があります。(2018/7/10)

sudo diskutil mount /dev/disk${DRIVE}s1