OS on Boot macOS

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

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

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

OpenCoreの設定

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

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

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

Sequoiaインストーラを入手

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

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

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

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

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

macOS Sequoia Installer

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

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

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

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

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

HDD構成

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

macOS Sequoia Installer

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

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

動作確認

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

About This Mac

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

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

OCLP 2.0.1

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

iPhone mirroring

まとめ

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

Sequoia

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

OpenCore Legacy PatcherがSequoiaに対応

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

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

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

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

OCLPがSequoiaに対応

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

OpenCore Legacy Patcher update

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

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

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

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

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

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

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

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

OCLPインストーラ

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

OCLP 2.0.0

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

Post-Install Root Patch

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

Wi-Fi

まとめ

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

Sequoia

Tue, 11 Jun 2024 23:50:44 +0900

macOS Sequoia（セコイア）15.0 をhackintoshで使う上で有用と思われる情報をメモしておきます。

機種設定

Sequoiaの対応Intel Macの機種IDは以下です。

iMac19,1 iMac19,2
iMac20,1 iMac20,2
iMacPro1,1
MacBookAir9,1
MacBookPro15,1 MacBookPro15,2 MacBookPro15,3 MacBookPro15,4 MacBookPro16,1 MacBookPro16,2 MacBookPro16,3 MacBookPro16,4
Macmini8,1
MacPro7,1

macOS SonomaでサポートされていたMacは、すべてSequoiaでもサポートされるようです。

ダウンロード方法

いろいろあります。

「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると入手できます。（下図。自動的にアップデート開始するので非推奨）
https://developer.apple.com/macos/ からもダウンロード可能です。（Apple Silicon版のみらしいので非推奨）
こちらのサイトで、ダウンロード用URLが紹介されています。このURLは、https://swcdn.apple.com/ というサーバーで、Apple公式ソフトウェアアップデートが使うサイトのようです。（簡単だけどダウンロード時間がかかる）
記事のコメントから、Mistというツールを教えていただきました。各種macOSをダウンロードして、インストーラを作るユーティリティです。次の項目の方法をGUI画面で自動化しているのだと思われます。
ターミナルからsoftwareupdateコマンドを使います。「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておき（下図）、

softwareupdate --list-full-installers

コマンドで目当てのベータ版がダウンロード可能なことを確認し、それが15.0ならば、

softwareupdate --fetch-full-installer --full-installer-version 15.0

コマンドでダウンロードできます。アプリケーションフォルダにインストーラが作られます。

Broadcom WiFi対策

Sonomaと同様、BroadcomのWi-Fi (BCM94360NG など) はサポートされません。そこでOCLPが必要です。OCLP 2.0.0からSequoiaに対応したので、これを使ってWi-Fiを有効化します。

OpenCore Legacy PatcherがSequoiaに対応

動作報告

以下はSequoiaの動作記録です。ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600、OpenCore 1.0.1、OCLP 2.0.1で動作してます。

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

EFIファイル類

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

リリースの経緯

2024/6/10: 開発者向けベータ版 Beta 1 の無償配布開始
その後のベータ版：
- 2024/6/24: Beta 2
- 2024/7/10: Beta 3
- 2024/7/15: Public Beta 1
- 2024/7/24: Beta 4 (Public Beta 2)
- 2024/8/6: Beta 5 (Public Beta 3)
- 2024/8/13: Beta 6 (Public Beta 4)
- 2024/8/21: Beta 7 (Public Beta 5)
- 2024/8/29: Beta 8 (Public Beta 6)
2024/9/17 (JST) ：正式版 macOS 15.0 Sequoia 配布開始

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

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

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

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

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

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

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

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

macOS Sequoia Full Installer Database. Download Directly from Apple!

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

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

インストールする

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

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

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

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

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

画面が出ない

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

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

動作確認

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

全コアが動作してます。

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

まとめ

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

OpenCore Legacy PatcherがSonomaに対応

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

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

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

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

OCLPがSonomaに対応

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

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

Releases · dortania/OpenCore-Legacy-Patcher

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

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

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

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

1.0.1に更新（追記）

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

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

まとめ

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

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

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

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

SonomaでWi-Fiが使えない

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

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

BCM94350 (BCM94352を含む)
BCM94360
BCM43602
BCM94331
BCM943224

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

OCLPで対応する

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

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

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

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

OCLPを使ってみる

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

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

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

要するに、

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

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

OpenCoreの調整

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

1. Kextの追加

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

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

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

2. config.plistの変更

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

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

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

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

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

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

OCLPを起動

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

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

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

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

Wi-Fi動作を確認する

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

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

まとめ

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

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

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

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

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

システム構成

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

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

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

アップデートできない

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

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

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

裏口からダウンロード

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

開発ベータ版

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

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

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

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

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

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

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

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

インストールする

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

ASRock Z690 Steel LegendでmacOSを動かす

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

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

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

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

画面が出ない

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

動作確認

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

全コアが動作してます。

WiFiが動かない

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

まとめ

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

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

Tue, 25 Oct 2022 18:28:02 +0900

macOS Ventura 13.0がいよいよ公開されました。Monterey 12.6でダウンロードし、起動用USBメモリを作り、クリーンアップデートしました。最新版のOpenCore (0.8.5) とkext類でMontereyが動いていれば、通常の作業でアップデートできるはずです。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

作業に使ったシステム構成

本日 (日本時間2022/10/25)、macOS Ventura 13.0 が正式配布されました。Montereyが配布されたのは去年の10月26日でしたので、ほぼ同じでした。Montereyの最初のバージョンが12.0.1だったのと同様、Venturaも13.0.1が最初の配布バージョンになりました。インストール先のマシンは、以下で、Z690マザーボードに12900Kを搭載しています。グラフィックスはRadeon RX 6600です。ブートローダはOpenCore 0.8.5でkext類は最新にしてあります。

ASROCK Z690 STEEL LEGENDのUSBを設定する

直近まで使っていたmacOSはVentura 13.0 RC (22A380)です。ベータ版ですが、あまりに快適なのでそのままメインで使ってました。ただ、パブリックベータが公開される前まで使っていたMontereyとは別のSSDで使ってました。それで、3ヶ月以上ぶりに、Monterey 12.5が入ったSSDから起動しました。WDの1TB M.2 SSD, WDS100T2B0Cです。ベータ版を使っている間に12.6が公開されましたので、まずは12.6にアップデートしました。その上で、Venturaへアップデートしました。

Venturaアップデートは自動

Venturaに更新したマシンの構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600で、Ventura公開前の最新版で12.6が動いてます。

このMontereyから、「システム環境設定」「ソフトウェアアップデート」を開いたところ、Venturaへのアップデートができるようになってました。容量は3.92GBだそうです。小さい気がしますが、多分必要に応じて追加でダウンロードするのかと思います。

ちなみに、「ほかにもアップデートがあります。」の表示が出ています。これをクリックすると12.6.1が来ていました。Venturaをすぐインストールしないという人も、こちらは入れておいた方が良いと思いました。

Venturaへのアップデート画面で「今すぐインストール」ボタンを押したところ、まずはダウンロードが開始します。

ダウンロード終了後は、アップデートがスルスルと進んで行きました。今までのメジャーアップデートでは、「macOS Venturaをインストールするには、”続ける”をクリックしてください」という画面が出て、そこで中断できました。今回は自動で進むようです。そういえばVenturaで最初にベータ版を導入した時も、自動更新でした。ベータ版でも後には中断できるようになったので、この仕様も、今後変更されるかもしれません。

ということであっけなくVenturaにアップデートされました。快調に動作してます。ビルドは22A380で、Ventura RC 2と同一です。RC 2がそのまま公式版になったようです。

クリーンインストールの手順

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

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

1. Venturaインストーラをダウンロード

先ほどの自動アップデート時にダウンロードされたインストーラは、アップデート終了時に消えてしまってます。ということで再度、インストーラをダウンロードし直すことにしました。すでにVenturaになってしまった環境から、App Storeに行き、Venturaを検索したらありました。

入手ボタンをクリックすると、ソフトウェアアップデートが動いてダウンロード開始しました。今回は、なぜか12.15GBとなってます。これなら全部を一括ダウンロードしてくれそうです。

ダウンロード終了すると、インストーラが起動します。今回は、「macOS Venturaをインストールするには、”続ける”をクリックしてください」というダイアログがちゃんと出て、中断可能です。

ここで中断すると、これもいつものようにアプリケーションフォルダに「macOS Venturaインストール」が出来上がっていました。先ほどのようにインストール作業で消えてしまうことがあるので、バックアップしておきましょう。

2. VenturaインストールUSBを作る

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

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

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

こうして作成したインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ&ドロップすれば良いです。この先、M.2 SSDは消去しますので、他にも必要なデータがありましたらバックアップしておきます。

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

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにVenturaインストーラが見えるはずです。

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

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

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

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

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

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

6. Venturaをインストールする

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

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

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

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

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

まとめ

OpenCoreで起動しているZ690マシンにVenturaをクリーンインストールしました。そのために、単体で起動してVenturaがインストールできるUSBメモリを作りました。ベータ版の時から安定していましたが、公開版Venturaも快適に動いています。

Venturaのpowerd暴走を止める

Fri, 26 Aug 2022 11:48:52 +0900

macOS 13 Ventura beta 3 (22A5321d) を、ASRock Z690 Steel Legend, 12900Kの環境で常用していたのですが、最近になって、CPUファンがうるさく回転していることに気づきました。アクティビティモニタでCPU使用状況を調べると、powerdというプロセスが104%くらいのCPUを使ってます。CPU使用の棒グラフを見ると左の方のコアの負荷が高いです。HWMonitorで温度を調べると、CPU Core 1が最高で77度くらいになって赤字表示でした。CPU Heatsink, Proximityも77度くらいまで上がってました。下のスクショは対応直後で、下がって余熱が残っている状況です。

ventura powerdで検索したところすぐに解決策が見つかりました。こちらです。

MacOS Ventura powerd activity util… | Apple Developer Forums

ターミナルから、

% sudo pmset schedule cancelall

とすれば良いようです。このコマンドを発行したら、CPUファンはすぐに静かになり、CPU温度も低下して、全部のコアが30度台になりました。この問題はredditでも話題になっているようです。

pmsetコマンドは、電力管理の設定を変更するコマンドです。schedule cancelallは、起動・再起動・終了・スリープ・スリープ解除を行うスケジュールを全部キャンセルするという指定のようです。このコマンドを発行する前に、pmset -g schedすると、異常なスケジュールが設定されている様子を確認できるらしいです。スケジュールは、「システム環境設定」「省エネルギー」から、曜日を指定して設定できる機能です。もともと設定していないので、キャンセルしても問題無いです。

手元の環境では、これで解決していますが、また暴走が始まることもあるそうです。ベータ版の途中から発生した問題のようですので、今後改善されると思います。

Windowsだけで作るmacOSインストーラUSB

Thu, 21 Jul 2022 13:59:59 +0900

macOSインストール用のUSBメモリをWindowsだけを使って作成しました。まず、OpenCoreパッケージに付属しているmacrecovery.pyというPythonプログラムを使ってMacの復元イメージをダウンロードし、次にFAT32のUSBメモリに保存します。これでMacで起動するRecoveryボリュームを作ることができました。手順だけを手短に見たい人は、以下のStep: 1, Step: 2, Step: 3の節を見てください。

macOS導入USB

macOSをインストールするためのインストール用USBメモリは、通常はmacOS上で作成します。macOSが動いていないとmacOSをインストールできないので、Macを持っていないと鶏と卵状態に陥ります。Windowsだけを使ってmacOSをインストールすることも、不可能ではないけどとても面倒です。

・・・と、思っていたのですが、試してみたところ予想していたよりずっと簡単でした。OpenCoreのバニラなインストールガイドで知られているDortaniaさんの説明ページを参考にしました。

このページを見るとややこしそうに見えますが、基本的には、

OpenCoreパッケージに入っているPythonプログラムを起動してmacOS復元イメージ（これを使うとmacOSをインストールできる）をダウンロードする
それをFAT32でフォーマットしたUSBメモリに入れる

だけです。

macOS環境ならば、Appleが配布しているmacOSインストーラの中にある、createinstallmediaコマンドを使ってインストーラUSBを作る方法が、Apple公式の方法で簡単です。この方法で作るUSBメモリは、HFS+でフォーマットされていて、MacやOpenCoreの起動選択画面ではそのOSのアイコンで表示されます。MontereyのインストーラUSBなら、下の写真にある「Install macOS Monterey」のようにOpenCoreの起動ボリューム選択画面に現れます。

これと同じものをWindowsで作るには、Windowsとは無縁なHFS+フォーマットのボリュームをなんとか作り出さないといけないので、とても大変だと思ってました。Dortaniaさんのページで紹介されているのは、HFS+形式USBメモリではなく、上の写真の右端に見切れて映っている、「Recovery 12.x (dmg)」という歯車アイコンに相当する復元用イメージを作る方法でした。

Step1: 復元ファイルをダウンロード

Windowsから、OpenCoreダウンロードのサイトを開き、最新版パッケージ一式をダウンロードします。ダウンロードサイトはここです。

Releases · acidanthera/OpenCorePkg

ここから、OpenCore-x.x.x-RELEASE.zipをダウンロードします。ダウンロードしたファイルは、Downloadsディレクトリの中に、OpenCore-x.x.x-RELEASE.zipというファイル名で保存されてます。次に、このzipファイルの中にあるPythonプログラムを実行します。

Pythonの実行のために、通常はWindowsにPythonをインストールします。手元のWindowsマシンでは、WSLの UbuntuにすでにPythonをインストール済みだったので、以下では、WindowsとWSL Ubuntuを行ったり来たりして作業しました。WindowsにPythonがインストール済み、もしくはWSLを使っていない場合は、Windows側でPythonを実行してください。

Pythonの実行をWSL環境で行うために、Ubuntuを開けて、OpenCoreのzipファイルを作業しやすい場所にコピーします。次に、zipを解凍し、その中のUtilities/macrecoveryというフォルダに移動します。そしてそこにあるmacrecovery.pyというPythonプログラムを起動します。以下がその作業です。

cp /mnt/c/Userx/xxxx/Downloads/OpenCore-x.x.x-RELEASE.zip .
unzip OpenCore-x.x.x-RELEASE.zip
cd Utilities/macrecovery
python3 ./macrecovery.py -b Mac-E43C1C25D4880AD6 -m 00000000000000000 download

macrecovery.pyは、http://osrecovery.apple.comというAppleのサイトから、特定のロジックボード用のリカバリーファイルをダウンロードするプログラムのようです。-bオプションでロジックボードのIDを指定します。上の操作で指定した番号 (Mac-E43C1C25D4880AD6) は、MacBook Pro (13-inch, Early 2015)、機種ID MacBookPro12,1のものです。検索したところ、以下のページにBoard ID一覧がありました。

List of Mac BoardID, DeviceID, Model Identifiers & Machine Models

MacBookPro12,1の機種対応の最終OSがMontereyなので、この指定でMontereyをインストールするリカバリーイメージをダウンロードできます。MacBookPro12,1はVentura未対応なので、この先もMontereyがダウンロードできるはずです。

他のmacOS、例えばBig Surのリカバリーイメージをダウンロードしたい場合は、最終サポートOSがBig Surである機種のロジックボードIDを指定します。Dortaniaさんのガイドでは、Big SurではMac-42FD25EABCABB274を指定することになってます。これはiMac (Retina 5K, 27-inch, Late 2014) iMac15,1のIDで、最終サポートOSはBig Surです。

macrecovery.pyを実行すると、

BaseSystem.chunklist
BaseSystem.dmg

という2つのファイルが出来上がってます。この先、Windowsでの操作を行うので、Windowsからアクセスしやすいように、Downloadsディレクトリに戻しておきます。

cp BaseSystem.* /mnt/c/Users/xxxx/Downloads/.

Step2: USBメモリを初期化する

次に起動用USBメモリを初期化します。GUIDパーティションマップ (GPT)で用意したパーティションをFAT32でフォーマットします。一般的なフォーマットなので、特に難しいところはないように思われました。実際、macOSのディスクユーティリティで作ったMS-DOS (FAT) (GUIDパーティションマップ)のUSBメモリもそのまま使えました。ただ、macOSからUSBメモリの名前を変更したところ、通常の起動ドライブとして見えてしまうようになり、リカバリーイメージとしては表示されなくなり、使えなくなりました。微妙なパーティション・フォーマットの違いで動作しなくなるようです。

Dortaniaさんの手順では、WindowsでUSBメモリをフォーマットするツールとして、

Windows標準のDisk Management （日本語名「ディスクの管理」）
Rufusというオープンソフトウェア
Windows標準のdiskpart

を使う3つの方式が紹介されています。ここではWindows標準装備の1. と 3.の方法を試し、動作することを確認しました。

Disk Managementを使う

Disk Managementは日本語名で「ディスクの管理」というツールです。macOSのディスクユーティリティに相当するツールかと思います。これで、USBメモリを選択し、初期化します。すでにGPTのパーティションが用意されていたら、それを削除して、未割り当てにして、「新しいシンプルボリューム」を作ります。

このメニューを選択すると、「新しいシンプルボリュームウィザード」というプログラムが起動します。これを用いて、FAT32のボリュームを作成します。ここでボリュームラベルを指定することもできます。

これでFAT32のUSBメモリが完成するので、Step 3に進んで、ファイルをコピーします。

Disk Managementは操作が簡単ですが、パーティションスキームを作り直す方法がわかりませんでした。MBR (Master Boot Record) でパーティション作られたUSBメモリは、FAT32でフォーマットされていてもリカバリーには使えないのですが、これをGPTに変更する方法がメニューには見つかりませんでした（Windowsスキルが低くてすみません）。次に示すdiskpartを使う方が確実だと思います。

diskpartを使う

diskpartもWindows標準搭載の、20年以上昔からあるツールです。CUIでサクサク操作できて良いです。これを用いると、パーティションの設定から完璧に作り直せるので、USBメモリを間違いなく初期化できます。Windowsメニューからdiskpartとタイプすると起動します。USBメモリはUSBポートに挿しておきます。

Microsoft DiskPart バージョン 10.0.22000.653

Copyright (C) Microsoft Corporation.
コンピューター: XXXXXXXXXX

DISKPART>

list diskコマンドでUSBメモリの番号を見つけて（ここでは2番）それを選択します。USBメモリは32GBなので、これに間違い無いです。

DISKPART> list disk
 ディスク 状態 サイズ 空き ダイナミック GPT 
 ------------ ------------- ------- ------- --- ---
 ディスク 0 オンライン 465 GB 0 B *
 ディスク 1 オンライン 232 GB 1024 KB *
 ディスク 2 オンライン 29 GB 127 MB *
DISKPART> select disk 2
ディスク 2 が選択されました。

次に、このUSBメモリを、

cleanして（ディスク構成情報を削除）
GPTに変換して（最小のパーティションができる）
primaryパーティションを作って（確認して、選択して）
fat32でフォーマットして
Eドライブに割り当てて
出来上がったvolumeを確認

します。その様子を下に示します。

DISKPART> clean
DiskPart はディスクを正常にクリーンな状態にしました。
DISKPART> convert gpt
DiskPart は選択されたディスクを GPT フォーマットに正常に変換しました。
DISKPART> create partition primary
DiskPart は指定したパーティションの作成に成功しました。
DISKPART> list partition
 Partition ### Type Size Offset
 ------------- ------------------ ------- -------
 Partition 1 予約済み 15 MB 17 KB
* Partition 2 プライマリ 29 GB 16 MB
DISKPART> select partition 2
パーティション 2 が選択されました。
DISKPART> format fs=fat32 quick
 100% 完了しました
DiskPart は、ボリュームのフォーマットを完了しました。
DISKPART> assign letter=e 
DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。
DISKPART> list volume
 Volume ### Ltr Label Fs Type Size Status Info
 ---------- --- ----------- ---- ---------- ------- --------- --------
 Volume 0 NTFS Partition 465 GB 正常
 Volume 1 FAT32 Partition 100 MB 正常 システム
 Volume 2 C NTFS Partition 232 GB 正常 ブート
 Volume 3 NTFS Partition 635 MB 正常 非表示
* Volume 4 E FAT32 Partition 29 GB 正常

太字部分が入力したコマンドです。これでエクスプローラーからEドライブとして見えます。

Step3: USBメモリにコピーする

次に、ダウンロードファイルをUSBメモリにコピーします。ここから先はエクスプローラーから操作できます。USBメモリに、以下の2つのフォルダを作ります。

com.apple.recovery.boot
EFI

com.apple.recovery.bootには、Step 1で入手した、

BaseSystem.chunklist
BaseSystem.dmg

を入れます。エクスプローラーのコピー・ペーストで行いました。

またEFIには、現在macOSを動かしているコンピュータのEFIをそのままコピーしておきました。

今回試したコンピュータは、ASRock Z690 Steel Legend + 12900K + RX 6600XTの組み合わせです。EFIはこちらに置いてあります（使う場合はシリアル番号などを入れてください）。ディレクトリ構成は結局、以下のようになりました。

com.apple.recovery.boot
- BaseSystem.chunklist
- BaseSystem.dmg
EFI
- APPLE
- BOOT
- OC

これでmacOSがインストール可能なUSBメモリが完成しました。

USBメモリで起動

このUSBメモリを挿してコンピュータを起動します。大抵は、起動可能なUSBメモリが挿さっているとそこから起動するようですが、BIOSメニューから確認・設定するのが確実かもしれません。USBメモリのルートにあるEFIディレクトリに、EFIファイル一式が正しくコピーできていれば、OpenCoreの起動ボリューム選択画面が表示されます。

ただ、この中にRecoveryイメージはありません。実は、使用しているconfig.plistで、選択メニューに復元イメージが表示されないよう設定してあるためでした。そのように設定されている場合、スペースキーを押すと、全部の候補が現れます。その結果、macOSがインストールされたそれぞれのボリュームの横に、Recovery xxx (dmg)という歯車アイコンの選択肢が現れます。実際のMacにも現れる復元用の起動ボリュームで、これを選択してOSの再インストールなどが可能です。

そして並びの左端に、今回Windowsだけを使って作成したUSBメモリが現れました。今回使用しているOpenCanopyの設定アイコンでは、他のRecoveryアイコンと違ってオレンジ色です。外付けドライブにあることで、色がオレンジのようです。アイコンの名前がNO NAMEなのは、FAT32のドライブ名のデフォルトがNO NAMEだからです。

これを選択して起動すると、リカバリーのメニューが現れます。ここでmacOS Montereyのインストールを選択すると、

インストーラが起動しました。この先インストールを進めることで、Montereyを動かすことが可能でした。

まとめ

Windowsだけを用いて、macOSをインストールするUSBメモリを作り、動作を確認しました。以前調べた方法はもっと複雑でしたが、今回はあっけなくできてしまいました。macrecovery.pyプログラムを開発された皆さんのおかげだと思います。Mac本体を持っていない人でも簡単にmacOSをインストールできると思います。その場合でも、OSを使わせてもらうお礼にApple製品やサービスを買ってあげてください。

macOS Ventura PBの導入用USBを作る

Wed, 20 Jul 2022 15:41:26 +0900

macOS 13 Venturaを起動してインストールできるUSBメモリを作成しました。配布されているpublic betaから、いつものようにcreateinstallmediaコマンドで作成します。USBメモリのESPには、すでにVenturaが動作しているOpenCoreとそのファイルを入れました。このUSBで起動して、Venturaをインストールできました。

Ventura PBの配布方式変更

macOS 13 VenturaのPB (public beta)を使用して10日近く経過しました。とても安定しているので、もはやメインOSとして使ってます。PBが配布された当初は、マイナーアップデートの時のように、「今すぐアップグレード」ボタンを押すと、本当にすぐにアップデートが開始してしまい、中断できませんでした。

最近試したところ、いつものメジャーアップデートのように、インストーラプログラムがApplicationsフォルダに格納されるようになってました。本番に備えて改善されたようです。ソフトウェアアップデートのアイコンも、Venturaのものに変わってました。ダウンロードされるデータサイズも12.3GBに増加してます。なので、インストールし直すことにしました。インストールしなおしても、ビルド番号は変更ないようです (22A5295i) 。

ソフトウェア・アップデートで、「今すぐアップグレード」を押すと、ダウンロードが開始され、終了するとインストーラプログラムが起動します。

ここでインストールを中断します。メニューから終了を選んで終了させると、Applicationsフォルダにインストーラが見つかります。中断せずにインストールを完了すると、このインストーラが消えてしまいます。他の場所にコピーをとっておくと良いです。これもいつも通りの動作です。

インストール用USBメモリを作る

この先も、いつものmacOSインストール用メモリ作成の手順と全く同じです。まずはUSBメモリをフォーマットします。ディスクユーティリティでUSBメモリの項目を選んで、「消去」ボタンを押し、「APFS」フォーマット「GUIDパーティションマップ」方式でフォーマットします。名前はなんでも良いのですがUSBとしました。

次に、ターミナルを開き、VenturaインストーラのResourcesディレクトリに移動します。そこにあるcreateinstallmediaコマンドを実行します。インストール先には、上で作成したUSBメモリを指定します。

$ cd /Applications/Install\ macOS\ Ventura\ beta.app/Contents/Resources/ 

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

この後、diskutil listコマンドでUSBメモリと起動中のドライブのEFIの場所を探して、それぞれをマウントして、ファインダーでEFIフォルダをコピーします。

% diskutil list

(略)
/dev/disk10 (external, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *31.4 GB disk10
 1: EFI ⁨EFI⁩ 209.7 MB disk10s1
 2: Apple_HFS ⁨Install macOS Ventur...⁩ 31.0 GB disk10s2
(略)

% sudo diskutil mountdisk disk10s1

USBメモリで起動する

今動いているEFIの内容を、USBメモリのESPにコピーできていれば、USBメモリから起動できます。OpenCoreの選択画面には、インストーラが現れます。今動いているドライブで起動して、OpenCoreの起動ボリューム選択画面でUSBメモリを選択しても良いです。

これを選択すれば、Macをリカバリーする画面が現れ、この中からドライブのフォーマットやVenturaのインストールを行えます。

Monterey 12.3 でユニバーサルコントロールを使う

Wed, 16 Mar 2022 18:29:26 +0900

macOS Monterey 12.3が配布されたので12.2.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.3の解説はありません）。ユニバーサルコントロールが使えました。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.9で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + BCM94360NG

システム環境設定のソフトウェアアップデートに、12.3のアップデートの通知が来ていました。

アップデートにより、

「ユニバーサルコントロール（ベータ）」が追加
「空間オーディオ」「絵文字」が改良
Podcastのエピソードが追加
Safariの翻訳がイタリア語と中国語に対応
ショートカットがリマインダーでのタグに対応
保存済みパスワードにメモを追加可能
バッテリ容量測定の精度改善
TVアプリと写真アプリのバグに対応

などが実現されるようです。中でも、ユニバーサルコントロールは目玉機能で、世間で注目されてます。Hackintoshで動くのかどうか、是非とも試したいところです。

早速アップデートしました。「今すぐインストール」ボタンを押すと、4.38GBのファイルがダウンロードされ、その後、自動的に3回再起動して、12.3に更新されました。いつもと同様に、再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。

再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.3が起動しました。ビルドは21E230です。

ユニバーサルコントロールを試す

早速、話題のユニバーサルコントロールを試しました。これを使うためには、システム環境設定のディスプレイから、ユニバーサルコントロール…ボタンを押して設定します。現れるチェックボックスを、とりあえず全部有効にします。

iPadを使う場合は、これも最新のiPadOS 15.4にアップデートしておきます。次に、iPadの「設定」を開き、「一般」から「AirPlayとHandoff」を開いて「カーソルとキーボード」をオンにしておきます。

他のマシンの用意ができたら、macOSのディスプレイから「ディスプレイを追加」を選びます。これで追加するマシンを選べます。以下の例では、中央が、今回12.3をインストールしたASRock Z590 Extreme + 10900Kマシンです。左がMacBookで、右がiPadです。

この配置の場合、ASRock Z590 Extreme に接続したトラックパッドのポインターを、画面左に持っていくとMacBookにポインターが移動します。画面右に持っていくとiPadに移動します。それぞれのマシンに移動した後、テキストが入力できる場所でクリックすると、そこにカーソルが現れ、キーボードから入力できるようになります。とても便利です。ASRock Z590 Extremeの機種設定はApple T2セキュリティチップ搭載機種のiMac20,1に設定しています。このことでユニバーサルコントロールが動かないのではと心配していましたが、全く問題ありませんでした。

Macとの連携は、今までも、画面共有をすればほぼ近い操作が可能なので、それほど大きな変化ではないかもしれないです。でも、iPadとの連携はすごいです。iPadでの文字入力が楽になるので、iPad用のキーボードを買う必要が無くなったかもしれないです。また、写真ファイルなどをドラッグ＆ドラッグすると、その写真を貼り付けられます。ファイルの移動も簡単にできます。今のところ連携できるのは、Mac同士、もしくはMacとiPadだけのようです。この先、MacとiPhoneが連携できたら、ますます便利になるのではと思いました。

macOS 12.1からRadeon 6600XTが使える

Sat, 30 Oct 2021 19:03:25 +0900

AppleのmacOS 12.1 betaリリースノートによると、AMD Radeon RX 6600XTが使えるようになったとのことです。色々なサイトで話題になっていますが、元ネタは以下のようです。

Apple Developer Documentation

情報のまとめ

これによると「ディスプレイに関するmacOS Monterey 12.1 betaの新機能：AMD Radeon 6600XT GPUを搭載したグラフィックスカードが使用可能になります。」とのことです！

Redditのコメントには以下のような内容が書かれてました。

Radeon RX 6600無印も6600XTと同じくNavi 23なのでdevice IDを偽装すればたぶん動く
Radeon RX 6900XTの新しいバージョン（XTXHチップ）もdevice IDを0x73BFに偽装する必要があるけど動く
Radeon RX 6700XTはNavi 22であり、GPUチップが違うので引き続き動かないと考えられる

6700だけはなぜかmacOSでサポートされない様子です。次期Mac製品ラインナップに関係しているのかもしれません。ということで、macOS 12.1でサポートされるRadeon RX 6000シリーズは

Radeon RX 6900XT
Radeon RX 6800XT, 6800
Radeon RX 6600XT (6600無印も対応可能？)

ということになりそうです。

12.0と12.1のkext比較

グラフィックスドライバーは、/System/Library/Extensions にあると思われます。macOS 12.0とmacOS 12.1で、それらしい名前のファイルを探してみたところ、そのどちらにも、AMDRadeonX6000という名前で始まる.kextファイルが3個、同じく.bundleファイルが3個ありました。

内部的にはこれらはディレクトリです。その中のContents/Info.plistを比較したところ、.bundle/Contents/Info.plistの中身は、バージョンの記述の違いだけでした。一方で、.kext/Contents/Info.plistの中身には違いがありました。このため、6600XT対応のために内容が更新されたのは、以下の3個の.kextファイルだと思われます。

AMDRadeonX6000.kext
AMDRadeonX6000Framebuffer.kext
AMDRadeonX6000HWServices.kext

AMDRadeonX6000.kext

12.0と12.1でAMDRadeonX6000.kextのInfo.plistを比較すると、以下の行を含む内容が追加されていました。6600XTに搭載されたNavi 23のために対応した部分と思われます。

<key>AMDNavi23GraphicsAccelerator</key>
（略）
<key>IOClass</key>
<string>AMDRadeonX6000_AMDNavi23GraphicsAccelerator</string>

AMDRadeonX6000Framebuffer.kext

こちらにのInfo.plistも比較したところ、12.1版には、Navi23に対応して追加されたフレームバッファと思われる情報が書かれていました。

AMDRadeonX6000HWServices.kext

このContents/Info.plistの中に、IOPCIMatchというキーがあります。12.0の内容が以下だったのに対して、

<string>0x73101002 0x73121002 0x73181002 0x73191002 0x731A1002 0x731B1002 0x731F1002 0x73401002 0x73411002 0x73431002 0x73471002 0x734F1002 0x73601002 0x73A21002 0x73AB1002 0x73BF1002 0x73A31002</string>

12.1では以下のように変更されていました。

<string>0x73101002 0x73121002 0x73181002 0x73191002 0x731A1002 0x731B1002 0x731F1002 0x73401002 0x73411002 0x73431002 0x73471002 0x734F1002 0x73601002 0x73A21002 0x73AB1002 0x73BF1002 0x73A31002 0x73E31002 0x73FF1002</string>

これは、対応デバイスの情報だと思われます。8桁の16進数のうち、下4桁がベンダーIDで、1002はAMDのvendor IDです。上4桁がdevice IDです。

0x73E31002
0x73FF1002

の2機種が追加されています。実際の商品とデバイスIDの組み合わせのしっかりした情報は見つけられなかったですが、巷の情報では、以下の対応だそうです。

73E3: Radeon Pro W6600
73FF: RX 6600, 6600M, & 6600 XT

6600無印には対応している可能性があります。

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

Tue, 26 Oct 2021 12:20:35 +0900

macOS Monterey 12.0.1が配布されたので、Big Surからアップデートしました。最新版のOpenCore (0.7.4) とkext類でBig Surが動いていれば、通常の作業でアップデートできるようです。ここではクリーンインストールしました。

作業に使ったシステム構成

本日 (日本時間2021/10/26)、macOS Monterey 12.0.1 が正式配布されました。Big Surが配布されたのは去年11月13日でしたのでそれより早く、過去のスケジュールに少し戻りました。Big Surの最初のバージョンが11.0.1だったのと同様、Montereyも12.0.1が最初の配布バージョンになりました。インストール先のマシンは、以下で、Z590マザーボードに10900Kを搭載しています。グラフィックスはRadeon RX 5700XTです。ブートローダはOpenCore 0.7.4でkext類は最新にしてあります。

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

現在インストールされているmacOSはBig Sur 11.6 (20G165)です。起動ドライブはWDの1TB M.2 SSD, WDS100T2B0Cです。

アップデートの手順

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

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

1. Montereyインストーラをダウンロード

Big Surの環境から、「システム環境設定」「ソフトウェアアップデート」を開いて、Montereyをダウンロードします。12.13GBあるようです。

ちなみに、「ほかにもアップデートがあります。」の表示が出ています。これをクリックすると11.6.1が来ていました。Montereyをすぐインストールしないという人も、こちらは入れておいた方が良いと思いました。

ダウンロードするといつものように自動的にインストーラが開きます。ここで「続ける」ボタンを押せば上書きインストールが開始します。今回は、クリーンインストールするので、メニューバーから「インストーラを終了」を選び中断します。

2. MontereyインストールUSBを作る

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

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

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

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

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

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにMontereyインストーラが見えるはずです。

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

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

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

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

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

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

6. Montereyをインストールする

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

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。

この後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

次にリンゴマークと棒グラフの表示が出ます。

この後多分5~6分くらいで、また再起動しました。またmacOS Installerが選択されてます。

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

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

インストール終了したあと、このMacについてを確認すると、バージョンは12.0.1 (21A559) でした。リリース候補(RC)と同じビルドでした。

まとめ

OpenCoreで起動しているZ590マシンにMontereyをクリーンインストールしました。そのために、単体で起動してMontereyがインストールできるUSBメモリを作りました。いつものようにベータ版で予行演習していたこともありますが、スムーズにMontereyに移行できました。

M1 MacでHackintoshを作る

Sun, 13 Dec 2020 18:17:14 +0900

本物のMacが無い状態からhackintoshを作るのは困難です。また、macOSを無料で使わせていただいているお礼としても、本物のMacを1台は持っていても良いと思います。その1台がM1 Macでも大丈夫でしょうか？ということを確認するため、M1 MacBook Airでhackintosh起動・インストール用USBメモリーを作ってみます。

Macを買おう

Hackintoshを作るためにmacOS上での作業が必要です。この記事は「M1 Macをhackintoshにする」と言う内容ではなく、「hackintoshを作る作業にM1 Macを使用する」と言う内容です。Hackintoshを作るなら、Macを買っておこうという内容の記事を、以前書きました。

Macintoshを買おう

今なら省電力な割に高性能なM1 MacBook Air/Proがおすすめです。M1 Mac miniも良いですね。今までのMac下位モデルはインテルのiGPUを使っていましたが、性能は良くありませんでした。M1のiGPUはインテルより数倍性能が良いです。反面、miniのようなデスクトップモデルでも拡張性はほぼ無いです。そこで、拡張性を補い、インテルmacOS環境を手に入れるために、自作macOSマシンを作るのも良いと思います。でもM1マックでhackintoshは作れるのでしょうか。Rosetta 2があるので、ツール類も正しく動くとは思いますが、確認します。

Big Surをダウンロードする

一番の懸念は、インテル版Big Surが正規のApp Storeから入手可能かどうかです。そこで、M1マシンからApp Storeに行き、Big Surをダウンロードしました。

「入手」をクリックすると、「ソフトウェア・アップデート」が起動して、ダウンロードが始まります。12.18GBあるので、そこそこ時間がかかります。サイズは大きいので、インテルのコードも入っていそうです。

ダウンロードが終わると、アプリケーションフォルダにインストーラができています。

/Applications/Install macOS Big Sur.app

「情報」を見るとUniversalアプリケーションになっているようで安心しました。インテル環境でも大丈夫なようです。

macOSインストール用USBメモリ

次に、「Macで起動できて、MacにmacOSをインストールできるUSBメモリ」を作ります。まずはUSBメモリをHFS+でフォーマットします。USBメモリを接続し、M1 Macで「ディスクユーティリティ」を起動します。まずは「表示」から「すべてのデバイスを表示」を選んでおきます。（以下の2枚のスクリーンショットは以前のmacOSで撮ったものなので、見た目が違います）

この次に、USBメモリのデバイス名（一番上の階層の名前）を選択し、「消去」ボタンを押します。そこで現れるパネルから、方式として「GUIDパーティションマップ」を選びます。フォーマットには「MacOS拡張（ジャーナリング）」を選びます。

これ以外の選択をすると、後の作業でエラーが出たり、起動ドライブにならなかったりします。名前はなんでも良いです。ここではUSBにしておきました。次に、ターミナルを開いて、

/Applications/Install macOS Big Sur.app/Contents/Resources

に移動して、インストーラの中に移動して、createinstallmediaコマンドを使います。

% sudo ./createinstallmedia --volume /Volumes/USB/

しばらく時間がかかり、無事、macOSインストール用USBメモリが完成しました。これで本物のMacを起動すれば、macOSがインストールできるはずです。M1 Macが文鎮化する事案が話題になってますが、このUSBメモリーさえ持っていれば安心です。

diskutil listコマンドで、USBメモリの場所を調べて、diskutil mountコマンドでESPをマウントしておきます。以下はESPがdisk4s1の場合の例です。この結果、/Volumes/EFIの場所にマウントされるはずです。

% diskutil list 
% sudo diskutil mount disk4s1

ターゲットマシンを決める

今回は、Z390 + 9900K + RX580の構成へのインストールUSBを目指します。これに必要なkextは以下です。

AppleALC.kext
IntelMausiEthernet.kext
Lilu.kext
VirtualSMC.kext
WhateverGreen.kext

また、必要とされるSSDTは、こちらの表を見るとわかります。このマシン（Coffee Lake）に必要なSSDTは、

です。リンク先から、それぞれのコンパイル済みamlファイルを入手できます。

この構成なら、システムモデルはiMac19,1が良いと思います。マシン用のシリアル番号やUUIDなどを決めておきます。今回は、すでに動いているマシンの番号をそのまま利用します。AppleIDの関係で、シリアル番号はできる限り変更しない方が良いです。新しいマシンにインストールする場合は、正しいフォーマットのシリアル番号を新たに作ります。OpenCoreをダウンロードすると、その中のUtilitiesの中にmacserialというコマンドがありますので、これで生成します。–modelオプションでモデルを指定すればそれに合うシリアル番号とボードシリアル番号を生成してくれます。macserialもM1で動きました。

% ./macserial --model iMac19,1
C02ZTHYTJV3Q | C02950108CDLNV91M
C02YDVZSJV3Q | C02910403CDLNV9UE
C02YP6Z8JV3Q | C02919301GULNV9CB
C02DDCZDJV3Q | C02037104CDLNV98C

OC Gen XでESPを作る

先ほどマウントした/Volumes/EFI/の場所に、EFIフォルダを作っていきます。そこで、OC Gen Xツールを使います。M1版Big Surでも起動しました。

OC Gen-XでESPを作る

System TypeとしてCoffee Lakeを選び、上でリストアップしたkextを選びます。またSystem ModelをiMac19,1にして、決めておいたシリアル番号などを入力します。最後に「Generate EFI」ボタンを押すと、デスクトップにEFIフォルダができています。これをUSBメモリのEFIの中にドラッグ&ドロップでコピーします。

ESPを手直しする

OC Gen Xツールは大体のことはしてくれるのですが、足りない部分を補います。まずはSSDTが入っていません。先ほどダウンロードしたamlファイルをACPIフォルダの中に入れます。また、config.plistの中に、kextやamlファイルの記載がありません。そこで、ProperTreeの、OC Clean Snapshot機能を使い、ACPI, Drivers, Kexts, Toolsの内容をconfig.plistに反映させます。ProperTreeもM1版Big Surで問題なく動きました。

自作マシンで起動する

これで100% M1で作ったhackintoshインストール用USBメモリーが出来上がりました。自作Z390マシンで起動を試みたところ、無事起動しました。macOSのインストールに使えそうです。

文鎮化しても救える？

先に述べましたが、M1 Macが文鎮化する事案が話題になっています。ファームウェアのアップデートに失敗すると起動しなくなるらしいです。その対策の一つが、ほかのMacからApple Configurator 2を起動して、ファームウェアをアップデートする方法らしいです。自作macOSマシンで、M1 MacBook Airの文鎮化を救えるのかどうか、試してみました。とは言っても、本当に文鎮化しているわけではないので、様子を見た程度です。

自作マシン（Z390 + 9900K + RX-580 + OpenCore 0.6.4 + BigSur) とM1 MacBook AirをType-Cケーブルで接続します。Z390側は、マザーボードのバックパネルのType-Cコネクタを使いました。そしてApple Configurator 2を起動しました。Apple Configurator 2はApp Storeからダウンロードできます。

するとMacBook Airが認識されていました。

文鎮化しているわけではなく、元気に起動していますが、Z390マシンの方からは、これのファームウェアアップデートが可能なようです。「このアクションは取り消せません」とありますので、この先試していません。インテルベースの安定したHackintoshを持っていると、M1が文鎮化しても安心な気がします。

まとめ

M1Macでhackintoshが作れることを確認しました。このほか、Kext Updater.appやPlistEDPlus.appなどのツールも使えました。モバイルでは省電力なM1 MacBookを使い、デスクトップは拡張性のある装備満載な自作マシンを使うのが良いのではと思いました。

Big SurでAFPファイルサーバ機能が廃止されました

Fri, 20 Nov 2020 23:18:52 +0900

以前から予告があったのですが、Big SurからとうとうAFPファイルサーバ機能が無くなっていました。SMBだけになったようです。AFPサーバへ接続するクライアント機能はBig Surになってもまだ動いていました。

AFP

AFP (Apple Filing Protocol または AppleTalk Filing Protocol) は、ファイル共有機能を実現するプロトコルの一つです。これにより、ネットワーク上のサーバにあるファイルを、手元のハードディスクにあるかのように扱うことが可能になります。元々AppleTalk用に開発されたのですが、TCP/IP上で動くように移植されて、今も使われてます。macOSの新ファイルシステムであるAPFSと紛らわしい名前ですが、別物です。AFPの仲間には、老舗のNFS (Network File System) とか、Windowsでお馴染みのSMB (Server Message Block) があります。

最近のmacOSの「システム環境設定」「共有」では、標準でAFPとSMBのサーバー機能がサポートされていました。なので、面倒な手続き無しでどちらのサーバも設定できました。でも、AppleはどうやらAFPから手を引きたいと考えているようで、しばらく前から「AFPをやめてSMBを使ってください」と言ってました。HFS+に代わってAPFSがmacOSの主流のファイルシステムになっても、AFPサーバではAPFSをサポートしてませんでした。なのでAPFSボリュームは、AFP方式でのファイル共有に使えませんでした。

Catalinaのファイル共有

Catalinaでは、「システム環境設定」「共有」からファイル共有の設定をすると、デフォルトではSMB方式のサーバとして機能するようになってました。AFPファイルサーバの設定も可能でしたが、「オプション…」ボタンを押してからようやく選択できるようになってました。できればAFPは使って欲しくないというメッセージが読み取れる設定画面でした。

Big Surのファイル共有

Big Surになって確認したところ、ファイル共有設定のオプションボタンを押しても、AFPの選択ができなくなってました。選択できるのはSMBだけです。

ちなみに、Big SurになってもAFPクライアント機能は健在です。AFPで立ち上げているファイルサーバに、Big Surから接続することができました。でもこれもそのうち廃止されるのかもしれないですね。

Big SurでTime MachineがAPFS対応する

Mon, 16 Nov 2020 17:19:52 +0900

Time Machine用に大容量HDDを搭載できるのは自作hackintoshの大きなメリットです。そのTime MachineがBig SurになってAPFSに対応したようです。APFSになると色々メリットがあるので、現用のTime Machineも移行しました。

Time MachineとAPFS

Time Machineによる自動バックアップ機能がOS標準なことは、macOSの大きなメリットだと思います。うっかり削除したり、書き換えてしまったファイルを、Time Machineに何度も救われてます。Macに安い大容量HDDを内蔵すれば、安価に高速にバックアップできます。お手軽なマシンでそれが可能なのが自作PCです。

そのTime Machineが、Big SurになってようやくAPFSに対応しました。今までのTime Machineは、古いHFS+ファイルシステムを使っていました。Time Machineでは、特定時間ごとの全ファイルのスナップショットをバックアップします。１回目は、全てのファイルをバックアップコピーしますが、２回目以降は、差分だけを記録します。でもTime Machineのドライブをファインダーで見ると、あたかも毎回の記録が全て揃っているように見えます。Time Machineが頑張ってそのように見せているのです。

この機能は、APFSで導入されたクローン機能と似ています。あるファイルをクローン機能で複写すると、物理的なデータは一つしかないけど、それを2個に見せてくれます。片方のコピーに変更が加わると、その変更分だけを記録します。おそらくは、Time MachineのコードがAPFSの開発にも役立っていたのではないかと思います。逆に、APFSに備わったクローン機能をTime Machineで使えば、よりシンプルに効率よく実現できるはずです。ファイルシステムの機能ならば色々な場面で動作チェックされますから、バグが減って、堅牢になって、さらには最適化が進んで高速化すると期待できます。でもAPFSが実用化されても、今までTime MachineはHFS+を使ってました。移行に手こずっていたのかもしれません。でもようやくBig Surで対応しました。

APFS対応の確認

Time MachineがAPFS対応したことの確認をしました。Time Machineは、今までのHFS+のバックアップファイルも、サポートします。でも、新しいバックアップディスクを作る場合は、APFSになるようです。まずは、500GBの2.5インチHDDを用意して、HFS+でフォーマットしました。先の記事で紹介したリムーバブルHDDラックに入れてあるので、オレンジ色のリムーバブルディスクに見えてます。

ファイダーにも、オレンジのアイコンで、New Diskという名前で見えてます。

diskutilコマンドでチェックすると、確かにHFS+になってます。全体が一つのHFSボリュームです。

/dev/disk8 (external, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *500.1 GB disk8
 1: EFI ⁨EFI⁩ 209.7 MB disk8s1
 2: Apple_HFS ⁨New Disk⁩ 499.8 GB disk8s2

この後、「システム環境設定」「Time Machine」から、「ディスクを選択」ボタンを押し、このドライブをTime Machine用に設定します。

ここで消去を選ぶと、Time Machine用のHDDとして再度フォーマットされます。HDDの名前は同じですが、アイコンがTime Machine用に変わりました。

diskutilコマンドで調べると、

/dev/disk8 (external, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *500.1 GB disk8
 1: EFI ⁨EFI⁩ 209.7 MB disk8s1
 2: Apple_APFS ⁨Container disk9⁩ 499.8 GB disk8s2

/dev/disk9 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +499.8 GB disk9
 Physical Store disk8s2
 1: APFS Volume ⁨New Disk⁩ 692.2 KB disk9s2

となってます。論理的な入れ物であるコンテナができて、その中にAPFSボリュームができてます。ボリュームの名前は、HFS+のボリュームの名前のNew Diskを引き継いでいます。このように、HFS+からAPFSにファイルシステムが変更されました。この後は、今までと同じように、Time Machineを利用できます。なお、ディスクユーティリティで確認すると、APFS（大文字、小文字を区別）になっていました。

APFSの利点

APFS化されたことで、堅牢になって高速化される可能性はあります。利便性も上がります。APFSのボリュームになったので、サイズが柔軟に変更できます。一台のHDDを丸ごとTime Machineに割り当てる場合は、悩む必要はないのですが、パーティションに分けて、一つのパーティションをTime Machine用に使う場合は、サイズの決定が難しかったです。Time Machineには大容量のHDDを割り当てるので、パーティションを分けて、その一つをデータ置き場にしようとか、別の一つにはバックアップのmacOSを入れておこうなどと考えることが多いです。

HFS+のパーティションの場合、パーティションの大きさを、フォーマット時に決める必要があり、それ以降変更することがほとんど不可能でした。なので、運用してみるとサイズが足りなかったり、大きすぎたので勿体無かったりします。APFSボリュームならば、可変サイズなので必要に応じて記録領域が伸縮します。後から別のボリュームを追加することも可能です。

ボリュームを追加する

すでにTime Machine用に設定してしまったこのHDDに、新たにデータを書き込んでおくボリュームを追加してみます。HFS+だと実現できなかった手順です。ディスクユーティリティで、コンテナを選び、上の+ボタンを選択します。これでAPFSボリュームを追加できます。dataという名前のボリュームを追加しました。

ついでなので、macOSというボリュームも追加しておきます。その結果、

/dev/disk10 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +499.8 GB disk10
 Physical Store disk9s2
 1: APFS Volume ⁨New Disk⁩ 84.8 GB disk10s2
 2: APFS Volume ⁨data⁩ 999.4 KB disk10s1
 3: APFS Volume ⁨macOS⁩ 991.2 KB disk10s3

こんな感じに3個のボリュームが出来上がりました。macOSには、本体macOSが壊れた時のために、Big Surをインストールしてみます。インストーラを立ち上げて、このボリュームを選択します。

これでBig Surもインストールできて、起動できるようになります。macOSがインストールされた後のコンテナを見ると、

/dev/disk10 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +499.8 GB disk10
 Physical Store disk0s2
 1: APFS Volume ⁨data⁩ 1.1 MB disk10s1
 2: APFS Volume ⁨New Disk⁩ 84.8 GB disk10s2
 3: APFS Volume ⁨macOS - Data⁩ 20.4 GB disk10s3
 4: APFS Volume ⁨macOS⁩ 14.9 GB disk10s5
 5: APFS Volume ⁨Preboot⁩ 282.1 MB disk10s6
 6: APFS Volume ⁨Recovery⁩ 655.5 MB disk10s7
 7: APFS Volume ⁨VM⁩ 1.1 MB disk10s8

手動で作成した、New Disk, data, macOSの3個のボリュームに加えて、macOSインストーラが作成した、macOS – Data, Preboot, Recovery, VMのボリュームが作られています。

まとめ

Time MachineがAPFSに対応したことを確認しました。Time Machine用のディスクを新たに作ると、APFSになります。APFSになったおかげで、Time Machineのデータはそのまま残しつつ、後からボリュームを追加したり、macOSをインストールしたりできるようになりました。ということで、今使っているTime Machineドライブも消去して、APFSに移行することにしました。

Big Surをクリーンインストールする (OpenCore + Z390)

Sat, 14 Nov 2020 19:24:47 +0900

メインで使っているZ390マシンにmacOS Big Sur 11.0.1をクリーンインストールしました。macOSの本体とユーザディレクトリを別のSSDに分けて入れてありました。そこで、前回作成したインストール用USBを起動し、macOS本体が入っているSSDだけを初期化し、Big Surをインストールしました。

システムの構成

Big Sur公開初日にZ490マシンにクリーンインストールしました。

Big Surをクリーンインストールする (OpenCore + Z490)

2日目の今日は、メインで使用しているZ390マシンにもクリーンインストールします。こちらのマシンです。現在は、OpenCore 0.6.3とCatalinaの最新版が動いています。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

Z490の方は、ほとんどデータがなかったので、クリーンインストールも簡単でした。でもこちらのマシンは、いろいろデータが入っています。Dropbox、iCloud, Timemachineなどでバックアップされているので、最悪、全部消えても困りませんが、できれば残しておきたいです。

幸いなことに、macOSの本体と、ホームディレクトリを別のSSDに置いていました。diskutil listコマンドで見ると、以下のようになってます。（TimemachineやWindowsなどのドライブも接続されているのですが省略しました。なので、番号が飛んでます）

% diskutil list
/dev/disk1 (internal, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *250.1 GB disk1
 1: EFI EFI 209.7 MB disk1s1
 2: Apple_APFS Container disk6 249.8 GB disk1s2

/dev/disk4 (internal, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *960.2 GB disk4
 1: EFI EFI 209.7 MB disk4s1
 2: Apple_APFS Container disk7 960.0 GB disk4s2

/dev/disk6 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +249.8 GB disk6
 Physical Store disk1s2
 1: APFS Volume Mojave 56.6 GB disk6s1
 2: APFS Volume Preboot 127.3 MB disk6s2
 3: APFS Volume Recovery 1.0 GB disk6s3
 4: APFS Volume VM 2.1 GB disk6s4
 5: APFS Volume Macintosh HD - Data 139.8 GB disk6s5
 6: APFS Volume Macintosh HD 12.2 GB disk6s6

/dev/disk7 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +960.0 GB disk7
 Physical Store disk4s2
 1: APFS Volume home 830.7 GB disk7s2
 2: APFS Volume Preboot 20.5 KB disk7s3
 3: APFS Volume Recovery 20.5 KB disk7s4
 4: APFS Volume VM 2.1 GB disk7s5

物理ディスクは

disk1 (250GBのM.2 SSD) と
disk4 (960GBのSATA SSD)

です。

disk1 (250GB SSD) には、APFSコンテナである
- disk6が作られていて、現用のCatalinaの論理ボリューム (Macintosh HD – DataとMacintosh HD) と、先代のMojaveの論理ボリュームがあります。
disk4 (960GB SSD) には、APFSコンテナである
- disk7が作られていて、homeという論理ボリュームがあります。ここには、ホームディレクトリのデータを置いてあります。

つまり、disk1および6がある250GB SSDには、macOS本体と、後から追加したドライバーやアプリケーション類が入っています。最近はパッケージで買うアプリケーションは皆無になりましたので、いずれもネットから再ダウンロードすれば良いものです。なので、250GB SSDの論理ボリュームは全部消去しても困らないと考えました。また、250GB SSDのESPには、OpenCore類が一式入っています。これは残しても良いのですが、サイズは小さいので、バックアップしていてから、SSD全体を削除して、その後復活させることにしました。

USBインストーラを起動

昨日の記事で作ったUSBインストーラを使います。まずは、このUSBメモリのESPの部分に、現在使用しているdisk1のEFIをコピーしておきます。これでUSBメモリから起動できます。disk1から起動することも可能ですが、これから消去する予定なので、ここでバックアップしておきます。

これでBIOSでUSBインストーラを指定して起動できます。昨日のZ490へのインストールの時は復旧（Revoery）画面が日本語でしたが、今回はなぜか英語画面でした。

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

まずはDisk Utilityを選んで、250GB SSDを綺麗に全消去します。

ここでEraseボタンを押したら元には戻れません。ひたすら進むだけです。Disk Utilityを終了して、最初の画面に戻り、Install macOS Big Surを選びます。

さらに、インストール先に、先ほどフォーマットしたボリュームを選び、インストールを開始します。

この先は、前回と同じく、数回ほど再起動しつつ、インストールが進んでいきます。インストールが一通り終了すると、国選択の画面になります。

この後、いくつかの設定をすればインストール完了です。

USBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。

ホームディレクトリを復活

インストール直後は、インストール先の/Users以下にホームディレクトリがあります。クリーンインストールしたので中身は空です。そこで、今まで使っていた2.5インチSSDの場所にあるディレクトリに、ホームディレクトリを移動します。「システム環境設定」「ユーザとグループ」で「変更するにはカギをクリックします。」を選び、自分のユーザアカウントの上で右クリックして、「詳細オプション…」を選べば、ホームディレクトリを元の場所に戻せます。これで再起動すれば、Catalinaで使っていたファイルが全て使えます。

まとめ

OpenCoreで起動しているZ390マシンにBig Surをクリーンインストールしました。ホームディレクトリをmacOSとは別のSSDに入れてありましたので、それを残しつつ作業しました。

Big Surをクリーンインストールする (OpenCore + Z490)

Fri, 13 Nov 2020 23:56:37 +0900

macOS Big Sur 11.0.1の配布が開始されました。早速、Catalinaからアップデートしました。最新版のOpenCore (0.6.3) とkext類でCatalinaが動いていれば、通常の作業でアップデートできるようです。

システムの構成

本日 (日本時間2020/11/13)、macOS Big Sur 11.0.1 の配布が開始されました。過去のメジャーアップデートのナンバリング方式から、最初に出るのは11.0だと思ってましたが、今回は最初から11.0.1でした。インストール先のマシンは、こちらです。Z490マザーボードに10900Kを搭載しています。グラフィックスはRadeon RX 5700XTです。

ASUS ROG STRIX Z490-G, 10900K

このマザーボードに取り付けたWestern Digitalの250GB M.2 SSD, WD BLACK SN750 NVMeにクリーンインストールしました。SSDには、OpenCore 0.6.3と最新のkext類が入っていて、Catalina 10.15.7が動いています。diskutil listコマンドで見ると以下のようになっています。

% diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *250.1 GB disk0
1: EFI ⁨EFI⁩ 209.7 MB disk0s1
2: Apple_APFS ⁨Container disk1⁩ 249.8 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +249.8 GB disk1
 Physical Store disk0s2
1: APFS Volume ⁨Macintosh HD - Data⁩ 32.6 GB disk1s1
2: APFS Volume ⁨Preboot⁩ 83.6 MB disk1s2
3: APFS Volume ⁨Recovery⁩ 528.9 MB disk1s3
4: APFS Volume ⁨VM⁩ 2.1 GB disk1s4
5: APFS Volume ⁨Macintosh HD⁩ 11.2 GB disk1s5

disk0s1がESPです。disk0s2にAPFSコンテナが作られていて、この中に論理ディスクdisk1があり、その中にCatalina一式が入っています。Macintosh HDがシステムの中核部分で、簡単には書き換えられないよう保護されています。Macintosh HD – Data⁩がその他のシステムとユーザのデータです。PrebootはFileVault用のボリューム、Recoveryはリカバリーモードで起動するためのボリューム、VMは仮想メモリー用のボリュームです。

アップデートの手順

せっかくのメジャーアップデートなので、現在のM.2 SSDは綺麗さっぱりと全消去して、クリーンインストールしようと思います。なので次の手順でアップデートを進めます。

disk1のCatalinaでBig Surインストーラをダウンロードする
USBメモリを用意してBig SurインストールUSBを作る
USBメモリのESPにdisk1のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、disk1を消去する
インストーラからBig Surをdisk1にインストールする

1. Big Surインストーラをダウンロード

Catalinaを起動して、「システム環境設定」「ソフトウェアアップデート」を開いて、Big Surをダウンロードします。12.18GBあるようです。公開直後はネットが混み合ってダウンロード困難だったらしいですが、30分くらいでダウンロードできました。

ダウンロードするといつものように自動的にインストーラが開きます。ここではインストールしないので、インストーラは一旦終了します。

2. Big SurインストールUSBを作る

インストーラ用のUSBメモリを用意します。32GBはあった方が良いです。今回は32GBのUSB 3.0メモリーを用意しました。起動速度がとても遅くなってしまいますがUSB 2.0メモリーの方が確実です。今回は設定済みのESPがあるので問題ありませんが、未知のマザーボードの場合、USBの15個制限の影響で、USB 3.0ポートがUSB 2.0として動いてしまうことがあります。その場合、BIOS起動時は3.0だったポートが、macOSに制御が切り替わった途端に2.0に変貌してしまうので、起動作業が止まってしまうのです。（config.plistで15個制限を外しておくという方法もありますが）

USBメモリをHFS+で初期化する

次に、USBメモリーをディスクユーティリティ.appを使って初期化します。ディスクユーティリティ.appのデフォルトではボリュームのみが表示されますので、まずは、メニューバーの表示から「すべてのデバイスを表示」を選んでおきます。

こうすると、USBメモリ製品名が入ったデバイス名がウィンドウ左側リストに現れますので、これを選択します。今回はJetFlash Transcendという製品名を選択しています。次に消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここでAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。Mac OS拡張（ジャーナリング）を選んでおく必要があります。

次に、Big SurインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもBig SurをインストールできるUSBメモリになります。ターミナルを使用して、Big Surインストーラの中のContents/Resourcesに移動して、lsするとcreateinstallmediaというファイルが見つかるはずです。

$ cd /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/
$ ls create*
createinstallmedia

これを使用して、macOSインストールUSBメモリを作成します。とりあえず起動すると、ヘルプ情報が表示されます。

$ ./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsオプションは、起動用USBメモリを作成する場合に、最新ファームウェアやApple T2チップ用ファームウェアをダウンロードする機能のようです。Hackintoshでは不要な機能なので使わないでおきます。–volumeオプションでは、先ほど作成したUSBメモリへのパスを書いておきます。ということで、以下のコマンドを入力します。

% sudo ./createinstallmedia --volume /Volumes/USB/

sudoしているのでパスワードを求められます。その後、確認を求められるのでyを押します。そうするといろいろ進捗して終了します。

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

これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。

3. USBメモリのESPにdisk1のESPをコピーする

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

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにBig Surインストーラが見えるはずです。

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

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

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

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

USBメモリから起動すると、復旧 (Recovery) というアプリケーションが起動します。

Time Machineから復元する、macOS Big Surインストールする、Safari (を開く)、ディスクユーティリティ（を開く）、の選択が可能になります。この他、メニューバーの「ユーティリティ」から、「起動セキュリティユーティリティ」と「ターミナル」が選べます。「起動セキュリティユーティリティ」は、Apple T2チップ用の機能と思われます。hackintoshでは関係ないです。

今回はクリーンインストールを目指すので、Catalinaが入っているdisk 1を消去します。ディスクユーティリティを開き、全てのドライブを表示するようにし、Catalinaが入っているドライブを選択して、消去します。

名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。

6. Big Surをインストールする

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

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。（ここでもう一つ見えているアイコンはUSBメモリです）

17分くらいでインストールできるそうです。

でも17分も経たないうちに（多分5~6分）、再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

次は30分程度のようです。

この後、30分も経たないうちに（これも多分5~6分くらい）また再起動しました。またmacOS Installerが選択されてます。

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

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。

あとはいつものように、設定を行なっていくだけです。

インストール終了したあと、このMacについてを確認すると、バージョンは11.0.1 (20B29) でした。Geekbenchブラウザに出回っている情報によると、M1搭載MacBook Airなどと同じOSが搭載されているようです。

USBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。

まとめ

OpenCoreで起動しているZ490マシンにBig Surをクリーンインストールしました。そのために、単体で起動してBig SurがインストールできるUSBメモリを作りました。以前のバージョンの場合と手順は同じです。ベータ版で予行演習していたこともありますが、スムーズにBig Surに移行できました。

Big Surでは古いBroadcom無線モジュールが使えない?

Wed, 08 Jul 2020 23:50:29 +0900

macOS Big SurではBroadcomのWiFi/Bluetoothモジュールが動かなくなるとか、そんなことはないとか情報が飛び交ってました。古いMacにBig Surを導入するパッチを作っているサイトによると、2012年モデル以前ではWiFiが動かないらしいです。今後は2013年以降モデル搭載の802.11 ac対応Broadcomの無線モジュールを使用するのが良いと思います。無線モジュールに関してはこちらのページをご覧ください。

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

古いMacは無線が動かない

iMac14,1, iMac14,2, iMac14,3ってHaswellなのになぜBig Surのサポート外なのだろうと不思議に思って色々検索していたら、こんなページを見つけました。Big Sur非サポートMacで動かすためのパッチを配布しているDosdude1さんらのページです。フォーラムでもまっくぷろさんに紹介いただいています。

macOS Big Sur Patcher Is No Longer Available

最初の疑問は解決しませんでしたが、別のことを発見しました。このページのパッチがサポートしている機種一覧表によると、パッチを使っても、2012年以前のMacではWiFiが動かないらしいです。もともとがサポート対象外の古いMacに搭載された無線モジュールですので、パッチを当てて動かそうとしている人たちにしか検証できない貴重な情報だと思います。

802.11ac対応が動作条件?

実は2013年モデルMacからWiFiが802.11acに対応して、搭載されているBroadcom社製モジュールが入れ替わっています。これが関係していると思われます。それ以前の、802.11nのみ対応のBroadcomモジュールがBig Surで切り捨てられたのではないでしょうか。ちなみに、Broadcomモジュール型番と搭載Macの関係は、以下のページ（ロシア語）が詳しいです。

https://deviwiki.com/wiki/User:Omega/Broadcom_modules_(Apple)

この2つのページの情報を組み合わせると、以下の古いBroadcomモジュールは、Big Surでサポートされなくなったと考えられます。型番がBCM9431、BCM9432、BCM9433で始まるモジュールです。

Broadcom BCM94311MCAG
Broadcom BCM94321MC
Broadcom BCM94321COEX2
Broadcom BCM94322USA
Broadcom BCM94322MC
Broadcom BCM943224PCIEBT
Broadcom BCM943224PCIEBT2
Broadcom BCM94331PCIEBT3A
Broadcom BCM94331PCIEBT3B
Broadcom BCM94331PCIEBT4
Broadcom BCM94331CSAX
Broadcom BCM94331CD

このうちの一部は、AliExpressで1,000円前後で格安販売されています。Catalinaまでは動いていた実績があるので、互換性があるように紹介されている場合もあります。Big Surを使用する予定でしたら、避けた方が良いと思います。

一方で、引き続きBig Surでサポートされると考えられるBroadcomモジュールは、BCM9436シリーズの、

です。はBCM94360CDを使っているので引き続き使用できると思われます。M.2 無線モジュールのもこの世代なのでBig Surで使用可能と思われます。

Big Sur

Tue, 23 Jun 2020 11:20:06 +0900

macOS 11.0 Big Surインストールに関する情報をメモしておきます。

機種設定

Big Surは、以下のIntel Macで稼働します。

MacBook：2015年 (MacBook8,1) 以降
MacBook Air：2013年 (MacBookAir6,1) 以降
MacBook Pro：2013年後半（Late 2013）(MacBookPro11,1) 以降
Mac mini：2014年 (Macmini7,1) 以降
iMac：2014年 (iMac14,4) 以降
iMac Pro：全モデル (iMacPro1,1)
Mac Pro：2013年 (MacPro6,1) 以降

なので機種設定は上の機種ID以降の番号にしないと起動しません。

追記：MacBookPro11,1とMacBookPro11,2も避けた方が良いらしいです。

Apple、アップグレード後に起動しなくなる不具合が確認された2013~2014年製のMacBook Proのサポートを一時的に中止した「macOS Big Sur 11.0.1 Build 20B50」をリリースしています。

ブートローダー

OpenCoreとCloverで起動することができます。ただ、OpenCoreが主流になりつつあるので、よくサポートされていて良いと思います。

Big Surがリリースされた時点でのOpenCoreは0.6.3でしたので、それ以降のバージョンを使うと良いです。Kext Updaterなどで、最新リリース版を使えば良いです。

Kext類

Kext Updaterで得られる最新版を使用しておけば良いです。

USB起動インストーラ

従来通り、createinstallmediaコマンドで起動USBインストーラを作ることができます。

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

インストール例

Big SurをインストールしたインストールやフォーラムトピックスをBig Surのタグをつけてまとめておきます（準備中）。

Big Surをクリーンインストールする (OpenCore + Z490)

Big Surをクリーンインストールする (OpenCore + Z390)

10.15.2にしたけどNaviの性能は向上しませんでした

Sat, 14 Dec 2019 16:23:05 +0900

AMDのNaviグラフィックスがmacOS 10.15.1からサポートされたものの性能が引き出せないでいました。先週 (2019/12/11) 10.15.2がリリースされたので、改善されると期待しましたが変化なしでした。

Radeon RX580と5700XTの比較

進捗無しの記事です、すみません。AMDの新しいNaviアーキテクチャグラフィックスはmacOS 10.15.1から標準サポートされて、OOBで動きます。RX 580などのPolarisアーキテクチャ製品の後継として期待していました。でも、macOS上でのRadeon RX580と5700XTの性能を比較したところ、あまり差がなくて残念でした。

Radeon RX580/Vega 64/5700XTの性能を比較

この時使ったmacOSは10.15.1でした。10.15.1のリリース後に、NaviアーキテクチャGPUを搭載したMacBook Proが発売されました。なので、10.15.2になれば、ドライバーが改善されて性能が向上するのではと期待していました。でも実測したところ、10.15.1と10.15.2で性能差はありませんでした。残念でした。

上のグラフは、電源投入直後にGeekbench 5で5回計測したスコアの最大値です。実際の測定値は、以下です。


	10.15.1-OpenCL	10.15.1-Metal	10.15.2-OpenCL	10.15.2-Metal
580	47807	49600	47132	49624
5700XT	51988	41266	51170	42244

MacBook Proに搭載されているのは、実はPro 5300MとPro 5500Mという型番のGPUです。モバイル用のGPUで、市販されていません。先日、5500 XTというグラフィックスカードが発売されました。番号が同じなので、もしかしたら性能を引き出せているのかも知れないです。でもお手頃価格で入手できる旧型のRX 580の方がハードウェア仕様は上なので、微妙なところですね。しばらくはRX 580/590がHackintoshに最適な状態は変わらない気がします。

Mac Proでも同様の結果

先日発売されたMac Proに、Radeon RX 5700XT, Radeon VII, Radeon, Radeon RX Vega 64のリファレンスモデルを装着してGeekbench 5のスコアを測ってくれている動画がありました。

2019 Mac Pro - Everything you can Upgrade & How!

これによると、それぞれのリファレンスモデルの

Radeon RX 5700XTのMetalのスコアは42905
Radeon VII, RadeonのMetalのスコアは45885
Radeon RX Vega 64のOpenCLのスコアは57841

だそうです。今回と、前回の測定とほぼ同様のようです。実機でも、市販のカードだとこのくらいなのですね。

HackintoshでSidecarを使う

Sun, 27 Oct 2019 00:45:55 +0900

Catalinaで導入されたSidecar機能が無線接続で使えました。使用したWiFi/BluetoothモジュールはBCM94360CDとFenvi T919です。どちらも最初は有線でのみ動作してましたが、うやむやのうちに無線でも動くようになりました。

Sidecar動作のための条件

Sidecarを使うと、iPadがmacOSマシンのセカンドディスプレイになります。ミラーリングもできます。またiPad側のApple Pencil操作で、macOS画面を操作できます。でもSidecarを動かすためには、いくつかの条件が必要なようです。必要そうな条件を以下にあげました。Hackintoshでは、この条件は間違っているかもしれませんし、今後のアップル社の対応で変わってくるかもしれません。

Apple IDと無線

実機のMacでは、macOSマシンとiPadが

同じApple IDでログインしていること、
同じWiFiに接続していること（有線LANでは駄目です）、
Bluetoothの到達範囲にあること、

がSidecarを使う条件だと言われています。もちろんHackintoshでも必要条件です。USBケーブルでSidecarする場合には、無線条件が満たされていなくても大丈夫のようです。

iGPUの条件

試したところでは、BIOSレベルでiGPUが機能していることが必要のようでした。macOSからiGPUが認識されている必要はないようです。なのでグラフィックスカードを使用しているマシンでも問題ありません。BIOSからiGPUを無効にしていると、Sidecarで接続はしても画面が暗いままです。おそらくは、iGPUの画像圧縮機能を使って、画面を転送しているので、それがないと表示されないのだと思われます。後述するようにBIOS設定でiGPUがマルチモニターで動くように設定します。

追記：コメントでは、iGPUの無いXシリーズCPUでも動いたという情報をいただきました。

T2チップ搭載の機種IDは使えない

コメントでいただきましたが、tonymacx86の情報によると、T2チップ搭載機種IDを使ったHackintoshではSidecarは動かないらしいです。T2チップ搭載モデルでは、Sidecarの認証または画面圧縮にT2チップを使っているのだと思われます。なので、以下のページで示された機種IDを使用している場合は、Sidecarは使えません。

Apple T2 セキュリティチップ搭載モデルの Mac

BCM94360CDで動かす

最初は、Z390+9900Kを搭載したマシンでSidecarを試した経緯を書いておきます。このマシンのパーツ構成、ESP構成、config.plistなどは、下のリンクを見てください。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

使用しているWiFi/Bluetoothモジュールは、純正のMacで使用されているBCM94360CDです。以下の製品です。これをPCIeカードに挿して使用しています。

HackintoshでSidecarを動かす前に、同じiPad/Apple PencilとMacBookで動作確認しました。この場合は、Sidecarが問題なく動きました。次に、このHackintoshで試したところ、画面は出たのですが、有線接続でしか動きませんでした。iPadをUSB接続しない状態では、システム環境設定・Sidecarの「接続先」に「デバイスなし」と表示されてしまい、iPadが現れません。

有線で接続すると、接続先が選べるようになり、iPadが選択できます。MacBookでは無線でも問題なく接続できるので、Hackintoshなりの調整が色々必要なのだと思って、しばらく放置していました。ところが、何かの拍子で繋がるようになりました。実際に何をしたのかというと

Z390マシンとiPadを有線接続でSidecarしました。
Apple Pencil をペアリングするためにiPadから線を外してPencilを挿しました。
この時「接続が切断されるよ」というような内容のダイアログがiPadに出ました。
ペアリングが終わってPencilを外したらなぜか無線でSidecar接続しました。

これで無線でもiPadが選択できるようになりました。iPadがセカンドディスプレイになりますし、またPencilを使って画面操作もできます。Hackintoshであっても、Sidecarの本来の機能は全て利用できていると思います。

これ以前に、有線でSidecar接続中にUSBケーブルを外すことは試みていました。でも接続が切れるだけで、無線では接続できませんでした。今回なぜ可能になったのかわかりません。

今回行ったPencilペアリング操作は、無線接続できたことは多分無関係です。SidecarはApple IDを介して動作していると説明されています。それぞれのマシンが同じApple IDで動作していることがSidecarを使うための条件です。なので対になるマシンの認定をアップル社のサーバーが行なっているはずです。今回、無線接続できた理由は、何らかのきっかけ、時間経過、またはアップル社の方針変更によって、Sidecar動作条件が満たされたからだと思います。有線接続の場合は、直接接続されていることが確実なので、ペアリング認定条件が緩かったのでしょう。このようなmacOS機能は、iMessageやFaceTimeと同じく、動作するかどうかはアップルのサーバー次第です。条件はいつでも変化するし、真相は謎のままです。

Fenvi T919で動かす

次に、Fenvi T919でも試しました。以下で紹介した無線PCIeカードです。中身は、おそらくBCM94360CDと同一と思われているので、問題なく動くはずです。

WiFi/BluetoothアダプタFenvi FV-T919

使用したマシンは、以下で紹介したMSI B360M MORTAR TITANIUMに9600Kを搭載したHackintoshです。

MSI B360M MORTAR TITANIUM, 9600K

こちらも最初は接続できませんでした。Sidecarの接続先がグレーになっていて、iPadが選択できませんでした。しかし、Z390マシンでSidecarが可能になった後で、こちらもどう言うわけか、iPad選択できるようになっていました。Sidecarのペアリングを管理するサーバの設定が変わったのかもしれません。しかしZ390マシンの場合とは違って、iPadをSidecar接続しても、iPad画面が真っ暗でした。画面をミラーリングにしてApple PencilでiPadを操作すると、macOS画面のポインターは動きます。なので、遠隔ポインティングは効いているけど、表示が出ていないことがわかります。

Sidecarのビデオ転送にはiGPUの機能が使われているらしいと言う話を聞いたことがありましたので、iGPUをチェックすることにしました。BIOSで設定を見るとIGD Multi-Monitorの設定がDisabledになっていました。iGPUにもモニターを接続して、マルチモニターにするかどうかの設定だと思います。Disabledの場合は、iGPUの機能を無効にしていると思われます。そこで、これをEnabledにしました。メモリの設定はデフォルトの64MBにしました。この結果、無事にiPadに画面表示されるようになりました。

まとめ

HackintoshでもSidecarが動きました。USB有線接続なら問題なく接続できました。無線経由では、最初は接続できませんでしたが、よくわからないうちに無線接続できるようになっていました。また接続を実現するためには、通常のMac/iPadの条件に加えて、iGPUが動いている必要があるようです。とはいえiGPUを搭載していないiMac ProでもSidecarは可能なようなので、機種IDにも依存しているのかもしれません。

今回、Apple Pencilを初めて使ってみました。使い勝手や速度はちゃんとしてました。でもiPadに差し込むという初代Apple Pencilの充電方式は、緊急時には良いけど、普通に充電したい場面では使いにくいです。そのうちにこんなアクセサリを揃えてみたいと思ってます。

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

Thu, 10 Oct 2019 23:37:53 +0900

CatalinaをクリーンインストールするためのUSBメモリーを作ります。まずはCatalinaに含まれるcreateinstallmediaコマンドを使います。次にESPを作ります。すでにMojaveが動いているHackintoshがあればESPのファイルをコピーするだけです。

Mojave用ESPを最新にする

Catalinaは、Mojaveの場合と同じefiドライバー、kext、config.plistでCatalinaが起動できることを確認しています。ただしどれも最新版にしておくのが望ましいです。

Catalinaにアップデートする

ということで、Kext Updater.appなどを使用して、Cloverとkext類を最新にしておきます。

Catalinaをダウンロードする

macOSが動いているマシンからAppleのサイトに接続して、Catalinaのインストーラをダウンロードします。ダウンロード後に、自動的に起動しますが、メニューから終了させます。アプリケーションフォルダにmacOS Catalinaインストール.appというアプリケーションができているはずです。

USBメモリを初期化する

インストーラ用のUSBメモリを用意します。インストーラのサイズが8GBを超えていますので、16GB以上のメモリが必要です。今回は32GBのUSB 3.0メモリーを用意しました。起動速度がとても遅くなってしまいますが、本当ならばUSB 2.0メモリーの方が確実です。今回は設定済みのESPがあるので問題ありませんが、未知のマザーボードの場合、USBの15個制限の影響で、USB 3.0ポートがUSB 2.0として動いてしまうことがあります。その場合、BIOS起動時は3.0だったポートが、macOSに制御が切り替わった途端に2.0に変貌してしまうので、起動作業が止まってしまうのです。

次に、USBメモリーをディスクユーティリティ.appを使って初期化します。この時、ESP (EFI System Partition) から起動可能なように、ESPが作られるように初期化します。ディスクユーティリティ.appのデフォルトではボリュームのみが表示されますので、まずは、メニューバーの表示から「すべてのデバイスを表示」を選んでおきます。

こうすると、USBメモリ製品名が入ったデバイス名がウィンドウ左側リストに現れますので、これを選択します。今回はSanDisk Extreme Mediaという製品名を選択しています。次に消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここで、最新のAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。

実機用インストーラを作る

まずは実機（本物のMac）でも使えるCatalinaインストール用USBメモリを作ります。ターミナルを使用して、Catalinaインストーラの中に移動します。ターミナルから見ることができるmacOSオリジナルの世界では、アプリケーションフォルダは、Applications, インストーラはInstall macOS Catalina.appという名前になっています。ここでlsするとcreateinstallmediaというファイルが見つかるはずです。

cd /Applications/Install\ macOS\ Catalina.app/Contents/Resources/
ls create*
createinstallmedia

これを使用して、macOSインストールUSBメモリを作成します。とりあえず起動すると、ヘルプ情報が表示されます。

./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

sudo ./createinstallmedia --volume /Volumes/USB\ Memory/

パスワード入力の後、USBメモリを消去する確認を求められ (yを押します)、USBメモリ作成が開始します。しばらく経つと、以下のようなメッセージが出てインストーラUSBメモリが完成です。

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

こうして完成したCatalinaインストール用USBメモリは、実機のMacでこれ単体で起動して、Catalinaのクリーンインストールが可能です。

Hackintoshの場合も、今までMojaveを起動していたのと同じドライブのESPから起動すれば、このUSBメモリーインストーラを使用できます。Cloverの起動選択肢に「Boot macOS Install from Install macOS Catalina」という項目が見えているはずです。これがここで作ったUSBメモリですので、これを選んで再起動します。この手順でCatalinaのインストーラが起動することを確認できます。

ESPを作成する

ドラッグアンドドロップで複製する

前のステップで、今までmacOSを起動していたESPからUSBメモリ内のCatalinaインストーラが起動したことが確認できました。そうであれば、USBメモリ単体で起動させる手順は簡単です。USBメモリのESPに、これを起動させることができたESPの内容をコピーするだけです。下のスクリーンショットでは、起動ドライブのESPの中身を、USBメモリのESPに、ファインダのドラッグ&ドロップ操作でコピーしています。

これで単体で起動するUSBインストーラが完成しました。BIOSでこのUSBメモリーから起動するよう指定すれば、USBメモリー単体で起動します。

Cloverを新規にインストールする

ドラッグアンドドロップで今までのESPを複製する代わりに、Cloverインストーラを使って新規にインストールしても良いです。結果は同じで、新規に作るので気分が多少良い程度の違いです。Cloverのインストール時に必要なefiドライバを選んでおきます。次にconfig.plistとkext類を、現行のものと同じにしておきます。ただ、SIPを有効にした状態でCloverインストーラを動かすと、現時点ではエラー表示が出て進捗しないようです。こちらの記事をご覧ください。

CatalinaにしたらCloverがインストールできない

USBメモリーから起動する

USBメモリーから起動すると、すぐにインストーラが起動するのではなく、macOSユーティリティというソフトウェアが起動します。ここから、ネットワーク設定、ターミナル、Time Machine操作、ディスクユーティリティなどが使用できますので、インストール以外にも色々と役立ちます。

まとめ

単体で起動するmacOSインストーラUSBメモリを作りました。Catalinaを対象としましたが、以前のバージョンの場合と手順は同じです。今回ご紹介した手順は、tonymacx86のサイトで配布しているUniBeastが行う作業に相当します。ただ、MojaveでHackintoshがすでに動いていることを前提にしているので、ESP部分の作成は簡単でした。

このインストーラUSBメモリがあれば、これ単体で起動してmacOSユーティリティを起動できます。ここから、ボリュームをフォーマットできるので、マシンに新規のドライブだけが接続されている場合でもインストールできます。また、ターミナルで様々な操作が可能です。macOSが起動できなくなった場合の緊急時用にこのようなUSBメモリを持っていると、復旧作業が楽です。

Catalinaにアップデートする

Wed, 09 Oct 2019 20:02:46 +0900

macOS Catalina 10.15の配布が開始されました。早速、Mojaveからアップデートしました。Cloverとkext類を最新版にすれば、時間はかかるものの通常の作業でアップデートできるようです。

アップデートの準備

昨日 (2019/10/8 JST)、macOS Catalina 10.15の配布が開始されました。例年だと1-2週間前に配布開始日がアナウンスされたのですが、今回は突然のことでした。慌ててインストールしたのですが、インストールが止まって見えてしまうトラブルがあって報告が遅れました。実は、単に時間がかかっていただけのようでした。

システムの構成

インストール先のマシンは、こちらです。

MSI B360M MORTAR TITANIUM, 9600K

これに取り付けたCrucialの1TB M.2 SSD, CT1000P1SSD8にインストールしました。

Crucialの1TB NVMe M.2 SSD (CT1000P1SSD8) を使う

光学ドライブとTimeMachine用のHDDなどが接続されているのですが、わかりやすいように一時的に取り外した状態で進めました。また、起動ボリュームは慣例に従ってMacintosh HDにしてあったのですが、これもわかりやすいようにMojaveにしました。ということで、diskutil listコマンドで見ると、次のように見えます。

$ diskutil list
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 1000.0 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk1
Physical Store disk0s2
1: APFS Volume Mojave 629.6 GB disk1s1
2: APFS Volume Preboot 47.5 MB disk1s2
3: APFS Volume Recovery 510.4 MB disk1s3
4: APFS Volume VM 3.2 GB disk1s4

SSDにはEFIシステムパーティション(ESP)と、APFSコンテナのパーティションができています。APFSコンテナのパーティションは、SSDの空きを全て割り当てて確保してあります。APFSコンテナの中には、改名したばかりのMojaveという名前のメインボリュームがあります。macOSのシステムもデータも全部がこの中に入っています。PrebootはFileVault用のボリューム、Recoveryはリカバリーモードで起動するためのボリュームです。VMは仮想メモリー用のボリュームです。APFSのボリュームは、サイズが可変で、必要な容量に対して柔軟に対応できます。

ESPを最新にする

バニラなインストールをしているので、Hackintoshに必要なファイルは全てESPに入っています。Catalinaに備えて、この内容を最新にアップデートしておきます。開発者の皆さんが対応してくださっていますので、アップデートで発生する問題の多くは、Cloverやkextが最新版にすることで対処できます。現時点でのCloverの最新バージョンは、5070です。最新でしたのでそのままにします。次に、Kext Updater.appで使用中のkextを最新にします。手元のシステムでは、WhateverGreen.kext, IntelMausiEthernet.kext, AppleALC.kextを更新しました。更新したら、念のために再起動して、Mojaveとして起動することを確認しておきます。

新ボリューム作成

現在のMojaveに上書きアップデートしても問題ないとは思います。でも念のためにMojave環境は残しておきたいです。また、せっかくだから気持ちよくクリーンインストールしたいとの考えもありました。APFSなら、新しいボリュームを作成するのは簡単です。ディスクユーティリティ.appを開いて、Macintosh HDという名前の新しいボリュームを作成しました。（よく考えたらもはやHDじゃないですね）

念のためにdiskutilコマンドでも確認しておきました。

$ diskutil list
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 1000.0 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk1
Physical Store disk0s2
1: APFS Volume Mojave 631.1 GB disk1s1
2: APFS Volume Preboot 47.5 MB disk1s2
3: APFS Volume Recovery 510.4 MB disk1s3
4: APFS Volume VM 3.2 GB disk1s4
5: APFS Volume Macintosh HD 647.2 KB disk1s5

Catalinaをダウンロードする

これで準備万端ですので、Mojaveで起動して、「システム環境設定」「ソフトウェアアップデート」を開いて、Catalinaをダウンロードします。8GBあるようです。

インストールする

ダウンロードするといつものように自動的にインストーラが開きます。デフォルトのインストール先は、現在起動しているMojaveになっていますが、新しく作ったMacintosh HDを選択します。

インストールが始まると、間も無く再起動します。再起動時のCloverの起動選択画面では、Boot macOS Install from Macintosh HDを選択します。デフォルトでこれが選ばれていると思います。

このあとインストール画面になります。今回の環境では、この先が長かったです。About 11 minutes remaining…という表示が出たまま、インストールが止まってしまったように見えました。小一時間様子を見たのですが、変化がありません。そこで強制終了していろいろ試したのですが、どうしても11分のところで止まってしまいました。仕方がないので、そのまま一晩放置したところ、インストールが終わっていました。単に、時間がかかっていただけだったようです。

実は以下で紹介したZ390マシンでも、同様な手順でCatalinaのインストールを並行して行いました。そちらでも、やはり11分で止まりました。でもZ390マシンはしばらくするとインストールが進みました。ということで、Catalinaへのアップデートでは辛抱強く様子を見る余裕が必要だと感じました。ちなみに本物MacのCatalinaアップデートでは、プログレスバーが停滞することはなく、割と順調に進みました。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

インストールが終了すると、再び再起動します。今度は、インストール用のボリュームは消えていて、Boot macOS from Macintosh HDに変わってます。この挙動はいつものアップデート作業と同じです。

インストール途中で、TimeMachineバックアップや他のMacのデータを転送するかどうかを聞かれます。最初の手順で、Mojaveのドライブを残してありました。これが転送元の選択肢に現れますので、これから復帰しました。クリーンインストールという観点からすると、古いデータを引き継ぐことになってしまうかもしれませんが、設定は楽です。ユーザデータは大量になるので、それ以外の設定とアプリケーションだけを引き継ぎました。ユーザデータは、古いUsers以下のディレクトリを、システム環境設定のアカウントで指定すれば簡単に引き継げるので、ここで転送する必要はないと思いました。

インストールが終了した状態で、diskutilコマンドでボリュームの様子を見てみます。インストール先のMacintosh HDに加えて、Macintosh HD – Dataという名前のボリュームができています。これがCatalinaから新しく作られたボリュームです。インストール先に指定したMacintosh HDボリュームは読み出し専用になって、保護されているらしいです。- Dataのついたボリュームに、ユーザデータを含む、書き換えするデータが置かれるようです。

% diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 1000.0 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1000.0 GB disk1
Physical Store disk0s2
1: APFS Volume Mojave 639.0 GB disk1s1
2: APFS Volume Preboot 129.2 MB disk1s2
3: APFS Volume Recovery 1.0 GB disk1s3
4: APFS Volume VM 3.2 GB disk1s4
5: APFS Volume Macintosh HD - Data 47.6 GB disk1s5
6: APFS Volume Macintosh HD 10.6 GB disk1s6

まとめ

インストールに時間がかかったので、待ちきれなくて試行錯誤してしまいました。でも、我慢強くじっと待っていればCatalinaへは何事もなく順調にアップデートできたと思います。

kextd stallというエラーで起動しないことに対処

Sat, 05 Oct 2019 14:06:57 +0900

10.14.6追加アップデート2を入れたマシンのうち1台が起動しませんでした。APFSが原因でした。ApfsDriverLoader.efiを外して10.14.6 (18G103) 付属のapfs.efiに差し替えたら起動しました。

症状

2019年9月27日にmacOS Mojave 10.14.6追加アップデート2 (Supplemental Update 2) が配布されました。ビルドは18G103です。追加アップデートの名前の最後に2という番号がつくのは珍しいと思います。Catalinaがまもなく出るので、おそらく最後のバージョンになると思います。追加アップデートを続ける理由は、もしかしたらMojaveを10.14.6で終わりにして、バージョン番号をあげたくなかったのかもしれません。

いくつかのマシンで、アップデータ経由で通常通りの更新が問題なく可能でした。ただ、iMac19,1に設定した9600Kマシン

MSI B360M MORTAR TITANIUM, 9600K

では、どういうわけか起動しませんでした。最近は大体問題なくOSアップデートできるのですが、たまにこういう状況になるのはHackintoshの宿命で仕方ないところです。

-vオプションで調べた症状は以下のようです。Cloverのメニューは出て、メモリー確保も正しく行えるのですが、その後メッセージが続いた後、表示が止まってしまいます。しばらく経過すると画面には、

busy timeout[0], (60s): 'iMac19,1'

という表示が出ます。iMac19,1に設定したこのマシンが60秒間応答しないという意味だと思います。この状態で、キーボードを接続すると、

kextd stall[1], (60s): 'Magic Keyboard'

というような表示が出ることもあります。

また、いろいろなUSB機器を抜き差しすると、同様にkextd stallというメッセージが出ます。

原因の推測

メッセージのkextdは、kext daemonのことだと思います。kext (カーネル拡張) を読み込んでカーネルに登録する機能を担っていると思われます。stallは、自動車のエンスト（エンジンストール）と同じ単語で、応答がなくて動かない、という程度の意味でしょう。つまりメッセージから判断するに、kextデーモンが特定のkextを呼び出そうとしたけど、60秒経っても応答がないようです。

失敗しているkextはどれもmacOS本体のkextです。Clover類はESP (FAT) にありますが、macOS本体のkextは主パーティション (APFS) の中にあります。となるとAPFS (アップルファイルシステム) の読み出しに失敗している可能性があると考えました。また、上記で紹介したtimeoutメッセージも、APFSからの読み出しをする局面になって、マシンから応答がなくなりタイムアウトしたとも解釈できます。

apfs.efiで解決

CloverがAPFSにアクセスするためには、macOS本体のapfs.efiを使っています。以前はmacOSからAPFSのドライバーである

/usr/standalone/i386/apfs.efi

をESPにコピーして使っていたのですが、最近は、 ApfsDriverLoader.efiを使って、macOSから自動的に読み込んでいます。動的に読み込むことで、macOSのバージョンに合わせたapfs.efiが使えるメリットがあります。でも今回は、この仕組みが何らかの理由で機能していないようでした。そこで、EFI/CLOVER/drivers/UEFIの中の

ApfsDriverLoader.efiを削除して
macOS本体からapfs.efiをコピー

しました。すると10.14.6 (18G103) が立ち上がりました。

実際に行った手順は、もう少し複雑です。というのは、このマシンは起動しないのでapfs.efiを取得できません。そこで、別のMacにUSBメモリーを挿して、これに

cp /usr/standalone/i386/apfs.efi /Volumes/USB

のようにしてapfs.efiをコピーします。次にこのUSBメモリを、起動しないマシンに接続し、CloverのメニューからUEFI Shellを起動し、cpコマンドでESPのEFI/CLOVER/drivers/UEFIにコピーしました。また、ApfsDriverLoader.efiは、rmコマンドで削除しました。UEFI Shellの使い方は、以下をご覧ください。

起動しないマシンをUEFI Shellで救う

ApfsDriverLoader.efiが動かなかった理由は不明です。他のマシンでは18G103でも動いていますので、このマシンだけの問題かと思います。ApfsDriverLoader.efiのアップデートで解決するかもしれません。何れにせよ、起動でtimeoutやkextd stallのメッセージで止まる場合には、APFS関係を疑うと良いかと思いました。

slideでカーネル読み込み番地を調整する (Clover編)

Sat, 10 Aug 2019 00:28:14 +0900

macOSが起動するときに、早い段階で禁止マークが出て停止してしまうことがあります。多くの場合、カーネルを読込むメモリが確保できないエラーです。これをslideオプションで解決します。

追記：この記事はCloverを前提に書いてあります。OpenCoreに関してはこちらをご覧ください。またコメントいただいたように、CloverにOpenCoreのツールを流用して対応することも可能なようです。

カーネル読み込みメモリ空間を確保する (OpenCore編)

症状

禁止マークが出て早々に起動停止してしまう場合に、-vオプションで起動すると、”Error Allocating xxxx pages at xxxxxxxx”というようなメッセージが出ていることがあります。例えば下のメッセージは、「0xe590000番地から0x11c01ページのメモリー空間を確保しようとしたけど失敗しました」という意味です。1ページは0x1000バイト、つまり4096バイトのことです。10進数を使ってわかりやすく書くと、「240メガバイトあたりの番地から298メガバイトくらいのメモリー空間を確保しようとしたけど失敗しました」といった感じのエラーです。100番台になってからのMSIマザーボードでよく発生するエラーです。

このエラーの特徴は、「何回か起動を試みるとそのうち成功することがある」とか、「大抵は起動するけどたまにこのエラーで起動しない」など、再現性が低いことです。

簡単な対策法

この問題を直してくれるのが以下のefiドライバです。

AptioMemoryFix.efi
OsxAptioFix3Drv.efi
OsxAptioFixDrv.efi
OsxAptioFix2Drv-free2000.efi

以下の記事で説明したように、このリストの順番がお勧め順らしいので、上から試して、問題なく起動するefiドライバを使います。一度に2個以上のefiドライバを入れてしまうと、どちらが動くのか定まらないので避けるべきとのことです。

Cloverで使うEFIドライバ

リストの上の方ほど新しく開発されたefiドライバで副作用が少ないらしいです。一番強力なのが最後のOsxAptioFix2Drv-free2000.efiです。その名前の通りメモリーを強制的に開放させます。どのマザーボードでもほぼ機能する最強のefiドライバです。でも強力すぎるので、大丈夫なのかという意見はあります。Redditには、OsxAptioFix2Drv-free2000.efiの利用は避けて、slideオプションで対応した方が良いという意見もありました。とはいえ、私もMSIのマザーボードでOsxAptioFix2Drv-free2000.efiを使い続けていますが、特に問題はありません。でもせっかくですので、slideを使った正しい解決策を試してみます。

カーネル読込に失敗する理由

KASLR (カーネル番地乱数化)

そもそもどういうことが原因で、カーネル読み込みに失敗するのかを調べました。macOSが起動する際に、カーネルが0x100000以降の番地（10進数で1,048,576、1MB程度です）のメモリーに読み込まれます。実際に何番地に読み込まれるかは定まってなく、ランダムです。上記のエラーの例では、カーネル（またはその一部）を0xe590000番地から始まるメモリー空間に読み込もうとして失敗しています。読み込み番地はセキュリティのためにわざとランダムにしているそうです。この仕組みを、KASLR (Kernel Address Space Location Randomization: カーネル番地空間場所乱数化) というらしいです。カーネルが読み込まれる番地が常に一定だと、その番地を狙って悪さを試みるマルウェアが可能です。特定の番地からプログラムを動かしたり、特定の番地の内容を書き換えることでOS動作を操れてしまうからです。そういう操作をされないために、起動毎に違う番地にカーネルを読み込んでいるそうです。

失敗しないマザーボード

以下で説明した方法で、UEFIシェルを起動すると、

起動しないマシンをUEFI Shellで救う

マザーボードのメモリーマップを見ることができます。これに使うコマンドがmemmapです。memmap -bとすると画面いっぱいになったところで一旦停止してくれます。また、fs0:などでドライブを指定して、必要ならばcdコマンドで適当なディレクトリに移動した後、memmap > memmap.txt などとタイプすると、その場所にメモリーマップをテキストファイルで保存します。

AptioMemoryFix.efiなどの穏当なドライバで問題なく起動するマザーボードもたくさんあります。そのメモリーマップを見てみましょう。以下は、ASUSのZ390マザーボードの例です。（memmapの出力にはAttributesという項目もありますが、長くなるので省略してます。）

Type Start End # Pages 
RT_Data 0000000000000000-0000000000000FFF 0000000000000001
Available 0000000000001000-000000000008FFFF 000000000000008F
RT_Code 0000000000090000-0000000000090FFF 0000000000000001
Available 0000000000091000-000000000009EFFF 000000000000000E
Reserved 000000000009F000-000000000009FFFF 0000000000000001
Available 0000000000100000-000000005315CFFF 000000000005305D
BS_Data 000000005315D000-0000000055101FFF 0000000000001FA5

ここを見ると、カーネルが読み込まれる可能性のある0x100000番地を先頭に、0x5315CFFF番地までが空き地になっていることがわかります。ページ数にして0x5305D番地の空き地です。1.4GBくらい空いているようです。最初に示したエラーメッセージによると、カーネル読み込みに必要なメモリー量は300MB程度らしいのです。なので、これだけ空いていれば、どの番地に読み込んでも順当にメモリー確保できます。おかげで、このマザーボードではメモリーアロケーションのエラーが出たことはありません。

ちなみにこの空き領域の容量は、起動するたびに多少変化することがあるようです。それでも変動は高々100MB程度です。また、iGPU割り当てメモリー量を変更してもほとんど変化しません。ASUSのメモリーマップはmacOSに適しているようです。

失敗するマザーボード

一方、最近のMSIマザーボードでAptioMemoryFix.efiなどを使うと、かなりの確率で起動しません。MSIはZ170チップセットモデルからOsxAptioFix2Drv-free2000.efiが手放せなくなってしまいました。どんなメモリーマップになっているのか見てみます。以下はB350Mマザーボードのメモリーマップです。最近のMSIマザーボードでは、どれもこんな感じのメモリーマップです。

Type Start End # Pages 
BS_Code 0000000000000000-0000000000007FFF 0000000000000008
Available 0000000000008000-000000000005DFFF 0000000000000056
BS_Data 000000000005E000-000000000005EFFF 0000000000000001
Reserved 000000000005F000-000000000005FFFF 0000000000000001
BS_Code 0000000000060000-000000000009FFFF 0000000000000040
Available 0000000000100000-000000000FFFFFFF 000000000000FF00
BS_Code 0000000010000000-000000001000AFFF 000000000000000B
Available 000000001000B000-000000007751AFFF 0000000000067510
BS_Data 000000007751B000-000000007755AFFF 0000000000000040

ASUSとMSIのメモリーマップを比較してみましょう。0x100000番地から先のページ数で示しています。ASUSは0x100000番地から0x53000ページ以上が空き地です。しかしMSIは0x100000番地から0xFF00ページが空き地で、その後0xBページ（10進数で11ページ）が使われていて（小さすぎて図では見えません）、その後、0x67510ページが空いています。

つまり、MSIマザーボードでは、0x100000番地からは、0xFF00ページ、つまり267MB程度のメモリーしか空いていません。その後に、0x10000000番地から、たったの11ページ、バイト数にして45KBだけ、誰かが使っています。BS_Codeというのがそれです。そしてその後、0x1000B000番地から0x7751AFFF番地まで大量に空き地があります。そのため、0x100000番地から300MB程度を確保しようとすると、使用中の45KBが邪魔をして確保できません。これでエラーが出ます。なんでこんな邪魔なところに使用中のメモリーがあるんだ、という気持ちになります。

ただ、何度も何度も起動を試みると、たまに起動することもあります。エラーになるかどうかは、上で説明したKASLRが使用する乱数次第です。0x1000B000より大きい番地からメモリー確保しようとした場合は、エラーは出ず、問題なく起動します。

slideオプションで解決する

slideの仕組み

config.plistなどに書くmacOSの起動オプションの中で、slide=x などと書くと、メモリーを確保する開始番地を指定できます。その規則は次のようになっているそうです。つまり起動オプションにslide=xと書くと、

最近のCPUでは、0x100000 + x * 0x200000が読み込み開始番地になります
ただし、SandyBridgeまたはIvyBridgeの場合は、xが0x00から0x7Fまでは、上記の計算ですが、xが0x80から0xFFまでの場合、0x10300000 + x * 200000になります

となることが知られてます。最近のCPUだけを考えれば、slide値を0x200000倍して0x100000を足すだけなので簡単です。以下ではこの計算が適用できるCPUを前提に説明を進めます。

空き地番地をSlideで指定する

上記のMSIマザーボードの場合、0x1000B000から、使われていないメモリーが大量にあるので、この番地以降を割り当てたいです。ということは、

0x100000 + x * 0x200000 = 0x1000B000
x * 0x200000 = 0x1000B000 - 0x100000 = 0xFF0B000
x = 0xFF0B000 / 0x200000 = 0x7F = 127

という計算になり、slide=127 （もしくはそれ以上の値）とすれば良さそうです。でもこの計算は切り捨てになっているので、実は127ではスライド量が足りません。127 (0x7F) の場合、

0x100000 + 127 * 0x200000 = 0xFF00000

からのメモリー確保がされるので、0x1000b000に引っかかってしまいます。1増やして128 (0x80) にすれば、

0x100000 + 128 * 0x200000 = 0x10100000

になるので、ようやく0x1000B000より大きな番地からの割り当てになります。つまりconfig.plistのBoot, Argumentに、以下のようにslide=128パラメタを追加すれば、このようなメモリー空き地が不連続な問題を回避できます。

<key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>slide=128 (他に必要なパラメータが続く)</string>

KASLRを無効にする

ブートオプションでslide値を指定しても、KASLRが効いているとslide値としては相変わらず乱数（0x00から0xFFまでの乱数）が割り当てられます。ブートオプションのslide値は無視されるようです。slide値を指定すると同時にKASLRを無効にする必要があります。

KASLRを無効にするためには、SIPでCSR_ALLOW_UNRESTRICTED_NVRAMフラグを立てる必要があります。これはNVRAMの変更制限を解除するフラグですが、同時にKASLRも解除されるようです。このフラグは、Appleが公開しているソースコードによると、

#define CSR_ALLOW_UNRESTRICTED_NVRAM	(1 << 6)

だそうです。1を6ビットだけ高位にシフトするという意味で、結果は0x40です。ということで、config.plistのRtVariables, CsrActiveConfigに0x40を書いておきます。

<key>RtVariables</key>
 <dict>
 <key>CsrActiveConfig</key>
 <string>0x40</string>
 </dict>

7ビット目が1ならば他の数字でも良いです。CsrActiveConfigとして、元々0x03という設定をされていたのであれば、0x43にすれば良いです。0x64という設定をしていたなら、これはすでに7ビット目が立っていますから、そのままで良いです。セキュリティをできるだけ確保するという観点からは、0x40が良いと思います。

これでブートオプションで指定したslide値が使用されるようになります。このようなconfig.plist設定で、MSIのマザーボードでもOsxAptioFix2Drv-free2000.efiを使わずに済むようになりました。AptioMemoryFix.efiで動きます。

ただ、CSR_ALLOW_UNRESTRICTED_NVRAMを許可すると、NVRAMの書き換えでSIPのすべての設定が変更可能になるので、セキュリティは脆弱になります。とはいえ、Hackintoshなのでconfig.plist書き換えて再起動すればSIPはどのようにも設定できるので、気にすることではないかもしれないです。さらにはslideパラメータでカーネル読み込みアドレスが固定されるのでKASLRの恩恵もなくなり、それも弱点になります。これに対しては、時々config.plistのslide値を微妙に書き換えて、人力KASLRしても良いかもしれません。

まとめ：マザボ別対処法

KASLRが機能していると、Slide値は0から0xFFまで乱数で設定されます。つまりカーネルが展開される先頭番地は、

0x100000 + 0 * 200000 = 0x100000 = 0番地から1MB程度先の番地

から

0x100000 + 0xFF * 200000 = 0x1FF00000 = 0番地から530MB程度先

になります。ここから、300MB程度の領域にカーネルが展開されるわけです。KASLRがどのようなslide値を指定しても、300MBのカーネルが読み込まれるためには、0x100000番地から900MB程度の空き地が必要ということになります。そこで0x100000番地からの空き地がどれくらいあるかによって次の対処法が考えられます。

なお、空き地容量の数値は、確保されるメモリーが300MB程度と仮定した場合の目安です。環境によってはもっと必要とされるかもしれません。

空き地が900MB以上あるマザボ

何もしなくて良いです。ASUSのマザーボードでは0x100000番地から1.4GBくらいの空き地がありました。なので、KASLRがどのように先頭番地を割り当てても平気です。SIPを弱めてKASLRを無効にする必要もありません。macOSに最適なメモリーマップを持つマザーボードと言えます。

空き地が300MB以下のマザボ

slideで空き地番地を指定します。MSIのマザーボードは、0x100000番地からの空き地が267MB程度しかありませんでした。次にある空き地が十分大きくてKASLRの範囲内にあるので、たまに起動しますが、大抵は起動に失敗します。このようなマザボでは、上記で説明したように、KASLRの範囲内にある300MB以上の空き地をslideで指定します。

空き地が300MB以上900MB未満のマザボ

slide=0にします。コメントで教えていただいたGIGABYTE Z390M GAMINGでは、0x100000番地からの空き地は480MBとのことです。この場合は、小さなslide値だと起動しますが（80以下程度）、KASLRで大きなslide値が指定されると失敗します。そこで、slide=0を指定して0x100000から必ず展開するように指定します。

10.14.6更新に失敗するのでiGPUを一時的に無効にしました

Wed, 24 Jul 2019 20:30:55 +0900

10.14.6が出たのでアップデートしました。いつものように簡単だとたかをくくっていたら、ちょっとつまづきましたので簡単にご報告します。アップデートしたハードウェア構成は、こちらです。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

以前も「グラフィックスカード(RX 580) に切り替わるタイミングで起動が止まる、もしくは止まって再起動する」という現象が発生しました。フォーラムで情報を頂いたように、この場合、BIOS設定でCPU内蔵グラフィックス (iGPU) を無効にすると直るようです。ただしiGPUが動かないとJPEGファイルのクイックルックが効かないので、ブートオプションに以下の記述をして、WhateverGreenに指示する必要があります。

shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94

今回、10.14.6へのアップデート作業の途中で再起動する過程で、この現象が発生しました。そこでBIOSでiGPUを無効にするよう設定したところ、無事にアプデートが完了しました。面白いことにアップデート後は、iGPUを有効にしても問題なくブートしました。なので上記のブートオプションは不要でした。原因はメモリー利用（メモリーマップ）の関係のように思えるのですが、条件によって発生したりしなかったりする微妙な現象のようです。

何れにしても、この問題が発生した時はiGPUを無効にすることで対応できるようです。

そういえばMojaveのインストーラやアップデータが、「インストーラリソースが見つかりません。」というメッセージを出して止まってしまうこともありました。これはインストールに無関係なドライブを一時的に切り離せば対応できました。今回の問題は、一時的なBIOS設定で回避できるので、少しは楽かもしれません。

Mojaveの「インストーラリソースが見つかりません」問題

tonymacx86式インストール手順 (その1: UniBeast)

Sun, 30 Jun 2019 15:33:31 +0900

tonymacx86のツールUniBeastを使って、単体で起動できるmacOSインストーラUSBメモリーを作成する方法を、Hackintosh初心者向けに紹介します。tonymacx86で開発配布されているツールにUniBeastとMultiBeastがあります。どちらもHackintosh初心者によく使われています。そこで、3つの記事で、以下の手順：

その1：UniBeastを使って単体で起動するmacOSインストーラUSBメモリーを作り、これを使ってmacOSをインストールする。
その2：MultiBeastを使ってCloverやkext類をインストールし、macOSを起動できる状態にする。
その3：kextの場所とconfig.plistを修正してバニラ化してチューニングする。

を説明します。この記事は、その1です。その2、その3は以下の記事です。

tonymacx86式インストール手順 (その2: MultiBeast)

tonymacx86式インストール手順 (その3: バニラ化と調整)

UniBeast

UniBeastはtonymacx86.comで作られて配布されているHackintosh作成ツールです。単体で起動するUSBメモリーを作成します。

UniBeastが行うことは、

macOSがMacで起動するUSBメモリーを作成する
これにCloverをインストールする
これに必要なkext類をインストールしてconfig.plistを作成する

という3つの作業です。1番の作業は、通常のMacユーザも行なっている作業です。Appleのサイトにも丁寧な説明があります。

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

2番目の作業は、Cloverを入手すれば、そのインストーラが行ってくれる作業です。インストール時のオプション選択には多少の知識が必要です。3番目の作業はUSBメモリーのESP (EFI System Partition)をマウントして、適切なkextファイル追加し、config.plistを正しく編集する作業です。このように2番目3番目の作業には、ハードウェア構成に関係したいろいろなノウハウが必要です。でも、それを知らなくても無難に起動できるUSBメモリーを作成してくれるところがUniBeastの便利なところです。

作業の準備

まずは、macOSが動いている環境（MacもしくはHackintosh）が必要です。これに、インストールしたいmacOSのインストーラをAppleのサイトからダウンロードしておきます。具体的な方法は上記のアップルのサイトに説明があります。この作業で、アプリケーションフォルダにmacOSインストーラが保存されます。

次に、UniBeastをtonymacx86からダウンロードします。macOSのメジャーバージョン別に用意されています。この記事の時点での最新はMojaveです。

12GB以上（Appleのサイトの情報）の容量のUSBメモリーを用意します。これをGUIDスキームでMac OS 拡張フォーマットでフォーマットします（どちらもディスクユーティリティ.appのデフォルト設定です）。

UniBeastで起動USBメモリーを作成

macOSインストーラがアプリケーションフォルダにあり、フォーマットしたUSBメモリが挿されたmacOSマシンで、UniBeastを起動します。言語が英語になっていないと起動しないので、必要ならばシステム環境設定の「言語と地域」から英語に設定しておきます。

UniBeastを起動して注意事項のページを経ると、USBメモリーを選択する画面になります。ここで、対象のUSBメモリーを選択します。内容はこのあと削除されるので、選択を間違えないでください。

次にmacOSインストールファイルの選択です。AppleのサイトからMojaveをダウンロードするとmacOS Mojaveインストール.appというインストーラプログラムがアプリケーションフォルダに出来上がります。UniBeastはアプリケーションフォルダにあるインストーラを表示しますので、選択します。

次にESPにインストールする (UEIF Boot Mode) か、macOS本体パーティションにインストールする (Legacy Boot Mode) かの選択肢が出ます。Cloverのインストーラを使う場合でもこの選択を問われます。この先、バニラなインストールを目指すので、混乱しないようにここもUEFI Boot Modeを選択しておきます。

次にグラフィックスのオプションを聞かれます。ここに出ているNvidiaとAMDのグラフィックスカードを使用する場合はチェックを入れます。いずれもかなり古いカードですので、チェックを入れる必要のある場合は少ないと思います。

このあと確認のウィンドウが出て、USBメモリー作成作業が始まります。USB 3.1 Gen1接続で3分くらいかかります。完成すると以下のメッセージが表示されます。

BIOSを設定する

macOSをインストールしようとしている対象のマザーボードのBIOS設定を、macOS向けに設定しておきます。最近のマザーボードではほとんどデフォルトで大丈夫ですが、一応チェックしておいてください。

USBメモリーで起動する

このUSBメモリーを、インストール対象のマシンに取り付けて起動します。大抵は、USBからの起動を優先するBIOS設定をしていないと思います。その場合は、起動時にBIOS画面でUSBメモリーを指定する必要があります。

USBメモリーから起動すると、Cloverの起動ドライブ選択画面が出ます。ここで、USBメモリーを選択します。

UniBeastの設定は、かなり汎用的な設定になっているようで、起動する成功率は高いです。今回は、ASUSのZ390マザーボード、Radeon RX580、macOS 10.14.5 Mojaveの組み合わせで実験したところ、とりあえずはインストーラが起動しました。tonymacx86で推奨されているハードウェアならインストーラ起動までは進めるのではないかと思います。

この後、言語を選択して、macOSのインストールを開始します。すると3-5分程度でインストール用イメージが用意され、再起動します。この時もUSBメモリーから起動します。Cloverのブート選択に、「Boot macOS Install from xxxx」という項目が増えているはずです。これを選択します。

この後、もう1回くらい起動します。その時も、Cloverのブート選択に「Boot macOS Install from xxxx」という選択肢があればこれを選択します。インストールが最終段階になると、この選択肢は消えて、「Boot macOS from XXXX」という項目が現れます。これを選択すれば、macOSのアカウント設定などの画面を経て、インストール終了です。

こんな感じでインストールされます。config.plistでiMac14,2と設定されているのでiMac Late 2013になっています。

実は、今回のハードウェア構成で試したところ、以上の手順ではmacOSインストール途中で失敗しました。そこで、次にUniBeastが作るESPの構成と、トラブル対策を紹介します。

UniBeastが作るESP

トラブル対策を説明する前に、まずはUniBeastにより作られるESPの中身を見てみます。多くのハードウェアで機能するためにNullCPUPowerManagementなどの汎用性を高めるkextなどが使われているのかと思ってましたが、使われていませんでした。標準的でシンプルな作りでした。

efiドライバー

drivers64UEFIフォルダには以下のefiドライバが入っています。無くても問題のないドライバも含まれていますが、Cloverのデフォルトに準じた一般的な構成です。必須もしくはあった方が良いドライバは、太字にした5個くらいかと思います。後で説明しますが、今回のマザーボードでは、これらのefiに加えてEmuVariableUefi-64.efiが必須であることがわかりました。

ApfsDriverLoader-64.efi （APFSドライバを取り寄せる）
AptioMemoryFix-64.efi （kernel用メモリを確保）
AudioDxe-64.efi （起動音を出す。あまり必要ではない）
DataHubDxe-64.efi （DataHubプロトコル、すでに機能していれば不要）
FSInject-64.efi （ESPに置いたkextを機能させる）
PartitionDxe-64.efi （特殊なパーティションの対応。なくても良い）
SMCHelper-64.efi （FakeSMCのためにNVRAMのSMCキーを保存）
VBoxHfs-64.efi （HFS+を読むためのドライバ）

kextファイル

kextは全てkexts/Otherに入っています。ESPに全て入れてあるのでバニラな構成と言えます。macOSインストール作業ではLANは必須ではないのですが、Intel, Atheros, Realtek向けのLANのドライバが全部入っています。全てのマザボに対応するためかと思います。最近流行りのVirtualSMC.kextではなく、昔ながらのFakeSMC.kextが使われています。

AtherosE2200Ethernet.kext （LANドライバー）
FakeSMC.kext （SMCをエミュレートする必須kext）
IntelMausiEthernet.kext （LANドライバー）
Lilu.kext （パッチを当てるkext）
RealtekRTL8111.kext （LANドライバー）
WhateverGreen.kext （グラフィックス用パッチ。Liluを使用）

config.plist

以下のようなconfig.plistを作ってくれます。DSDTの設定が長々とありますが、ほとんどがコメントアウトされたりfalseに設定してあり、無効になっています。その後の設定はごく一般的です。Boot Argumentsのnv_disable=1はもはや古いので不要かと思います。その代わりBoot Argumentsに-vオプションを追加しておくと、トラブル特定に役立ったのではと思いました。

config.plist by UniBeast 9.2.0 - Mojave - Pastebin.com

KextToPatchではUSBポートの15個制限を回避するパッチが書いてあります。ただこれはmacOS 10.14.4用のパッチですので、今回使用した10.14.5では使えません。他のバージョンにパッチを試みて不具合が起きないように、MatchOSキーで10.14.4以外では機能しないように設定してあります。USB個数制限を回避するためにパッチを当てる方法は、どのマザーボードでも動くので楽なのですが、macOSバージョンごとにパッチを変更する必要があります。あまりお勧めではありません。詳しくはこちらをご覧ください。

SMBIOSではiMac14,2に設定されています。シリアル番号などは指定されていません。Cloverが適当に設定してくれます。

トラブルとその対策

インストーラUSBメモリが完成したら、インストール先マシンで起動して、macOSをインストールします。その過程で発生しうるトラブルを時系列で解説します。

メモリー確保の失敗

メモリー確保失敗は、Cloverで起動ドライブを選択して起動プロセスが開始した直後に発生します。-vオプションをつけていないと、白いリンゴマークに代わって禁止マークが出ます。-vオプションをつけていれば、kernel読み込みのためのメモリーの確保 (allocation) に失敗したというメッセージが読み取れます。

今回使用したASUSのZ390マザーボードは、AptioMemoryFix-64.efiで、メモリー確保に成功します。GigabyteのZ390もこのefiファイルでOKのようです。MSIとASRockの300シリーズはAptioMemoryFix-64.efiで失敗するという報告が多数あります。メモリー空間を強制的にクリアするので副作用が心配ですが、OsxAptioFix2Drv-free2000.efiを使えば良いようです。詳細は以下をご覧ください。

Cloverインストーラの設定

USB個数制限問題

USB個数制限による失敗はmacOS（ここではmacOSインストーラ）が起動するプロセスの中盤以降で発生します。-vオプションをつけていないと、白いリンゴマークに代わって禁止マークが出ます。-vオプションをつけていると、メッセージが突然停止します。メッセージの表示が崩れることもあります。

macOSにはUSBの個数が15個までの制限がありUSB 2.0が優先されます。また、USBInjectAll.kextが入っていない場合、全てのUSB 2.0が確実に見えるわけでもなく、取りこぼしされることもあります。ということで、USB 3.0 (最近の表記で正しく書くとUSB 3.1 Gen 1) を使用しようとすると、かなりの確率でmacOSからは読めません。USB 2.0でも見えないことがあります。

マザーボードのBIOSが制御している段階では、全てのUSBメモリーが見えています。なので、起動ドライブとして選択できるし、Cloverの起動ドライブ選択画面も出ます。しかし、その後、macOSに制御が移管されるタイミングで運悪く15個の個数制限に引っかかると、起動の途中で突然USBメモリーが認識されなくなってしまいます。当然ながら起動には失敗して、画面に禁止マークが出ます。起動作業の中程で発生します。

USB 3.0のUSBメモリーであっても、USB 2.0用のコネクタに接続するとUSB 2.0として機能します。なので、除外される可能性は低くなります。それでも除外される可能性はあります（今回もそれに遭遇してしまいました）。そのような場合でも、機能している2.0コネクタはどこかに必ずあるので、他のコネクタに挿し直して起動を試みます。

今回入手した最新のUniBeastのconfig.plistには、上で説明したように、10.14.4の個数制限を回避するパッチは書いてありますが、10.14.5には対応していません。10.14.5に対応したパッチに書き換えればこのような苦労はありません。ただ、パッチで対応することはあまりお勧めできません。USB制限問題は、macOSが正しくインストールされた後で、じっくりと対応するのが良いと思います。インストール段階で、機能するUSBポートを探して対処したら良いと思います。

NVRAMの不具合

上の2つの問題は回避できたものの、今回の試みではまだ正しくインストールできませんでした。言語選択の画面

の後、最初の再起動の手前で画面が動かなくなります。調べたところ、efiドライバにEmuVariableUefi-64.efiが足りないのが原因でした。drivers64UEFIフォルダにこれをいれておきます。現行の300シリーズチップセットのマザーボードは、どれもEmuVariableUefi-64が必要のようです。マザーボードには設定内容を記憶するNVRAMがありますが、これがmacOSから読めない場合があります。EmuVariableUefi-64は、NVRAMをエミュレーションして、この問題を解決します。

まとめ

UniBeastですんなりとインストールできれば楽なのですが、実際にはここで説明したような問題がかなりの頻度で発生します。それならば最初から、createinstallmediaで起動USBメモリーを作って、Cloverインストーラでefiを選びつつインストールしても良いように思いました。

macOSがインストールできれば、Hackintoshは7割方完成です。USBメモリーから起動すればmacOSは起動できます。USBメモリーのESPを、macOSをインストールしたドライブのESPにコピーすれば、USBメモリー不要で起動させることもできます。tonymacx86の方法では、この後MultiBeastを使ってインストールを完成させます。その後、それぞれのハードウェアに合わせて、バニラに起動するよう調整するのが良いと思います。続きは以下をご覧ください。

tonymacx86式インストール手順 (その2: MultiBeast)

tonymacx86式インストール手順 (その3: バニラ化と調整)

Catalina Public Betaが配布されました

Tue, 25 Jun 2019 18:45:55 +0900

Public Betaの配布

本日 (2019/6/25) からいよいよPublic Betaが配布され、無料で誰でも試せるようになりました。去年とほぼ同じタイミングです。

macOS Mojave Public Beta版を試す

無料配布のPublic版とは言っても、例年通り緩い守秘義務はあります。「Appleが公表していない情報はPublic Betaプログラム参加者以外に伝えてはいけない」のだそうです。以下の情報は公開済みの内容と思いますが、念のためにベータプログラム参加ページで登録してから読んでください。

Apple Beta Software Program

うっかり読まないように空行を入れておきます🙂

さて、上記のページから登録するとmacOSPublicBetaAccessUtility.dmgというファイルをダウンロードできます。この中に入っている

macOSPublicBetaAccessUtility.pkgを起動すると、ソフトウェアアップデートでPublic Betaが受信できるようになります。

ベータ受信機能は、ウィンドウ左下の「詳細」をクリックすれば、簡単にキャンセルもできますので、気軽に試してみましょう。

インストール方法

ダウンロードしたCatalinaのインストーラ、Install macOS Catalina Beta.app

を開いて、HDD内のHFS+でフォーマットした空きパーティションにインストールしてみました。使ったマシンは、こちらの構成です。Z390、第9世代CPU、Radeon RX580の構成です。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

EFIファイル類は上記のリンク先で紹介したものをそのまま使いました。Mojaveの起動に使用している構成です。ただ、Lilu関係のバージョンチェックを避けるために、念のために

-lilubetaall

を起動オプションに追加しました。これで問題なく起動しました。

（訂正：初稿に書いたリセット問題はCatalinaとは関係なく、BIOSの設定が足りなかったのが原因のようでした。BIOS設定の中で、System Agent (SA)関連のメモリ設定を色々変えていたら治りました。）

コンテナ構成が刷新

Public Betaをインストールしてコンテナ構成が新しくなったことに気づきました。上で書いたように試したボリュームはHFS+の古いタイプのHDDだったのですが、Catalinaのインストールで自動的にAPFSに変換されました。さらに、APFSのコンテナが2個作られました。今回はインストール先をCatalinaという名前にしたのですが、Catalina – Dataというコンテナが新たに作成されました。ディスクユーティリティ.appで見ると以下のようになります。

Catalinaで書き込み不可になったファイルとディレクトリー類が本体のコンテナに、それ以外の内容が – Data が末尾についたコンテナに自動的に振り分けられるようです。

まとめ

インストールは簡単でMojaveと同じ構成で起動可能です。また、サクサク動いて快適です。このままメインで使い続けても問題ないように思いました。

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

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

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

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

新iMac対応Mojaveが公開される

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

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

CPUの名称表示を改善する

10.14.4ではCPUが「不明」

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

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

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

10.14.5ではCPUが「Core i7」

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

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

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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CPU</key>
	<dict>
		<key>Type</key>
		<string>0x01005</string>
	</dict>
</dict>
</plist>

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

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

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

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

Sat, 06 Apr 2019 12:47:04 +0900

（10.14.5が配布されたのでこの情報は不要になりました。）

この記事の執筆時点で配布されているmacOS Mojave 10.14.4はビルド18E226です。しかし最新のiMac Early 2019には18E2034が搭載されています。これが簡単に入手できることがわかりました。

新iMac対応Mojaveが欲しい

第9世代CPU 9900KでHackintoshを作ったら、機種ID、シリアル番号、ボードIDなどのSMBIOS設定も同じCPUを搭載するiMac Early 2019に合わせたいところです。ところがボードIDを27インチiMac Early 2019の値、Mac-AA95B1DDAB278B95に設定するとmacOSが起動しません。

Cloverのブートオプションに-no_compat_checkを追加するだけで簡単に回避できるのですが、できれば対応したmacOS Mojaveが使いたいと考えていました。10.14.5が出るまで待たねばと思っていたところ、コメント欄から、実機に搭載されている10.14.4 (18E2034)が入手できたとの情報をいただきました。試してみました。

iMac19,1の設定でMojaveを入手

入手方法は簡単で、iMac19,1として動いているマシンからApp Storeに接続してMojaveをダウンロードするだけです。

今回使用したマシンは、ASUS MAXIMUS XI HEROに9900Kを搭載したHackintoshです。iMac E2019が店頭に出回る前には、このマシンをMacmini8,1と設定していました。その時に、App StoreからMojaveを入手して、インストールしていました。これをiMac19,1のSMBIOS情報に設定し直した状態の「このMacについて」ウィンドウが以下です。

ビルドは通常配布されている18E226であることがわかります。iMac19,1に設定すると、上で述べたようにそのままでは起動しないので、Cloverのブートオプションに-no_compat_checkを追加して無理やり起動しています。CPUは9900Kなのですが、表示では不明になっています。この状態で、再び10.14.4を入手し直します。まずは、App Storeへ接続し、Mojaveを検索してそのページに移動します。

ここで「入手」をクリックすると、いつものようにソフトウェア・アップデートのウィンドウに移動します。次にダウンロードボタンを押すと、macOS Mojaveインストール.appを入手することができます。

この方法で入手できるインストーラのバージョンは14.4.10です。

これを使ってMojaveをインストールすると、ビルドが18E2034になります。

プロセッサは不明のままです。（途中でメモリを追加したので容量が増えていますが同じマシンの画面です。）

18E2034はEarly 2019限定？

面白いことにiMac19,1（と多分iMac19,2）に設定されていないマシンからApp Storeに行っても、18E2034はダウンロードできないようです。本物のMacでも試みましたがダメでした。その場合、ダウンロードされるインストーラのバージョンは14.4.08になります。これをインストールするといつものビルド番号である18E226になります。

手順のまとめ

以上から、現時点で、9900Kマシンを作って対応したmacOSを入手する手順はこうなると思います。

9900Kマシンを作る
本物のMacでMojave 10.14.4インストーラを入手する。本物はおそらくMacがiMac Early 2019では無いので、18E226になる。
9900Kマシンにインストールする。この時、SMBIOSをiMac19,1に設定しても良いが、ボードIDの関係で起動しないので、ブートオプションに-no_compat_checkを追加しておく。
起動した9900KマシンからApp Storeへ行って、再度10.14.4を入手してインストールする。これでビルドが18E2034になる。

10.14.4で第9世代CPUの互換性が向上

Tue, 26 Mar 2019 17:58:21 +0900

10.14.4へのアップデートが現地時間で昨日公開されました。早速インストールしてみたところ、9900KのiGPUを使うためのconfig.plistの設定が不要になっていました。第9世代CPU搭載のiMacが発売された直後のリリースなのでこれに対応したものと思われます。

10.14.3以前で必要だった設定

9900Kを使うためには、config.plistのDevices, Propertiesの項目にiGPUの設定が必要でした。9900Kにも、MacBook Pro 2018やMac mini 2018のCPUにも、同じIntel UHD グラフィックス630が搭載されています。しかし、デバイスIDが異なっていました。そのため、config.plistに、本物Macに搭載されているiGPUのデバイスIDを書いておく必要がありました。以下のようにです。

<key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>

 <key>device-id</key>
 <data>
 mz4AAA==
 </data>

 </dict>
 </dict>

これを設定すれば完璧に動作しますが、書いておかないと、

スリープが正しく機能しない。（画面は暗くなるもののCPUファン電源が遮断されない。さらには、その後スリープから復帰しない。）
JPEGファイルのクイックルックができない。

などの不具合が発生しました。こちらをご覧ください。

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

10.14.4で互換性が向上

10.14.4にアップデートしたところ、device-idの記述を含めて、Propertiesの記載を全部削除しても、スリープとクイックルックが問題なく動作しました。（10.14.3でPropertiesの記載を削除すると、これらの問題が発生することを確認しています。）。新型iMacが対応したことで第9世代CPUの互換性がさらに向上したものと思われます。これを反映した9900K用のconfig.plistを以下に掲載しておきます。SMBIOSのProductNameはMacmini8,1です。新型iMacの情報が判明したら差し替えたいと思っています。

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

Macシリアル番号の仕組み

Sun, 24 Mar 2019 12:52:47 +0900

Hackintoshを作る時には、機種IDやシリアル番号などのいくつかのIDを決める必要があります。今回はシリアル番号とボードシリアル番号の文字・数値の意味を説明します。以下の、シリアル番号自動生成ツールの資料とソースコードを参考にしました。

GitHub - acidanthera/macserial: Decode mac serial number

Hackintoshに必要な番号

HackintoshがMacとして機能するためには、機種ID、様々なシリアル番号、ファームウェアバージョンなどを決めておく必要があります。これらはconfig.plistのSMBIOSセクションに記述されます。Clover configuratorを使うと、Macの機種を指定するだけでSMBIOSに書くべき内容を自動的に作成してくれます。しかし、最近のバージョンのCloverでは、SMBIOSのほとんどの内容を自動的に設定してくれますので、この機能に任せた方が間違いが無くて良いです。またBIOSバージョンなどの数値は、本来ならばmacOSインストーラがファームウェアアップデートすると更新される数値なので、Cloverが決めてくれる最新値を使う方が良いです。Cloverに任せておけば、間違いのない最新の数値を設定してくれます。

その一方で、手作業で設定した方が良い番号もあります。以下の設定です。

 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>xxxxxxxxxxxxx</string>
 <key>ProductName</key>
 <string>Macmini8,1</string>
 <key>SerialNumber</key>
 <string>xxxxxxxxxxxx</string>
 <key>SmUUID</key>
 <string>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>
 </dict>

ProductNameは、機種IDに相当します。一般には、ハードウェア構成（特にCPUの種類）が一番近いMacの機種IDを設定するのが良いです。SmUUIDは、ターミナルから何度かuuidgenとタイプして得られる32桁の適当な数値を設定しておきます。一部のソフトウェアではインストール台数制限のチェックにも使っているようです。一度決めたら変えない方が良いです。

SerialNumberはMacのシリアル番号です。本物のMacでは筐体に刻印されています。また、BoardSerialNumberはロジックボード（Apple社はマザーボードをロジックボードと呼びます）のシリアル番号です。ロジックボードに刻印されていることがあります。普通にMacを使っている限り、どちらの番号もずっと同じものですが、Macを修理してロジックボードを交換するとBoardSerialNumberは違うものになる可能性があります。

SerialNumberとBoardSerialNumberはとても重要です。これが正しい値に設定されていない場合、iMessageやApp Storeなどが正しく機能しない場合があります。2014年8月から2015年2月にかけて、iMessageでのシリアル番号チェックが非常に厳しくなった時期がありました。これをきっかけにシリアル番号のリバースエンジニアリングが進みました。

シリアル番号

Macのシリアル番号には11桁のものと12桁のものがあります。古い機種は11桁で、最近の機種では12桁です。それぞれの桁は、以下のような意味があります。

| Type | Location | Year | Week | Line | Platform |
| --------- | --------- | ---- | ---- | ---- | -------- |
| Old (11) | LL | Y | WW | SSS | PPP |
| New (12) | LLL | Y | W | SSS | PPPP |

以下では、以下のiMac15,1のシリアル番号の例（12桁）を使って説明します。

C02PJTYNFY10

製造場所番号(2 or 3桁)

最初の3桁 C02は製造国、製造都市、メーカなどを表します。C02は中国のQuantaコンピュータが製造したという意味だそうです。他に判明している3桁コードは以下です。

 - C02, China (Quanta Computer)
 - C07, China (Quanta Computer)
 - C17, China
 - C1M, China
 - C2V, China
 - CK2, Ireland (Cork)
 - D25, Unknown
 - F5K, USA (Flextronics)
 - W80, Unknown
 - W88, Unknown
 - W89, Unknown
 - CMV, Unknown
 - YM0, China (Hon Hai/Foxconn)
 - DGK, Unknown

ちなみに11桁シリアル番号では製造場所コードは2桁です。以下の意味だそうです。

 - CK, Ireland (Cork)
 - CY, Korea
 - FC, USA (Fountain, Colorado)
 - G8, USA
 - QP, USA
 - XA, USA (ElkGrove/Sacramento, California)
 - XB, USA (ElkGrove/Sacramento, California)
 - PT, Korea
 - QT, Taiwan (Quanta Computer)
 - UV, Taiwan
 - RN, Mexico
 - RM, Refurbished Model
 - SG, Singapore
 - W8, China (Shanghai)
 - YM, China
 - H0, Unknown
 - C0, China (Quanta Computer, Tech-Com)
 - C3, China (Shenzhen, Foxconn)
 - C7, China (Shanghai, Pegatron)
 - MB, Malaysia
 - EE, Taiwan
 - VM, Czech Republic (Pardubice, Foxconn)
 - 1C, China
 - 4H, China
 - MQ, China
 - WQ, China
 - 7J, China (Hon Hai/Foxconn)
 - FK, China (Zhengzhou, Foxconn)
 - F1, China (Zhengzhou, Foxconn)
 - F2, China (Zhengzhou, Foxconn)
 - F7, China
 - DL, China (Foxconn)
 - DM, China (Foxconn)
 - 73, Unknown

RMは整備品であることを表しています。

製造年(1桁)

例に示したシリアル番号の、次の一桁であるPは製造年を表します。12桁のシリアル番号では各年号に英字が割り当てられています。ペアの最初の英字が1-6月で、後半が7-12月を表しているそうです。なので、Pは2015年前半を表します。アルファベットのうち英字のI, Oなどが抜けているのは1や0と間違えやすいからだと思われます。他の欠番も何か理由があってのことと思います。

| Pair | Year |
| -------- | ---- |
| `C`, `D` | 2010 |
| `F`, `G` | 2011 |
| `H`, `J` | 2012 |
| `K`, `L` | 2013 |
| `M`, `N` | 2014 |
| `P`, `Q` | 2015 |
| `R`, `S` | 2016 |
| `T`, `V` | 2017 |
| `W`, `X` | 2018 |
| `Y`, `Z` | 2019 |

追記 : 上記の方式では2020にコードを使い切ることになります。実際にどうなったかというと、iMacの2020年モデルでは、こちらで紹介したように、CとDが使われています。2010のコードを再利用しているようです。(2020/8/14)

11桁シリアル番号では、製造年は西暦一桁めの数値です。

| Char | Year |
| ---- | ---- |
| `3` | 2003 |
| `4` | 2004 |
| `5` | 2005 |
| `6` | 2006 |
| `7` | 2007 |
| `8` | 2008 |
| `9` | 2009 |
| `0` | 2010 |
| `1` | 2011 |
| `2` | 2012 |

こちらは2012年に一巡して破綻してます。現行のシリアル番号も2020年以降の年番号がどうなるのか心配です。

製造週(2 or 1桁)

例に示したシリアル番号の、次の一桁であるJは製造週を表します。これは1月1日から始まる7日を最初の週としています。なので最後の週以外は全て7日間です。次の27種類の英数字が使われます。シリアル番号の例では、2015年の前半年とわかりましたので、Jは15週目を表しています。

| Char | 1st half | 2nd half |
| ---- | -------- | -------- |
| `1` | `1` | `27` |
| `2` | `2` | `28` |
| `3` | `3` | `29` |
| `4` | `4` | `30` |
| `5` | `5` | `31` |
| `6` | `6` | `32` |
| `7` | `7` | `33` |
| `8` | `8` | `34` |
| `9` | `9` | `35` |
| `C` | `10` | `36` |
| `D` | `11` | `37` |
| `F` | `12` | `38` |
| `G` | `13` | `39` |
| `H` | `14` | `40` |
| `J` | `15` | `41` |
| `K` | `16` | `42` |
| `L` | `17` | `43` |
| `M` | `18` | `44` |
| `N` | `19` | `45` |
| `P` | `20` | `46` |
| `Q` | `21` | `47` |
| `R` | `22` | `48` |
| `T` | `23` | `49` |
| `V` | `24` | `50` |
| `W` | `25` | `51` |
| `X` | `26` | `52` |
| `Y` | `-` | `53` |

11桁のシリアル番号では週は2桁で表記されて、週の数値がそのまま、00から53までの数値で表現されます。

製造ライン(3桁)

例に示したシリアル番号の、次の3桁であるTYNは製造ラインもしくは、組み立て担当者のIDを表していると考えられています。それぞれの桁は、IとOを除く0からZまでの英数字を0から33に割り当てた数値を表しています。この3桁は、製品個体ごとに違い、一台一台を特定する部分です。

| Char | Value | Char | Value |
| ---- | ----- | ---- | ----- |
| `0` | `0` | `H` | `17` |
| `1` | `1` | `J` | `18` |
| `2` | `2` | `K` | `19` |
| `3` | `3` | `L` | `20` |
| `4` | `4` | `M` | `21` |
| `5` | `5` | `N` | `22` |
| `6` | `6` | `P` | `23` |
| `7` | `7` | `Q` | `24` |
| `8` | `8` | `R` | `25` |
| `9` | `9` | `S` | `26` |
| `A` | `10` | `T` | `27` |
| `B` | `11` | `U` | `28` |
| `C` | `12` | `V` | `29` |
| `D` | `13` | `W` | `30` |
| `E` | `14` | `X` | `31` |
| `F` | `15` | `Y` | `32` |
| `G` | `16` | `Z` | `33` |

この3桁の値は次の式でIDに変換されているようです。

1桁目 x 68 + 2桁目 x 34 + 3桁目

この例のTYNは、それぞれ27, 32, 22を表し、上の式から2,946になります。

27 x 68 + 32 x 34 + 22 = 2,946

製造コピー

上の計算式はちょっと変わっています。34進数だと考えたら最初の桁は34×34倍すべきなのですが、68倍になっています。何か根拠のある計算式ではあると思われますが、この計算では、得られる数値に重複が発生します。

例えば、 0L0, 1J0, 2G0, 3E0, …, 920という複数の英数字が、どれも680という製造ライン番号になります。別の例では、KYL, LWL, MUL, …, Z4Lという英数字は、どれも2400という数字になります。同じ数値になってしまう英数字の組を、製造コピーと呼んでいます。最初の桁の値の小さい方から1, 2, 3,…と番号をつけます。この例では、0L0やKYLがコピー1、1J0やLWLがコピー2などです。920と74Lは、最後のコピーです。英数字の組み合わせによりコピーの総数は変わります。色々な実験で、最初のいくつかのコピーだけが、Appleから有効だと判定されるようです。無効だと判定されたコピー番号より大きな番号のコピーは全て無効になります。Apple内部のことはもちろんわかりませんが、一つのラインから製品が製造されるごとに、コピー値が増加するのではないかと推定されています。何れにしても、ある値を示す製造ライン番号のうち、最初のコピーを使用するのが安全であると言えます。

プラットホームモデル(3 or 4桁)

11桁シリアルでは最後の3桁、12桁シリアルでは最後の4桁が、製品種類を表す番号です。例に示したシリアル番号では、最後の4桁であるFY10がこのプラットホームモデルです。この4桁が製品機種を表していることは、以下のURLにアクセスすることで確認できます。

http://support-sp.apple.com/sp/index?page=cpuspec&cc=PPPP

ここのPPPPの部分にFY10を入れてアクセスすると

http://support-sp.apple.com/sp/index?page=cpuspec&cc=FY10

iMac15,1の仕様書ページにリダイレクトされます。iMac15,1にはLate 2014とMid 2015の2機種がありますが、このモデルはMid 2015年のiMacであることがわかります。

ちなみに一つの機種ID（例えばiMac15,1）が全て同じプラットホームモデル（ここではFY10）になるわけではありません。同じ機種IDでも製造時期が違うと仕様が異なります。それで複数のプラットフォームモデルが割り当てられています。例えば、iMac15,1に相当するプラットホームモデルは、以下の27種類が確認されています。

"FY10", "FY11", "FY14", "FY68", "FY6F", "GCTM", "GDQY", "GDR3", "GDR4", "GDR5", "GDR6", "GDR7", "GDR8", "GDR9", "GDRC", "GFFQ", "GJDM", "GJDN", "GJDP", "GJDQ", "FY13", "FY6D", "GL1Q", "GL1R", "GL1T", "GL1V", "GL1W"

シリアル番号の注意事項

シリアル番号は上記のフォーマットに従って、適切な値が入っている必要があります。そうしないと、iMessageへのアクセスなどでAppleから無効なモデルと判定される可能性があります。

また、細かい整合性もチェックしておいた方が良いと思われます。例えば、製造年、製造週は、プラットホームモデルが示す発売日より後の日付である方が良いでしょう。また、製造ラインのコピー数は、できるだけ小さい値、できればコピー1である方が安全です。

上の例で示したC02PJTYNFY10は、

Country: C02 - China (Quanta Computer)
Year: P - 2015 (前半)
Week: J - 15 (2015年4月9日-2015年4月15日)
Line: TYN - 2946 (copy 1)
Model: FY10 - iMac15,1 Retina 5K, 27 inch, Mid 2015, 2015年5月発売

となります。製造日が発売日より早いのが気になりますが、発売日に備えて前もって製造しているはずなので、それほど不自然ではないと思います。

また、下記のサイトで生成したシリアル番号が未使用であることは、確認しておくべきかと思います。「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。

ボードシリアル番号

SMBIOSでもう一つ設定しないといけない番号がボードシリアル番号です。12桁シリアル番号の場合、ボードシリアル番号は17桁です。ロジックボードのシリアル番号です。修理によってロジックボードは交換される可能性があることもあり、Appleはそれほど厳密にはチェックしていないと感じています。昔のガイドでは、12桁のシリアル番号に適当な英数字を5個足しておけば良いとか、LANのMACアドレスの一部を足しておけば良いなどというゆるい手法が説明されていることもあります。

Clover configuratorなどに搭載されている最近のシリアル番号発生機能では、シリアル番号と対になってボードシリアル番号も作り出してくれます。それを採用しておけば良いです。例えば、先の例で使用したシリアル番号C02PJTYNFY10と対で生成されたボードシリアル番号は

C02514701CDG2Y71H

でした。これを例に構成を調べていきます。

製造場所番号(3桁)

シリアル番号と同じで、最初の3桁は製造国、製造都市、メーカなどを表します。この例のC02は中国のQuantaコンピュータです。

製造年(1桁)

4桁目は年号です。西暦年号の1の位です。この例では、シリアル番号が2015年なので、それに合わせて5になっているようです。

製造週(2桁)

次の2桁は製造週です。上の例では、14週目の製造という意味です。シリアル番号は15週目でした。ロジックボードが製造されたあとで、本体が製造されるのが自然ですから、前の週に製造されたことにしているのだと思います。

MLBBlock1(3桁)

以下のいずれか一つの数値です。Clover configuratorやmacserialが自動生成する場合には、この中から乱数で選んでいるようです。

"200", "600", "403", "404", "405", "303", "108", "207", "609", "501", "306", "102", "701", "301", "501", "101", "300", "130", "100", "270", "310", "902", "104", "401", "902", "500", "700", "802"

MLBBlock2(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"GU", "4N", "J9", "QX", "OP", "CD", "GU"

ボードコード(3 or 4桁)

ロジックボードの種類を示す英数字です。一つのモデルに対して多数のコードが発見されているようです。例えば、上の例のiMac15,1では、以下のコードが使われているようです。このリストのうち、最初のコードG2Y7が、問題が少ないとされているので、これが使われることが多いようです。

"G2Y7", "G2Y8", "GG3L", "GG3N", "G2QD", "G2QF", "GG3T", "GG3W", "FT04", "FW6K", "GG3K", "GG3M", "FW29", "FW2C", "GG3Q", "GG3V", "FQY8", "FTPF"

MLBBlock3(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"1H", "1M", "AD", "1F", "A8", "UE", "JA", "JC", "8C", "CB", "FB"

ボードシリアル番号の注意事項

上記で、「自動生成する場合には乱数で選んでいる」と書きましたが、生成プログラムのソースを見ると、チェックサムも考慮しています。ボードシリアル番号が表す値を、最初から奇数番目の桁はそのまま、偶数番目の桁は3倍して足していき、その合計が34の倍数である場合は正しいチェックサムを持ったボードシリアル番号としているようです。正しいチェックサムになるまで、ランダムに候補を選んでいるようです。手作業では面倒なので、自動生成ツールを使うのが良いです。

機種のシリアル番号に比べて、ボードシリアル番号はAppleにより厳しく検査されることはないので割と適当でも大丈夫な印象があります。シリアル番号の製造週より前の製造週にしておいた方が良いでしょう。自動生成ツールでは、シリアル番号の前の週になるように生成しているようです。ただ、ロジックボード交換修理する可能性も考えると、それもチェックされていないと思います。何れにしても、以下の自動生成ツールを使えば、整合性のある番号を生成してくれますので問題ありません。

シリアル番号自動生成ツール

シリアル番号はClover configuratorでも生成できますし、この記事の冒頭で示したmacserialというツールでも生成できます。おそらくはClover configuratorもmacserialと同じアルゴリズムを使っているのではないかと思います。macserialは、冒頭のリンクからソースコードを入手してコンパイルしても良いです。また以下のサイトで、コンパイル済みのコードも配布されています。

Releases · acidanthera/macserial

更新：現在は以下で配布されているようです (2019/12/28)。

Releases · acidanthera/MacInfoPkg

更新2 : 現在はOpenCoreに含まれています (2020/8/14)。

GitHub - acidanthera/OpenCorePkg: OpenCore bootloader

現時点では2.0.4が最新のようです。mac版とwindows 32版があるようです。zipをダウンロードすると解凍されてmacserialというファイルができます。

$ ./macserial

として起動すると、現在のMac/Hackintoshのシリアル番号などの情報が表示されます。–helpとすれば使い方の説明が表示されます。

$ ./macserial --help
./macserial arguments:
 --help (-h) show this help
 --version (-v) show program version
 --deriv <serial> (-d) generate all derivative serials
 --generate (-g) generate serial for current model
 --generate-all (-a) generate serial for all models
 --info <serial> (-i) decode serial information
 --list (-l) list known mac models
 --mlb <serial> generate MLB based on serial
 --sys (-s) get system info

Tuning options:
 --model <model> (-m) mac model used for generation
 --num <num> (-n) number of generated pairs
 --year <year> (-y) year used for generation
 --week <week> (-w) week used for generation
 --country <loc> (-c) country location used for generation
 --copy <copy> (-o) production copy index
 --line <line> (-e) production line
 --platform <ppp> (-p) platform code used for generation

–generateオプションで現在モデルのシリアル番号とボードシリアル番号を複数生成してくれます。–generate-allで全てのモデルの番号を生成します。–model Macmini8,1などとすれば特定のモデルの番号を生成してくれます。–info シリアル番号でそのシリアル番号を分析してくれます。例えば、この記事で例に使ったC02PJTYNFY10でしたら、

$ ./macserial --info C02PJTYNFY10
 Country: C02 - China (Quanta Computer)
 Year: P - 2015
 Week: J - 15 (09.04.2015-15.04.2015)
 Line: TYN - 2946 (copy 1)
 Model: FY10 - iMac15,1
 Valid: Possibly

のように表示されます。

古いmacOSをコレクションする

Mon, 11 Feb 2019 12:54:54 +0900

過去の特定のバージョンのmacOSが必要になることが稀にあります。でも古いバージョンのmacOSは入手困難です。アップルから正規に入手できる時期に忘れずにダウンロードして確保しておきましょう。
（更新：CatalinaとBig Surの情報を追記しました。2021/10/29）

古いmacOSが必要になる時

OSの更新で使えなくなったハードウェアでマシンを組もうと思う時、古いOSが必要です。例えば10.14 MojaveからIntel HD Graphics 3000のドライバが削除されてしまったので、Sandy Bridgeの内蔵GPUは動かなくなってしまいました。そこで10.12 SierraからIntel HD Graphics 3000のドライバを持ってくると動きました。10.13 High Sierraのドライバでは動きませんでした。2世代前のmacOSをたまたま持っている人だけが対応できる方法です。

また、最初のiMac Proには10.13.2が搭載されていましたが、この時に10 GbpsのEthernetがmacOSで動くようになりました。搭載されているのは、一般的に使われているAquantia AQC107というチップです。ただし拡張カードのファームウェアが違うのでそのままでは動きません。10.13.3になった時に、なぜかmacOS対応のファームウェアが含まれていて、10 Gbpsカードを挿したままアップデートするとファームウェアが書き換えられてmacOSで動くと報告されています。10.13.2以下のHigh Sierraをたまたま持っている人だけが対応できる方法です。

以上はかなりニッチな事例です。しかしMojaveでNVIDIAのドライバが動かなくなったので、いまだにHigh Sierraなどの古いmacOSが必要になる場面は多いかと思います。

古いmacOSの入手方法

App Storeアプリから入手する

App Storeから一旦購入したアプリケーションは、いつでも入手可能なところがApp Storeの優れた点です。この原則はmacOSでも有効で、一旦ダウンロードした古いmacOSは「購入済み」ボタンを押すとApp Storeの画面に現れました。

でもMojaveになって、これが出来なくなりました。Mojaveからは、左下の名前をクリックすると現れる「アカウント」のページに、購入済みのアプリケーションが現れるようになりました。ただmacOSは現れません。私の場合は、なぜか古いmacOSのPublic BetaやGM Candidateが表示されます。昔購入したServer版も現れます。でもmacOSは現れません。現行のMojaveだけは、検索窓からMojaveを検索すると現れます。

ということでまだMojaveに移行していないみなさんは、High Sierra以前で稼働しているうちに、昔に購入したmacOSをダウンロードしておきましょう。

プロダクトIDを手掛かりに入手する

App Storeで配布されているソフトウェアは、プロダクトIDという一意の番号で管理されています。これを知っていればMojaveで選択肢に現れない古いmacOSをダウンロードできる可能性があります。

こちらのサイト

OS X 10.7 Lion ~ macOS 10.13 High Sierraまでのインストーラーアプリをダウンロ…

ではいくつかのmacOSのプロダクトIDを紹介してくれています。それによると、

OS X 10.7 Lion 444303913
OS X 10.8 Mountain Lion 537386512
OS X 10.9 Mavericks 675248567
OS X 10.10 Yosemite 915041082
OS X 10.11 El Capitan 1018109117または 1147835434
macOS 10.12 Sierra 1127487414
macOS 10.13 High Sierra 1246284741
macOS 10.14 Mojave 1398502828
macOS 10.15 Catalina 1466841314
macOS 11 Big Sur 1526878132

だそうです。この番号を使って、

https://itunes.apple.com/jp/app/idプロダクトID?mt=12

にアクセスすると古いmacOSのApp Storeアプリ画面が開きます。ただ、現時点で試したところではYosemite以前はこんなダイアログが出て利用できないようです。

この方法でダウンロードできるのは以下のバージョンでした。

El Capitan https://itunes.apple.com/jp/app/id1147835434?mt=12
Sierra https://itunes.apple.com/jp/app/id1127487414?mt=12
High Sierra https://itunes.apple.com/jp/app/id1246284741?mt=12
Mojave https://itunes.apple.com/jp/app/id1398502828?mt=12
Catalina https://itunes.apple.com/jp/app/id1466841314?mt=12
Big Sur https://apps.apple.com/jp/app/macos-big-sur/id1526878132?mt=12

masコマンドを使う

上記のサイトではHomebrewで導入できるmasコマンドを紹介してくれています。コマンドラインからMacのApp Storeにアクセスするためのアプリケーションです。ターミナルで以下のようにすれば、Homebrewをインストールして、次にmasをインストールできます。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install mas

単にmasとだけタイプすると

mas
Available commands:

account Prints the primary account Apple ID
help Display general or command-specific help
home Opens MAS Preview app page in a browser
info Display app information from the Mac App Store
install Install from the Mac App Store
list Lists apps from the Mac App Store which are currently installed
lucky Install the first result from the Mac App Store
open Opens app page in AppStore.app
outdated Lists pending updates from the Mac App Store
reset Resets the Mac App Store
search Search for apps from the Mac App Store
signin Sign in to the Mac App Store
signout Sign out of the Mac App Store
uninstall Uninstall app installed from the Mac App Store
upgrade Upgrade outdated apps from the Mac App Store
vendor Opens vendor's app page in a browser
version Print version number

とヘルプが出ます。

mas intall プロダクトID

とすればダウンロードできるようです。info, searchなどはあまり効きません。それに出てこなくてもinstallコマンドは動くことがあるようです。

mas install 444303913

でプロダクトIDが分かっているうちの一番古いLionをダウンロードしてみました。

App Storeアプリからダウンロードする方法も、masコマンドも、どちらも購入したことのあるmacOSしか再入手できません。一旦はダウンロードしておく必要があります。

マイナーバージョンを入手する

今までの方法で、運が良ければ古いmacOSを入手できます。でも入手できるのは、それぞれのメジャーバージョン（MojaveとかHigh Sierraなどのバージョン）の最終版です。例えばHigh Sierraなら10.13.6が入手できます。では10.13.3が必要な場合はどうしたら入手できるでしょうか？

アップル社は統合アップデート(combo update)を長期にわたって配布してくれています。統合アップデートなら同じメジャーバージョンのすべての古いバージョンからアップデートできます。統合アップデートは、サポートページで検索したり、

[Apple - Support - Downloads](https://support.apple.com/downloads/combo update)

Googleの検索で「macOS 10.13.3 combo update」などと検索すると出てきます。私が探せた一番古いcombo updateは10.2.4でした。

OSメーカとしては、少しでも新しいバージョンにアップデートして欲しいので、全てのマイナーバージョンへのアップデートを配布し続けてくれているのだと思います。なのでできるだけ最初のマイナーバージョンを持っていれば、多くのマイナーバージョンへアップデートできます。例えば、10.13.0を持っていれば、10.13.1から10.13.6のすべてにアップデートできます。10.13.0は1ヶ月少しだけ配布されていました。今では入手できない貴重なバージョンですので、大事に保存しておきましょう。

LionとMountain Lionが無償配布

（追記：2021/7/18）Appleの公式サポートページから、LionとMountain Lionが無料でダウンロードできるようになったようです。以下です。

Mac OS X Lion Installer

Mac OS X Mountain Lion Installer

まとめ

古いmacOSを入手可能にしておくためには以下のことが重要です。

どのメジャーバージョンのmacOSも一度はダウンロードしておくと良いです。例えば、Mojaveは嫌いだからといって次のバージョンが出るまでダウンロードせず放置していると、正規に入手するチャンスを逃してしまいます。
古いmacOSがApp Storeで入手できることをあてにしてはいけないです。いつダウンロードできなくなるかわかりません。手元にコピーを置いておくべきです。
できるだけ最初のマイナーバージョンを持っておくと良いです。全部のマイナーバージョンのコピーを集めておくのは面倒ですし、ストレージの場所も必要です。10.xx.0を持っていれば統合アップデートでどのバージョンにもアップデートできます。実用上は一番安定と思われる最終バージョンも持っていると良いと思います。High Sierraなら10.13.0と10.13.6を持っていれば完璧なコレクションになります。

kextはどこに置けば良いのか

Sat, 02 Feb 2019 22:17:14 +0900

今までkextファイルはEFI/Clover/kexts/Otherに置くと良いと紹介してきました。でも以下の投稿によるとそれは「全く正しくない」のだそうです。

今回はHackintoshに必要なカーネル拡張ファイル（kextファイル）を置く場所に関する議論を紹介します。（コメントで紹介いただいた情報です。ありがとうございます。）

kextを/L/Eに置く利点と方法

上記の投稿にはkextを/L/Eに置くべきである理由と、推奨するkextの置き方が書かれています。抄訳します：

macOSの流儀である

FakeSMCなどを含むすべての3rdパーティkextは/Library/Extensions (以下/L/E) に置くべきです。多くの人が「これらのkextをEFI/Clover/kexts/Other (以下ESP) に置き、config.plistでInject KextsをYESにすることが、メンテナンスフリーであり、よりネイティブなmacOSインストール方法だ」という印象を持っているように思えます。しかしこの考えは完全に間違っています。

この俗説とは逆に、Cloverに3rdパーティkextをインジェクトしてもらうことは、クリーンなインストールにはならないどころか、その逆です。インジェクトされたkextはmacOSの保護メモリー空間の外側で機能します。大量のkextをインジェクトすると、システムが不安定になる可能性があります。Cloverによってインジェクトされる多くの3rdパーティkextは正しく動きません。インジェクトされたkextはカーネルキャッシュに含まれず、その結果macOSが行うエラー検査の対象外になります。kextを/L/Eに置くことは、アップルが推奨しています。何らかの周辺機器を買ってドライバをインストールする時、kextは/L/Eにインストールされます。Hackintoshのkextも同じです。

Cloverのkext読み込み機能の目的

/L/Eに追加のkextを置くのが正しいやり方なのだとしたら、なぜCloverはESPに置いたkextをインジェクトする機能を持っているのでしょうか？それは、次のような形式のmacOS、つまり

MacOS Installer
MacOS Updater
MacOS Recovery

をブートする場合に、最小限必要なkextを読み込むために必要だからです。これらはどれもフルサイズのmacOSではないため、通常の方法では必須kextを読み込めないので、Cloverがそれを行う必要があるのです。ほとんどの場合、これらのパッケージを機能させるためには、通常はEFI/Clover/kexts/Other に FakeSMC があれば良いです。場合によっては3rdパーティのストレージ制御用ドライバ、NASで動かすTimeMachineバックアップへのアクセス用ドライバ、ノートPCのマウス用ドライバなどが必要なこともあります。このような、本当に必要なkextだけをEFI/Clover/kexts/Otherに入れます。

CloverのDetect設定

Hackintoshに必要なkext類を、

通常のmacOSブート時は、/L/Eにkextを置いてmacOSでロードしつつ、
Installer/Updater/Recoveryの時だけESPに置いてCloverでインジェクトする

ように設定するには以下のようにします。

Cloverのconfig.plistのSystem Parameters セクションでは、Inject Kextsの設定ができます。ここでは、Cloverがkextをインジェクトしてくれるよう、通常はYESを設定します。

<key>InjectKexts</key>
<string>YES</string>

これをDetectに設定すると、

<key>InjectKexts</key>
<string>Detect</string>

Cloverは/L/Eにあるkextを調べて、

FakeSMCが/L/EにあればCloverはkextをインジェクトしない
FakeSMCが/L/Eに無ければCloverはkextをインジェクトする

という動作をします。なので、macOSの/L/Eと、CloverのEFI/Clover/kexts/Otherの両方にkext類を入れておけば、フルサイズのmacOSを起動するときは/L/Eのkextを、Installer/Updater/Recoveryの時はCloverがインジェクトするkextを使えることになります。

抄訳はここまでです。

/L/Eにkextを入れる方法

今まではバニラな方法しか説明していませんでした。/L/Eにkextを入れるとするといくつかの手順が必要です。

まずはHackintosh用のkext類は、当然ながらアップル社の承認を受けていませんので、「署名されていないkextも動く」設定にSIP (System Integrity Protection)を設定する必要があります。これにはconfig.plistで

<key>CsrActiveConfig</key>
<string>0x01</string>

と設定します。また、/L/Eに必要なkextをコピーした後で、パーミッションを設定して、キャッシュを作り直す必要があります。ターミナルから行うには、

sudo cp -R *.kext /Library/Extensions/.
sudo chown -R 0:0 /Library/Extensions/*.kext
sudo kextcache -i /

などとします。*.kextの部分は、追加するkextだけ指定すれば良いです。これで再起動するとキャッシュが再構成されます。

kextをESPに置く利点と欠点

以上で、/L/Eにkextを置く方法が良いという意見とその実際を紹介しました。kextをESPに置くバニラな方法と比較して、長所短所を検討してみます。

macOSの流儀からは外れる

macOSの設計では追加のkextは/L/Eに置くべきのようです。Cloverがインジェクトする方法では、メモリー不足になる可能性があるようです。ただ、そのような報告はあまり聞いたことがないので、実際には支障はないのかもしれません。

また、/L/Eに置くと、キャッシュに入れる際にkextのエラーチェックをしてくれるそうです。ただこれも、kext開発者でなければあまり恩恵の無い機能のように思います。ちなみに、/L/Eに置くと、そのkextがシステム情報–>ソフトウェア–>拡張機能に現れます。これを使って得られる情報がトラブル対応の参考になるかもしれません。

ESPでは動かないkextもある

一部の kextはESPでは正しく動きません。これらは/L/Eに置かざるを得ません。ただ、そのようなkextは少数で、大体はESPで動きます。

SIPを有効にできる

もともとHackintoshのkextは、macOSの規格外の拡張です。なので署名が無く、/L/Eで有効にするにはSIPで署名の無いkextを許可する設定が必要です。せっかくのSIPの仕組みなので、マルウェア対策としてSIPは有効のまま使いたい気がします。もちろんESPにkextを置くことも同様に危険なことですが、Hackintoshを狙ったマルウェアは少なそうですし、署名のあるkextと、署名の無いkextを、/L/EとESPに分けて管理するのは、セキュリティ対策として有効です。/L/EにHackintoshのkextを入れると、混在してしまいます。

ESPに置くと管理が楽

/L/Eに置くと、パーミッションを設定し、キャッシュを作り直す手間がかかります。ESPへ置くのはコピーするだけなので簡単です。また、上記で説明したInject KextsをDetectにする手法では、/L/EとESPの両方にkextを置かないといけません。この方式ではkextの入れ替えや、アップデートの手間が倍以上になります。/L/Eにkextを簡単に置くためのツールもありますが、手間が増えることには変わりありません。

以上のことを考えると、このままバニラな方法（ESPに置く方法）を続けても良いように思いました。

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

Sun, 07 Oct 2018 15:55:55 +0900

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

というダイアログパネルが先週唐突に現れました。Mojaveにアップデートしてからだいたい1週間目のことです。正確には604,800秒後のことです。

Appleのサポートに公式の説明があります。

support.apple.com

このメッセージは、Mac に実際にインストールされているファームウェアと、macOS で必要とされるファームウェアとの間に違いが認められた場合に表示されます。

（略）
macOS High Sierra 10.13 から、Mac はファームウェアが変更されていないか定期的にチェックし、そうした変更点について Apple に情報を送信できるようになりました。

そういえば1年以上前、High Sierraのベータ版が出た頃にこの新機能が話題になっていました。このチェックを定期的に行なっているのはeficheckというプログラムです。本体は、

/usr/libexec/firmwarecheckers/eficheck/eficheck

にあります。

MacのEFIファームウェアのチェックサムを、Apple社の何処かにあるデータベースと比較して、違っている場合には安定性やセキュリティに問題があると判断して、警告を出してくれるプログラムだそうです。Hackintoshの場合は、当然のことながらEFIファームウェアは本物のMacと違うので、警告出まくりになるだろうと、当時は話題になっていました。でも一度も警告は出たことがなく、すっかり忘れていました。ネットで調べても、警告が出たという報告はすごく少ないです。私も初めてです。なんで出たのか不明ですが、Mojaveにアップデートしたことと関係がありそうです。

eficheckの動く仕組み

eficheckはコンピュータに常駐して動き続けるデーモンと呼ばれるタイプのプログラムです。macOSではデーモンの起動と設定を、

/System/Library/LaunchDaemons/

ディレクトリで行います。この中に一つのデーモンを設定する.plistファイルを置くと、Macの起動時に動くようになります。今回のeficheckを設定しているのは、

/System/Library/LaunchDaemons/com.apple.driver.eficheck.plist

というファイルです。書き換えて遊んでみましょう。

ただ、SIPを有効にしている場合、/System以下のファイルはSIPで保護されています。sudoコマンドでも書き換えることができません。その場合は、SIPを無効にしてから作業します。書き換え作業した後はSIPを有効に戻しても大丈夫です。

/posts/132/

com.apple.driver.eficheck.plistの中身を見てみましょう。以下は抜粋です。

<key>ProgramArguments</key>
<array>
<string>/usr/libexec/firmwarecheckers/eficheck/eficheck</string>
<string>--integrity-check-daemon</string>
</array>

略

<key>com.apple.driver.eficheck</key>
<dict>
<key>Interval</key>
<integer>604800</integer>
</dict>

最初の方に、eficheckへのフルパスと、起動の引数が書かれています。真ん中あたりに、間隔が604,800と書かれています。単位は秒です。割り算してみると、ちょうど7日間になります。つまり、1週間ごとにEFIが正しいものであるかどうかをチェックして、警告を出してくれるようです。

1週間待って次の警告が出るかどうか確認するのは大変でしたので、

<key>com.apple.driver.eficheck</key>
<dict>
<key>Interval</key>
<integer>180</integer>
</dict>

と書き換えて再起動してみました。3分くらいで警告が出ました。やはりこのまま毎週警告が出てしまうようです。

eficheckを止める

なんにせよ厄介なので、起動しないようにしてみました。

cd /System/Library/LaunchDaemons/
sudo mv com.apple.driver.eficheck.plist com.apple.driver.eficheck.plist.org

としました。オリジナルというつもりでorgという拡張子に変更しましたが、oldでもbackupでもなんでも好きな名前で良いです。いずれにせよ、plistという拡張子ではなくなったので、多分大丈夫なはずです。結果は来週以降報告します。 plistという拡張子ではなくなったことで起動しなくなります。１週間後、２週間後にも起動しませんでした。

EFICheckDisabler.kextを使う

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

www.insanelymac.com

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

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

原因は不明ですが、このエラーメッセージが一向に出ないマシンもあります。何が違うのかよくわからないのですが（ご存知でしたらコメントでお知らせください）、メッセージが出ないなら、上記の対応をしなくても良いと思います。

追記：いつからかこの問題は発生しなくなりました。少なくともCatalinaでは経験していません。なので古い情報です。(2020/3)

Mojaveにアップデート

Sat, 29 Sep 2018 11:32:52 +0900

火曜日にmacOS Mojaveが公開されました。Hackintoshをアップデートする時間がなかなか取れなかったのですが、ようやく作業できました。結論としては、ベータ版で確認されていた通りで、今回のアップデートには難しいところは全くありません。

上書きアップデート編

macOSアップデートの一番お手軽な方法は、App Storeからダウンロードして、そのままアップデートする方法です。環境設定も、インストールしたアプリケーションも、ユーザ設定もデータも全部そのまま引き継げますので簡単です。今回のアップデートは、OSの根本に大きな変化が少ないので、上書きアップデートができそうです。今回は、High Sierraが動いている初代NUC, DC3217IYEで試してみました。Ivy Bridgeマシンなので、なんとかギリギリでMojaveに対応しています。

NUCで作る超小型macOSマシン

Clover, KEXTをアップデートしておく

macOSのアップデートが簡単になった舞台裏では、Hackintosh開発者の皆さんの努力があります。ベータ版を元に不具合検証して、多数のアップデートが施されています。感謝です。なのでmacOSアップデート前に、最新版にアップデートしておきましょう。

現時点でのCloverの最新版リビジョンは4674です。古いようでしたらアップデートしておきます。

Kext類のアップデートにはKext Updater.appが便利です。起動すると、Kext Updaterそのものがアップデートされることもあります。最新版kextに関するデータベースが更新されるのだと思いますので、これもやっておきます。

アップデートしたら、もう一度Kext Updaterで最新になっていることを確認しても良いです。ただ、再起動を行わないと、新しいClover, Kextが機能しませんので、再起動してから確認します。

KextをMojaveの場所に複製する

もしKext類をEFI/CLOVER/kexts/10.13/に入れているようでしたら、同じ内容をEFI/CLOVER/kexts/10.14/にもコピーしておきます。これを忘れるとMojaveが起動しません。当たり前のことですがうっかり忘れて慌てた経験が複数回あります。

そういう可能性をなくすために、EFI/CLOVER/kexts/Other/にKextを入れておくのも良いかと思います。CloverはOtherの場所のkextを読み込んだ後で、10.14などの場所のkext類を読み込みます。同じkextがOtherとバージョン番号のフォルダの両方に存在しても、片方しか動かないので問題ありませんが、無駄なのでどちらか片方だけに入れておくのが良いです。

App StoreからMojaveをダウンロードする

App Storeに行くと、今ならバナー広告でmacOS Mojaveが絶賛宣伝中になっている思います。ダウンロードボタンを押してダウンロードします。6.03GBあります。

ダウンロードが終了すると、自動的に起動してインストーラが起動します。これは一旦終了して（しなくても良いですが）、アプリケーションフォルダを見てください。macOS Mojaveインストール.appというアプリケーションがありますので、これをどこかに複製して保存しておきます。バックアップしておかないと、インストール後に消えてしまうことがあります。せっかく時間をかけてダウンロードしたのですから、バックアップしておきましょう。

インストーラを起動する

macOS Mojaveインストール.appを起動すると以下のウィンドウが現れます。

「続ける」をクリックして、あとは指示に従ってどんどんインストールして行くだけです。

インストール途中で再起動する場面があります。この時、「Boot macOS Install from xxxx」という項目が作られていて、それから起動するようになっているはずです。xxxxの部分は、アップデートしようとしているパーティションの名前です。

以上の結果、無事アップデートできました。App Storeからのダウンロードによる上書きアップデートで問題なくMojaveに移行できることが確認できました。

クリーンインストール編

クリーンインストールも試してみました。問題ありません。こちらはタワー型デスクトップのHackintoshで試しました。HDDを多数搭載していて、予備のHDDにもmacOSとCloverがインストールしてあります。

作業の前に、メインのドライブと予備のドライブのESPに入っているCloverとkextを最新版にしておきます。メインのドライブのESPだけを使って以下の作業を行うことは可能ですが、将来、サブのESPを使うことも考えて、ついでにアップデートしておきました。

次に、予備のmacOSで起動して、メインで使っているシステムの入ったパーティションをAPFSでフォーマットしてしまいます。そしてmacOS Mojaveインストール.appを起動し、空になったパーティションにインストールしました。この場合も、インストール途中で1回再起動しますので、Boot macOS Install from …の項目から再起動します。

あと12日！Mojaveの受け入れ準備

Thu, 13 Sep 2018 21:00:00 +0900

Mojaveは9月25日に登場

今朝未明のキーノートは、いつもの秋のイベント同様にiPhoneメインで、ささやかに期待された新型Macの情報は皆無で寂しい限りです。ただ最後の3分を切ったところで、macOS Mojave配布日が発表されました。日本時間で9月25日だそうです。あと12日ですね。それまでのあなたのHackintoshに新バージョンをお迎えする準備をしておきましょう。（去年の状況と同じですね😀あと13日！High Sierraのお迎え準備）

以下はMojaveのベータ版での情報ですが正式版Mojaveでも同様と思われます。

High Sierraからのアップデートは簡単

今現在HackintoshをHigh Sierraで動かしているならアップデートは簡単です。Cloverとkext類を最新にしておけばokです。High Sierraへの移行では、APFS起動に伴いファームウェアアップデートされ、多少の対応が必要でしたが、今回はそれも不要です。

なお、Kext Updater.appを使うと、使用中のkextの最新版をチェックして、ダウンロードしてくれるので楽です。

Mojave移行の注意

Cloverなどを最新版にしておく以外にほとんど問題はないはずです。それでもありえそうな注意事項を列挙して見ます。

kextの格納場所

kextをEFI/CLOVER/kexts/10.13に入れている人は、10.14を新たに作って、全部のkextをコピーしておきます。もしくは、Otherフォルダにコピーしておいても良いです。10.14で起動する場合は、Otherの内容が先に読み込まれ、次に10.14フォルダが読み込まれます。10.13のフォルダの内容は無視されてしまいます。当たり前のことですが、うっかりして失敗した経験が何度かあります。

APFS

High SierraのインストールではAPFSを使わない選択肢がありました。でもMojaveからは必須になったようです。システムドライブをまだHFS+で運用している人は、対応が必要かと思います。ファイルシステムの移行は大事なので、APFS移行でも問題が発生するのではという懸念がありました。しかし、APFS移行問題は、実機でもHackintoshでもほとんど報告されていません。円滑に移行できていると思われます。

High Sierraが出た頃は、macOSからapfs.efiをESPにコピーしていました。その後公開されたApfsDriverLoader-64.efiを入れておけば、macOSに含まれる最新のapfs.efiを使ってくれるようになります。

Clover 4558で登場したApfsDriverLoader.efi

Mojave非対応Mac

公式サイトの情報によるとMojave対応機種は以下です。

MacBook (Early 2015 以降)
MacBook Air (Mid 2012 以降)
MacBook Pro (Mid 2012 以降)
Mac mini (Late 2012 以降)
iMac (Late 2012 以降)
iMac Pro (全モデル)
Mac Pro ( Mid 2010, Mid 2012, Late 2013)

CPU世代でいうとSandybridge以前が非対応になりました。これ以外の機種名をconfig.plistで設定しているHackintoshでは、起動時に禁止マークが出て止まってしまいます。

これを避けるためには、Cloverのブートオプションに

-no_compat_check

を追加します。これで機種チェックを回避できます。例えばconfig.plistに以下のように設定します。

<key>Boot</key>
  <dict>
    <key>Arguments</key>
    <string>-v -no_compat_check</string>

少なくともベータ版では、これでMojaveが起動しました。

Mojave非対応グラフィックス

MojaveからはMetal対応グラフィックスが必須になりました。ただ、今のところは、Metalの機能が無いと全く動かないという状態ではなく、Metal非対応のドライバをmacOSから除外したという状態のようです。なので、古いmacOSからMojaveで削除されたドライバを持って来ればなんとか動くようです。ただ、Metalの機能を使っている部分もあるので、多少の不具合（ぼかしが機能しないなど）はあるようです。

古いグラフィックスドライバを入れたり、また機種名を誤魔化すためのパッチを当てるツールも公開されています。実機向けのツールですが、Hackintoshでも使えると思います。

macOS Mojave Patcher

古いハードウェアがMojaveに対応していないのは実機でも同様のことですので、Hackintoshもハードウェアのアップデートを検討するのが良いと思います。自作機ならアップデートは簡単ですから。

Mojaveへの移行方法

これは実機でも同じですが、新しいOSバージョンへ移行するには、大胆または慎重などの移行方針を選べます。バニラなインストール方法でHackintoshしているなら、実機とほぼ同様の方法でアップデート可能です。

/posts/131/

主ドライブを上書きアップデートする

今動いているHigh SierraからMojaveのアップデータを起動する方法です。実機と同様に、App Storeからダウンロードしたアップデータをそのまま起動すれば、問題なくアップデートされるはずです。Appleお勧めの一番簡単な方法です。ただ、上記で説明したCloverとkext類のアップデートは済ませておきましょう。

別ドライブにインストールする

別ドライブにクリーンインストールする方法です。新OSの動作を確認して、問題がなければ移行しようという慎重な人向けです。自作HackintoshならSSDなどの追加は簡単だと思います。macOSだけならSSDは30GBもあれば十分ですが、現行製品だと120GBか256GBあたりがビット単価からしてお得感があります。直接内蔵しなくても、外付けケースに入れてUSB接続した別ドライブでもokです。

方法は簡単で、今動いているHigh Sierraから別ドライブをフォーマットして、Mojaveのアップデータを起動してインストールすれば良いです。クリーンインストールするために、単体で起動できるUSBメモリを作る方法もありますが、すでに起動できるドライブがあるならその必要はないと思います。インストールの途中で古い環境からの移行をするオプションが現れます。これを使えば、High Sierraでの設定などを移行することも簡単です。

別ドライブにmacOSをインストールしたら、そのドライブのESPにCloverとkext類も入れておきましょう。それで起動できれば、Hackintosh設定で失敗して主ドライブが起動しない時のバックアップになります。

主ドライブにクリーンインストールする

単体で起動できるUSBメモリを作った場合は、主ドライブにクリーンインストールすることもできるでしょう。または、「別ドライブにインストール」した後であれば、それを起動して、主ドライブにクリーンインストールすることもできます。

ユーザデータまでフォーマットすると復帰が大変ですが、/Users以下を別ドライブや別パーティションに入れてあれば、システム部分をフォーマットしてクリーンインストールしてもそれほど手間はかからないと思います。

Mojaveで消えたkext、増えたkext

Wed, 18 Jul 2018 00:30:00 +0900

High SierraとMojaveで/System/Library/Extensions (/S/L/E) の中に含まれるkext類がどう違うのか、調べてみました。

High Sierra 10.13.6をクリーンインストールして、MojaveのPublic Beta 1と比較しました。/S/L/Eの内容をlsしてdiffで比較しました。High Sierra, Mojaveの順にdiff引数を指定したので、行頭に<がついているのがHigh Sierraにのみ存在するkext、行頭に>がついているのがMojaveにのみ存在するkextになります。

消えたkext

High SierraにあったけどMojaveでは消えてしまったkext（アルファベット順）は、以下です。

$ diff HighSierra.text Mojave.text | grep "<"
< AMD2400Controller.kext
< AMD2600Controller.kext
< AMD3800Controller.kext
< AMD4600Controller.kext
< AMD4800Controller.kext
< AMD5000Controller.kext
< AMD6000Controller.kext
< AMDLegacyFramebuffer.kext
< AMDLegacySupport.kext
< AMDRadeonX3000.kext
< AMDRadeonX3000GLDriver.bundle
< ATIRadeonX2000.kext
< ATIRadeonX2000GA.plugin
< ATIRadeonX2000GLDriver.bundle
< ATIRadeonX2000VADriver.bundle
< AppleIntelHD3000Graphics.kext
< AppleIntelHD3000GraphicsGA.plugin
< AppleIntelHD3000GraphicsGLDriver.bundle
< AppleIntelHD3000GraphicsVADriver.bundle
< AppleIntelHDGraphics.kext
< AppleIntelHDGraphicsFB.kext
< AppleIntelHDGraphicsGA.plugin
< AppleIntelHDGraphicsGLDriver.bundle
< AppleIntelHDGraphicsVADriver.bundle
< AppleIntelSNBGraphicsFB.kext
< AppleIntelSNBVA.bundle
< AppleTyMCEDriver.kext
< GeForceGA.bundle
< GeForceTesla.kext
< GeForceTeslaGLDriver.bundle
< GeForceTeslaVADriver.bundle
< NVDANV50HalTesla.kext
< NVDAResmanTesla.kext

最初の方を見ると、AMDの古いドライバがいくつか削除されたようです。Metalに対応していないグラフィックスカードのドライバと思われます。2400, 2600は2007-2008年代のiMacに搭載されたグラフィックスだと思われます。4600, 4800, 5000, 6000は、おそらくiMacや昔のタワー型Mac Proに搭載されたHD 4000/5000/6000シリーズに対応するドライバだと思われます。ただAMDRadeonX4000,5000,6000.kextはMojaveにも存在しているので、HD 4000/5000/6000シリーズはまだ使えるのかもしれません。

タワー型Mac ProにはPCIeスロットがありますが、Mac用のBIOSを搭載したカードでない場合には、起動時の表示が出ません。なので古いMac Proユーザはいまだに古いカードを使っていることも多いのですが、Mojaveでは使えなくなったようです。Hackintoshしている人がこのような古いAMDカードを使っていることは稀だと思いますので、影響は少ないと思われます。

次に、Intel HD Graphics 3000シリーズのドライバと思われるApple Intel HD3000 Graphicsで始まるkext類が削除されています。3000の前には、無印のIntel HD Graphicsという規格がありましたが、Mac製品には搭載されていません。なので、AppleIntelHDGraphicsで始まるkext類も同じく3000シリーズのものと思われます。また、AppleIntelSNBGraphicsで始まるkext類は、検索してみたら、SNBがSaNdy Bridgeの略だそうで、これも3000シリーズのものです。3000シリーズがMetal対応から外されたので、Sandy Bridgeを使っているHackintoshは、PCIeグラフィックスカードを利用するか、CPU/マザーボードアップグレードを検討すべきでしょう。

また、GeForceで始まるkext類も一部削除されています。Mojave対応機種がiMacではLate 2012だそうです。グラフィックスチップは、GT 640M, 650M, 660M, 675MX, 680MXのあたりなら対応しているようです。それ以前のGeForceのドライバが外されたのかもしれません。

グラフィックスドライバ以外では、AppleTyMCEDriver.kextが外されています。検索して見ると、これは ECCメモリに関連する何かのようです。

登場したkext

HighSierraには無くて、Mojaveで新しく登場したkextは以下の5個でした。よくわかりません、すみません。

$ diff HighSierra.text Mojave.text | grep ">"
> AMDRadeonX6000HWServices.kext
> AppleUSBCHCOM.kext
> AppleUSBPLCOM.kext
> AppleUSBRealtek8153Patcher.kext
> CoreTrust.kext

ちなみにRealtek 8153というのはUSB 3.0 – ギガビットEthernetのチップのようです。こんな製品で使われているようです。Appleブランドにはこのようなアダプタが無いので謎です。

/L/Eに置かれたkext

/Library/Extensionsに置かれたkextに変更はありませんでした。

ちなみに以下のkextが/L/Eに置かれています。CalDigitというのはThunderbolt接続周辺機器を作っている会社のようです。HighPointはRocketなんとかシリーズでPCIeスロット搭載RAIDアダプタなどを作っていますね。ATTOはネットワークカードなどを作っていて、Celerityは光ファイバーカードのようです。

ACS6x.kext
ATTOCelerityFC8.kext
ATTOExpressSASHBA2.kext
ATTOExpressSASRAID2.kext
ArcMSR.kext
CalDigitHDProDrv.kext
HighPointIOP.kext
HighPointRR.kext
PromiseSTEX.kext
SoftRAID.kext

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

Tue, 10 Jul 2018 21:37:37 +0900

更新：古い情報です。こちらの方法が良いと思います。(2018/9/8)

昨夜、おそらく最後のHigh Sierraになる10.13.6が配布されました。すでに配布されているMojave Public Betaを使っていて気づいた変更点が、早々と10.13.6で導入されていました。大したことではないのですが、ESPパーティションをdiskutil mountコマンドでマウントする場合に管理者権限のパスワードが必要になりました。例えば、今までは、disk0s1にあるESPは、diskutil mount /dev/disk0s1 でマウントすることができました。しかし10.13.6で同じコマンドを実行すると、

$ diskutil mount /dev/disk0s1
Volume on disk1s1 failed to mount
If the volume is damaged, try the "readOnly" option

のようにエラーが出てしまいます。readOnlyでマウントしても同様です。

$ sudo diskutil mount /dev/disk0s1

として、この後、パスワードを入力する必要があります。

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

以前、ESPをマウントするためのシェルスクリプトを紹介しました。

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

上記で紹介したスクリプトのdiskutil mountの行を、sudoで実行するように以下のように変更する必要があります。

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

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

やはり、以前、ESPを自動でバックアップする方法を紹介しました。これも、パスワードが必要になったことで対応する必要があります。

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

この方式は、ログインするときにAutometorで作ったアプリケーションを起動する方法でした。これもパスワードに対応していないので、動かなくなってしまいました。パスワードを求めるように変更するのも良いのですが、いちいち、ログインするごとに、パスワードを入力するのは面倒です。

そこで、macOSが起動した直後に、root権限でESPをバックアップする方法に変更することにしました。Launchd (ローンチデーモン)を使います。

Launchdを使う

以下のサイトなどでLaunchdの説明がされています。

qiita.com

コンピュータが起動したときに特定のプログラムを自動的に実行させる仕組みに、Linuxだとrcスクリプトがあります。大昔のDOSにはautoexec.batというのがありました。また、UNIX系OSでは、ある時間になったら特定のプログラムを自動的に実行させる仕組みにcronがあります。

このような仕組みを実現するために、macOSにはLaunchdがあります。これでrcスクリプトとcronの両方の機能を実現しています。ちなみに、cronはmacOSにも搭載されています。特定日時、時間、時間間隔でプログラムを実行させたい場合には、Launchdの他にcronも使うことができます。

Launchdでは、動かそうとするプログラム1つに対して、設定ファイルを1個用意します。これは、 launchd.plist と呼ばれる各種 XML ファイルです。以下に説明がありました。

ka-zoo.net

launchd.plistは、以下のいずれかの場所に置きます。

/System/Library/LaunchAgents/
/System/Library/LaunchDaemons/
/Library/LaunchAgents/
/Library/LaunchDaemons/
~/Library/LaunchAgents/

/System以下はmacOSが必要とするサーバなどのプログラムを置く場所であり、触らない方が良いでしょう。そもそもSIPで保護されているので簡単には変更できません。

なので、自作プログラムの設定ファイルを置くとしたら、/LIbrary以下か、もしくは~/Library以下になります。LaunchAgentsとLaunchDaemonsフォルダの違いは次のようです。

LaunchDaemonsフォルダに設定ファイルを置くプログラムは、サーバや常駐プログラムのようなデーモンであり、これはroot権限で機能します。
LaunchAgentsフォルダに設定ファイルを置くプログラムは、ログインしたユーザごとに、ユーザの権限で起動されます。/Library/LaunchAgents/には、全ユーザ共通で起動したいプログラムを、~/Library/LaunchAgents/には、特定ユーザのみで動作するプログラムの情報を書きます。

launchd.plistを作る

今回のESPバックアッププログラムは、macOSが起動した時点で、root権限で一回だけ起動させたいと考えました。root権限で起動すれば、diskutil mountでのパスワード入力も不要なはずです。ということで、/Library/LaunchDaemons/に設定ファイルを入れることにしました。

そこで、以下のようなXMLファイルを作成して、/Library/LaunchDaemons/に置きます。このディレクトリにはすでに他のplistファイルが置かれているかもしれません。それを参考にしても良いです。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
<string>com.bootmacos.ESPbackup</string>
        <key>Program</key>
        <string> /Users/bootmacos/Documents/Hackintosh/backup_scripts/ESPBackupZ97A.command
        </string>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

このplistにはいくつかのキーを設定できますが、今回は、最小限の3個だけ使いました。

Labelはこのプログラムを特定するための名前です。名前の作り方は全く自由ですが、他のファイルの例を見ると、開発者のURLを逆に書くことで、特定が簡単になる工夫をしているようです。それに倣って、このブログのURLに機能名を加えて命名しました。
Programキーは、プログラムの場所です。ここはフルパスで書いておきます。起動時にはパスが張られていない可能性がありますので、エラーを引き起こさないために全部書いて置くのが良いです。
RunAtLoadは、Launchdがこのプログラムをロードしたときに実行するかどうかを決めます。

この他、常駐させるかどうかのキーもありますが、デフォルトで常駐しない設定なので、省略しました。この内容を、

$ cd /Library/LaunchDaemons/
$ sudo vi com.bootmacos.ESPbackup.plist

として、/Library/LaunchDaemons/以下に作ります。ファイルの名前も自由なのですが、これも特定しやすいように、URLを逆にして命名するのが一般的のようです。

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

次に、実際にESPのバックアップを行うスクリプトを作成します。保存場所と名前は、上で作成したlaunchd.plistの内容に合わせます。スクリプトの内容は、Automatorで使ったものとほぼ同じです。パーティションUUIDの探し方は、以前の記事をみてください。

#!/bin/sh
ESPUUID=00000000-0000-0000-0000-000000000000
BACKUP=/Users/bootmacos/Documents/Hackintosh/currentConfig/MSIZ97AG7/
diskutil unmount $ESPUUID
diskutil mount $ESPUUID
rsync -av --delete --exclude '.*' /Volumes/EFI/ $BACKUP
diskutil unmount $ESPUUID

最初のdiskutil unmountのコマンドは本来なら不要です。ただ、これが無い状態では、次のdiskutil mountコマンドがtimed outというエラーを表示して、うまく動作しないことがありました。ネット上で調べたら念のためにunmountしておくとエラーが出ないとあり、それを真似ました。快調に動いています。

また、rsyncのパラメータに–excludeを追加しました。ピリオドで始まる隠しディレクトリは不要なので、バックアップから外しました。

ここでは、root権限で起動するのでsudoをしていません。これでパスワードの入力をすることなく、ESPパーティションをマウントして、バックアップできるようになりました。

完成したら実行可能に設定しておきます。

$ chmod a+x ESPBackupZ97A.command

Launchd.plistの内容

今回、以下のディレクトリを見たところ、意外なファイルが入っていました。

/Library/LaunchDaemons/
/Library/LaunchAgents/
~/Library/LaunchAgents/

すでに使っていないドライバやアプリに関するplistや、心当たりがあまり無いplistなどです。macOSをクリーンインストールすると、これらのディレクトリは全て空です。なので、何かが入っているとしたら、アプリケーションのインストーラなどにより後から入れられたものです。特に、/Library/LaunchDaemons/はマシンが起動したら必ず起動して、しかもroot権限で動くプログラムです。時々はチェックして、起動するプログラムを把握して、おかしな設定が残っていたら削除するのが良いかと思います。

もうmacOSベータ版は要らないと思ったあなたに

Fri, 06 Jul 2018 00:30:00 +0900

Public Betaが出たのでMojaveを試してみたけど問題なく動いたのでひとまず安心。新機能も気に入ったけど、日常的に使うのは、9月の正式発表の時まで楽しみに待っていても良いかな。と、思ったあなた。例年ですとこの後、数回のアップデートが配信されるはずです。さらにはMojave体験希望者にはもれなく10.13.6 Public Betaも配信されています。

正式版になってから受け取りたい、もうベータ版は要らないと思ったのに、アップデートはどんどんやってきます。他のアップデートと混じってわかりにくいです。うっかりクリックしたらインストールが始まってしまいます。そこで今回はmacOSベータ版の配信を止める方法の紹介です。

そもそもなぜベータ版が来るようになったのか

もちろん私がお願いしたからです。Public Beta参加のページからmacOSPublicBetaAccessUtilityというパッケージをダウンロードして、これをインストールしました。

すると、すぐにApp Storeが開いて、Mojaveがインストールできるようになったのです。その後、アップデートも送られるようになりました。

App Storeの環境設定で止める

ベータ版の配信を止めるメニューはApp Storeの「環境設定…」の中にあります。ここに、「お使いのコンピュータは、ベータ・ソフトウェア・アップデートを受信するように設定されています」という項目があります。この右にある「変更…」のボタンを押すと、「App Storeでベータ・ソフトウェア・アップデートを表示するのを停止しますか？」というダイアログが出ます。ここで「ベータ・ソフトウェア・アップデートを表示しない」ボタンを押せば、アップデートが来ても表示されなくなります。

ただしこの作業をしてしまうと、ベータ・ソフトウェア・アップデートに関するメニューは現れなくなってしまいます。配信中止ボタンを押したら後戻りはできません。再び配信して欲しいと思う場合は、もう一度macOSPublicBetaAccessUtilityを起動して、配信を開始してもらう事になります。

macOS Mojave Public Beta版を試す

Wed, 27 Jun 2018 22:43:49 +0900

いよいよMojaveのPublic Betaが公開されました。そこで早速Hackintoshで動かしてみました。去年のHigh SierraではAPFSが登場しました。でも今回のアップデートでOSの根本が大きく変化している箇所はあまり多くないようです。なので、すでにHigh Sierraが動いているHackintoshでしたらMojaveを動かすのは簡単です。10.13.4から10.13.5のようなマイナーアップデートと変わりません。(とは言え、High Sierra の時もapfs.efiを追加するくらいでした。)

Public Betaを入手する

MojaveのPublic Betaを入手するには、Appleのサイト

Apple Beta Software Program

で、macOSPublicBetaAccessUtility.pkgを入手します。Apple IDでのログインが必要です。

これをダブルクリックすると、App StoreからInstall macOS Mojave Beta.appをダウンロードできるようになります。

macOSPublicBetaAccessUtility.pkgがインストールされたマシンでないと、ダウンロードできません。しかし、一旦App StoreからダウンロードしたInstall macOS Mojave Beta.appは、どのマシンでも使用できます。

インストールの手順は、こちらにも詳しく紹介されています。

www.itmedia.co.jp

Mojaveを導入・起動

こうして入手したInstall macOS Mojave Beta.appさえあれば、Mojaveの起動ディスクを作成できます。また、High Sierraに手を加えないVanillaなHackintoshならば、その起動用ESPを使って、Mojaveを起動できます。

そこで、以下の手順でMojave起動ドライブを作成して、Mojaveを起動しました。ここではHackintosh上でMojaveをSSDにインストールしましたが、もちろん実機のMacで行っても良いです。

現在のHigh Sierra起動用ボリュームのESPに入っているCloverとkext類を念のために最新にしておきます。これがHigh Sierraで起動することを確認します。
kext類を10.13のフォルダに入れている場合は、10.14というフォルダを作ってコピーしておきます。もしくはOtherに入れておきます。これでHigh Sierraを起動します。
新OSを試す為のドライブを用意します。今回は余り物の2.5inch SATA SSDを用意してHackintoshに接続しました。SATA接続でもUSBケースに入れてUSB接続でも良いです。動作は遅いですがHDDでもUSBメモリでも良いです。容量は32GBほどあれば良いです。このSSDをDiskutility.appでフォーマットします。パーティションスキームはGUID、フォーマットはMac OS拡張（ジャーナリング）にします。
ダウンロードしたInstall macOS Mojave Beta.appを開き、SSDにMojaveをインストールします。
インストール途中で何回か再起動（たぶん２回）します。本物のMacの場合は自動で正しく再起動します。Hackintoshの場合は、再起動ボリュームが正しく引き継がれないことがあります。Cloverの選択画面で「Boot macOS Install from xxxx」という項目が選択されている事を確認してください。
Cloverの選択画面が「Boot macOS from xxxx」になったらインストールは終わりです。これを選択すれば、ユーザ設定などの画面になり、Mojaveを使えます。せっかくですからダークモードを試してみましょう。

Metal非対応では導入できない？

以上は、Apple社がmacOS純正ドライバーを提供しているRadeon RX 580搭載Hackintoshで作業しました。メーカー配布のドライバーがまだMojaveに対応していないNVIDIA GeForce搭載のHackintoshでインストール作業をしたところ、インストール途中でinstaller resourcesが足りないと言われてしまいました。なんのことか不明ですが、Metal対応のRadeonでは問題なかったことから、Metalに対応していないマシンではインストールできないという意味かと思われます。

MojaveドライブにCloverを入れる

これでMojaveが起動すれば、このドライブにClover類を入れて単体で起動できるようにするのは簡単です。以下の手順でESPを複製すれば良いです。

Mojaveを入れたドライブにCloverをインストールします。（このステップは飛ばしても良いと思います）
High Sierraが動いているドライブのESPの内容を、MojaveをインストールしたドライブのESPと同一にします。上のステップでCloverを入れているなら、全部コピーしなくても、CLOVERディレクトリの一部だけを差し替えればokです。kextをバージョンごとのフォルダに入れている場合は、10.14というフォルダを作って入れるようにします。

色々なマシンでMojaveを起動

ここで作成したMojaveの起動SSDを手元のマシンで試してみました。HackintoshではHigh Sierraの起動で使用しているESPを使っての起動を行いました。

AMD Radeon RX580搭載のHackintosh: 上のステップでMojaveインストールに使用したマシンです。Metal対応のドライバがmacOSに含まれているので、問題なく起動し、全てが快適に動作します。過渡期はmacOS標準サポートされているRadeon RX570/580は安心ですね。
NUC DC3217IYE Hackintosh: Intelの初代Core i3 NUCです。NUCの初代はIvy Bridgeなので、実はNUC iGPUの多くがMetal対応していて、その結果、Mojave対応です。これも全く問題なく起動しました。
Nvidia GPU搭載Hackintosh: NVIDIAが配布するドライバー (Web driver) がMojaveに未対応なので、表示解像度が低いままで表示がちらつくものの、とりあえずは起動しました。Web driverが対応すればMetalが動いてMojaveが使えると思われます。まず大丈夫と思いますが、実際にドライバが出てみないとわからないですね。
ThinkPad X220 Hackintosh: 非対応CPUであるSandy Bridge搭載ThinkPadです。禁止マークが出て起動しません。
-vオプションでエラーメッセージを見ると以下のようです。起動しない理由として表示される番号、Mac-94245B3640C91C81 は、MacBook Pro Late 2011 13インチモデルのBoard-IDでした。config.plistのSMBIOSセクションで指定したIDです。試しにこれを2012年モデルのIDである Mac-6F01561E16C75D06に変えてみたところ起動はしました。ただ解像度は低くちらつきます。Metal非対応のグラフィックスにはmacOS標準ドライバが提供されなくなったのかと思われます。実質的にMojaveは使えないです。
実際に/System/Library/Extensionsを10.13.5と比較すると、Intel HD Graphics 3000に関係すると思われる名前のファイル（AppleIntelHD3000Graphics.kext, AppleIntelHD3000GraphicsGA.plugin, AppleIntelHD3000GraphicsGLDriver.bundle, AppleIntelHD3000GraphicsVADriver.bundle）がごっそりと消えています。
**追記：**動きました

/posts/47/
古いMacBook: Mojave非対応のLate 2009 MacBookに接続して起動を試みました。Hackintoshではなく本物のMacです。X220の時と同様に、禁止マークが出て起動しません。Command-vで起動すると、やはり次のようなメッセージが出ていました。Mac-F22C8AC8はこの機種のBoard-IDです。このような古いMacもBoard-IDを誤魔化す手法でなんとか起動できるのかもしれません。ただその場合も、グラフィックスは低解像度でしか動かないと思われます。

Windowsと同居する

Sun, 14 Jan 2018 14:48:50 +0900

Hackintoshで使うコンピュータはもともとWindowsをインストールする前提で作られているので、当然ながらWindowsも走ります。本物のMacでは、Boot CampというツールでWindowsを動かすようにしますが、その必要はありません（そもそもBoot Campは使えません）。今回は、macOSとWindowsのマルチブートを設定するときの注意事項を書いてみました。

別ドライブにインストールするのが楽

WindowsとmacOSを同一の物理ドライブの別パーティションにインストールすることは可能ではあります。でも色々面倒なので、できれば別の物理ドライブに、macOSとWindowsを分けてインストールするのが簡単です。デスクトップPCなら複数ドライブ搭載は簡単だと思います。

同一のドライブの別パーティションにmacOSとWindowsをインストールしようとすると、それぞれがESPを書き換えることになります。Cloverで設定したものが、Windowsをインストールすると動かなくなります。もう一度、設定すれば良いのですが、かなり面倒です。このような問題は、ESP以前のMBR（マスターブートレコード）を使っていた時代からありました。物理的に別のドライブにインストールすれば、それぞれのESPに個別に起動項目が書き込まれるので、干渉しません。別のドライブにインストールされたWindowsは、UEFI/BIOSの起動メニューで選択することもできますし、Cloverの起動選択画面からも起動できます。

最近の経験では、そもそもパーティションスキームが違ってインストールできないこともありました。特にAPFSになって採用された新しい論理パーティションなどは、Windowsインストーラから使えません。なので同じドライブにインストールしようとする場合は、パーティション分けの方法も面倒になり、試行錯誤が必要になると思います。

インストールに関係ないドライブを外す

Windowsをあまり使わないこともありますが、Windowsインストーラの挙動は、いまだに謎です。インストール対象のドライブ以外のドライブがコンピュータに多数接続されていると、インストールできないことがあります。もしかしたら接続されているドライブがmacOS用にパーティション分けされていたのがいけないのかもしれません。関係ないドライブは外しておいた方が良いです。

先日、m.2 SSDを外すのが面倒だったので接続したまま別ドライブにインストールを試みたら、m.2 SSDのESPに起動ファイルが書き込まれてCloverが起動しなくなってしまいました。Windowsインストーラは、インストール先として指定しないドライブを書き換えることもあるようです。面倒でもm.2 SSDを外すか、せめてUEFI/BIOSでm.2を読めないように設定して、Windowsインストールするのが良いと思いました。

時刻を合わせる

macOSとWindowsを切り替えて使用すると、時刻が合いません。9時間だけずれます。macOSはUTC (協定世界時: Coordinated Universal Time, 昔はグリニッジ標準時GMTと呼ばれていた時刻）を使っているのに対して、Windowsは現地時間を使っているからです。

コンピュータは、ファイル作成時刻などを管理するために、時計機能を備えています。マザーボードにはRTC（リアルタイムクロック）というチップが搭載されていて、電源が切れている時も、ボタン電池で時刻を刻んでいます。時差の違う場所に置かれたコンピュータ同士をネットワーク接続で使うことを考えると、コンピュータの時刻はどれか一つの基準時間を使うべきです。そうするとUTCを使用するのが順当です。ということで、macOSやLinuxなどのUNIX系のOSでは、UTCで時刻を管理して、必要に応じて現地時間に換算して表示しています。

UNIX系OSは専門家が使う高価で大掛かりなコンピュータのためのOSとして開発されました。一方、Windowsの先祖は、単独で動く簡素な個人用コンピュータ（マイクロコンピュータ、マイコン）で使われたOSです。昔のコンピュータには電池バックアップのRTCなどなかったので、起動時に時刻を入力させられました。個人ユーザがいちいちUTCと時差を入力するのは面倒なので、マイコンの時計は現地時間に設定することになっていました。それでWindowsは今でもRTCを現地時間に設定していて、UTCが必要な場合には、現地時間から換算しています。

RTCがUTCでも現地時間でも、必要に応じて換算すれば良いので問題はありません。でも、macOSとWindowsで同一のRTCを共有すると、OSを切り替えるたびに時間がずれてしまいます。Boot Campではこの問題を解決するドライバが用意されています。Hackintoshでは、当然ながらそういう配慮はありませんので、自力で解決することになります。

WindowsをUTCにする

WindowsとmacOSのどちらを相手に合わせても良いのですが、歴史的な経緯で仕方なく(?)現地時間を使っているWindowsを正統なUTCに切り替える方が簡単です。これにはレジストリを書き換えます。Windowsでregedit.exeを実行するとレジストリエディタが起動します。

左の階層から、コンピュータ、HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Control, TimeZoneInformationと辿っていきます。TimeZoneInformationで右ボタンクリックでコンテクストメニューを呼び出し、「新規 (N)」「DWORD (32ビット) 値(D)」を選択します。

ここで、RealTimeIsUniversalという値を作り、この名前をダブルクリックして設定ウィンドウを開き、値を1に設定します。このあとWindowsをシャットダウンし、一旦macOSを起動して、またWindowsに戻ってくると、Windowsの時刻がmacOSと一致します。

コマンドプロンプトで設定する

フォーラムで教えていただきましたが、レジストリエディタを使う代わりに、Windowsのコマンドプロンプトから設定することも可能のようです。以下のようにタイプします。

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

HackintoshのOSアップデートは難しい？

Sun, 24 Dec 2017 16:34:39 +0900

「Hackintoshは最初は動いてもmacOSのアップデートのたびに大変なトラブルに陥る」というイメージがあるかもしれません。Apple社がちゃんとサポートしてくれている実機に比べたら面倒なのは確かですが、それほど変わらないと思います。macOSが好きで、動かないコンピュータを動かすことが趣味な人間が言うことですので、あまり当てにはなりませんが、

マイナーアップデートは楽勝

です。例えば10.13.1から10.13.2へのアップデートのように、年に数回行われるマイナーアップデートは実機と同じくらいのお手軽さです。少なくともここ2-3年の状況では、Cloverとkextを最新に保っておけば、App Storeからのアップデートをそのまま受け入れて、macOSアップデートしてもまず問題は起こりません。

NVIDIAのグラフィックスカードでWeb driverを使っている人は、新しいmacOSに対応したドライバが配布されるまで高解像度表示ができなくなるかもしれません。でもNVIDIAの対応はいつも敏速で、ほぼ24時間以内に新しいドライバを配布しています。Mac Proのユーザも多いのでしょうが、Hackintoshユーザからしたらありがたいメーカーです。

メジャーアップデートは少し大変

ここのところ年に一度、9月にあるメジャーアップデート（例えば10.12から10.13へのアップデート）は少し面倒な作業が伴います。それも年に一度のお祭りとして楽しんでいただければ良いと思います。

最近の出来事ですと、10.11でUSBの個数制限が行われて使用可能なUSBポートの数が、コントローラ当たり15までと制限されました。この制限を解除したり、制限の枠の中で使用するポートを指定する作業が必要でした。

USBポートを設定する

10.11ではSIPも導入されました。/S/L/Eや/L/Eにkextを置く場合ではSIPを無効にする設定が必要になりました。バニラなインストールをすればSIPはデフォルトでも大丈夫です。

/posts/132/

10.13ではAPFSが導入され、実機でファームウェアアップデートが行われました。それに合わせて、HackintoshでもSMBIOSの変更が必要でした。APFSボリュームから起動するためにはドライバも入れておかねばなりません。

HackintoshをHigh Sierraにする

このようにメジャーアップデートでは予期しない課題が発生する可能性がありますので、古いmacOSはそのまま残して、予備のSSD/HDDにシステムを作って動作を確認した方が良いと思います。パブリックベータが配布されている時期か試しておけば、正式リリースの時にいち早く導入できるかと思います。

アップデートは面倒なことだけではなく、新しいCPUへの対応、NVMe SSDの対応、ビデオカードの対応など、新しい技術の恩恵にあずかれるチャンスですので、積極的に受け入れていきたいと思います。

10.13.2へのマイナーアップデートで躓く

マイナーアップデートは楽勝と書きましたが、最近、躓いたことを書いておきます。メインで使用しているHackintoshで10.13.1から10.13.2へのアップデートをしたのですが、これはApp Storeからのダウンロードだけで簡単に終了しました。10.13.2でスリープが効かなくなったとかの噂も聞くのですが、全く問題ありません。

ところが、サブで使っているマシンでアップデートしようとしたら、インストールのための再起動で失敗しました。Boot macOS Install from xxxxが選択された、起動しようとするところで失敗し、再び再起動を無限に繰り返すようになりました。

たまにしか使わないサブのマシンでしたので、しばらくはあきらめて10.13.1の古いままで使っていました。このところ時間もできたのでじっくりと原因を探して見たら、なんとkextの一つ、Lilu.kextが古いだけでした。Lilu.kextは10.13.2のベータ版に合わせて11月上旬に1.2.1に更新されています。メインのマシンでは早々と更新していたのですが、サブマシンでは1.2.0のままでした。とほほな単純ミスでした。

ということで、最初にも書きましたが、Cloverとkext類は最新に保っておきましょう。

HackintoshでmacOS Serverを運用

Sun, 03 Dec 2017 22:42:38 +0900

更新：MojaveになってmacOS Serverからほとんどのサーバ機能が廃止されてしまいました。廃止された機能の多くはmacOSに移行されたので、macOSでサーバを立上げるメリットはまだあると思います。

macOSは基礎がUNIXなのでWindowsに比べてネットワークやサーバ関連のツールが充実しています。最初からApacheやsshdやPHPなどが搭載されています。なのでサーバとして使うのにも適しています。

Server.appを購入する

Server.appというアプリケーションはApp Storeで購入できます。これをインストールするとmacOS Serverになります。macOSは無料なのですが、Serverは2,400円します。しかし、昔はユーザ数無制限のMac OS X Serverが10万円くらいしたことを考えると、夢のような価格です。

もっとも、現在のServer.appは、OSそのものではなくて、すでに搭載されているサーバ機能をonにしたり、設定を管理するユーティリティです。昔のようにOSをインストールする手間に比べると、今のmacOS Serverは気軽に導入できるかと思います。

HackintoshでServerするメリット

HackintoshでServerするメリットは多いと考えています。Hackintoshで比較的難しい課題は、iMessageなどのiCloud関連のアプリケーションをちゃんと動かす、iOSやwatchOSとの連携をする、グラフィックスを正しく動かす、スリープを機能させるなどです。どちらかというとクライアントとして使う上での課題です。一方で、24時間稼働させるサーバならば、スリープなどの電源管理はあまり重要ではないです。ディスプレイやキーボード無しで運営するなら、グラフィックス機能は不要です。ssh接続や画面共有で設定すれば良いからです。なので、ちゃんと動くサーバを作ることは、完璧に動くデスクトップマシンを作るよりずっと簡単です。

また、必要とするサーバに特化したハードウェア構成が自由に選べるのもHackintoshのメリットです。

大きなPCケースを選んで、大容量のHDDを多数搭載したサーバを作ることもできます。複数のHDDをRAID 1構成にして、HDD障害に敏速に対応する体制を作ることもできます。また、大容量のHDDを搭載して、TimeMachineサーバを作ることもできます。TimeMachine機能を使って、大容量HDDにサーバー自身のバックアップを作っておくことも簡単です。

このような重量級サーバが作れる一方で、NUCなどを使えば、低消費電力のサーバを作ることもできます。NUCはMacBook Airなどで搭載するモバイル用の低消費電力CPUを搭載しているにも関わらず、メモリやストレージなどは簡単に増設できます。家庭で24時間稼働させる小型の省電力サーバを作るのには最適かと思います。

（NUC消費電力の例）

macOS Serverで何ができる

ではmacOS Serverで何ができるかというと、実のところ多少微妙なところはあります。例えば、Linuxでサーバを作る方が、多彩なサーバを作ることができます。様々な構成を自作できるメリットはHackintoshと同じです。macOSも、土台がUNIXなので、様々なサーバ機能をLinuxと同じく手作業で設定することももちろん可能です。ただ、これらの設定は、OSのバージョンアップで動かなくなる可能性があります。また、運用しているユーザも少ないので、情報が得られにくいです。macOS Serverが提供している機能だけを素直に使用するのが簡単だと思います。

一方、macOS Serverは、できることが限られていますが、サーバとしては比較的簡単に設定して、管理することができます。代表的な機能は、Webサーバ、VPNサーバ、メールサーバ、DHCPサーバ、DNSサーバ、カレンダ、メッセージ、連絡先などのサーバがあります。あまり使わないかもしれませんが、プロファイルマネージャサーバ、Netinstallサーバ、Xsanサーバがあります。VPNは、当然ですがmacOSクライアントと相性が良いので、設定が楽です。ちなみに、ファイルサーバ機能は、macOS通常版で提供されていて、macOS Serverには特に機能がありません。また、コンテンツキャッシュ（ソフトウェアアップデートやiCloudのキャッシュ）とTimeMachineサーバの機能は、High Sierra Server機能ではなくなり、High Sierra通常版で提供されるようになりました。コンテンツキャッシュはiCloudデータをキャッシュしてくれるので、自宅と職場で同期するなどの場合に、遅延の少ない確実な同期を期待できます。TimeMachineと共に、便利な機能なので、クライアントmacOSの機能に格上げされたのだと思います。

macOSが提供するサーバ機能の多くは、QNAPやSynologyなどのNAS製品を使えば、使いやすいインタフェースで構築可能です。でも、外部から接続できる常時稼働macOSマシンがあると、いろいろな場面で便利かと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/posts/126/

Clover EFI Bootloader

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

sourceforge.net

FakeSMC.kext

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

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

Lilu.kext

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

/posts/118/

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

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

sourceforge.net

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

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

sourceforge.net

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

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

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

github.com

そのほかのkext

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

Ethernetを設定する

/posts/120/

USBポートを設定する

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

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

Cloverインストーラの設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(8) config.plistを編集する

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

config.plistの実例紹介

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

[XML] Clover config.plist – Pastebin.com

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

DisableDrivers
CsmVideoDxe
VBoxExt4

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

#DisableDrivers
CsmVideoDxe
VBoxExt4

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

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

(9) SMBIOSを設定する

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

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

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

[XML] Customized config.plist – Pastebin.com

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

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

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

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

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

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

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

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

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

iMessageを動かす

Thu, 28 Sep 2017 23:11:19 +0900

Hackintoshの完成度を評価する目安は色々あります。例えば、起動するかどうか、画面が出るか、音が出るか、LANに接続できるか、WiFiが動くか、iPhoneと連携できるかなどあります。中でも、iMessageが動くかどうかは機種情報が正しく設定できていることの目安になります。

iMessage騒動

2014年の8月に、多くのHackintoshが、iMessageに繋がらなくなりました。「カスタマーコード」が表示され、iMessageサポートに連絡せよというダイアログが出て、締め出されて（ロックアウト）しまったのです。サーバ管理者側でセキュリティポリシーが変更されたことなので、具体的にどうなったのか知る由もありません。でもHackintoshコミュニティが手探りで試し尽くしたところ、機種ID、ロムとメインロジックボードのシリアル番号情報が、接続ごとに変動したり、フォーマットが正しくない場合に接続できないらしいとわかりました。

2014年のセキュリティ強化はあまりに過激すぎたのか、Appleサポート掲示板を見ると、本物のMacユーザにも支障が出ていたようです。セキュリティはその後、緩んだり厳しくなったりして、11月頃には、とうとう実機のシリアル番号じゃないと接続できなくなったこともありました。でも2015年の2月のバレンタインデーに、突如チェックが緩和され、ロックアウトが発生しなくなりました。それでも、シリアル番号やボードシリアル番号などは、設定機種に合った正しいフォーマットのデータを継続的に使用することが良いとされています。間違った設定を行っても、ロックアウトには至らなくなりましたが、接続できない問題が発生するようです。

en0に設定する

iMessageに限らず、Appleのネットサービスを利用するためには、EthernetもしくはWi-FiのBSD装置名がen0である必要があります。実機がそうなっているからです。en0になっていないと、iMessageは使えませんし、App Storeへの接続でもエラーが出ます。

以下の記事でも紹介していますが、

Ethernetを設定する

以下のファイルを消して再起動すれば良いです。

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
/Library/Preferences/SystemConfiguration/Preferences.plist

また、en0があってもこれの状態がBuiltinになっていないと接続できないことがあるようです。コメントで教えていただきました。こちらに説明があります。これの対処法も、上記のファイルを消して再起動すれば良いようです。

シリアル番号類を正しいフォーマットで設定する

先のiMessage騒動の時に、iMessageに認められる正しいシリアル番号のフォーマットが、コミュニティの協力で調べられました。その結果が、Clover Configuratorの自動生成機能に組み込まれています。なので、これを利用して、正しい情報を設定しておけば良いです。以下の記事で紹介しておきました。

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

注意すべき点は、一回設定したら、継続して使い続けることです。iMessageにログインするたびに機種情報が変動すると、不正な利用とみなされて接続できなくなる場合があるようです。

iMessageへの接続失敗を無かったことにする

以前にiMessageにログインしようとして失敗したことを無かったことにするためには、以下のファイル/ディレクトリを消して再起動すると良いそうです。

~/Library/Caches/com.apple.Messages*
~/Library/Caches/com.apple.imfoundation*
~/Library/Preferences/com.apple.iChat*
~/Library/Preferences/com.apple.imagent*
~/Library/Preferences/com.apple.imessage*
~/Library/Preferences/com.apple.imservice* ~/Library/Messages

ただし、ロックアウトが発生していた時は、ローカルの記録をいくら消去しても無駄でした。失敗した記録は当然ですがサーバ側にも残っているようです。

そのほかの条件

大抵の場合は、en0にすることと、SMBIOSで機種情報を正しく設定することで、iMessageを利用できます。それでも、接続がうまくいかなくて苦労している人もいるようです。ネット上にはたくさんの対処法が紹介されています。わかりやすいガイドには以下があります。

www.tonymacx86.com

www.youtube.com

iMessageのメッセージが届かないとか、遅延するなどの問題も報告されますが、実機を使っても、同様なことが発生します。なので、実はHackintoshの問題ではなく、iCloud / AppleID自体のトラブルである可能性も高いです。

また、古くからのApple IDユーザのアカウントであったり、クレジットカードを登録しているアカウントは問題を起こしにくいという噂もあります。本当かもしれませんし、都市伝説みたいなものかもしれません。さらには、最近はApple IDが2ファクタ認証に移行しつつあります。2ファクタ認証しているApple IDは従来よりセキュアなので、その結果ロックアウトされにくいように思います。何れにしても、サーバ側でどのように運営しているかは謎ですし、そのポリシーも変化していると思われます。

HackintoshをHigh Sierraにする

Tue, 26 Sep 2017 12:18:21 +0900

Sierraで動いているHackintoshなら移行は簡単

High Sierraが出ました。HackintoshはOSのバージョンアップの時に設定がダメになって苦労する、と思い込んでいる人も多いかもしれません。でも、最近はとても簡単になりました。マイナーバージョンアップ（例えば10.12.5から10.12.6へのバージョンアップ）なんて、App Storeからダウンロードしてクリックするだけです。実機と同じです。今回のようなメジャーアップデート（10.12から10.13）は、いろいろと対応する必要がある場合もあります。でも、今年は楽勝の部類でした。

ということで、すでにSierraで動いているHackintoshをHigh Sierraにアップデートする方法を書いておきます。ここで紹介する手順は、別ドライブを用意してそこにHigh Sierraをインストールする手順です。

Sierra版の現状のHackintoshを最新版にアップデートしておく(Step 1~2)
別ドライブを用意してそこにHigh Sierraをインストールする(Step 3)
APFS起動に必要なapfs.efiをHigh Sierraから手に入れる(Step 4)
High SierraドライブにCloverを仮インストールする(Step 5)
現状のSierra HackintoshのESPをHigh Sierraドライブにコピー(Step 6)

別ドライブでちゃんと起動したら、あとはゆっくり、メインドライブのHigh Sierra移行にとりかかってください。

Step 0: macOSをバニラな状態にしておく

簡単に移行するための前提です。こちらで解説して置きましたのでごらんください。

/posts/131/

つまり、macOSが入っているパーティションの内容には一切手を加えないで、実機と全く同じ状態にしておけば、アップデートは簡単になるということです。

Step 1: 旧バージョンSierraのHackintoshを最新にしておく

ここからが作業本番です。Hackintoshコミュニティのハッカーの方々は、High Sierraに向けて更新してくれています。なので、移行前に、最新にしておきましょう。最新にすることでSierraが動かなくなることはありません。最新にしてもSierraがちゃんと動くことを確認してきましょう。

まずはCloverを最新にします。今日現在ではリビジョン4220が最新のようです。システム環境設定に登録してある場合は、「更新を確認」するだけです。
kextを最新にします。kextの名前でGoogle検索すると配布サイトが出てきますので、最新版に差し替えておきましょう。
kextをEFI/CLOVER/kexts/10.12に入れている人は、10.13を新たに作ってコピーするか、Otherフォルダにコピーしておきます。

詳しくはこちらをご覧ください。

あと13日！High Sierraのお迎え準備

Step 2: config.plistのSMBIOS情報を最新にしておく

OSとしてのHigh Sierraの一番の変更点は、ファイルシステムがHFS+からAPFSに移行することです。High Sierraのアップデートでは、APFSでも起動できるようにファームウェアもアップデートされます。Hackintoshにとっては関係のないことですが、ファームウェアが対応版にアップデートされていないと判断されると、インストールが止まってしまうようです。そこでconfig.plistのSMBIOSセクションのBIOSバージョンの記述を、最新版ファームウェアと同じバージョン番号に書き換えます。

詳しい手順は、これもこちらをご覧下さい。

あと13日！High Sierraのお迎え準備

Step 3: High Sierraを別ドライブにインストールする

ここまでのステップで準備がしっかりできたので、ここから先は簡単です。

High Sierraをインストールするドライブを接続します。SSDでもHDDでも良いです。USB接続でも良いです。自作の人なら、余っているドライブをSATAケーブルでマザーボードに接続しても良いですね。

このドライブをディスクユーティリティでフォーマットします。フォーマットは、GUIDパーティションマップとHFS+ (Mac OS拡張ジャーナリング）とします。SierraのディスクユーティリティではAPFSを選択できません。が、ここでHFS+でフォーマットしても、SSDの場合は、この後のインストールで自動的にAPFSに変換されます。

Apple App StoreからHigh Sierraインストーラをダウンロードして、このドライブにインストールします。インストール途中で再起動することがあります。その場合は、現行のドライブで起動して、Cloverのメニューからインストール途中と思われるドライブを選択します。「Boot macOS Install from XXXX」というのがインストール途中にだけ現れるボリュームで、これを選択します。

途中の起動回数は、いつもは1回の気がしましたが、今回は2回のようでした。たまたまかもしれませんが、もしかしたらファームウェアをアップデートする作業（Hackintoshでは無駄な作業ですが）があったのかもしれません。もしくは、APFS変換の関係なのかもしれません。

インストールが終了したら、やはり、再起動します。インストール途中の再起動なのか、インストールが終了した後の再起動なのかは、先ほどの「Boot macOS Install from XXXX」というボリュームの有無で判断できます。Cloverの選択画面にこれがなくなっていれば、インストールは終了しています。

インストーラがHFS+でHigh Sierraをインストールした場合、Cloverのボリューム選択にHigh Sierraが現れていると思います。High Sierraを起動しても良いのですが、ここは、ぐっと我慢して次のステップに行きましょう。APFSに変換された場合は、High Sierraが現れていないと思います。次のステップで対応します。

次のステップでは、まずは古いSierraのドライブを選択して起動します。

Step 4: 最新版のAPFSドライバapfs.efiをESPに入れる

2018/06/19更新：Clover 4558からApfsDriverLoader.efiというドライバができて、apfs.efiの機能を自動的にロードしてくれるようになりました。なので、 /usr/standalone/i386/ からapfs.efiを取り寄せてESPに置く以下の作業は不要になりました。記録のために残しておきます。

High Sierra Public Betaの初期のバージョンでは、HFS+でのインストールがメニュー選択で可能でした。しかし、正式版をSSDにインストールする場合は、自動的にAPFSフォーマットに変換されるようです。HDDやFusion driveの場合はHFS+のままのようです。

Clover、というか一般にブートローダは、OSが起動する前に、ドライブからブートのためのファイル（例えばカーネルなど）を読み込む必要があります。なので、ファイルシステムにアクセスできる必要があります。この機能は、High Sierraの

/usr/standalone/i386/apfs.efi

で行えます。そこで、このファイルを、CloverのESPにコピーします。それを行わないと、APFSでフォーマットされたHigh Sierraを起動できません。そこで、APFSブートには以下のステップが必須です。

APFSでインストールしたHigh Sierraの起動はひとまずお預けにして、今まで通りHFS+の古いSierraを選択して起動します。この時High Sierraを選択したくてもAPFSなので選択画面に現れていないはずです。
CloverのESPをマウントします。
High Sierraの中のapfs.efiをEFI/CLOVER/drivers64UEFIの中にコピーします。
再びSierraのボリュームで起動すると、今度はAPFSのHigh SierraがClover選択画面に見えているはずです。これを選択して起動します。

ベータ版時代のバージョンアップでapfs.efiは度々更新されていました。初期のベータ版から入手したapfs.efiで、後期のHigh Sierraが起動できなかったこともあります。apfs.efiがネットに落ちていることもありますが、公開版High Sierraに入っている最新版を使うのが良いでしょう。

High Sierraは起動しましたでしょうか？うまく起動すれば、ユーザ設定などの画面に進み、ログインできます。ここまでくればもう安心です。

Step 5: High SierraのドライブにCloverをインストールする

このステップは飛ばしても良いです。

現行のドライブのCloverからHigh Sierraのドライブが無事起動できて、アカウントなどの設定が終わったら、Cloverのインストーラを起動して、新しいドライブにCloverを入れます。このとき、ESPにインストールするよう指定します。

Step 6: 現行のESPからファイルをHigh SierraのESPにコピーする

High SierraのESPには、とりあえずインストールしたClover関連のディレクトリができているはずです。前のステップを省略すると、できていないかもしれません。何れにしても、古いSierraのドライブのESPの内容を、新しいHigh SierraのESPにコピーして、同じ内容にします。ファインダーからのドラッグ&ドロップで作業しても問題ありません。これで、High Sierraのドライブを起動ディスクにしても、ちゃんとHigh Sierraが起動するはずです。

次のStep: メインドライブのアップデート

これで無事、別ドライブで起動できましたでしょうか。問題なければメインドライブもアップデートしましょう。このステップと同様に、今度は、High Sierraのドライブから、メインドライブにインストールしていけば良いです。上書きインストールでも、いっそすっきりとフォーマットしてのクリーンインストールでもどちらでも良いと思います。Time Machineでバックアップとってあれば、クリーンインストールの後で移行することもできます。

補足

SMBIOSのデフォルト設定

Clover r4179以降では、config.plistで以下の値：

BiosReleaseDate
BiosVersion
FirmwareFeatures
FirmwareFeaturesMask

を指定しなくても、機種モデルの最新の値がデフォルトで設定されるようになったという情報もあります。実際にBiosVersionを削除して見たところ、それでも最新の値が使われていました。Step 2の作業の代わりに、これらの指定を単に削除して、Cloverのデフォルトに任せるのも可能かと思われます。

http://www.insanelymac.com/forum/topic/304530-clover-change-explanations/page-4#entry2482211

apfs.efiを入手するもう一つの方法

上記の説明では、High Sierraをインストールした後で、apfs.efiを入手しています。インストールする以前の、Install macOS High Sierra.app (日本語名は macOS High Sierraインストール.app)から取り出すこともできます。.appの中の

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

にあるBaseSystem.dmgを開いてマウントします。次に、

/Volumes/OS X Base System/usr/standalone/i386/apfs.efi

の場所にあるapfs.efiを手に入れます。これで、Step 3の段階でapfs.efiを入手してESPに入れることができ、すぐにHigh Sierraから起動できます。

パッチを当てるkext: Lilu.kext

Sat, 23 Sep 2017 23:09:00 +0900

Lilu.kextはkext (カーネル拡張)にパッチを当てる仕組みを提供するkextです。ライブラリやプログラムにもパッチを当てられるようですが、kextにパッチを当てるために便利に用いられています。今年になってから登場した新しいkextです。元々は、サウンドを提供するkextであるAppleALC.kextを開発していた人が、パッチ当ての部分を分離して公開してくれたものです。なので、現在のAppleALC.kextもLilu.kextを使っています。

Releases · acidanthera/Lilu

Lilu.kextはパッチを当てるkextと一緒に使います。バニラな構成ならば、それぞれをEFI/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。Cloverもconfig.plistのKextsToPatchセクションの記述でkextにパッチを当ててくれます。この記述は簡単なのですが、kext本体のバイナリーファイルにしかパッチを当てられません。Lilu.kextは、パッチ方法を指定するkextを開発する必要がありますが、kext本体以外の様々なファイルや設定にパッチを当てられるようです。

以下で、Lilu.kextと一緒に使うためのkextを紹介します。

AppleALC

macOSのHD audio機能を使って音を出すためのパッチ。こちらで説明しました。

/posts/120/

古いバージョンは単独で動きますが、パッチ当て機能をLilu.kextに分離した後のバージョンは、Lilu.kextと一緒に使います。

Releases · acidanthera/AppleALC

WhateverGreen

~~10.12.6からRX480/580などのAMDグラフィックスカードがサポートされました。しかし、メインディスプレイにはならず、起動時にはCPU内蔵GPUなどの補助GPUが必要でした。これを解決するのがWhateverGreen.kextです。Radeonを使う人には必須です。~~以前はAMDグラフィックスカードの不具合に対応するkextでした。それでAMDカラーのgreenという名前が付いています。今は、

IntelGraphicsFixup
NvidiaGraphicsFixup
Shiki

の機能を統合し、ディスプレイに関係するパッチ機能をすべて盛り込んだkextになりました。詳しくは以下をご覧ください。これを入れれば統合されてしまったkextは使う必要がありません。

NvidiaGraphicsFixup

このkextはWhateverGreenに統合されました。

NVIDIAのGPUをiMac15,1 iMac17,1 MacPro 6,1のシステム設定で使おうとすると、ブート後に画面が黒くなって起動しなかったり、画面がスリープしたりする問題が発生します。 WebドライバだけでなくmacOS標準のドライバでも発生します。 iMacのレティナディスプレイやProのデュアルグラフィックスカードハードウェアを前提とした macOSの設定が、この問題を引き起こしているようで、black screen問題と呼ばれています。このkextを使うと、black screenを回避できます。

Releases · lvs1974/NvidiaGraphicsFixup

IntelGraphicsFixup

このkextはWhateverGreenに統合されました。

~~Intel HD Graphicsを使う場合に発生する以下の不具合を解決します。~~

~~Intel Graphics HD4000以降のブートロゴ表示の乱れ~~
~~Intel Azul Graphics (HD4400, HD4600)におけるPAVPフリーズ問題~~

ブートロゴの乱れは、起動時のアップルロゴとプログレスバーが表示される場面の後半で、表示が8個に分裂してストライプ状になる現象です。起動時だけのことで、無視しても良いくらいの問題ですがこれが解決されます。もう一つのPAVPフリーズ問題はもっと深刻で、一部の動画サイトをSafariで閲覧する場合や、iTunesでiTunes Storeの予告編を見る場面で、動画再生が滞ったり、場合によってはOSがフリーズする問題です。

Releases · lvs1974/IntelGraphicsFixup

Shiki

このkextはWhateverGreenに統合されました。

iTunesにあるDRM保護されているビデオはivy bridge以降で再生できない問題があります。購入した映画や、その予告編を再生しようとすると、映像が出ないとか、音だけしか出ない状態です。これを回避します。

Releases · acidanthera/Shiki

NightShiftUnlocker

10.12.4から導入されたNight Shift機能ですが、これにはMacBookPro9,x iMac13,x Macmini6,x MacBookAir5,x MacPro6,x MacBook8,x以降の機種が対応しています。これより古い機種でNight Shiftを動かすためのkextです。

Releases · 0xFireWolf/NightShiftUnlocker

そのほか

用途・効果を理解できていないのですが、Lilu.kextのサイトによると、このほかにも以下のようないろいろなパッチがあるようです。

AirportBrcmFixup Broadcom Airport Wi-Fi cardsへのパッチ

AzulPatcher4600 Intel HD 4600 へのパッチ

CoreDisplayFixup 非Iris Intel graphicsの高解像度サポート

CPUFriend 動的なパワーマネージメント

EnableLidWake ラップトップで蓋を開けた時のIntel Graphicsスリープ解除対応

HibernationFixup 3モードと25モードのハイバネーション対応

Jeffさんのインストールガイドビデオ

Tue, 19 Sep 2017 13:25:38 +0900

ネット上にはたくさんのインストールガイドの文章や動画がありますが、これが一番わかりやすくて見やすいと思います。9TO5Macに記事を書いているJeff Benjaminさんのビデオです。9TO5Macの記事にも連動しています。テンポが良くて、映像が綺麗です。バニラなインストール方式なので、のちのOSアップデートが簡単です。ナレーションは英語ですが、聞き取れない箇所があったら字幕をonにすると良いです。

Hackintosh 101: the macOS Sierra step-by-step install guide

次の手順でインストール作業を進めています。

Apple App StoreからSierraをダウンロードする
インストーラが起動するので中断する
USBメモリーをフォーマットする
createinstallmediaコマンドを使ってUSBメモリにmacOSインストーラを入れる
必要ファイル（Clover, FakeSMC.kext, LANとAudioとgraphicsのドライバ）を入手する
Cloverインストーラを起動してUSBメモリにCloverを入れる（インストール先はESPにしてバニラインストールする。OsxAptioFixDrv-64を入れる）
FakeSMC.kextとLANのkextをUSBメモリに入れる
インストール先のマシンにこのUSBメモリを挿す
マザーボードのUEFI設定画面で必要な設定をする
USBメモリから起動してSierraをマシンにインストールする
USBメモリのCloverからマシンのSierraを起動する
Cloverを対象マシンにインストールする。FakeSMC.kextとLANとAudioとgraphicsのkextを入れる
色々設定する。例えばブラックスクリーン問題が起きないように機種を設定する

補足

ステップ12のあたりで、マシンから起動したら大成功ですね。あとのステップは、ゆっくり調整すれば良いところです。とてもわかりやすくて、適切なガイドなのですが、補足と、ちょっとだけ気になったところを書いておきます。

Nvidia Web driverの有効化

ビデオの中ではnvda_drv=1というブートコマンドを使っていますが、最近ではこれが効かないらしいです。config.plistに以下のように書くのが良いようです。

        <key>SystemParameters</key>
        <dict>
                <key>NvidiaWeb</key>
                <true/>
        </dict>

OsxAptioFixDrv-64.efi

ビデオでは、OsxAptioFixDrv-64.efiを使っていますが、マザーボードによってはOsxAptioFix2Drv-64.efiの方が良いこともあります。また、どっちでも起動できないことがあります。その場合は、OsxAptioFix2Drv-free2000.efiというドライバをGoogle検索して探して入れて見ましょう。これらのefiが機能しないと、macOSを最初に読み込むところで（++++マークが並んだ直後で）止まってしまいます。なお、これらのドライバを２種類以上入れるとどれが動くかわからないので、一つだけにします。

mountコマンド

ビデオの中では、mountコマンドを使ってEFIをマウントしています。mountコマンドは、UNIX起源の素朴なコマンドです。macOSが提供しているdiskutilコマンドの方が適切です。diskutil mount /dev/disk0s1 などとタイプします。この方法だとパスワードが不要です。このほか、EFIのマウントの話題はこちらもご覧ください。

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

LANのkext

ビデオの中では、AppleIntelE1000e.kextを使っています。Ethernetのkextについて、以下の記事を書いておきました。ここにあるようにIntelのチップに対しては、AppleIntelE1000e.kextよりも、IntelMausiEthernet.kextの方が評判が良いようです。また、Intel以外のチップに対しては、それぞれに対応したkextを使います。

Ethernetを設定する

機種設定

完璧な機種設定方法はこちらに書いておきましたので参考にしてください。ビデオで紹介されている方式は、簡易的な方式で、Jeffさんも言っていますがiMessageが動きません。

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

ブラックスクリーン問題

機種を正しく設定するとブラックスクリーン問題が発生するかもしれません。Jeffさんのビデオでは、問題の発生しない機種に設定して、この問題を避けています。機種設定を正しくした上でブラックスクリーン問題を回避するには、Lilu.kextとNvidiaGraphicsFixup.kextを使ってください。こちらに解説がありました。

www.reddit.com

そのほかの参考記事

インストールに関するここのブログの記事もご覧ください。

マザーボードの設定はこちらに書いておきましたので参考にしてください。

マザーボード (BIOS) 設定

kextの解説はこちらです。

/posts/126/

Cloverインストールの解説はこちら。

Cloverインストーラの設定

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

Mon, 18 Sep 2017 19:52:05 +0900

Hackintoshは本物のMacintoshではありませんが、macOSは本物の機種上で動いていると思い込んでいます。Macintoshの機種名によってハードウェア構成が違いますから、それに合わせた効率的な動作を行ったりする可能性もあります。またiPhoneとの連携、iMessage, iCloudなどのサービス利用の際に、機種名をチェックし、不整合があると機能を止めることもあります。

なので、実際のハードウェア構成に近い実機のふりをして、その情報を正しく設定しておくことが重要です。

Clover Configuratorを使って設定

ハードウェアを特定する情報は、Cloverのconfig.plistの中の、SMBIOSセクションに書き込まれます。この記事では、その書き方を説明します。SMBIOS (System Management BIOS)というのは、BIOSを使っていたマザーボードにあるシステムを記述する機能です。

SMBIOSセクションに書き込む内容を作るために、Clover Configuratorの機能が便利です。これを起動して、左のメニューからSMBIOSを選択します。右の画面で、いろいろな設定をします。

機種を決める

まずは、Macintoshのどの機種にするかを決めます。ハードウェア、特にCPUが近いものが良いです。CPUが近ければ、チップセットも同じですし、ハードウェアの動作も近いと考えられます。Macintoshの仕様を確認するためにはMactrackerというフリーウェアが便利です。

‎Mactracker

自作PCならば、おそらくiMacのどれかが適当だと思います。Xeonなどを使う場合は、もしかしたらMac Proかも。またIntel NUCなどで自作する場合は、Mac miniとかMacBook Airなどに同等または近いCPU搭載機種が見つかるかもしれません。

例えば、Kaby LakeのCore i7 7700Kで自作したマシンなら、iMac18,3が最適です。

Clover ConfiguratorのSMBIOSを選ぶと現れる大きな疑問符の右下のボタンを、クリックします。すると機種一覧が出ますので、ここから目的の機種、例えばiMac18,3を選びます。

シリアル番号を決める

最初に決めるのはシリアル番号です。左のほうに、Serial Numberと書かれた場所の番号です。

このシリアル番号はある規則に従って、自動生成されています。最初のアルファベットが製造地（Cは中国）で、次が年号、その年の週、その週に生産された何台めであるかの番号、機種を表す記号、などが特定の規則に従って記載されています。Generate Newというボタンを押すと、番号を生成し直してくれます。変化する部分が、週と製造番号の部分です。

未使用のシリアル番号であることを確認

こうして生成したシリアル番号と同じ番号を持つMacintoshが実在する可能性があります。その場合、実機のユーザに迷惑をかけ、Hackintoshする事に支障が出るのではないかと、コミュニティの人たちは心配しています。そこで、実在するシリアル番号と重複しない番号を使うことが強く推奨されています。

実存の番号と重複しているかどうかの確認方法は、簡単です。生成したシリアル番号をコピーして、以下のページにペーストします。

Check Your Service and Support Coverage - Apple Support

この結果、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。もし、保証状況やサービス期間の案内が出るようなら、このシリアル番号は実機で使われている番号です。その場合は、別のシリアル番号を生成し直します。実際に生成してみるとわかるのですが、実存するシリアル番号に当たることはほとんどありません。

SmUUIDを設定する

SmUUID と書かれた欄が空白かと思います。UUIDはオブジェクトを一意に識別するための128ビットの数値です。例えばSSDやHDDにも付いていて、ボリュームを識別できます。ソフトウェアによってはSmUUIDで不正利用のチェックをしているようなので、一旦決めたらめったには変更しないようにしましょう。

UUIDはターミナルを開いて、uuidgenというコマンドをタイプすると生成できます。

$ uuidgen
97809030-7837-424E-BB69-246B934CB66D

何度か生成して、適当な番号を選べば良いです。これをコピーして、Clover ConfiguratorのSmUUIDの欄にペーストします。

その他の値

その他の値は自動生成された値で問題ありません。

Board Serial NumberはMacintoshのロジックボードのシリアル番号です。適当にそれっぽい値が生成されているので、そのまま使います。Bios Versionは、High Sierraで重要になりました。APFSからの起動に対応しているかをこれでチェックし、対応していないとインストールできないようです。最新のClover Configuratorを使えば、対応したバージョンが生成されます。この他、Firmware FeaturesやFirmware Features Maskなどは機種を特定するための値です。これもHigh Sierraのインストールに必要なようです。

config.plistに書き込む

Clover Configuratorは設定した値を元にCloverのconfig.plistを作ってくれます。とはいえ、SMBIOSの設定しかしていませんので、中身はSMBIOSのセクションだけです。

作った内容をconfig.plistファイルに書き出すメニューがあります。もしくは、左の一番下にある、Text Modeを選ぶと、設定に基づいたconfig.plistをテキスト形式で観ることができます。これらのSMBIOSセクションをコピーして、Cloverのconfig.plistに書き込みます。

補足

SMBIOSのデフォルト設定

Clover r4179以降では、config.plistで以下の値：

BiosReleaseDate
BiosVersion
FirmwareFeatures
FirmwareFeaturesMask

http://www.insanelymac.com/forum/topic/304530-clover-change-explanations/page-4#entry2482211

(2019/4/10 加筆）

さらに、最近のCloverでは、SMBIOSのかなりの部分を自動的に作ってくれるようです。ファームウェアバージョンなどを最新にしてくれるようなので、config.plistで指定しない方が良いかもしれません。ということで以下の4種類、

BoardSerialNumber
ProductName
SerialNumber
SmUUID

を指定しておくだけで良いらしいです。

Hackintoshのためのkext入門

Fri, 15 Sep 2017 23:23:26 +0900

改定：2018/9/15

kextとは

kextとはKernel EXTension（カーネル拡張）の略で、カーネルと呼ばれるOSの本体を拡張する一連のファイルです。OSに必要とされる機能が増加し、いちいちカーネルに組み込んでいると管理が大変になったので、別ファイルにして必要に応じて組み込むことになりました。macOSに限らず、多くのOSで一般的な方式です。ネットワーク、グラフィックス、サウンドなどのハードウェアを動かすデバイスドライバの機能も、kextとして提供されています。

Hackintoshのためには、Hackintoshを実現するためにmacOSの機能に手を加えるkextや、実機でサポートされていないハードウェアを動かすためのkextなどが開発されて、配布されています。必要なものを集めてHackintoshにインストールします。

kextの置き場所〜macOSの場合

macOSでは、kextを/System/Library/Extensions/ (/S/L/Eと略されます）もしくは、/Library/Extensions/に置きます。/S/L/Eに置くkextは、SIPで署名チェックされます。なので、当然ながら署名のないHackintosh用のkextを加える場合、SIPをdisableにする必要があります。

/posts/132/

kextは、実はファイルではなくてディレクトリです。macOSのファインダーからファイルのように見えているだけで、中には、多数のファイルが含まれています*1。これらのファイルの全てがカーネルから実行できるように、パーミッションが正しく設定されている必要があります。また、kextを起動のたびにkextファイルから読むと時間がかかってしまいます。そこで、キャッシュして高速化を図っています。なので、新しいkextを加えるためには、単にディレクトリにコピーするだけでなく、中身のすべてのファイルのパーミッションを正しく設定して、キャッシュを作り直さないといけません。この作業をGUIで実行するツールも配布されています。

kextの置き場所〜Cloverの場合

kextの追加をCloverにお任せすれば、前節のややこしそうなkextインストールの手間は無関係です。EFI/CLOVER/kextsの中にkextを入れておくとCloverが追加してくれます。SIPはenableのままで大丈夫です。またパーミッション設定もキャッシュ作り直しも不要です。ディレクトリに入れるだけです。以前は、kextによっては（例えばLANのkext）/S/L/Eに入れないと機能しないこともありましたが、最近では、ほとんどのkextがCloverのディレクトリに置いても問題なく機能します。それでも依然として、/S/L/Eに置かないと機能しないkextも稀にありますので、その場合は試行錯誤して確認してください。

EFI/CLOVER/kextsは、macOSのルート、もしくはボリュームのESPのどちらかにあります。デフォルトはmacOSのルートですが、その場合、macOSをまっさらに入れ替えると消えてしまいます。ESPにおいてあれば、アップデートで変更されないので管理が容易です。ESPにCloverをインストールする方法は、バニラインストールとも言われます。以下で説明してあります。

/posts/131/

EFI/CLOVER/kextsの中には、macOSのバージョン番号のディレクトリと、Otherという名前のディレクトリがあります。Cloverは、

まず、Otherに入っているkext
次に、該当するバージョン番号のディレクトリに入っているkext

の順番で、kextをインストールします。この後はmacOSに引き継がれて、/L/E、/S/L/Eの順にkextがインストールされます。同じ名前のkextがあったとしたら、後からインストールされた方が優先します。

kextは、該当するバージョン番号のディレクトリに入れておいても良いです。もしくは、バージョン番号のディレクトリは使わない（空にしておく、もしくはそもそもディレクトリを作らない）でOtherに全部入れておいても良いです。両方に入れても良いですが、混乱しやすいかもしれません。皆さんのやりやすい方法で管理すれば良いです。

FakeSMC.kext

kextはたくさんありますが、FakeSMC.kextは、Hackintoshするために唯一で必須のkextです。SMCはSystem Management Controller（システム管理コントローラ）の略です。昔は、PMU (Power Management Unit)と呼ばれていました。Macintoshの電力をコントロールしたり、ハードウェアをコントロールするサブシステムです。メインのCPUとは別に、SMCと呼ばれるマイクロコンピュータが内蔵されていて、それがハードウェアの管理を仕切っています。Macintosh独自のもので、ATXマザーボードには（もちろん近いものは搭載されていますが、同一のものは）搭載されていません。でもmacOSはSMCがあるものと思って働きかけてきます。そこで、SMCのふりをするフェイクのSMCを実現するのがFakeSMC.kextです。

NullPowerManagement.kext

現代のCPUは、負荷によって動作周波数を変更したり、スリープをしたりして、消費電力を制御しています。この結果、省電力を実現し、発熱量を減らしています。搭載しているCPUがどのように電力制御を行うかの情報は、マザーボードからACPIテーブルを介してOSに伝えられます。ただ一般のマザーボード使用を想定していないmacOSには、この情報が正しく伝わらないことがあります。そもそも実機で採用されていないCPUの場合には、macOSで対応することができないこともあります。CPUの電力制御が正しく行えない場合、macOSがカーネルパニックを引き起こして起動しないこともあります。

macOSでCPUの電力制御を担当しているkextは、AppleIntelCPUPowerManagement.kextです。NullPowerManagement.kextはこのkextを無効にします。その結果、電力制御関連の設定が正しく行われていなくても、とりあえずはHackintoshが起動するようになります。なので、tonymacx86で配布されているインストール用USBメモリ (UniBeast)などのインストーラではこのkextが使われます。

起動してくれるのはありがたいのですが、電力制御が行われないので、CPUは最大出力で稼働し続けます。そこで、DSDT, SSDT, config.plistなどを正しく設定してこのkextがなくても起動するように調整することが、Hackintosh作りの一つの目標になります。

このほかのkext

このほかの主なkextには、

Ethernetを動かすためのkext
サウンド関係のkext
USB関係のkext
グラフィックス関係のkext

などがあります。これらは、該当するハードウェアを機能させるためのkextです。そのハードウェアが原因のトラブルを解消する機能を持ったkextもあります。FakeSMC.kext以外のkextは、絶対に必要というものではなくて、必要に応じてインストールすれば良いものです。それぞれのハードウェアの話題のところで説明していこうと思います。

kextの探し方

Hackintoshに必要なkextは、その名前で検索すると開発サイトや配布サイトが見つかります。また、KextUpdater.appを使うと、現在使用しているkextの最新版をチェックしてダウンロードしてくれます。また主要なkextを個別にダウンロードすることも可能です。

*1:macOSのアプリケーション、.appも同様にファイルではなくてディレクトリです。

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領域にする

あと13日！High Sierraのお迎え準備

Wed, 13 Sep 2017 14:28:32 +0900

High Sierraは9月26日に登場

昨夜の発表では、Macintoshはおろか、間も無く登場のmacOSも紹介されなくて寂しい限りです。でもアップルのサイトには、macOS High Sierraの発表日がひっそりと掲載されています。9月26日だそうです。あと、13日ですね。それまでに、あなたのHackintoshに新バージョンをお迎えする準備をしておきましょう。

ドライブを用意

今使っているメインのドライブにいきなりHigh Sierraを入れるのは、多分問題なく動くと思いますが、さすがにチャレンジングです。使っていないドライブを用意しておきましょう。HDDでも良いですが、古いSSDでもあれば尚良いです。動かすには30GBくらいあれば十分です。自作マシンなら、マザーボードにSATAケーブルで接続すれば良いです。最近は、USB 3.0接続のUSBメモリーで高速なものもありますので、下手なHDDよりずっと速いかもしれません。それでもokだと思います。

Cloverを最新版に更新

最新版なほど安心です。現時点での最新版のリビジョンは4200です。古いようなら更新しておきましょう。

kextファイルを最新版に更新

開発者の皆さんがベータ版を使ってHigh Sierra対応を進めてくれています。使っているkextファイルの最新版が出ていないかどうか確認しましょう。kextファイルの名前でGoogle検索すれば良いです。全部最新版に更新しておきましょう。

また、kextをEFI/CLOVER/kexts/10.12に入れている人は、10.13を新たに作って、全部のkextをコピーしておきます。もしくは、Otherフォルダにコピーしておいても良いです。10.13で起動する場合は、Otherの内容が先に読み込まれ、次に10.13フォルダが読み込まれます。10.12のフォルダの内容は無視されてしまいます。

config.plistのSMBIOS情報を更新

High Sierraのアップデートでは、APFSでも起動できるようにファームウェアがアップデートされます。ファームウェアが対応版にアップデートされていないと判断されると、インストールが止まってしまうようです。そこでconfig.plistのSMBIOSセクションのBIOSバージョンの記述を、最新版ファームウェアと同じバージョン番号に書き換えておきましょう。また、Firmware FeaturesとかFirmware Features Maskという謎の情報がSMBIOSにないとインストールできなかったという報告もあります。config.plistにこの記述がなかったら、これも設定しておきましょう。

書き換えるべき情報は、機種ごとに違います。これを簡単に確実に知る方法の一つは、Clover Configuratorを使う事です。

mackie100projects.altervista.org

これをダウンロードして、左のリストからSMBIOSを選びます。右の疑問符のところをクリックして現れるポップアップメニューから、自分が設定している機種名を選びます（下の写真では疑問符が消えてiMacの写真に変わっています）。すると必要な数値を自動的に作ってくれます

この結果を、Save As…でconfig.plistファイルに書き出します。書き出したconfig.plistにはSMBIOSのセクションの記述しかありません。これを見ながら、現在のconfig.plistで足りない記述を書いていきます。更新、追記しないといけない項目は、以下です。これはiMac18,3の場合の例です。

<key>BiosReleaseDate</key>
<string>08/08/2017</string>
<key>BiosVersion</key>
<string>IM183.88Z.0151.B00.1708080034</string>
<key>FirmwareFeatures</key>
<string>0xFC0FE136</string>
<key>FirmwareFeaturesMask</key>
<string>0xFF1FFF3F</string>

これ以外の情報、例えば、シリアル番号とかUUIDなどは、現在の値を引き続き使います。書き換えてしまうとiMessageなどの動作に支障をきたすかもしれません。

SMBIOSの設定についてはこちらでも解説しておきました。

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

起動できることを確認

以上の変更を一つずつ行い、その度に起動できるかどうか確かめていきましょう。全部が最新版に更新されて、config.plistの記述が完全になるので、High Sierraにアップデートしないとしても、良いメンテナンス作業になります。

これでHigh Sierraを迎える環境は整いました。待ちきれないようでしたら、新しいドライブをディスクユーティリティでフォーマットして、今のドライブから新しいドライブにESP部分を複製して、Cloverが起動するようにしておいても良いでしょう。

macOSをバニラに保ってインストールする

Tue, 12 Sep 2017 23:05:32 +0900

macOSをインストールしてHackintosh をつくる方法、流儀、ツールはいくつかあります。ここでは、一番おすすめの、バニラな方法を紹介します。macOSをできる限りオリジナルなままに保ってインストールする方法です。バニラというのはVanillaアイスクリームのバニラで、チョコレート味とか抹茶味みたいに手を加えてない、素材のままという意味です。

バニラな方法では、macOSが入っているメインのパーティションの内容には一切手を加えないで、実機と全く同じ状態にしておきます。この方法では、カーネルやカーネル拡張（kextファイル）を書き換えません。HackintoshのためのkextファイルもmacOSパーティションには追加しません。

バニラのメリット

バニラな構成では、macOSメインのパーティションは本物のMac（実機）と同一です。なので、Hackintoshのドライブを本物のMacに取りつければ、そのまま起動します。macOSから見ると、このパーティションが世界の全てです。なので、macOSのバージョンアップをした時、書き換わるのもmacOSが入っているパーティションだけです。この部分に手を加えていると、バージョンアップのたびに対応し直す必要があります。しかしバニラに保っておけば対応の必要が無く、実機と同じようにApp Storeからバージョンアップするだけでの簡単な操作で行えます。

macOSのインストール手順

macOSをバニラにインストールする一般的な手順を書いておきます。Hackintoshに必要なファイルを、macOSメインパーティションではなく、ESP (EFI System Partition)に置くのがポイントです。

ボリュームをディスクユーティリティでフォーマットする
通常のインストーラを使ってmacOSをインストールする
Clover EFI BootloaderをESPにインストールする
Cloverの設定ファイルconfig.plistを目的に応じてカスタマイズする
必要なkextファイルを集めてESPのkext用フォルダに入れる

手順1と手順2は、通常のmacOSインストール手順です。実際のMacintoshにmacOSをインストールするのと同じ手順です。実機ならばm.2/SATA/USBなどで接続したボリュームをフォーマットしてそこにインストールします。Hackintoshならば、macOSインストーラが起動するUSBメモリを以下の手順：

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

で作成して、これで起動して、ディスクユーティリティ.appを使って対象ボリュームをフォーマットして、macOSインストーラを使ってインストールします。

手順4と手順5は、macOSとHackintosh用ブートローダのCloverをインストールした後の、「ポストインストール」とも呼ばれる作業です。Hackintoshが正しく動くようにする作業で、色々なノウハウが必要です。手順3、手順4、手順5は、以下の記事を参照してください。

Cloverインストーラの設定

手順3は、macOSをUEFIマザーボードで起動させるためにUEFIブートローダであるCloverをインストールする手順です。Cloverはオープンソースで開発されているツールです。

Cloverのインストーラでは、Hackintoshに必要なファイルを置く場所を選択できます。一つの選択肢は、macOSが入っているメインパーティションのルートです。もう一つは、EFIシステムパーティションです（頭文字でESP）。

前者の場合、macOSのパーティションにファイルを追加するので、バニラに保つポリシーからは外れます。

後者でファイルが追加されるESPは、macOSでドライブをフォーマットすると自動的に作ってくれるパーティションの一つです。UEFIマザーボードが起動するときに使用するファイルが置かれる場所です。しかしmacOSはこのパーティションを使用しません。なので、ESPにHackintoshに必要なファイルを全て置けば、バニラなインストールが実現できます。

ESPを利用するためには、Cloverのインストーラで、カスタムインストールを選択し、「ESPにインストール」にチェックマークを付けます。

この記事の以下では、

フォーマット後に出来上がるパーティション構成と、
バニラを目指してCloverをインストールした後のESPの内容

を説明します。

バニラなディスク構成

バニラな方法で使用するESPは、macOSでドライブをフォーマットすると自動的に作ってくれます。試しに、ディスクユーティリティを使って120GBのSSDをまっさらにフォーマットしてみました。ターミナルからdiskutil listとするとフォーマット後のパーティションの一覧が出てます。例えば以下のようになります。これは全てディスクユーティリティが作ってくれるパーティションです。ただし、メインのパーティション名は、フォーマットの時に指定します（ここではMacintosh HDとしました）

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                  SIZE       IDENTIFIER
   0:      GUID_partition_scheme                      *120.0 GB   disk0
   1:                        EFI EFI                   209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD          119.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD           650.0 MB   disk0s3

/dev/disk0s2がメインのパーティションです。macOSのインストーラは、macOSをこの/dev/disk0s2にインストールします。
/dev/disk0s3はリカバリ用のパーティションです。macOSのインストーラは、ここにリカバリ用のデータをインストールしてくれます。
/dev/disk0s1がESPです。macOSはここを使用しません。ESPは実機にももちろんありますが、やはり空のままです。Cloverをインストールする時に、カスタマイズ指定すると、ESPの中に必要なファイルを書き込んでくれます。

ESPは通常はマウントされていませんが、ターミナルから以下のようにすると /Volume/EFI 以下にマウントしてくれます。

sudo diskutil mount /dev/disk0s1

10.13.6からマウントするためにsudoが必要になりました。それより古いmacOSでしたらsudoなしでもマウントできます。

ESPの中身

先のmacOSのインストール手順の箇条書きに示したように、ボリュームをフォーマットした後に、macOSをインストールして、次にCloverをインストールします。Cloverをインストールした後の、ESPの一例を見てみましょう。

CLOVERというディレクトリができていて、この中に、設定ファイルconfig.plist, システム拡張ファイルkextを入れるkexts, EFIのドライバを入れるdrivers64UEFIなどが出来上がっています。これらはCloverのインストーラが作ってくれますが、手作業で作っても良いです。すでに動いているHackintoshの環境を移行する場合などは、このディレクトリ構造そのままに新しいドライブのESPにコピーすれば、引き継がれて稼働します。Cloverのインストーラは、最小構成のconfig.plistと、必要なdrivers64UEFIの中身をインストールしてくれます。

kextsは、必要に応じて手作業でESPに入れておきます。kextsフォルダのOtherフォルダには全てのバージョン用の、数値のフォルダにはそのバージョン番号のmacOS用のkextを入れられます。 macOSでは、kextを/System/Library/Extensions/ (/S/L/Eと略されます) もしくは、/Library/Extensions/ (/L/Eと略されます) に置きます。Hackintoshで使うkextも/S/L/Eや/L/Eに置くこともできますが、それではバニラで無くなってしまうので、ESPに入れるのが良いです。/S/L/Eや/L/Eに置く場合は、パーミッションを正しく設定したり、キャッシュを作り直したり、SIPを無効にしたりなどの作業が必要です。ESPなら、Cloverがkextを有効にしてくれるので手間いらずでもあります。

SIP システム整合性保護機構

Tue, 12 Sep 2017 19:00:25 +0900

El CapitanでSIP (System Integrity Protection, システム整合性保護）という仕組みが導入されました。SIPは、システム管理者であっても、システムの要のディレクトリのファイルを変更したりファイル追加したりできない仕組みです。また、アップルに認められて署名されたカーネル拡張機能 (kextファイル) 以外は、機能しません。なんでも書き換えられるスーパーユーザであるルートはもはや居ないという意味で、rootlessとも呼ばれています。

デフォルトではSIPは有効になっていますが、無効にすることもできます。実機の場合は、以下のようにします。

リカバリーモードで起動します。
ターミナルを起動して csrutil disableもしくはcsrutil enableと入力します。
この後、再起動すれば、それぞれSIPが無効もしくは有効になります。

SIPに関してはこちらの記事に詳しく書いてあって参考になります。

news.mynavi.jp

Hackintoshでの対処方法

SIPが登場した時、Hackintoshが困難になるのではという予想もありました。でもCloverの開発者たちが頑張って対応してくれました。今では、Clover設定で、実機と同様に、SIPを有効にも無効にも自在に設定できます。HackintoshでSIPをどう設定して運用するか、対照的な2通りのアプローチがあるかと思います。

SIPは無効にして自由自在にパッチを当てまくる
macOSをバニラな状態に保ってSIPを有効にする

前者はSIP登場前と同様にmacOSに手を加えるアプローチです。後者のアプローチにある「バニラに保つ」方法の詳細は、以下をご覧ください。

/posts/131/

バニラな方法では、Hackintoshに必要なファイルは、全てをEFIシステムパーティション (ESP) に置きます。ESPはSIPの管轄外なのです。ここに置いたファイルは自在に書き換えられますし、ここに置いたkextファイルは、署名がなくても動きます。ESPは管理者アカウントなら自由にアクセスできるので、SIPの有効性を低下させてしまいますが、それでも、本体へのアタックはある程度は防げます。また、SIPを有効にできるかどうかは、システムがバニラに保たれているかどうかの指標にもなります。

CloverでのSIPの設定

起動時のClover設定画面でも一時的にSIP設定変更が可能です。

継続的に指定する場合はconfig.plistを編集します。config.plistのRtVariableセクションでSIP設定を変えられます。

        <key>RtVariables</key>
        <dict>
                <key>CsrActiveConfig</key>
                <string>0x0</string>
        </dict>

ここで使う代表的なCsrActiveConfigの値は以下です。

0x0 = SIPを有効にする (デフォルト値)
0x3 = SIPを部分的に無効にする (署名されていないkextをロードする)
0x67 = SIPを完全に無効にする

現在の設定状態は、csrutil statusコマンドで知ることができます。手元のマシンだと、以下のようになっていました。有効になっているということです。

$ csrutil status
System Integrity Protection status: enabled.

ちなみにRtVariablesキーでは、CsrActiveConfig以外にROMとかMLBとかBooterConfigの値を設定できますが、どれも今のCloverでは不要です。CsrActiveConfigだけが有効です。