Mac信者のHackintosh修行

惑星で一番美しいOSが1台でも多くのマシンで動くことを目指します。

バージョンを誤魔化してNVIDIAドライバを入れる

f:id:siroanko:20181106231456p:plain

 これはMojaveでNvidiaのドライバを動かす方法ではありません。Mojave対応ドライバが待ち望まれている時節柄紛らわしい記事ですみません。この方法でWebドライバがMojaveで動かなくはないらしいですが、性能が全く出ないらしいです。

経緯

MojaveではNvidiaドライバが動かないので、Nvidiaを搭載したマシンはHigh Sierraで使っていました。先日、それにうっかりPublic Beta版のセキュリティアップデートを当ててしまいました。これです。

f:id:siroanko:20181105140704p:plain

通常盤のアップデートだと勘違いしました。ベータ版配布をoffにしておくべきでした。

siroanko.hatenablog.com

アップデートしたことでmacOSのビルトが上がりました。17G4005です。

f:id:siroanko:20181105141020p:plain

配布されているWebドライバの最新版は17G3025用なのでバージョンチェックで動かなくなってしまいました。そこで、17G3025用のドライバを、無理やり17G4005にインストールして動かすことにしました。

バージョン違いのドライバをインストールする

17G3025用のドライバを入手しても、バージョンが違うと、そもそもインストールできません。

f:id:siroanko:20181105141524p:plain

そこで17G3025用ドライバのパッケージを開いて、設定を変更します。まずは、パッケージユーティリティを使って展開します。

pkgutil --expand (pkgへのパス) (展開先ディレクトリ)

例えば

pkgutil --expand WebDriver-387.10.10.10.40.108.pkg exp

とします。こうするとexpというディレクトリに内容が展開されます。この中に、Distributionという名前のテキストファイルがあります。これを開いて、インストールチェックをしているところ

function InstallationCheck()
{
if (!validateSoftware()) return false;

return true;
}

 をコメントアウトします。

function InstallationCheck()
{
//if (!validateSoftware()) return false;

return true;
}

 もしくは、後ろの方にvalidateSoftware()関数の定義がありますので、そこのビルト番号を書き換えても良いです。つまり、

function validateSoftware()
{
var supportedOSVer = "10.13.6";
var supportedOSBuildVer = "17G3025";

というところを、

function validateSoftware()
{
var supportedOSVer = "10.13.6";
var supportedOSBuildVer = "17G4005";

とします。

次に、以下のコマンドでパッケージし直します。

pkgutil --flatten exp webdriver.pkg

これは上の例でexpという名前のフォルダを作った場合です。このパッケージを使ってWebドライバをインストールします。

バージョン違いのドライバを動かす

インストールはできましたが、バージョンが合わないのでドライバが動きません。Not compatibleというメッセージが出てしまいます。そこでパッチを当てます。

f:id:siroanko:20181105144749p:plain

ドライバにパッチを当てるためのスクリプトが、benjamin.dobellさんによって配布されていまう。以下のコマンドで入手できます。

curl -O https://raw.githubusercontent.com/Benjamin-Dobell/nvidia-update/master/nvidia-update.sh

こうしてできたnvidia-update.shを実行可能にして起動します。

chmod a+x nvidia-update.sh

./nvidia-update.sh

 最初の質問(ダウンロードするか?)にはN、次の質問(パッチを当てるか?)にはYとタイプします。そして再起動します。無事動くようになりました。

f:id:siroanko:20181105145135p:plain

ここまで、SIPは有効のままでも問題なく作業を進められました。

2018 Mac miniはすごい

Mac miniが4年ぶりにニューアルされて話題になっています。 Apple社はディスプレイなしのデスクトップMacなどにもはや興味がないのではと思っていました。 特にローコストのminiは見捨てられているのだと感じていました。 なので、今回の新製品は意外でした。素晴らしいです。

CPUはモバイル用のBモデル

一番素晴らしいことはCPUがデスクトップに匹敵するCPUになったと言われていることです。 従来のminiはひ弱なモバイル用CPUを搭載していたのが残念に感じていました。 重量やサイズの制約がないデスクトップなら、性能を追求して欲しいと思っていました。

CPUはインテルの第8世代CPUと言われています。 型番が8000番台のCPUです。 製品が出回ればすぐに明らかになると思いますが、 実際にどの型番なのかは今現在では明らかになっていません。 でもおそらく8100, 8500, 8700ではないかと思われます。 というのは3モデルの仕様が、インテルの仕様に合致しているからです。 公式サイトで紹介されている仕様は以下です。

mini i3 4コア mini i5 6コア mini i7 6コア
動作周波数 3.6GHz 2.8GHz 3.2GHz
Turbo Boost 記載無し 4.1GHz 4.6GHz
L3キャッシュ 6MB 9MB 12MB

これに対して、8100, 8500, 8700の仕様は以下です。

Core i3 8100 Core i5-8500 Core i7-8700
Core/TH 4/4 6/6 6/12
動作周波数 3.6GHz 2.8GHz 3.2GHz
Turbo Boost 非対応 4.1GHz 4.6GHz
L3キャッシュ 6MB 9MB 12MB
TDP 65W 65W 65W

完全に一致しているので、ほぼ間違いないと思います。 いずれもTDPが65Wなので、miniの筐体に入ると思われます。

ただし、通常の自作PC用に販売されているデスクトップ用の8100, 8500, 8700ではないと思われます。 実は、本年4月に、Intelがデスクトップ版Core i7-8700と同仕様の8700Bを投入したというニュースがありました。

pc.watch.impress.co.jp

Bモデルは、デスクトップ用無印CPUと同じスペックのようです。 ただ、パッケージがデスクトップ向けのLGA1151ではなく、モバイル向けのHプロセッサと同じFCBGA1440となっています。 8700Bについてはこちらのサイトで詳細が紹介されています。

Core i7-8700B - Intel - WikiChip

CPUの形状はこんな感じです。

f:id:siroanko:20181103232143p:plain

この記事の冒頭にある、アップル公式サイトの写真とそっくりです。なので2018 miniのCPUは8100B, 8500B, 8700Bだと思われます。

f:id:siroanko:20181103232640p:plain

自作PCで使う現行インテルCPUはマザボとの接続がLGAです。ランドグリッドアレイという名前で、CPUの底にランドと呼ばれる楕円の電極パターンが印刷されています。マザボのソケットのピンがランドに接して接続されます。ソケットを使用することを前提とした構造です。これに対してminiで使われるBモデルはBGAだそうです。Bはボールで、接点部分にハンダボールが付いています。マザボ上の接点パターンに乗せて炉で加熱してハンダ付けします。なのでiMacのように簡単にCPU交換する事は出来ないでしょう。

今のタイミングなら、9000番台の第9世代CPUで作って欲しかった気もします。 とはいえ、第8世代デスクトップ用CPUがmacOSで正式サポートされたことで、 同じCPUを使っているHackintoshの安定性がさらに向上するものと思います。

チップセットは何?

もう一点注目していることは、チップセットです。 これもiFixItなどで分解されればすぐにわかる事ですが、 Mac miniチップセットがH370ではないかと期待しています。 H370はZ390と同じ世代のチップセットなので第9世代CPUを使ったHackintoshの安定性も上がります。 またMac miniがH370なら、インテルのUSB 3.1 Gen2, WiFi, Bluetooth機能が搭載されています。 それをmacOSがサポートしているならHacintoshで今まで以上にUSB 3.1が安定し、さらにはインテルの無線が使えるようになるのではと期待しています。 公式のサイトにも特徴に

と書かれているので少し期待しています。

省電力・iGPU Hackintoshは無用

今回のminiはデスクトップ用Core i3 CPUを初めて搭載しています。 省電力を目指してi3 NUCでHackintoshする必要がなくなりました。 また、CPU内蔵のiGPUだけを使って省スペースなmacOSマシンを入手するためにHackintoshする必要もなくなりました。 グラフィクスカードを搭載しないMini ITXやMINI STX型小型Hackintoshはもやは不要です。 本物のMac miniを買えば、デスクトップCPU搭載macOSマシンが手頃な価格で入手できるからです。 もともとApple社が欲しいMacを作ってくれないので自作Hackintoshを始めたので、 今回のMac miniが出て、Hackintoshが不要になることは嬉しい限りです。

一方で、グラフィックスカードを搭載した重量級デスクトップHackintoshはまだまだ必要です。 強力なグラフィックス性能が必要ならば、 Thunderbolt経由の外部GPUボックスを使って欲しいというのがAppleの方針かと思います。 でもThunderboltはPCIe x 4なので、フルサイズPCIe x 16に比べると接続ケーブルがボトルネックになります。 ジサトラKTUのベンチマークテストでもかなりの差が出ています。

youtu.be

小型軽量が重要なモバイル機器ならThunderboltで拡張する意義はありますが、 デスクトップではせっかくのGPUがもったいないと感じます。 来年発表されると噂の「モジュラー型」Mac Proで、タワー型デスクトップHackintoshも無用の存在にして欲しいと願っています。

MojaveでJPEGファイルが開けない

f:id:siroanko:20171118234329p:plain

MojaveではAMD Radeon RX570 RX580などがOOBでほぼ問題なく動きます。でも多少の不具合はあります。それをメモしておきたいと思います。以下では、CPU内蔵GPUをiGPU, 内蔵ではないGPUをdGPU, Thunderbolt拡張ボックスで増設するGPUをeGPUと書くことにします。

GeekBenchの性能低下は解決

BIOSでiGPUを機能させないように設定すると、しばらく使っているうちにGeekBenchのOpenCLスコアが下がってしまう問題がHigh Sierraではありました。この問題はMojaveになってから解決したようです。iGPUはoffのままでも、性能低下は発生しないようです。

SafariAmazonの動画が見られない

BIOSでiGPUが機能するように設定すると、なぜかSafariAmazon動画が見られません。謎です。Google Chromeなどでは見られます。表示が出ない・乱れるという訳ではなく、「再生エラー」というダイアログがAmazonから出されるので、デジタル著作権保護に関する問題かもしれません。もしかしたら、実機のeGPUでも同様の症状が発生するのかもしれません。またAmazon以外でも動画再生に問題が発生するのかもしれません。でもSafari以外のブラウザを使えばokなので大した問題ではないです。BIOSでiGPUを機能させない設定にすれば、SafariでもAmazon動画が再生されます。

JPEGファイルがクイックルックできない

BIOSでiGPUを機能させないように設定すると、JPEGファイルのクイックルックができません。プレビュー.appでもJPEGファイルを開くことができません。レインボーカーソルが出て止まってしまいます。JPEGの展開にiGPUの機能を使っているためこうなるようです。これはかなり不便です。この問題はNVIDIAのグラフィックスカードでも発生するようです。この方法の解決策として以下の3通りが知られています。

  • BIOSでiGPUが機能するように設定します。ただし、上の、SafariAmazon動画が再生されない問題が発生します。
  • 同系統のdGPUを搭載しているMacの機種IDになるように、config.plistのSMBIOS設定を変更します。ただしCPUやチップセットが違う機種に設定することになりうるので、動作が不完全になる可能性があります。あまりお勧めできません。
  • NoVPAJpeg.kextをLilu.kextと一緒に使います。これを使えば、iGPUがoffでもJPEGファイルクイックルックの問題が発生しません。

    www.insanelymac.com

ということで、3番目の方法であるNoVPAJpeg.kextを使えばすべて解決するようです。でも、実のところ私はiGPUを機能させる設定でしばらく使うことにしました。せっかく搭載されているのにiGPUを使わないのはもったいない気がするからです。SafariAmazon動画を見なければ良いだけですので。

今回紹介した問題は、iGPU, dGPUの切り替えがうまくいっていないことで発生しているように思います。実機でも、GPU切り替えが原因のトラブルが時々話題になっています。Hackintoshの問題ではなくて、どちらかというとmacOSの問題のような気がします。eGPUを公式サポートするようになったのは最近のことなので、今はあまり気にしなくても将来のmacOSで改善されると期待しています。

APFSのVolumeを活用する

f:id:siroanko:20181008122822p:plain
 HFS+から大幅刷新されたAPFS (Apple File System)には色々便利な機能があります。今回は、Hackintoshライフに役立つAPFS Volume機能をご紹介します。

HFS+のVolume

HFS+でもAPFSでも、アプリケーションから見えるのは最終的にVolumeです。Volumeは物理的にはストレージの一部なのですが、アプリケーションからは

/Volumes/

以下にマウントされ、ディレクトリのように見えます。

物理的なストレージからVolumeに至る階層構造を以下にまとめます。HFS+では、

  1. 物理的なドライブ。物理的なSSDやHDDです。本当はファイルではないのですが、システムからは/dev/disk0のように見えます。ファイルのようにも見えますが、実際にはファイルではありません。ストレージの内容を読み書きするデバイスドライバへアクセスする場所として使われます。システムファイルとも呼ばれます。
  2. 物理的なパーティションSSDやHDDを分割した領域です。これも/dev/disk0s1のようなスペシャルファイルとして現れます。
  3. 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がコンテナの機能で実現されることは、以前の記事で紹介しました。

siroanko.hatenablog.com

以下では、コンテナの中に複数のVolumeが作れる機能を利用して、Hackintoshの保守を簡単にする方法をご紹介します。

HFS+で複数Volumeを使う

HFS+以前は1パーティションが1 Volumeでした。

Hacintoshに限らないのですが、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以下を移動させてみます。Disk Utility.appを開いて、現在のコンテナを選択して、「パーティション作成...」ボタンを押します。すると以下の案内が出ます。

f:id:siroanko:20181008130205p:plain

1つのコンテナは1つのパーティションを占有し、コンテナ内のストレージ領域はコンテナ内の複数のAPFSボリュームで共有されます。APFSボリュームの追加や削除は、パーティションマップを編集するよりも簡単かつ高速に実行できます。 

 ここに書いてあるように、新しいVolumeを作るためには、“編集”メニューの“APFSボリュームを追加”コマンドを使用するか、ツールバーの“ボリュームを追加/削除”ボタンを使用しても良いです。本当はそちらの方法が正当で、このメッセージは従来のパーティション作成を試みようとしたユーザにAPFSへの移行を促す目的の案内なのだと思います。

ここで「ボリュームを追加」を選ぶと、このコンテナにVolumeを追加できます。homeという名前のVolumeを追加します。結果を以下に示します。「このMacについて」から見たいストレージの状況です。ここでお詫びです。ここまで1TBのSSDなどと豪勢なことを言っておりましたが、余分な1TB SSDを持っていなかったので打ち捨てられていた160GB HDDを使いました。

f:id:siroanko:20181008133651p:plain

/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以下のサイズです)などとなっています。

 

OS切り替えにも複数Volumeが便利

APFS Volumeは、簡単に追加したり削除したりできます。ストレージの容量は実際に使用している分だけしか消費しません。Mojaveならたったの13GBです。なので、複数Volumeを用意して、複数のmacOSをインストールしておけば、以下のようなことが可能です。

  • 別バージョンのmacOSに切り替える。例えば別のVolumeにMojaveとHigh Sierra(APFSでブートできるのはMojave以外にこれしかありませんが)をインストールしておく。
  • テストバージョンのmacOSを別Volumeにインストールする。古いmacOSは残っていますから、不具合があったらすぐに戻れます。新OSのベータ版を試すような場合にも便利です。
  • メインで使うVolumeの他に、別 VolumeにもmacOSをインストールしておく。うっかり怪しいアプリやkextをインストールして起動できなくなった場合でも、バックアップから起動して、修正作業ができます。

などの使い方が考えられます。

バニラなインストールをしておけば、macOSは通常のインストールで機能するので、管理が簡単です。

siroanko.hatenablog.com

不具合があっても別のVolumeのmacOSから起動できます。ただし、ESPの部分は同じものを使いますので、こちらもバックアップをしておくと安心です。

siroanko.hatenablog.com

Mojaveインストーラがリソースを見つけられない問題

 f:id:siroanko:20180929094941p:plain

Mojaveへの移行は基本的に簡単で、Cloverやkext類が最新なら何の問題もありません。ただ、一部の環境で、macOSインストーラが止まってしまうトラブルがあるようです。手元のマシンでも2台が止まってしまいました。どういうわけか不明です。インストーラの不具合ではないかという説もあります。ただ、世の中ではあまり話題になっていなくて、Hackintoshで主に発生しているようです。

症状

macOS Mojaveインストール.appを起動して、インストールの準備は順調に進みます。その次、1回目の再起動が発生します。ここで、Boot macOS Install from xxxxというエントリーから再起動すればインストーラが立ち上がって問題なく次に進むはずです。

f:id:siroanko:20180929104305p:plain

しかしこの時に、「インストーラリソースが見つかりません。」と言われてインストーラが止まってしまうことがあります。再起動しても、またここで止まります。

f:id:siroanko:20181010121249p:plain

画面に表示されるメッセージは、日本語では、

コンピュータにmacOSをインストールできませんでした

インストーラリソースが見つかりません。

インストーラを終了してコンピュータを再起動してからやり直してください。

です。英語の環境でインストーラが立ち上がった場合には、

macOS could not be installed on your computer

The installer resources were not found.

Quit the installer to restart your computer and try again.

と表示されます。 句読点は表示のままです。

発生する時は、上書きインストールでも、クリーンインストールでも発生します。ファイルシステムがAPFSでもHFS+でも発生します。

解決策

このメッセージで検索しても事例はあまり見つかりません。それでもtonymacx86にはいくつかの報告と解決事例がありました。それによると、

  • USBに接続したSSDにインストールしようとしたらこうなったので、内部ドライブにインストールしたら成功した 
  • M.2に挿していたNVMeを外したらインストールできた

などとありました。どうも、ストレージを複数接続している場合に発生しやすいようです。とは言え、手元のHDDを多数搭載したマシンでは問題ありませんので、数の問題ではないようです。

いろいろ探していたら、まとめてあるページを発見しました。

bartechtv.com

書いてある内容をまとめると、以下になります。

  • SATAドライブだけの構成の場合は、インストール先以外の全てのドライブを取り外してインストールする
  • M.2 NVMe SSDにインストールしているときは、M.2を外して、SATAドライブにインストールしてからコピーする

どうもスッキリ解決というわけにはいかないようです。

 やってみた

手元で問題を起こしている1台のマシンはM.2 NVMe SSDを搭載しています。M.2 SSDにも、SATAのドライブにもどちらにインストールしようとしても、このエラーメッセージで止まってしまいます。上記のサイトのガイドでは実質的にお手上げのケースです。

M.2 SSDを取り外すのが厄介でしたので、別のマシンで予備のSSDにインストールしました。32GBの2.5インチSSDを外付けUSBケースに入れて、MacBook Proに接続しました。インストール直後のMojaveの容量は14GB以下なので、16GBくらいのUSBメモリでも可能かもしれません。Mojaveインストーラを起動して、USB経由でインストールしました。

2度再起動して、国名を選択する設定画面で、ちょっと乱暴でしたが、電源を切ってSSDをとりはずしました。これを、問題起こしているマシンのUSBに接続します。

M.2 SSDはAPSFでしたのでボリューム作るのが簡単です。クリーンインストール用にボリューム作ります。先ほどのUSB SSDの内容を、新しく作ったボリュームにコピーすれば良いのです。

上記のサイトでは、ここで使うツールとしてCarbon Copy Cloner (CCC)を一例にあげています。CCCに問題がある訳ではありませんが、出来るだけ素朴なツールを使いたい主義なので、まずはDisk Utility.appの復元をためしました。内部では多分ddコマンドが動いていると推測してます。でもエラーで止まってしまいました。

そこでrsyncコマンドをつかってみました。上手くいきました。/Volumesに、コピー元がsource 、コピー先がtargetとマウントされている場合、以下のコマンドでコピー出来ます。

sudo rsync -av /Volumes/source/ /Volumes/target/

次に、M.2 SSDのこの新ボリュームから起動させたところ、インストールの続きか始まり、無事完了しました。

手元でインストーラが止まっているもう一台のマシンにはmSATAとSATASSD/HDDが接続されています。前述のサイトによると、こちらは使わないドライブを外すだけで良いようです。そのうち試して報告します。 

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

f:id:siroanko:20181007151835p:plain

コンピュータに問題が発生している可能性があることが検出されました

というダイアログパネルが先週唐突に現れました。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 

にあります。

MacEFIファームウェアチェックサムを、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を有効に戻しても大丈夫です。

siroanko.hatenablog.com

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という拡張子ではなくなったことで起動しなくなります。1週間後、2週間後にも起動しませんでした。

EFICheckDisabler.kextを使う

コメントで紹介していただいた

www.insanelymac.com

でRehabManさんが配布しているEFICheckDisabler.kextを使ってみました。これをESPに入れるだけでも、エラーメッセージは止まりました。