OpenCoreのブートエントリがうまくでない、出すぎるとき。

Hackintosh

 1.ScanPolicyを0にしても、NoNameとWindowsしかでない。(macOSのエントリがでない)
 まず以下を試しましょう。

Set UEFI -> APFS to see APFS based drives:

    EnableJumpstart: YES
    HideVerbose: NO

 私のマザーボード(ASUS PRIME H370-A)の場合、これで、表示が出ました。
2.NoNameを消したい。
 ScanPolicyの問題です。0x00000000にすると、すべてのビットを立てて、すべてのスキャンをすることと同じになるので、全てが出てしまいます。

• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy, and to avoid mounting of undesired file systems it is best not to load its driver. This bit does not affect dmg mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.
• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. This is not always possible to detect protocol tunneling, so be aware that on some systems it may be possible for e.g. USB HDDs to be recognised as SATA. Cases like this must be reported. Known device types are prefixed with OC_SCAN_ALLOW_DEVICE_.
• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.
• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.
• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.
• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.
• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_EXT, allows scanning of EXT (Linux Root) file system.
• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.
  47
• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.
• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.
• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.
• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA. • 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.
• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.
• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.
• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus

 いろいろ試してみましたが、OC_SCAN_ALLOW_FS_ESPを入れると、NoNameとWindowsが両方出ます。別々に消すことはできませんでした(つД`)。
 そこで、まず、OC_SCAN_ALLOW_FS_ESP以外をONにしてみました。USBメモリとかを、入れた場合も対応できます。
 一番ラクな方法は、config.plistを指定しないで、OpenCore Configratorを単独で起動してMisc-SecurityのScanPolicyのビットを入れて、10進数を見ることです。(もちろん電卓で計算しても構いません)

ScanPolicyを33495811にします。これで、macOSのエントリのみがでます。

3.Windows等の他のOSを表示させる。
 Misc-EntriesにItemを作ります。例は以下のとおりです。

Misc
	Entries
		Item 1
				Arguments
				Auxiliary	false
				Comment		Windows10 Pro
				Enabled		true
				Name		Windows10 Pro
				Path		PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,06FB0163-59F8-46BA-9465-7DAA35F85887,0x3F,0x31FFF)/\EFI\Microsoft\Boot\bootmgfw.efi 
				TextMode	false

Pathの確認の仕方をまとめます。
(1)Cloverでも、OpenCoreでもいいので、efiのShellを起動する。
(2)以下のようにコマンドを入れて、お目当てのEFIのパーティションを探します。
(キー配列が英字になっているかもしれません、:はShift+;です。)

Shell>fs0:
fs0:>ls
(fs0パーティションのルートのディレクトリ内容が表示される)
fs0:>fs1:
fs1:>ls
(fs1パーティションのルートのディレクトリ内容が表示される)

(3)お目当てのEFIのドライブが見つかったら、mapコマンドでリダイレクトして、ファイルを作っておく。
 お目当ての、WindowsドライブのEFIパーティション(ESP)はfs5でした。

fs4:>fs5:
fs5:>ls
fs5:>ls EFI\Microsoft\Boot\
(Windowsのブートローダーである、bootmgfw.efiが表示されるはずです。 )
fs5:>map > fs5.txt

 結果を確かめる一番簡単なのは、Clover ConfigratorでMount EFIでWindowsのEFIをマウントすることです。(もちろん、diskutilでマウントしても構いません)

 fs5.txtを見てみましょう。以下のような感じで、ディレクトリのデバイスからパーティションまでの記述がわかるはずです。

Mapping table
FS0: Alias(s):HD0t0b:;BLK1:
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x13,0x0)/HD(1,GPT,7935ED5D-91A8-4116-9B79-07FB45534A7C,0x28,0x64000)
FS3: Alias(s):HD0w0c:;BLK7:
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x16,0x0)/HD(2,GPT,5352B84F-F94D-4E46-BCBA-FCD8D882F8BF,0x8000,0xE8E00000)
FS4: Alias(s):HD0x0c:;BLK10:
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x17,0x0)/HD(2,GPT,EAC51899-3E78-43BD-95D0-5FF45847C290,0x8000,0x1D1C03000)
FS5: Alias(s):HD1a65535a1:;BLK12:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,06FB0163-59F8-46BA-9465-7DAA35F85887,0x3F,0x31FFF)
(続く)

ここで、fs5は、

PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,06FB0163-59F8-46BA-9465-7DAA35F85887,0x3F,0x31FFF)

だとわかりました。
 そこで、これにフルパスでブート用のefiファイルを付け足して、pathの完成です。(HD(1,・・・)のあとに1つ”/”を入れるのを忘れないでください。)

PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,06FB0163-59F8-46BA-9465-7DAA35F85887,0x3F,0x31FFF)/\EFI\Microsoft\Boot\bootmgfw.efi 

 基本的に、どのOSでもUEFI対応になっていれば、ブート用のefiファイルをこの方法で探せますので、例えば”\EFI\ubuntu\grubx64.efi”などで問題ないはずです。
※注意
 ただし、表示させたとしても、それをDefaultに設定できるかは、マザーボードによります。(macOS上のシステム環境設定から設定してということになるようですが、かなり多くのマザーボードではBIOSの不具合でできません・・・こういうときの救済策なくBIOSのせいだと言われても、ユーザーに諦めろと言ってるようなものです。・・・ライセンスはかなりフリーなので文句は言えませんが、変なところで教条的なのは悲しいですねぇ)
 また、表示させたとしても、うまく動くかも解りません。以下が、OpenCore上の一応の妥協的設定です。

WindowsユーザーでもOpenCoreを使いやすくする設定方法(問題のあるASUSマザーのBIOSの問題の回避)

 これでもうまく行かない場合は、OpenCoreでの無駄なPickerを諦めましょう。

OpenCoreと他のOSと可能な限りうまく共存(チェーンローダーの導入)

コメント

Translate »
タイトルとURLをコピーしました