no what I was trying to say it never worked even before open core on cMP5,1. Windows 10 is not supported on this machine anyway nor is UEFI boot.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Windows 10 EFI on SSD/Sata boots fine for me under Mojave via Startup disk.
It stopped booting under Catalina for both Sata and PCIe setups.
OC with SIP disabled was the only way to boot Windows (EFI/NVMe) under Catalina.
@vit9696 I'll share the debug logs tomorrow.
I wonder if there is a way to examine the bless command output from the Startup disk utility? How is your Windows installed? On a separate disk or on the same disk as the Mojave/Catalina? Where is your boot.efi/bootX64.efi? If it is on the same disk then it is a hybrid MBR.
Last edited:
Code:
~ sudo systemsetup -getstartupdisk
Password:
➜ ~
Code:
sudo systemsetup -setstartupdisk /Volumes/WIN10NVME
Not a System Folder: /Volumes/WIN10NVME/System/Library/CoreServices
Code:
sudo systemsetup -liststartupdisks
/Volumes/High Sierra/System/Library/CoreServices
/Volumes/MojaveSSD/System/Library/CoreServices
/System/Library/CoreServices
/Volumes/MojaveNVME/System/Library/CoreServicesCoreservices is only on HFS or APFS drives. So if it is on a separate drive there is no way startupdisk will bless it.
[automerge]1579876743[/automerge]
Maybe we can copy bootx64.efi to a created folder
/Volumes/BOOTCAMP_DRIVE/System/Library/CoreServices
Last edited:
Just compare nvram -p before and after changing something in Startup Disk Utility?
It may also change HFS+ info (but not usually since each HFS+ macOS volume only has one startup file).
It may also change BootOrder or Boot### values in nvram with 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
You can build gfxutil from https://github.com/acidanthera/gfxutil
Take my gfxutil.sh script and modify the path to gfxutil
Then
source gfxutil.sh to load the functions included in that script.Then execute
dumpallbootvars.You should see something like this:
Code:
joevt@Joes-Mac-Pro ~ % source /Volumes/Work/Programming/ThunderboltProjects/OSXOLVED/gfxutil.sh
joevt@Joes-Mac-Pro ~ % dumpallbootvars
BootOrder: Boot0080 Boot0000
Boot0000: 1, "ubuntu" : HD(1,GPT,19D44A4A-72CE-488C-869C-32776991515D,0x28,0x64000)/\EFI\ubuntu\shimx64.efi
Boot0080: 1, "Mac OS X" : PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(12,GPT,01A40057-B54C-4974-AF84-A70CD2E937FF,0x6FC68A00,0x19088)
Boot0081: 1, "Mac OS X" : PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(8,GPT,977D4C1D-54CA-4594-B9F6-FCABF87AC36C,0x4B405D88,0x174876E8)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,7E98A08505BD8940A1199C16AA7CD67D)/\10D5CE8C-43FE-43F2-8089-DAEDF6485644\System\Library\CoreServices\boot.efi
joevt@Joes-Mac-Pro ~ %You can use gfxutil to view nvram variables or ioreg properties that are EFI paths
Code:
testioreg () {
local thedev="$1"
local thevar="$2"
echo "$thedev" "$thevar"
ioregp IODeviceTree "$thedev" "$thevar" | xxd -p -c 99999
gfxutil -d "IODeviceTree:/$thedev" "$thevar"
ioregp IODeviceTree "$thedev" "$thevar" | gfxutil
echo
}
(
testioreg chosen boot-device-path
testioreg chosen boot-file-path
testioreg options BootCampHD
testioreg options efi-apple-payload0-data
testioreg options efi-apple-payload1-data
testioreg options efi-apple-payload2-data
testioreg options efi-backup-boot-device-data
testioreg options efi-backup-boot-device-data-data
testioreg options efi-boot-device-data
) > ioregefidevicepaths2.txt 2>&1Thanks Joe, As I said I don't think startup disk can work on non Apple formatted volume so if the Windows UEFI is installed on a separate GPT drive nothing will happen:
Code:
~ source /Users/g5/Downloads/gfxutil.sh
➜ ~ dumpallbootvars
BootOrder: Boot0080
Boot0080: 1, "CATALINA" :
➜ ~This is giving more info:
Code:
sudo bless --getBoot --verbose
Password:
EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>74ED13D5-6F51-4204-A8CF-21CCA5D38A6B</string></dict></dict><key>BLLastBSDName</key><string>disk9s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\OC\OpenCore.efi</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'CATALINA'
Boot device path incorrect
Boot option does not match XML representation
XML representation doesn't match true boot preferenceYour 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080 is missing the efi path information which may explain the "Boot device path incorrect" message and other messages after that? Or gfxutil is not setup properly. Use
nvram 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080 to find out. We can decode it manually to see if it has an unexpected format.On my MacPro3,1, when I select a Windows partition in Startup Disk, it sets BootCampHD to the path of the drive and efi-boot-device-data is set to a Boot Camp program located in the EFI firmware. This is for legacy BIOS booting. It will run the boot code in the MBR which will run the boot code in the PBR of the active partition selected in the MBR which will then run the Windows boot loader.
On my MacMini8,1 when I select a Windows Boot Camp partition in Startup Disk, it sets efi-boot-device-data to the EFI partition with no file path. This is for EFI booting. Without a file path, I expect it to run the default bootx64.efi program.
@vit9696 Manually blessing the Windows drive stopped working with the debug version, with debug level set to 65, of OC compiled from master branch causing the system to freeze. I was able to gather some logs for your perusal.
The release version with debug level set to 0 works fine when manually blessing Windows. Blessing through Startup Disk fails with both REL/DEBUG.
I am guessing that activating writing to disk (debug level 65) may be causing the EFI folder of the macOS drive to be scanned first instead of the manually blessed Windows drive resulting in the system freeze. Windows resides on dedicated 2TB drive, while macOS is on the 1TB.
The command I use to manually bless Windows (and which works with REL-055-2020-01-25 with debug level set to 0):
I will try switching my 5700XT with a MVC flashed GTX 780 to see what actually happens on display with the debug version.
[automerge]1579944087[/automerge]
Windows is installed on a dedicated 2TB NVMe disk. OC's and BOOT folders are in the ESD/EFI partition on the macOS drive.
Both drives have GPT partition tables.
The release version with debug level set to 0 works fine when manually blessing Windows. Blessing through Startup Disk fails with both REL/DEBUG.
I am guessing that activating writing to disk (debug level 65) may be causing the EFI folder of the macOS drive to be scanned first instead of the manually blessed Windows drive resulting in the system freeze. Windows resides on dedicated 2TB drive, while macOS is on the 1TB.
The command I use to manually bless Windows (and which works with REL-055-2020-01-25 with debug level set to 0):
Code:
sudo bless --folder /Volumes/NO\ NAME --file /Volumes/NO\ NAME/EFI/Microsoft/Boot/bootmgfw.efi --setBoot --nextonly --verboseI will try switching my 5700XT with a MVC flashed GTX 780 to see what actually happens on display with the debug version.
[automerge]1579944087[/automerge]
Windows is installed on a dedicated 2TB NVMe disk. OC's and BOOT folders are in the ESD/EFI partition on the macOS drive.
Both drives have GPT partition tables.
Last edited:
@w1z, better create an issue in acidanthera/bugtracker. It is not really possible to track stuff on the forums. The only useful log file is opencore-2020-01-25-062452-Windows-BootviaPanel.txt.
Basically the issue is with your NVMe driver. If you look closely, it creates absolutely inadequate device paths. Here is what macOS gives, SasEx is Apple's extension introduced before NVMe standardisation, so on hackintosh it is NVMe, and we match both SasEx for Apple and NVMe for hackintosh on failure:
However, this is what your NVMe driver gives:
It contains something absolutely weird and unrelated: Msg. Did you patch your firmware with a NVMe driver or is that driver natively provided by Apple? If the former, it kind of makes sense to use the NVMe driver from OpenCore / EDK II, as the one you have is completely broken. If the latter… we could try to consider something, but it is really messed up.
Basically the issue is with your NVMe driver. If you look closely, it creates absolutely inadequate device paths. Here is what macOS gives, SasEx is Apple's extension introduced before NVMe standardisation, so on hackintosh it is NVMe, and we match both SasEx for Apple and NVMe for hackintosh on failure:
Code:
00:644 00:003 OCB: Dumping BootOrder
00:648 00:003 OCB: 0 -> Boot0080 = MemoryMapped(0xB,0xFFD50000,0xFFFDFFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)
00:651 00:003 OCB: Predefined list
00:654 00:003 OCB: 0 -> Boot0080 = MemoryMapped(0xB,0xFFD50000,0xFFFDFFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)
00:657 00:003 OCB: 1 -> Boot0081 = PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x11,0x0)/Pci(0x0,0x0)/SasEx(0x0100000000253857,0x91500E337074616C,0x0,NoTopology,0,0,0)/HD(1,GPT,5E201C4F-0982-4DFD-1CB6-74B5D2273719,0x800,0x32000)
00:661 00:003 OCB: 2 -> Boot0082 - failed to read
00:664 00:003 OCB: Predefined list
00:667 00:003 OCB: Default is AppleLegacyLoadApp
00:670 00:003 OCB: Default DP pre-fix - PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x11,0x0)/Pci(0x0,0x0)/SasEx(0x0100000000253857,0x91500E337074616C,0x0,NoTopology,0,0,0)
00:674 00:003 OCB: Default DP post-fix - PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x11,0x0)/Pci(0x0,0x0)/NVMe(0x1,33-0E-50-91-57-38-25-00)
00:677 00:003 OCB: Default DP post-fix remainder - NVMe(0x1,33-0E-50-91-57-38-25-00)
00:680 00:003 OCPI: Locating disk's ESP - PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x11,0x0)/Pci(0x0,0x0)/NVMe(0x1,33-0E-50-91-57-38-25-00)
00:684 00:003 Failed to locate the disk's ESPHowever, this is what your NVMe driver gives:
Code:
00:617 00:004 Entry 2 is BOOTCAMP Windows at \EFI\BOOT\ (T:3|F:0)
00:621 00:003 Entry 2 is BOOTCAMP Windows at dp PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x11,0x0)/Pci(0x0,0x0)/Msg(34,010000000025385791500E33)/HD(1,GPT,5E201C4F-0982-4DFD-1CB6-74B5D2273719,0x800,0x32000)/\EFI\BOOT\BOOTX64.efiIt contains something absolutely weird and unrelated: Msg. Did you patch your firmware with a NVMe driver or is that driver natively provided by Apple? If the former, it kind of makes sense to use the NVMe driver from OpenCore / EDK II, as the one you have is completely broken. If the latter… we could try to consider something, but it is really messed up.
Sure, I will raise the issue on the bug tracker.
The current loaded bootrom, 144.0.0.0, is from Apple with no modifications or custom drivers injected into it and the PCIe NVMe card is HighPoint 7101-A, using it without HP's drivers. Apple added NVMe booting capability to the 5,1 bootrom.
They also introduced a restriction in Startup Disk/Mojave+ that only allows Windows CSM (non-EFI) MBR/Hybrid MBR installs to be selected/blessed via the panel on a 5,1 as I was previously able to boot Windows 10 EFI with GPT partition from a PCIe mounted SSD (Sonnet Tempo Pro).
I will reshare the above in the bug tracker.
Thanks
Last edited:
I noticed that after a firmware re-flash I have no such messages. As soon as I start booting from OC I get:
Code:
Boot option does not match XML representation
XML representation doesn't match true boot preferenceSo is there a way to select the startup disk without rebooting and check what the paths are set for? Because all the time after that it will boot to a black screen with an error cannot find the boot device.
[automerge]1579955960[/automerge]
I looked at your log file and you too have this:
Code:
00:009 00:003 OCCPU: MP services Pkg 2 Cores 16 Threads 32 - SuccessSo it must be something common to the firmware as I even re-flashed the firmware.
@tsialex what do you think?
Last edited:
So it is a mistake of writing 0x22 (34) instead of 0x16 (22). Happens I guess. OK, I implemented the support for this in master:
[master 318dddf] OcDevicePathLib: Implement support for fixing more device paths
1 file changed, 29 insertions(+)
You may not create a bugreport, I will just leave a reference to this post.
This is raw data we receive from MpProtocols. It is printed for debugging reasons only, the operating system gets the value printed later (OCCPU: Pkg %u Cores %u Threads %u).
Conclusion:
Those who want to run their MP5.1 Catalina-capable with the possibility of software updates have to
A) live with the constant processor clocking in the simple variant with active VM-flag
or B) get involved in SMC-spoofing with all its risks, so that the VM flag is then not needed and the processors are dynamically clocked, correct?
This behavior in A) cannot be solved with OC, it is an Apple "feature"...
Well I just tried updating the Catalina to the latest beta with VMM flag. Now I constantly get KP:
Code:
Panic (system crashes) log:
Source: /Library/Logs/DiagnosticReports/Kernel_2020-01-25-102356_G5.panic
Size: 3 KB (3,198 bytes)
Last Modified: 1/25/20, 10:23 AM
Recent Contents: Anonymous UUID: 809FA503-F86E-7D21-BEC1-E179DF331D85
Sat Jan 25 10:23:56 2020
*** Panic Report ***
panic(cpu 16 caller 0xffffff8008b94a08): "a freed zone element has been modified in zone kalloc.1664: expected 0 but found 0, bits changed 0, at offset 0 of 1664 in element 0xffffff80f9b81480, cookies 0x3f00116ac1108ede 0x535215e1dc3fd55"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.61.1/osfmk/kern/zalloc.c:1229
Backtrace (CPU 16), Frame : Return Address
0xffffff8e1e593890 : 0xffffff8008b3bb1b mach_kernel : _handle_debugger_trap + 0x47b
0xffffff8e1e5938e0 : 0xffffff8008c733e5 mach_kernel : _kdp_i386_trap + 0x155
0xffffff8e1e593920 : 0xffffff8008c64e5e mach_kernel : _kernel_trap + 0x4ee
0xffffff8e1e593970 : 0xffffff8008ae2a40 mach_kernel : _return_from_trap + 0xe0
0xffffff8e1e593990 : 0xffffff8008b3b207 mach_kernel : _DebuggerTrapWithState + 0x17
0xffffff8e1e593a90 : 0xffffff8008b3b5eb mach_kernel : _panic_trap_to_debugger + 0x21b
0xffffff8e1e593ae0 : 0xffffff80092d24f9 mach_kernel : _panic + 0x61
0xffffff8e1e593b50 : 0xffffff8008b94a08 mach_kernel : _zone_find_largest + 0x128
0xffffff8e1e593b80 : 0xffffff8008b94b71 mach_kernel : _zone_find_largest + 0x291
0xffffff8e1e593bb0 : 0xffffff8008b94838 mach_kernel : _zfree + 0xe28
0xffffff8e1e593bd0 : 0xffffff8008b92dc1 mach_kernel : _zalloc_async + 0x3e1
0xffffff8e1e593d00 : 0xffffff8008b487f4 mach_kernel : _kalloc_canblock + 0xa4
0xffffff8e1e593d70 : 0xffffff8009205577 mach_kernel : _IOMalloc + 0x27
0xffffff8e1e593da0 : 0xffffff7f89cb17b6 com.apple.filesystems.apfs : __ZN24AppleAPFSContainerScheme5probeEP9IOServicePi + 0x196
0xffffff8e1e593e40 : 0xffffff800921a50a mach_kernel : __ZN9IOService15probeCandidatesEP12OSOrderedSet + 0x63a
0xffffff8e1e593ef0 : 0xffffff8009219d3e mach_kernel : __ZN9IOService14doServiceMatchEj + 0x2ce
0xffffff8e1e593f50 : 0xffffff800921c4dd mach_kernel : __ZN15_IOConfigThread4mainEPvi + 0x15d
0xffffff8e1e593fa0 : 0xffffff8008ae213e mach_kernel : _call_continuation + 0x2e
Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1412.61.1)[BFCAECB1-348B-3C39-AAAE-B162D45A401B]@0xffffff7f89c89000->0xffffff7f89dc1fff
dependency: com.apple.kec.corecrypto(1.0)[BDC53810-BC66-3B24-8F2B-EE3F9A7CF761]@0xffffff7f8953e000
dependency: com.apple.driver.AppleEffaceableStorage(1.0)[9CFE1D96-820B-3199-97F9-D85A7CA182E4]@0xffffff7f89c7d000
dependency: com.apple.iokit.IOStorageFamily(2.1)[D6C7A1D3-1E90-37A3-9D36-F6793A476858]@0xffffff7f8946a000
BSD process name corresponding to current thread: kernel_task
Boot args: -v agdpmod=pikera -shikidbg -raddbg -liludbgall liludump=10 debug=0x164 keepsyms=1 -no_compat_check -wegtree shikigva=144
Mac OS version:
Not yet set
Kernel version:
Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64
Kernel UUID: C3E7E405-C692-356B-88D3-C30041FD1E72
Kernel slide: 0x0000000008800000
Kernel text base: 0xffffff8008a00000
__HIB text base: 0xffffff8008900000
System model name: MacPro5,1 (Mac-F221BEC8)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
System uptime in nanoseconds: 5479317851
EOF10.15.3 beta 3 (19D75a)
Here is the output after I re-flashed the firmware:
Code:
sudo bless --getBoot --verbose
Password:
EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>3C84B9EC-B13D-44B6-9ACD-6742EBD4609B</string></dict></dict><key>BLLastBSDName</key><string>disk12s2</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\47997222-1DEF-4C0D-BB4B-E5BA02417DFF\System\Library\CoreServices\boot.efi</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'Mac OS X'
Boot option matches XML representation
Found device: disk12s2
Disk boot device detected
Detected APFS volume. Skipping Boot!=Root check.
No auxiliary booter partition required
System partition found
Preferred system partition found: disk7s1
Preferred system partition found: disk10s1
Preferred system partition found: disk11s1
Preferred system partition found: disk13s1
Preferred system partition found: disk14s1
Returning booter information dictionary:
{
"Auxiliary Partitions" = (
);
"Data Partitions" = (
disk12s2
);
"Preboot Volumes" = (
disk12s2
);
"System Partitions" = (
disk10s1,
disk14s1,
disk13s1,
disk11s1,
disk7s1
);
}
/dev/disk12s2 is a preboot volume
Substituting found system volume /dev/disk12s5
/dev/disk12s5Blessing OC prior to booting:
Code:
~ sudo bless --getBoot --verbose
EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>74ED13D5-6F51-4204-A8CF-21CCA5D38A6B</string></dict></dict><key>BLLastBSDName</key><string>disk15s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\OC\OpenCore.efi</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'Mac OS X'
Boot option matches XML representation
Found device: disk15s1
Disk boot device detected
/dev/disk15s1Booting from OC:
Code:
sudo bless --getBoot --verbose
Password:
EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>74ED13D5-6F51-4204-A8CF-21CCA5D38A6B</string></dict></dict><key>BLLastBSDName</key><string>disk15s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\OC\OpenCore.efi</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'CATALINA'
Boot device path incorrect
Boot option does not match XML representation
XML representation doesn't match true boot preferenceNot sure why are you posting your AMD Hackintosh in the MacPro forum?
Last edited:
I tried again updating to the latest Catalina beta with the VMM flag and I got another KP this time it points to the software raid driver:
Code:
panic(cpu 6 caller 0xffffff800fcdda4d): Kernel trap at 0xffffff80101c9180, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000000000038, CR3: 0x0000000cb0730024, CR4: 0x00000000000226e0
RAX: 0x0000000000000000, RBX: 0x0000000000000003, RCX: 0x0000000000000001, RDX: 0xffffff81011cfb90
RSP: 0xffffff8e2771bae0, RBP: 0xffffff8e2771bc70, RSI: 0x0000000000000001, RDI: 0xffffff810094bb00
R8: 0xffffff8101435720, R9: 0xffffff80104a46a8, R10: 0x000000000000000d, R11: 0x0000000000000000
R12: 0xffffff810094bb00, R13: 0xffffff80106208c8, R14: 0xffffff81011cfb90, R15: 0x0000000000000002
RFL: 0x0000000000010202, RIP: 0xffffff80101c9180, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000038, Error code: 0x0000000000000000, Fault CPU: 0x6, PL: 0, VF: 0
Backtrace (CPU 6), Frame : Return Address
0xffffff8e2771b5b0 : 0xffffff800fbb058d
0xffffff8e2771b600 : 0xffffff800fcec0f5
0xffffff8e2771b640 : 0xffffff800fcdd82a
0xffffff8e2771b6b0 : 0xffffff800fb5d9d0
0xffffff8e2771b6d0 : 0xffffff800fbaffa7
0xffffff8e2771b7f0 : 0xffffff800fbafdf3
0xffffff8e2771b860 : 0xffffff800fcdda4d
0xffffff8e2771b9d0 : 0xffffff800fb5d9d0
0xffffff8e2771b9f0 : 0xffffff80101c9180
0xffffff8e2771bc70 : 0xffffff80101c9346
0xffffff8e2771bca0 : 0xffffff801022d705
0xffffff8e2771bd00 : 0xffffff8010237473
0xffffff8e2771bd20 : 0xffffff801028bb64
0xffffff8e2771bd50 : 0xffffff800fc99e0a
0xffffff8e2771bd80 : 0xffffff800fbb5dcc
0xffffff8e2771bdd0 : 0xffffff800fb90b41
0xffffff8e2771be50 : 0xffffff800fba525e
0xffffff8e2771bef0 : 0xffffff800fcc3767
0xffffff8e2771bfa0 : 0xffffff800fb5e1b6
BSD process name corresponding to current thread: diskarbitrationd
Mac OS version:
18G3019
Kernel version:
Darwin Kernel Version 18.7.0: Thu Jan 23 06:52:12 PST 2020; root:xnu-4903.278.25~1/RELEASE_X86_64
Kernel UUID: 71EBCAB7-7239-36ED-A2B8-3DCEB0D5EFD1
Kernel slide: 0x000000000f800000
Kernel text base: 0xffffff800fa00000
__HIB text base: 0xffffff800f900000
System model name: MacPro5,1 (Mac-F221BEC8)
System uptime in nanoseconds: 8877200075
last loaded kext at 8800586420: com.softraid.driver.SoftRAID 5.6.6 (addr 0xffffff7f91f8d000, size 401408)
loaded kexts:
com.softraid.driver.SoftRAID 5.6.6
com.paragon-software.filesystems.ntfs 71.5.15
|IO!BUSBDFU 6.0.14d4
>ACPI_SMC_PlatformPlugin 1.0.0
@filesystems.msdosfs 1.10
@filesystems.autofs 3.0
>!AWWANSupport 4.0.0
|SCSITaskUserClient 408.250.3
>!AFileSystemDriver 3.0.1
>!AVirtIO 2.1.3
@filesystems.hfs.kext 407.200.4
@!AFSCompression.!AFSCompressionTypeDataless 1.0.0d1
@BootCache 40
@!AFSCompression.!AFSCompressionTypeZlib 1.0.0
@!ASystemPolicy 1.0
@filesystems.apfs 945.275.8
>!AFWOHCI 5.6.0
>!AAHCIPort 329.260.5
@private.KextAudit 1.0
>!AHPET 1.8
>!ARTC 2.0
>!AACPIButtons 6.1
>!ASMBIOS 2.1
>!AACPIEC 6.1
>!AAPIC 1.7
>!A!ICPUPowerManagementClient 220.0.0
@nke.applicationfirewall 202
$TMSafetyNet 8
>!A!ICPUPowerManagement 220.0.0
>!UAudio 315.6
|IOAudio!F 206.5
@vecLib.kext 1.2.0
|IOFireWireIP 2.3.0
>IOPlatformPluginLegacy 1.0.0
>IOPlatformPlugin!F 6.0.0d8
@kext.triggers 1.0
|IOSCSIMultimediaCommandsDevice 408.250.3
|IOBD!S!F 1.8
|IODVD!S!F 1.8
|IOCD!S!F 1.8
|IOAHCISerialATAPI 267.50.1
>usb.IOUSBHostHIDDevice 1.2
>usb.cdc 5.0.0
>usb.networking 5.0.0
>usb.!UHostCompositeDevice 1.2
>usb.!UHub 1.2
|IOSerial!F 11
@filesystems.hfs.encodings.kext 1
|IOAHCIBlock!S 301.270.1
>!AXsanScheme 3
>usb.!UXHCIPCI 1.2
>usb.!UXHCI 1.2
|IOFireWire!F 4.7.3
|IONVMe!F 2.1.0
|IOAHCI!F 288
>!UMergeNub 900.4.2
>usb.!UEHCIPCI 1.2
>usb.!UUHCIPCI 1.2
>usb.!UUHCI 1.2
>usb.!UEHCI 1.2
>usb.!UHostPacketFilter 1.0
|IOUSB!F 900.4.2
>!UHostMergeProperties 1.2
>!AEFINVRAM 2.1
>!AEFIRuntime 2.1
|IOSMBus!F 1.1
|IOHID!F 2.0.0
$quarantine 3
$sandbox 300.0
@kext.!AMatch 1.0.0d1
>DiskImages 493.0.0
>!AFDEKeyStore 28.30
>!AEffaceable!S 1.0
>!AKeyStore 2
>!UTDM 456.260.3
>!AMobileFileIntegrity 1.0.5
|IOUSBMass!SDriver 145.200.2
|IOSCSIBlockCommandsDevice 408.250.3
|IOSCSIArchitectureModel!F 408.250.3
|IO!S!F 2.1
@kext.CoreTrust 1
>!ACredentialManager 1.0
>KernelRelayHost 1
|IOUSBHost!F 1.2
>usb.!UCommon 1.0
>!ABusPower!C 1.0
>!ASEPManager 1.0.1
>IOSlaveProcessor 1
|IOTimeSync!F 740.2
|IONetworking!F 3.4
|IOReport!F 47
>!AACPIPlatform 6.1
>!ASMC 3.1.9
|IOPCI!F 2.9
|IOACPI!F 1.4
@kec.pthread 1
@kec.Libm 1
@kec.corecrypto 1.0I can confirm that I am now able to boot/bless Windows 10 EFI on a dedicated NVMe drive using Startup Disk and with debugging enabled (write to disk) - log attached.
Thank you =)
If anyone wants to try this, make sure to compile OC from the master branch
Code:
<key>AdviseWindows</key>
<true/>
Last edited:
I can't even see the Windows Partition in the startup disk. I wonder if the Paragon NTFS for Mac has something to do with it.
What is the output of :
Code:
sudo systemsetup -liststartupdisks
/Volumes/High Sierra/System/Library/CoreServices
/Volumes/CATALINA/System/Library/CoreServices
/System/Library/CoreServices
/Volumes/MojaveNVME/System/Library/CoreServicesYes, paragon ntfs interferes with Startup Disk so you will need to disable it.
Code:
➜ ~ sudo systemsetup -liststartupdisks
/Volumes/WIN10/WINDOWS
/System/Library/CoreServicesNow when I disabled it it is there:
Code:
sudo systemsetup -liststartupdisks
/Volumes/High Sierra/System/Library/CoreServices
/Volumes/CATALINA/System/Library/CoreServices
/Volumes/WIN10NVME/WINDOWS
/System/Library/CoreServices
/Volumes/MojaveNVME/System/Library/CoreServicesEven startup disk selection is not allowed with SIP:
Code:
sudo systemsetup -setstartupdisk /Volumes/WIN10NVME
Setting startup disk not allowed while System Integrity Protection is enabled.
Use VMM flag spoofing just when software updates are released and rely on boot-args="-no_compat_check", no need to use SMBIOS spoofing.
Did you try it through Startup Disk and not only via terminal? If you did and it's still not applying it then try disabling NVRAM protection only in SIP.