OpenCoreはCloverから分岐し、OZMOSISの流れを取り込んだ新しいオープンソースのブートローダーです。Z390マザーボードで動かしたところとりあえずはmacOSが起動しました。
追記：最近のOpenCore関連の記事もご覧ください。
Table of Contents
OpenCoreとは
OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダーです。Cloverから分岐し、OZMOSISの流れを取り込んでいます。OZMOSISを開発していたドイツのHackintosh-Forum.deの人たちが開発を進めているようです。OZMOSISってどんなものだったかと言うと、ファームウェア形式のブートローダーで、マザーボードのBIOSを置き換えて動作します。OZMOSISをマザーボードのBIOS更新機能を使ってインストールすれば、普通のマザーボードがmacOSを直接起動できるマザーボードに変身します。macOSもmacOSインストーラも実機と同様にそのまま起動できるという理想を追ったブートローダーだったのですが、調整やアップデートのたびにBIOS更新作業をするのは大変でした。ChameleonやCloverみたいにドライブの一部に書き込む方式の方が色々楽です。ということでOZMOSISはあまり流行りませんでした。開発チームもそれを認識して、今度はClover方式のブートローダーを作ることにしたのだと思われます。
使用したハードウェア
OpenCoreを試したハードウェアは、以下で紹介したZ390マシンです。モデルIDはiMac19,1で、macOS Mojave 10.14.5です。
ここで使っているkextは
- AppleALC.kext
- IntelMausiEthernet.kext
- Lilu.kext
- USBInjectAll.kext
- VirtualSMC.kext
- WhateverGreen.kext
です。efiファイルは大半がClover 5018で配布されているものです。
- ApfsDriverLoader.efi
- AptioMemoryFix.efi (これはKext Updater.appで入手)
- FSInject.efi
- VirtualSmc.efi （VirtualSMC.kextに同梱されているもの）
- VBoxHfs.efi
- EmuVariableUefi.efi
またUSBInjectAll.kextで使うためのSSDTファイルも使っています。こちらで作成したものです。これがSSDT-UIAC.amlという名前です。
OpenCoreを入手する方法
いろいろな方法がありますが、一番お手軽なのは最近のKext Updater.appを使う方法です。Kext UpdaterもOpenCoreを作っている人たちが活躍しているHackintosh-Forum.deで作られていますので、その関係でOpenCoreダウンロード機能が実装されているのだと思います。Load Bootloaderのラジオボタンを選択して、右のポップアップメニューからOpenCoreを選択します。
ダウンロードすると、Kext-Updatesフォルダの中にOpenCoreというフォルダができて、この中にデバッグ版とリリース版
- OpenCore-0.0.4-DEBUG
- OpenCore-0.0.4-RELEASE
のフォルダが出来ています。今回はRELEASE版を使ってみましたが、DEBUG版の方がより多くのエラーメッセージを出してくれるらしいです。
ESPディレクトリ構築
Docsフォルダの中には、とても詳しい取扱説明書が入っています。Cloverにはあまりなくて、ネット上のマニュアルも古かったりします。説明書を一緒に配布してくれているのは助かります。まだちゃんと読んでませんが、必要な情報は全部書いてあるのではないかと思います。マニュアルによると、構築すべきディレクトリ構造は以下の通りのようです。
グレーの項目は任意の項目です。なので、EFIの下に、BOOTとOCを作って、OCの中のDriversにefiファイルを、Kextsにkextファイルを入れれば良いようです。またOCの中にconfig.plistを起きます。名前がOCになっただけで、CloverのESP配置とだいたい同じです。この図に従ってESPの中にディレクトリを用意し、DriversフォルダとKextsフォルダに上記のefiファイルとkextファイルを入れました。またACPIフォルダにSSDT-UIAC.amlを入れました。
config.plist編集
Docsフォルダの中に、マニュアルと一緒にconfig.plistのサンプルファイルも入っています。名前が、Sample.plistとなっています。今回はこのファイルをもとに動かしてみました。まずはSample.plistをconfig.plistに名称変更します。そして以下の手順で書き変えました。
SMBIOS設定
まずは機種設定からです。どうやら<key>PlatformInfo</key>の中の<key>Generic</key>の中が機種設定関連のようです。この部分のMLBがCloverでのBoardSerialNumberに対応し、SystemProductNameがProductNameに、SystemUUIDがSmUUIDに対応するようです。それぞれの値を書いておきます。
<key>MLB</key> <string>C02921130GULNV9JA</string> <key>SystemProductName</key> <string>iMac19,1</string> <key>SystemSerialNumber</key> <string>C02YR2YHJV3Q</string> <key>SystemUUID</key> <string>E45005B4-95C7-4B0C-9739-30947DDEB37C</string>
FileVault設定
この状態で起動させようとしたところ、FileVaultの用意ができていないというような内容のメッセージが出て起動が中断しました。config.plistを見ると、<key>Misc</key><key>Security</key>の中にFileVaultらしい設定があり、有効にされているようです。ここのtrueの部分2箇所をfalseに書き換えました。これでメッセージが出なくなりました。
<key>Security</key> <dict> <key>ExposeSensitiveData</key> <integer>2</integer> <key>HaltLevel</key> <integer>2147483648</integer> <key>RequireSignature</key> <false/> <key>RequireVault</key> <false/> <key>ScanPolicy</key> <integer>983299</integer> </dict>
efi設定
次に、HFSPlus.efiが見つからないというメッセージで起動が中断されました。最近はAPFSになって、HFS+での起動は使わないので、上記のリストのようにCloverデフォルトのVBoxHfs.efiを使っていました。なんでこのメッセージが出るのかと思ったらconfig.plistの<key>UEFI</key><key>Drivers</key>の中にefiファイルの一覧が書いてありました。フォルダに入れるだけでなくconfig.plistにも書いておくようです。FileVaultに関係したefiファイルも入っています。これらのリストを、実際に使っているefiファイルに書き換えました。
<key>UEFI</key> <dict> <key>Drivers</key> <array> <string>VBoxHfs.efi</string> <string>ApfsDriverLoader.efi</string> <string>EmuVariableUefi.efi</string> <string>FSInject.efi</string> <string>AptioMemoryFix.efi</string> <string>VirtualSmc.efi</string> </array>
kext設定
ほかも見てみると、<key>Kernel</key><key>Add</key>の場所に、kextに関する記載もあります。この記述順にロードされるようなので順番も大事なようです。
IntelMausiEthernet.kextの名前が違っている（IntelMausi.kextになっている）のとEnabledされていないようなので、修正しました。
<dict> <key>BundlePath</key> <string>IntelMausiEthernet.kext</string> <key>Comment</key> <string></string> <key>Enabled</key> <true/> <key>ExecutablePath</key> <string>Contents/MacOS/IntelMausiEthernet</string> <key>MatchKernel</key> <string></string> <key>PlistPath</key> <string>Contents/Info.plist</string> </dict>
また、USBInjectAll.kextの記述も追加しました。順番が大事のようです。arrayの最初の方に入れたら動きません。arrayの最後に追加しました。
<dict>
<key>BundlePath</key>
<string>USBInjectAll.kext</string>
<key>Comment</key>
<string></string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string>Contents/MacOS/USBInjectAll</string>
<key>MatchKernel</key>
<string></string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
SSDT設定
使用するSSDTもconfig.plistで指定する必要があるようです。今回は、SSDT-UIAC.amlを使います。そこで、<key>ACPI</key><key>Add</key>のarrayの中に、
<dict>
<key>Comment</key>
<string>USB list for USBInjectAll</string>
<key>Enabled</key>
<true/>
<key>Path</key>
<string>SSDT-UIAC.aml</string>
</dict>
を追加しました。
動作確認
BIOSでOpenCoreをインストールしたドライブを選択すると、Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面です。ここで10.14.5の入ったMacintosh HDを選択しました（この例ではキーボードの5を押す）。この後、設定に不備があると上記のようなエラーメッセージが出ることもありますし、起動が停止することもあります。
でも、ここまでの設定で、なんと起動しました。config.plistで手付かずの項目がいっぱいあるのに、とりあえず起動したのは意外でした。よかったです。
使用したconfig.plistを以下においておきます。
動くこと
画面が出て動作します。Radeon RX 580が正しくと動きます。IntelMausiEthernet.kextも動きます。なのでLAN接続ができます。またBroadcomの純正WiFiも動きます。
USBInjectAll.kextと自作のSSDTの組み合わせで、USBの取捨選択ができています。15個制限問題を解決できています。
動かないこと
シャットダウンすると画面は消え、シャットダウンプロセスが実行されるのですが、電源が切れるところまで行き着きません。電源スイッチを長押しして強制的にoffにする必要があります。その影響で次の起動の時にBIOS表示で警告が出ます。ACPI関係の設定が足りないのだと思います。
OpenCoreに行くべきか？
ということで、OpenCoreでの起動を確認できました。今後は、USBの指定方法や、今回見た以外のconfig.plistの設定など、マニュアルや検索して調べて見たいと思います。
ではCloverをやめてOpenCoreに移行すべきでしょうか。OpenCoreの人たちは、以下のようなメリットを訴えています。
- 完全にオープンソースなので安心
- 設計が新しい
確かにCloverは開発過程がそれほどオープンになっていないので、わかりにくいところがあるかと思います。ロシアで開発されているCloverとドイツで開発されているOpenCoreでは、偏見かもしれませんが、なんとなくOpenCoreに安心感を感じます。開発がオープンなのでHackintoshの主流がOpenCoreに移行していく可能性は高いです。でも今現在では、Cloverに関するノウハウが大量にネットにありますし、しばらくはCloverが使われると思います。
主流ブートローダーは、数年前にChameleonからCloverに交代しました。ただ、この交代では、レガシーなMBR (マスターブートレコード)からESPに対応すること、起動時に動的にパッチを当ててくれる機能、macOSとの相性が良くなることなど、いくつもメリットがありました。CloverからOpenCoreに変えても、目に見えるメリットはないので、移行は緩やかかもしれません。CloverからOpenCoreに移行したらグラフィックスカードの動作が安定したと言う情報も見かけました。今後どうなるにしても、選択肢が複数あることは良いことです。
お疲れ様です。
記事をもとに、少しいじってみました、(ASUS Prime H310-A)
efiは
ApfsDriverLoader.efi
EmuVariableUefi.efi
FSInject.efi
OsxAptioFix3Drv.efi
SMCHelper.efi
VBoxHfs.efi
kestは
AppleALC.kext
FakeSMC.kext
Lilu.kext
RealtekRTL8111.kext
USBInjectAll.kext
WhateverGreen.kext
です。
USBInjectAll.kextは
<dict><key>BundlePath</key>
<string>USBInjectAll.kext</string>
<key>Comment</key>
<string></string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string>Contents/MacOS/USBInjectAll</string>
<key>MatchKernel</key>
<string></string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
で動きました。15個の制限のブートオプションを
<dict><key>boot-args</key>
<string>-v keepsyms=1 alcid=7 uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06</string>
<key>csr-active-config</key>
<data>AAAAAA==</data>
<key>nvda_drv</key>
<data>MQ==</data>
<key>prev-lang:kbd</key>
<data>cnUtUlU6MjUy</data>
</dict>
の通り入れて、動きました。
シャットダウン関係は無理でした。
Ver0.0.4、これから、ノウハウがたまっていくんでしょうね。
[OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダー] なので、新しい時代の夜明けなのかも。Chameleon -> Clover の移行の際の変化も経験したユーザーとして、さらに Clover-> OpenCoreへの変革にも、参加できるとは本当にラッキーです。
ダメ元で、ちょっと サンプル Config.plisの汎用度を試してみました。
1) Clover Configurator
やはり内部構造が異なっていることから、まったくの互換性なし。
でも、text modeでは読み取れますが、ベタ文字列の羅列で編集が大変です（初心者には酷）
長期的にはOpenCore専用のConfiguratorの早期提供が、今後のユーザー拡大に大きく貢献するかも。
2) Xcode
かつて、Clover が世の中に普及（認知）し始めた時に、専用のconfigurator がまだ用意されていない時期だったので、同じように このXcodeで読み込んで編集した思い出があります。
歴史は繰り返す….ですが、 新しい時代の変革は新しいツール（OpenCore)で切り開かれる…と感じます。
Key – Type – Valueと 整然と表示されて、読み落とし、記入漏れの誤りは少なくなるでしょう。
ーーーーーーー
追記： ＜ Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面 ＞
Cloverのような GUIのテクニックを駆使した画面と比較して、な、なんと シンプルな.. 画面！！
モノは考えようで、試読性（ぱっと見てすぐわかる）の点では GOOD ！！
OpebnCoreを使うこと：現時点でのメリット
1) 既に使い慣れている kext Updater ツールで、一括管理できそう
2) オープンソース主体ゆえに、万人の智恵・工夫が迅速に反映され、さらにコード自体が万人にDEBUGされており、大勢でかついた神輿のように 今後 勢力を増すのでは。
愛用している Braveブラウザーのように、 いずれカミソリのような切れ味（高速処理）が OpenCoreのソースコードの中に取り込まれて、それを我らユーザーが享受できることを期待
後記：
先人 お二人の冒険心に導かれ、私も この新世界に一歩 踏み込んでみました。
1) 初見：
EFIフォルダー内の階層構造が３段、 一方Cloverでは４段。
やはり、階層構造が浅い分だけ、シンプル差がBetter
2) まだバージョン・リリースが 1.0.0にも達していないPreview版ゆえ、 良い子の皆さまには利用を強くお奨められません。
約三時間の奮闘（頭のパズル）で得られた事を以下にQuickにご紹介。
– Clover Configurator に相当するツールがまだないので、 ほぼ手作業…しんどい
生産効率は超最悪、でも動き出したらフットワークが軽くてやみつきになりそう。
– FakeSMC およびVirtualSMCの両方のタイプで検証したが、 センサー用の xxxx.kextが見つからない（正しく登録していても）とのERRORが出る。
センサー用にxxxxx.kextの登録手順は別の方式なのかも？？
– kext群の一つとして、NullCPUPowerManagementCPUPowerManagement.kextを放り込んでいるせいなのか、我がHainctosh（OpenCore)は正常にShutdownしてくれました。
ここらで、ちょっと一休み….
———————–
追記２：
3) 今回は、怖いもの見たさで Release版ではなく、あえて ERROR表示のメリハリがきいているであろうDebug版の OpenCoreコードを使用
4) Mojaveレベルでは、 VirtualSMC系 および FakeSMC系のいずれを採用しても（センサー周りのkextの取扱いがまだ不勉強）、同じようにサクサク動く。
しかしながら、こと Catalina Public Beta版に限って言うと、FakeSMC系の方が最後まで 起動プログレスバーが進み、どうにかログイン画面までたどり着けた。
5) mifjpn さんが 紹介なさっているいくつかのパッチ作業は、実際にConfig.plist上で書き込む適切な場所を探したが、力不足で見つからず現時点では、適用を保留中。
———————–
追記3：
6) Kext Updaterツールが、Clover環境の場合と同様に以下の作業ができるかどうか試してみた、
Kext群のそれぞれが最新版かどうかの検証
EFI区画のマウント/ アンマウント
すると、Kext Updaterアプリからは、以下のメッセージを表示してきた。
The value for ‘Expose Sensitive Data’ (Misc/Security) in your OpenCore config.plist must be set to ‘3’. Without this value, the Kext Updater works only to a limited extent.
そこで、指示内容に従って、該当する値を２から３に変更し、次にEFI区画からの再起動、再度 作業をTRY. これで、ようやく 念願ことができるようになり、めでたしめでたし。
注： 副次効果として、 EFI区画マウント/アンマウント作業のために残していたClover COnfiguratorを、ラウンチDOCから切り離すことができた。 さらに、アプリケーションフォルダーからも抹殺。
お疲れ様です。
NullCPUPowerManagement.kext
一応試してみましたが、Shutdownは無理でした。
Cloverでは、EmuVariableUefi.efiが効いたのですが、何らかの機微のあるオプションと共に効いてるのか、不明点も多いですね。（ただ、解決方も、やや伝承的になるのは、世のMB,CPU,VGAの組み合わせが非常に多くあるからでしょうねぇ）また、そのように、世のMB,CPU,VGAの組み合わせが非常に多くあるために、CloverスイートClover configrator（unibeast multibeastなども）があるということが、万人が解決法を探ることができるという正の相関を生み出しているのでしょうね。
初心者ながら私が思うに、OPENCOREのシェアが上がるのは、あまりあまたあるハードウェアの組み合わせに、いかに対応するかという点にあるような気がします。（ありえないとは思いますが、オープンソースだから万人がビルドできるので、自分のMB,CPU,VGA用にビルドしてください。ビルド用のmakeオプションはこちらです。ではCloverを超えられないでしょう。）
まず本体がVer1.0.0を迎えることもありますが、セットスイートとともに、ほぼ万人に解を探すことのできる環境が必要なのかもしれませんね。
mifjpnさん、
迅速なレスに感謝いたします。
「手間のかかる子ほど可愛い」ではないですが、このOpenCoreに一度触れると次から次へと やってみたいことが出てきて、雑学的なコメント投稿をつづけてしまい、折角のブログ掲示板を汚してしまったかも..と思ったりもしています。
o 「NullCPUPowerManagement.kext。一応試してみましたが、Shutdownは無理でした。」
そうでしたか 残念。 上述のコメント投稿で書き漏らした（まだ網羅していない）ことがひとつ。
xxxx.efi および xxxx.kextの箇所は、 bootmacosさんの提示内容に沿って行いましたが、さらに自分の直感で、わがHacintosh環境において大切であろうと考え、Clover環境 EFI-Clover-ACPU-Patchedで保管していたファイル群を このOPenCore の EFI-OC-ACPIフォルダーにコピペしていました。
o すみません、OpenCore Config.plistへのPatch適用の方法にまだ不慣れなので、お手数ですが以下のPatch適用をどの場所にどのように記載（指定）なさったのか その手順を「種明かし」していただけないでしょうか？
OpenCoreに興味を持ち始めたコミュニティーの皆さんも、きっと知りたがるかとおもいます。
ーーー引用箇所 ーーーー
15個の制限のブートオプションを
boot-args
-v keepsyms=1 alcid=7 uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06
csr-active-config
AAAAAA==
nvda_drv
MQ==
prev-lang:kbd
cnUtUlU6MjUy
の通り入れて、動きました。
ーーーーーーーーーーーーーーーーーー終わり
追記 4:
すでに熟成されたツール：CloverLoader他 に慣れており、まだまだ荒削りで手間のかかるツール：OpenCore に興味がわかない方は、当コメント内容をスルーしてください（折角の時間がもったいないので）。
—–新ブートローダー OpenCoreを使うと、こんなことってあるの？
a) 昨夜 夕方 OpenCore ブートローダーの入ったEFI区画をBIOS省略時起動ボリュームにしたまま、電源オフ。
すでに多くの方がご存知かと思いますが、昨夜から明け方の間に,macOSx Mojaveの最終リリース(10.14.6 Final)が提供開始されました。
そのニュースを見て、現有Mojave 10.14.6 public beta xの起動ボリュームの上書きアップグレードと、
他の起動ボリューム（Mojave 10.14.5 Final)のクリーン導入作業を思い立った。
b）OpenCore ブートローダーの入ったEFI区画起動による[起動ボリュームへのOSx10.14.6 上書き導入]のてんまつ；
作業結果：問題なく、日本語表示で導入作業を完了
良かった点： OpenCorteブートローダーのもとで、上書き導入すると 途中２回再起動があったが、キーボードに一切手を触れることなく、自動で作業が進んだ。
（あたかも、純正macでの上書き導入をおこなっているがごとく）
注：Cloverブートローダー使用時のような、さてさえどれかいな？と探して手動選択する手間・時間はまったく不要。
c) OpenCore ブートローダーの入ったEFI区画起動による[OSx10.14.6 新規導入]のてんまつ；
導入作業の結果： 中断
背景・理由は、第一優先順位の起動ボリュームではにために、 該当する数字でその対象起動ボリュームを選んだ、それを２回も繰り返し。 問題は一応 Install作業が終えて、ターゲットのボリュームからの起動が行われて、ユーザー環境初期設定の時に、問題発生。
な、なんと！！ 表示されたのは、ロシア語（日本 -> Япония （読み方 Yaponiya）。
これでは、表示されている文章・意味が理解できず、 ギブアップ！！！！
救済策： BIOS起動ボリュームとして、やむなく CLoverboot Loaderが入っているEFI区画に選び変えて再起動、使い慣れているClover Boot Loaderを利用して、最終的には日本語表示で無事完了。
＜教訓＞ OpenCoreはまだまだ発展途上なかば、CloberBootLoader環境はゴミ箱に捨てるなかれ！！
d) OpenCorerブートローダーの方が、Clover ブートローダーよりもフットワークが軽いって本当？
おそらく、OpenCorerブートローダーが知名度・熟成度合いが低いので、両ブートローダーを比較した資料は出ていないかも。 実際に、わがHacintosh環境（自作PC,i7-6700K, Z170M-OC-Fomula.マザボ）で動かした後で、判明したことは ひとつ。
どういうわけか、わがHacintosh環境では ハーパースレッデング（HTT)を Enabled(ON)にすると、駄々をこねる困った子ちゃんです（ これまではClover BootLoader 主体）
ところが、ブートローダーをOpenCoreに切り替えると、あらふしぎ HTT Enableにしても、お利口さんのままで、上機嫌のまま。
-> OpenCoreの内部コードは、きっと洗練されて（プチ断捨離も行われて？）、フットワークがより軽やかになり、省電力に貢献しているのだと確信。
ここで、一休み。
（不定期な投稿、 つづく）
訂正：
第一優先順位の起動ボリュームではにために、 -> 第一優先順位の起動ボリュームではないため、
追記５：
上述の後記：で以下のように述べた件に関して、重要な解決ヒントが見つかったのでご紹介します。
————————-
– FakeSMC およびVirtualSMCの両方のタイプで検証したが、 センサー用の xxxx.kextが見つからない（正しく登録していても）とのERRORが出る。
センサー用にxxxxx.kextの登録手順は別の方式なのかも？？
————————-
＊解決ヒントを見つけられたかも・・・ ー
参照Webページ：
Getting-Started-With-OpenCore
A brief guide to using the OpenCore bootloader for hackintoshes
https://insanelymacdiscord.github.io/Getting-Started-With-OpenCore/
＊とても重要な情報（解決ヒント）は以下の４行です。
>Kernel
>Add: Here we can specify kexts to inject from our EFI into the kernel kextcache. Order of kexts is >important, they are loaded in this order. Plugins for other kexts should always come after the main >kext. Lilu should be first, then Lilu plugins like WhateverGreen and VirtualSMC.
＊このヒントから得られた解決策
定義する順番は、 まず最初は かならず Lilu, 次にメインのkextのグループ, 後ろの方にLiluや 他の主要なkextためのpluginを並べること
1) LiluのためのPluginとしてはWhateverGreen やVirtualSMCが該当するので、
これらは必ず Lilu.kextの定義した後（下部？）に定義する
2) 例えば、SMCProcessor.kextは VirtualSMC.kextのためのPluginなので、
Virtual.kextの定義した後（下部？）に定義する
（つづく）
情報ありがとうございます。順番が重要なのですね。USBInjectAll.kextを入れる場所を調整して再挑戦してみます。
kext記述の順番が大事という情報ありがとうございました。おかげさまでUSBInjectAll.kextが動きました。ロード順の一番最後に追加しました。またUSBInjectAll.kextが使用するSSDTの指定もしました。これでUSBの15個制限問題を回避できました。助かりました。
お疲れ様です。失礼しました。
boot-argsの15個の制限とは
uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06
のことで、
https://bootmacos.com/entry/2017/09/30/222518
ここに書いてあります。
DSDTよりも簡便なので、ブートオプションでやってみています。
以上です。
mifjpn さん、
まだOpenCore ブートローダー（Config.plist作成を含む）全体を不慣れなので、お教えください。
具体的には、OpenCoreパッケージのどの箇所を修正して、自分の希望するブートオプションを指示するのでしょうか？
お手数をおかけしますが、よろしくお願いいたします。
ごめんなさい、ちょっとわかりづらかったかもしれませんね。
場所がどこになるのかは、XMLなので、そこを示すシンタックスがあればいいので、前後も含めて、辞書形式～Key＝boot-arg部分を抜いたのです。
<dict><key>boot-args</key>
<string>-v keepsyms=1 alcid=7 uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06</string>
<key>csr-active-config</key>
<data>AAAAAA==</data>
<key>nvda_drv</key>
<data>MQ==</data>
<key>prev-lang:kbd</key>
<data>cnUtUlU6MjUy</data>
</dict>
と書いたのです。
わたしは簡便にcoteditorで、<key>boot-args</key>を検索し、そこから位置を特定しました。
ここではHTMLを生で書くので、うまく見えてればいいですが、どうでしょうか？
追伸
もちろん、Config.plistですし、ここでダウンロードしたものを、改変して使いました。
よろしくお願いします。
<わたしは簡便にcoteditorで、boot-argsを検索し、そこから位置を特定しました。
貴重なヒントをお提示いただき、ありがとうございます。
腰をすえて、そして真剣にOpenCoreパッケージで提供されているDocs内の取説（Configuration PDF)を頭から尻尾の方まで、”boot-args”をキーワードにしてスキャンして、念願の設定手順の箇所を見つけました。
それは、 取説の２６ページ下 ８。５ Other Variables での最初の特定Variablesの所でした。
見つかって良かった。
お疲れ様です。すみません。
こちらでは、Boot macOSさんへの追試コメントとして、書き込みました。
長くなるようでしたら、ディスカッションに行った方がいいかな＾＾；ｗとおもいます。
失礼しました。
ありがとうございます。記事に直接関係する情報ですので、ここで続けていただいた方が散逸しなくて良いと思います。
ありがとうございます。
Shutdownについては、
https://www.reddit.com/r/hackintosh/comments/a8uthx/vanilla_mojave_wont_shutdown/
で、SSDT-GPRW.aml のはなしは、がじってみようかと思いますが・・・
なにせ、ひとまず、Windows10のブートの選択肢がないんですね。
デュアルブート（USBのSSD,HDDのEFIもスキャンしてくれないので、実質クワトロブートですが）には、とても厳しいので、実際のところちょっと萎えています。
<>
最初はとっつきにくそうな感じがしましたが、触れればふれるほどますますその魅力にハマってしまいます。個人的にテストして得られた成果をご紹介（個人的な見解）いたします。
長文になりましたが、参考になれば幸いです。
なお、実際に適用する場合は、事前に バックアップを作成し、自己責任にて行ってください。
1) センサー用の xxxx.kextが見つからない（正しく登録していても）とのERRORが出る… の対処法
<>
OCフォルダー内のConfig.plistにて、該当センサーを登録する際にはBundlePath 名は、FakeSMC＿CPUSensors.kext であっても、その下行で明示する ExcutablePath 名は「実際にそのパッケージ内で記録されている名称までのリンク情報」でなければなりません。
具体的には、Contents/MacOS/CPUSensors としなければ正しく認識・ロードされません。
2) 「SLIDEでカーネル読み込み番地を調整する」手法を OpenCore ブートローダーのConfig.plist に反映するには..
<>
a) Boot-Argument: slide=128
b) RtVariables: CsrActive 0x40
実際にConfig.plist 上に反映したXcodeの出力結果（NVRAMーAddだけを抜粋、ASCII Text形式）
NVRAM = {
Add = {
“4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = {
UIScale = ;
};
“7C436110-AB2A-4BBB-A880-FE41995C9F82” = {
“boot-args” = “-v keepsyms=1 slide=128”;
“csr-active-config” = 0x40;
“nvda_drv” = ;
“prev-lang:kbd” = ;
};
};
３）UEFI – Driversでの記載順序に注意！
「SLIDEでカーネル読み込み番地を調整する」記事を読解しようと奮闘していた際に、ふと
ー これらのカーネル番地にはどんなモジュール（xxxx.efi など）がどのような順番で読み込まれるのだろう？
ー 先日、同じConfig.plist 内のKernel – Add の箇所で、 xxxx.kext を読み込む順番 にはあらかじめ決められたルールがあることを学んだが、もしかして UEFI – Driversでの記載順序（すなわち 読み込み順序）にも、最適化する手法があるのでは？？
<>
aa ) UEFI – Driversでの記載順序を２種類用意する。 Catalina PB4環境を利用。
A案 （従来のランダムな記載）と
B案 （カーネル読み込みにおいてシステムが ”とある優先順位”を持って、動作内容を選別し並行処理している…と推測。それに見合うであろう順番で記載）
A案： 抜粋、ASCII Properly List
UEFI = {
ConnectDrivers = YES;
Drivers = (
“OsxFatBinaryDrv.efi”,
“ApfsDriverLoader.efi”,
“FSInject.efi”,
“EmuVariableUefi.efi”,
“OsxAptioFix3Drv.efi”,
“VirtualSmc.efi”,
);
B案： 抜粋、ASCII Properly List
UEFI = {
ConnectDrivers = YES;
Drivers = (
“ApfsDriverLoader.efi”,
“OsxAptioFix3Drv.efi”,
“OsxFatBinaryDrv.efi”,
“EmuVariableUefi.efi”,
“FSInject.efi”,
“VirtualSmc.efi”,
);
bb ) 実際に、２種類のUEFIー Drivers記載順序で、どのような違いが出るのかを検証。
あえてシステム負荷を増やして差異が出やすいように、「Hyper Threading : Enabled」環境下で実施。
結果： A 案の場合は、システム起動中に息切れ（？）状態となり、ログ展開の途中でフリーズ。
一方、B案の場合は、内部処理の流れに無駄が少ないのか 無事 起動を完了しログイン画面到達。
注：これらは、あくまでもクイックな確認であり、引き続きB案で動作状況を継続観察いたします。
たまたま、今日 Kext Updater ツールにて、 OpenCore Bootloader パッケージの再ロードをしようとしたら、 従来のレベル 004 から 一段高いレベル 005に変わっているのに、気がつきました。
１） [ダメ元覚悟で] クイックですが、efi-OC フォルダー内の OpenCore.efiと efi-Boot フォルダー内のBootx64.efi の２つだけを最新版(005) に置き換えて、再起動してみたらすんなり問題なく動きました。
2) さらに、我がHacintosh環境（Z170M , i7-6700K)で HyperThreading= Enableで試した結果、起動時の安定度合いが「これまで悩まされ続けられていたCatalina(PB4)環境」においても、かなり満足度の高い状況であることを知りました。粘ってここまで来た甲斐がありました。
参考になれば、幸いです。
これで、ようやく我がHacintosh環境でもCatalinaに利用携帯の軸足を移す時期が来たようです。
後記：
Kekt Updater V3 アプリでの機能強化に同期して、OpenCoreブートローダーによるOSx起動時での立ち上がりが良くなって 起動の途中で 息切れ状態になることが ほぼ皆無になりました。
我がHacintosh環境（Hyper Threading Enabled )では、 これまでOCフォルダー内のConfig.plistにおいて、Root – NVRAM – add 指定の中で boot-argsにて -vオプションを明示的に選んでいました。
———————— -v オプションにてコンソールロギングを表示
Add
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14
UIScale
AQ==
7C436110-AB2A-4BBB-A880-FE41995C9F82
boot-args
-v keepsyms=1 slide=128
csr-active-config
0x40
nvda_drv
MQ==
prev-lang:kbd
cnUtUlU6MjUy
＜起動途中での原因探しのためにロギングを取りやめて、 通常のブート形態に変更＞0
同じConfig.plist 内（NVRAMーadd)を以下のように変更しました。
結果的にブートに要する時間を短縮できて、大変 満足しています。
—————— -v オプションの指定なし、Debug Modeは.オフ、
4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14
UIScale
AQ==
7C436110-AB2A-4BBB-A880-FE41995C9F82
boot-args
keepsyms=1 slide=128
bootercfg
log=0, debug=0
csr-active-config
0x40
nvda_drv
MQ==
prev-lang:kbd
cnUtUlU6MjUy
————————
お役に立てれば、幸いです。
補足： plistの中身を抜粋して貼り付けたのですが、などの区切りワードが吸収されてしまったので 形式タイプを変えて再書き込みいたしました。
ASCII Property List 形式にて、NVRAM-ADDの箇所のみ抜粋して提示いたします。
１）——-#Configの latest コピー, v005, -v debug
NVRAM = {
Add = {
“4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = {
UIScale = ;
};
“7C436110-AB2A-4BBB-A880-FE41995C9F82” = {
“boot-args” = “-v keepsyms=1 slide=128”;
“csr-active-config” = 0x40;
“nvda_drv” = ;
“prev-lang:kbd” = ;
};
};
Block = {
“4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = (
UIScale,
);
“7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
“boot-args”,
);
};
LegacyEnable = NO;
LegacySchema = {
“8BE4DF61-93CA-11D2-AA0D-00E098032B8C” = (
Boot0080,
Boot0081,
Boot0082,
BootNext,
BootOrder,
);
“7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
EFILoginHiDPI,
EFIBluetoothDelay,
“LocationServicesEnabled”,
SystemAudioVolume,
SystemAudioVolumeDB,
“bluetoothActiveControllerInfo”,
“bluetoothInternalControllerInfo”,
flagstate,
“fmm-computer-name”,
“nvda_drv”,
“prev-lang:kbd”,
);
};
};
２）——-#Configのlatest コピー none of -v, Debug=0
NVRAM = {
Add = {
“4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = {
UIScale = ;
};
“7C436110-AB2A-4BBB-A880-FE41995C9F82” = {
“boot-args” = “keepsyms=1 slide=128”;
bootercfg = “log=0, debug=0”;
“csr-active-config” = 0x40;
“nvda_drv” = ;
“prev-lang:kbd” = ;
};
};
Block = {
“4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = (
UIScale,
);
“7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
“boot-args”,
);
};
LegacyEnable = NO;
LegacySchema = {
“8BE4DF61-93CA-11D2-AA0D-00E098032B8C” = (
Boot0080,
Boot0081,
Boot0082,
BootNext,
BootOrder,
);
“7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
EFILoginHiDPI,
EFIBluetoothDelay,
“LocationServicesEnabled”,
SystemAudioVolume,
SystemAudioVolumeDB,
“bluetoothActiveControllerInfo”,
“bluetoothInternalControllerInfo”,
flagstate,
“fmm-computer-name”,
“nvda_drv”,
“prev-lang:kbd”,
);
};
——-
「新ブートローダーOPENCOREを使う」という この記事に惹かれ、Clover ブートローダの代替品として 追加こなすべく奮闘し、今日に至っています。
「素材が良いのだけれど…」の心情に、今 陥っている次第です。
なんとなれば、Catalina Public Beta Test＃８までは、そこそこ順調に”てなづけて”来ましたが,
#9の至った後 動作が不自然（Disk Utilityの FirstAidで 長時間のループが頻繁に,,, など）になり、一時休止にして、急遽 元のClover Boot ( R5070)に戻って Hacintoshを稼働させています。
他の方がたは、どのようになさっているのでしょうか？ とても、気になります。
願わくば、 OpenCore 060にアップグレードされ、速やかにリリースされることを ？！
「新ブートローダーOPENCORE 051 (正確には0.5.1)を使う」
Catalina Public Beta #10 (Nearly Equal GM)を導入した後、どうもOpenCore 050の起動ステップがぎこちなくなった。 上述(10/2)のようにレベル050の後継となる新コードを期待していたら、今日 Kext Updater (最新はV3.1.7)でいつものようにチェックしたら、新しく 051が入手可能であると知らされた。
モノは試し….と、直ぐに 0.5.1の新コードを導入（置き換え）。
直前まで起動ステップがぎこちなさで苦労していたのが、嘘のよう！！
すっきり、ササさっと、Catalina pb #10が立ち上がるようになり、一安心。
追伸：Cloverboot Loaderに「もしものことあっった」場合の代替ローダーとして、遊休のEFS区画が空いていたら、このOpenCore 0.5.1のコードを導入しておくと便利です。お勧めいたします。
「新ブートローダーOPENCORE 0.5.2がリリースされました」
あえて、変更・改善点を確認しないで 盲目的に最新版0.5.2 に更新。
起動ステップにおいては、0.5.1と差異は感じられず。
追記：Kexts Updaterは 3.1.8に更新し、さらに VirtualSMC.kext 1.0.8 ( 及び VirtualSMC.efiも) 、 WhateverGreen 1.3.3も 同時に更新。
お疲れ様です。
０．５．３になって、どうなったかと、前の通りやっても、ブート画面すら出ません。
興味自体はあるので、続けてみればと思うのですが、Success例が少ないので、探しかねてます。
スマの辰五郎様、導入を教えてくださると幸いです。
お疲れさまです
https://github.com/littlegtplr/Hackintosh-Clover-folder-for-Coffee-Lake-builds
が参考になりそうですね。（設定項目はだいぶ変わってますね）
ここから、いじってみることとします。
初めまして。いつも参考にさせてもらっています。
OpenCoreを試しているのですが、ブート画面で起動項目を選択できずに
何か勝手に選択されて次のシーケンスへ移動してしまっている様です
ブート画面で一旦止まってくれる様にするために何かパラメータ等必要でしょうか？
Cloverだと、何もせずとも選択画面で止まってくれるのでブートしたいドライブなど
選べるのですが、OpenCoreだと出来ないんです。
aroo さん、
横から失礼いたします。
「OpenCoreを試しているのですが、ブート画面で起動項目を選択できずに
何か勝手に選択されて次のシーケンスへ移動してしまっている様です。
ブート画面で一旦止まってくれる様にするために…」
の箇所について、当方で偶然見つけて 学んだ（経験した）方法を以下にご紹介いたします。
１.OpenCoreでの起動時に、その起動可能なドライブ一覧が表示されます。
でも OpenCoreならでの凝った工夫が、その画面の中に盛り込まれています。
2. それは、起動可能なドライブ一覧の最上段のドライブ名の前に、＊（アスタリスク）が付いていることです。これは、Config.plist内の特定の箇所で記述する秒数間だけ、ユーザーからの選択指示を待ってくれます。
3. その数秒間すら待つのが惜しい（セッカチな）方には、別の方法で起動可能なドライブを選べます。
それは、「その起動可能なドライブ一覧が表示された」らすぐさま、スペース・キーを押してください。 これにより、指示（ドライブ選択番号の入力）がなされるまで、永遠に待ってくれます）。
参考になれば、幸いです・
スペースキーで回避できるんですね。それも試してみます。
ありがとうございました。
Timeoutの秒数をマイナスにしたらどうでしょうか。今、試せなくてすみません。
タイムアウトの秒数、調べて試してみます。ありがとうございます。
タイムアウトの秒数でいけました！！
ありがとうございます。今、Catalinaインストール始めてます。うまく行くといいですが・・・。
<>
リリースノートの詳細は、以下のURLで参照可能です。
https://github.com/acidanthera/OpenCorePkg/releases
–> 早速、0.5.3から この0.5.4に更新してみました。
なんら問題なく、再起動できています。
OpenCore Bootloaderに深い興味のある方は、是非ともおためしください。
ども、Boot macOSさん、
>OpenCoreとは
OpenCore Vanilla Guide
https://khronokernel-2.gitbook.io/opencore-vanilla-desktop-guide/
↑こちらに記事にOpenCoreとはというものと、OpenCoreの利点の説明が詳しくまとめてあって参考になりますね。
Boot時のHot Key hold Option or ESC at startup to choose a boot device, Cmd+R to enter Recovery or Cmd+Opt+P+Rもサポートしてるとは知りませんでした。
このサイトを見て本格的に移行しようとも思いましたが、まだver 1.0には遠そうだと思うと（いろいろ変わりそうで）ためらってます。
CloverとClover Configuratorに慣れちゃってるのもあるのか、どうもPlistをいじるのがなんかめんどくさく感じるのもあるです。。。
たなかＱさんとこで配布されてるPropertyListEdi-tanを使ったりして、当面OpenCoreのplist設定を試行することが状態化しそうですね。
https://anikikobo.com/software/propertylistedi-tan/index.html
Clover Configuratorと同じようなものを同じ開発者の人たちがOpenCore Configuratorというのも開発していて、もうあるのですね。。。
OpenCore Configurator
https://mackie100projects.altervista.org/download-opencore-configurator/
みなさんもう当たり前に利用されてるのでしょうかね？、とりあえずOpenCore後発隊の人には朗報だ思いましたので展開しておきます。。。
ども、Boot macOSさん、
>どうやらPlatformInfoの中のGenericの中が機種設定関連のようです。
>この部分のMLBがCloverでのBoardSerialNumberに対応し、
>SystemProductNameがProductNameに、SystemUUIDがSmUUIDに対応するようです。
ただ今OpenCore0.5.7を実験してまして、Cloverの実起動環境から移行する場合は、ROM value も重要のようです。これを既存のCloverだとRtVariables –> ROM に設定してたらそれをもってこないとAppleIDがなんちゃらっというので赤①が出てきました。。。
OpenCore CconfiguratorのPlatformInfoの画面でいうところのDataHub-Generic-PlatformNVRAMで、この画面です。
ちなみに私は昔ながら?のUseMacAddr0をせっていしてて、何を入れてよいかすらわからなかったので、acidantheraさんのMacInfoPkgなるものの中のmacserialをClover環境で起動した後に実行して、ROM値を入れてなんとかなりました。。。
macserial
https://github.com/acidanthera/MacInfoPkg
macserial is a tool that obtains and decodes Mac serial number and board identifier to provide more information about the production of your hardware. Works as a decent companion to Apple Check Coverage and Apple Specs portal. Check the format description for more details.
CloverからOpenCoreへ移行する場合は、このGenericの5つの情報(Product Name, Serial Number, SmUUID, Board Serial Number, ROM)をCloverで使ってるのと同じものを入れるのがポイントみたいです。
>OpenCore ConfiguratorのPlatformInfoの画面でいうところのDataHub-Generic-PlatformNVRAMで、
>この画面です。
https://www.tonymacx86.com/data/attachments/400/400561-0e44adbec6036d92511755444ef08962.jpg
OCですとBig Surが導入できるらしと言う事でこちらの頁を参考にさせて頂き初めてトライ、OpenCore Sanity Checkerでは以下の３箇所に赤バツに、
Need either VBoxHfs.efi or HFSPlus.efi here
NvmExpressDxe.efi should not be here!
XhciDxe.efi should not be here!
とりあえずそのまま起動しましたら、以下の注が出る以外は全て作動している様です。
ocs: no schema for blacklistAppleupdate at 3 index, context
ver0.6.0ですがopencoreのガイドver0.5.9のsecurityにはBlacklistAppleUpdate項目は無いのですが
trueに変更されてるのですか、appleIDとの関連はあるでしょうから削除はまずいでしょうか？
0.5.9のマニュアルによるとBlacklistAppleUpdateのデフォルトはfalseです。なのでおそらく削除したらfalseになります。マニュアルとバニラガイドの説明によると、AppleIDに関係する項目ではないようです。(Setting BlacklistAppleUpdate true) Ignores Apple’s firmware updater, recommended to enable as to avoid issues with installs and updates. とありますので、macOSのアップデートの時にMacのファームウェアアップデートを実行させないようにする機能のようです。機種IDに古い機種を選んでいると、APFS起動に対応するために、ファームウェアをアップデートしようとするので（hackintoshなら意味がないですので）それを阻止する機能だと思います。High Sierra以降の機種のIDを使用しているなら、falseでも、削除してもどちらでも良いと思います。trueでも無害だと思います。
情報ありがとうございます。
その後、trueにしてみても同じメッセージが出るので削除して見ましたら出なくなりました。紹介されているSnapshotは簡単にconfig.plistが作成でき助かりました。
今後はrun-efi-updater NO stringsに変わるっていう方向感なんですかね？？？
BlacklistAppleUpdateは、0.5.8で出てきたけど、実際に使えなくって？、0.5.9で使えたけど、0.6.0で、run-efi-updater に変わったのかなぁ？
GithhubでMaster, Slaveが問題になって変えるよって話もあったし、お名前がちょと問題ありなんで、run-なっちゃらになったのかな？
7C436110-AB2A-4BBB-A880-FE41995C9F82:run-efi-updater
Override EFI firmware updating support in macOS (MultiUpdater, ThorUtil, and so on). Setting this to No or alternative boolean-castable value will prevent any firmware updates in macOS starting with 10.10 at least.
ども、boot MacOSさん、
フォーラムでOpenCoreのWindows同居についてお話見かけましたけど、こっちの記事にPostしておきます。
現時点0.5.9および0.6.0 DevBuildでは、Windowsの起動はできるけど、一つ何ですとぉ！！という点に気が付きました。それは、Windowsは起動できるけど、お使いのマザボのBiosからのNativeなWindowsじゃねぇーんだよっていうことを主張してる方がいて、初めてハっとしました。。。
https://www.tonymacx86.com/threads/dual-boot-w-opencore-0-5-7.295160/post-2099363
何でそうなってるのかっていうことで、調べてたりしてて、あぁーそうだねOZMOSISの流れもあるし、Cloverみたいに、いろんなOS皆んなで仲良くやりましょうねのような雰囲気はなくって、結局のところ可能な限りMacのUEFIっぽい ROMなどを含むBoot環境をPCのUEFIをこねこねして忠実にエミューレーとするのが本筋っぽい流れなのかなぁと感じましたね。。。
んで、何ですとぉ！！の話に戻りますが、OpenCore0.5.9では、OS個別にACPIがDropできないらしく、MacのSMBIOSのまんまWinちゃんが起動して、おや？ちょっと変わったPCだねっていうことで動いてるみたいですね？？？なので、IRQがちゃうからWi-FIうごかねぇ〜とかも起こるっぽいのかなぁと思いました。
CloverはDropForAllOSでそんなところもスイッチできるけど、それがないもんだから、NativeなWindowsじゃない事を知らないと、何でかな？？？というふうに挙動がおかしなのが出てくるのかなと理解しました。。。
ただ、そんな事態なんですけど、今まではフォークされたN-D-KさんのやつはGUIが付いてるだけかと思っていたところ、DropForAllOS風な機能が実装されてるっぽいことまで判明しやした。。。
MaLd0nさんのN-D-KについてのAdditional features/changes implementedの説明はこちら
https://www.olarila.com/topic/8228-hackintosh-guide-mojave-catalina-on-notebooks-desktops-series-100-200-and-300-with-opencore-ndk-bootloader/
– ACPI patches and Booter Quirks are optional for non macOS with setting ACPI->Quirks->EnableForAll / Booter->Quirks->EnableForAll to yes (default is no).
ということで、Windowsを使ってるけど、細かすぎる違いがあるのはイアな人でBios Bootのネイティッブで使う事を望む方は、当面、N-D-KやはたまたCloverとの宮本武蔵にならないとダメっぽいです。。。
vit9696さん曰く、下記のページのメッセージで、
”We understand that some people need multiboot support with Windows”と申されているんで、今後さらなるWindows multi bootサポートの可能性は排除されてはないけみたいですね？？？
でも、Multiboot or WindowsとのTriple boot Linuxなどなどは今後OpenCoreでどこまでサポートされていくのかは、私にはよくわかりませんけどね？？？
Acidanthera Updates: June 2020 Jun 1, 2020
https://dortania.github.io/hackintosh/updates/2020/06/01/acidanthera-june.html
Secondly, boot management. We understand that some people need multiboot support with Windows, sometimes even on the same drive your macOS installation exists. In the latest OpenCore version we reworked boot management from the ground to provide first-class Windows support. This was a tough decision, but it is here and brings better performance and compatibility. In addition to that with the help of the new bootstrap mechanism we were able to mostly resolve duplicated boot entries on ASUS APTIO V boards.
ということで、とりあえず以上です。
必要なら、OpenCoreの実態？とか、結局のとこと誰のためのOpenCore？みたいな記事にまとめて頂けるもいいのかとおもいましたぁ。w
どうぞよろしくお願いします。。。
OpenCoreのオリジナルのブートドライブ選択メニューが素っ気無いのも、macOS専用という方向の現れなのかな。Windowsは滅多に起動しない（最近だとBIOS起動ロゴを変えるくらい）のですが、起動の振る舞いに注意しておきます。
ちなみに今朝、OpenCoreのお供？Kext Updaterの更新実行したら、NDKプロジェクトは音沙汰なしっぽいんで、無慈悲削除ということらしいです。。。なんだかなぁ。。。w
お疲れ様です。
Windows起動時の問題は、なんとなく気づいていたんですよね、・・・初めてWindows選択するとPlymouthのWindowsの点々くるくるが長いんですよ。また、InsanelyMacの OpenCore Discussion で、「OCで一度Windowsを選ぶと、BIOS画面が出なくなるよ・・・」と言っても、音沙汰なしです。Cloverはブートローダーから流れが来ているので、ディュアルブートにはそもそも寛容ですね。
実務上、他人との関係や、バックアップの容易さもあって、Windowsは避けて通れないので、メインがOpenCoreになったら、いさぎよくBIOSでの起動ディスク選択で行かないといけないかもしれませんね。・・・なんかちょっとカッコ悪いなぁ＾＾；
CloverやOpenCoreはmacOSのブートローダーであり、ブートマネージャーとしては
使用しない方がスッキリするのでは？と思います。
例えばGRUB2やrEFIndをブートマネージャーとして、そこからWindowsやCloverや
OpenCoreのブートローダーを起動するような感じです。
私のマルチブートへの要件として、互いに干渉しないことが考えとしてあり、
有償ですが、BootItUEFIをブートマネージャーとして使用しています。
BootItUEFIにはEFIディレクトリのリネーム機能があり、上記要件を
満たしてくれますので、少し紹介させて下さい。
Windows、Clover、OpenCoreすべからずそうですが、EFIディレクトリ名が
決め打ちになっていて、マルチブートでの互いに干渉しない、ということが
困難になりますが、BootItUEFIのリネーム機能により解決できます。
拡張子は私の趣味ですが、以下のようにEFIを配置してBootItUEFIの
リネーム機能により、それぞれに干渉しない状態でブートできます。
EFI\Microsoft.7\bootmgfw.efi → Windows7用、起動時にEFI\Microsoftにリネームされる
EFI\Microsoft.10\bootmgfw.efi → Windows10用、起動時にEFI\Microsoftにリネームされる
EFI\CLOVER.14\CLOVERX64.efi → Mojave用、起動時にEFI\CLOVERにリネームされる
EFI\CLOVER.15\CLOVERX64.efi → Catalina用、起動時にEFI\CLOVERにリネームされる
EFI\OC.16\OpenCore.efi → OpenCore用、起動時にEFI\OCにリネームされる
上記により、Windowsの起動にCloverやOpenCoreに依存しない、macOSのバージョンにより
CloverかOpenCoreを使い分ける、を実現しています。
ども。匿名さんお疲れさまです。。。
＞BootItUEFIにはEFIディレクトリのリネーム機能があり、
＞上記要件を満たしてくれますので、少し紹介させて下さい。
TeraByte Unlimitedっていう会社さんがこしらえてるんですね？
Manage Drive Partitions and Multi-Boot the Easy Way with the BootIt
https://www.constructiondive.com/press-release/20180916-manage-drive-partitions-and-multi-boot-the-easy-way-with-the-bootit-1/
なかなか便利そうなしろものですね。。。情報展開ありがとうございます。
気がついたらCloverとOpenCoreに赤くコア化されてしまって、他のUEFI Boot Loaderを探すことすらできなくなっています。。。w
評価版もあるみたいだし、どこまでカスタマイズできるのかとか気になるし面白そうなんで遊んでみたいですねぇ。
あぁまた時間がぁぁ。。。
＞以下のようにEFIを配置してBootItUEFIのリネーム機能により、
＞それぞれに干渉しない状態でブートできます。
おぉ。。。ずらりとと各種OSがありますね。本格的なテスト環境な気配を感じますね。w
このくらい、数が必要になると有償でも探さないと無理ゲーですよね？
結構クセがあるのと、操作を誤ると簡単にパーテーションを飛ばしてしまうので
機能制限なしの30日間のトライアル版で試されるといいと思います。
実際、私は30日間＋別PCで30日間追加で2ヶ月色々試してから購入しました。
長くなるので書きませんでしたが、GPTパーテーション番号のリナンバリング機能も
ありますので、どのOSで起動しても
パーテーション0 EFI（macOSではdisk0s1）
パーテーション1 OS（macOSではdisk0s2）
とでき、混乱せずに済むのもありがたいです。
専用のソフトは流石に良く出来ていますね。
すみません。書き間違えました。
EFI\OC.16\OpenCore.efi → OpenCore用、起動時にEFI\OCにリネームされる
↓
EFI\OC.16\OpenCore.efi → BigSur用、起動時にEFI\OCにリネームされる
お疲れさまです。
専用ソフトの紹介ありがとうございます。さすがに有償だけあって作り込まれてるようですねぇ。試してみたいですね。
正直なところ・・・
macOSでは、次回再起動のエントリの指定ができるのが味噌なので、特にOSのアップデート時にこれがないと、以外に面倒ですねぇ。
あとは、Windowsもそうですがパックアップを書き戻すとUUIDがつけ直されてしまいます。起動時に検索するタイプだとうまくいく場合もあるのですが、はじめに検索指定するタイプでは、意外と再設定が面倒です。（特にブートマネージャー自体を書き戻すと更に面倒かもしれません）
なので、実のところBIOSの起動先選択は堅実で簡単なのでそう悪くはないんですよね。
一番は、見た目が最悪ということですかねぇ＾＾；
単純にマザボメーカーがちょっとリストの見た目を変えられるようにしてくれて、デフォルトを選べられれば、嬉しいかもしれません。
こんなのを観測いたしました。。。
Opencore Gen-X
Opencore Generation X is a Utility to create a pre-structured EFI Folder to the Desktop Based on the selection of the user.
https://github.com/Pavo-IM/OC-Gen-X
こんにちわ、OpenCore6.2を使っているのですが、インストール画面がドイツ語？になってしまいます。
なんとかうる覚えでインストールしました。気になるので調べたらprev-lang:kbdを変更するというのを
ガイドで拝見、prev-lang:kbd can be changed into a String so you can input en-US:0 directly instead of converting to HEX
まだ英語ならいいとおもったのでen-US:0を入力しましたが、言語は変更されませんでした。
↑の書き込みにcnUtUlU6MjUyというのを見つけたので入れてみましたが駄目でした。
これ何か数値が違うのかどうすればいいのでしょう？
開発してる主幹の方がラシア？だから知らないですけどぉ。。。ロシア語の表示が出てきてびっくらどうのこうのってのはよく散見されますねぇ。。。w
NVRAMちゃんと動いてますかぁ？NVRAMのテストするBootMacOSさんのガイドがあるのでそれと同じことして確かめてみるとか？。。。NVRAM動いてないならダメかもですよぉ。。。
あとは。。。いわゆる？わけわかになったら、兎にも角にもNVRAM一回でもクリアの儀をしてみましたかぁ？
16進数でconfig.plistのNVRAMのprev-lang:kbdに
656e2d55533a30
を設定すれば良いようです（en-US:0という文字列のアスキーコードそのものです）。ProperTreeを使うと簡単です。ちなみに素のconfig.plistではBase64で記述されてて、こんな内容になってます。
ここなどに説明があります。
https://dortania.github.io/OpenCore-Install-Guide/config.plist/comet-lake.html#nvram
まっくぷろさん、bootmacos さん、素早いレスを有り難うございます。
参考に家に帰ったら早速やってみたいと思います。
こんにちは。インターネットを調べていることのようなものを見つけました。
https://mackie100projects.altervista.org/download-opencore-configurator/
こちらのOpencore ConfigratorはClover Configlatorのように使うことができるものなのでしょうか？
Dortaniaさんのガイドに「Mackie氏のconfiguratorはconfig.plistを壊すので使うな」って書いてあったので、避けてました。もしかしたら今は改善されているのかもしれませんが。OpenCore Gen-XはDortaniaさんガイドに準拠したconfig.plistを作ってくれることを確認したので紹介させていただきました。
https://dortania.github.io/OpenCore-Install-Guide/config.plist/coffee-lake.html
ありがとうございます。
BIOSからUSBメモリを選択してもまた起動ディスクを選択する画面に戻ってしまいOpenCoreが起動できませんでした。
これはUSBメモリの問題なのでしょうか？
何度も確認したので中身の間違いはないと思います。
色々な原因が考えられますので、フォーラムのUSER BUILDSの方に[HELP]というタイトルで始まるトピックを作って質問していただけますでしょうか。詳しい状況（再起動するのか、そのUSBメモリから本物のMacは起動するのか）、構成（マザボ、CPU, グラフィクス、OpenCoreとmacOSのバージョン、aml, efi, kext, config.plistの内容）などできるだけ書いていただけると、皆さんからヒントがもらえるかと思います。
＞これはUSBメモリの問題なのでしょうか？
USBメモリの問題？にもいろいろあるので。。。
稀にハッキントッシュで’起動を拒絶するタイプのUSBメモリも存在するようなことを、ブログで動かんかったみたいなこと書いてる方がいらっしゃいました。ソースのブログのURL忘れちゃいました。wすみません。。。メーカー名は書いてあったのは覚えてますけどね。。。なぜ拒絶してたのか原因が不明だったので、気になって記憶に残ってはいるんですけど、USBメモリ型SSDに絡む何らかの要素かどうかなど、起動しなかった理由は謎のままなのが残念でしたぁ。
USBメモリ型SSDは“OS上からの認識され方が異なる”らしいので、そうゆう問題につながってる気もしなくもなくもないかなぁとか、下記の記事を思い出しました。。。
「USBメモリ」と「USBメモリ型SSD」は何が違うのか?
https://pc.watch.impress.co.jp/docs/topic/feature/1291158.html
後は、念のためというか、USBのメーカーとか、容量（Big Surなら16GB以上Catalinaまでは8GB）とかも報告する必要があるかもですね。起動ディスクのこしらえ方やフルインストーラのAppが破壊されてて、Mediaコマンドでこしらえても、エラーなしでできちゃってるとか、想定外なこともあるので、お使いのUSBメモリがほんまに壊れてないかWindowsでのインストール用ディスクで作り直して、動作確認とかもやってみてみるといいいかもです。
はじめての、おつかいのHackを自作されてるとかなら、USBメモリに起動用として、ちゃんとGUIDパーティションフォーマットしてないとか、Windowsで使ってたMBR形式でパーテション切ってまんまだとよろしくないので注意してかないといけませんしね。。。
USBメモリの詳しい情報を書くべきでした。すみません。
新しいものに買い直したら治ったのでもう大丈夫です。詳しい説明ありがとうございました。