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
Good to hear. As for AdviseWindows, please be aware that it is a bit unrelated. This option is to enable choosing (UEFI) Windows on any machine regardless of the Mac model. However, it is only applicable if you use Generic section and choose to update NVRAM. If you do not change your Mac model via Generic, you will have to do bit manipulation manually.
Select the startup disk, then select a different preferences panel. The setting is saved when the Startup Disk preferences panel is closed or a different preferences panel is displayed.
Changing the 34 to a 22, produces a SasEx node, but the format is different than what is defined in edk2. I made a guess that Apple uses 32 bit SasAddress and Lun instead of 64 bit but maybe that is wrong.
gfxutil handles both sizes and produces reversible results at least, but maybe the short Apple size needs a different interpretation. I'll have to check devtree in the EFI Shell for my MacMini8,1, and compare with "diskutil info -all".
Code:
gfxutil "Msg(34,010000000025385791500E33)"
03221000010000000025385791500e337fff0400
gfxutil "Msg(34,010000000025385791500E33)" | gfxutil
Msg(34,010000000025385791500E33)Node at offset 0 has unknown type 0x03 or sub type 0x22.
gfxutil "Msg(34,010000000025385791500E33)" | gfxutil | gfxutil
03221000010000000025385791500e337fff0400Node at offset 0 has unknown type 0x03 or sub type 0x22.
gfxutil "Msg(22,010000000025385791500E33)"
03161000010000000025385791500e337fff0400
gfxutil "Msg(22,010000000025385791500E33)" | gfxutil
SasEx(0x01000000,0x00253857,0x330E,0x5091,0,0,0)
gfxutil "Msg(22,010000000025385791500E33)" | gfxutil | gfxutil
03161000010000000025385791500e337fff0400
gfxutil "SasEx(0x0100000000253857,0x91500E337074616C,0x0,NoTopology,0,0,0)"
03161800010000000025385791500e337074616c000000007fff0400
gfxutil "SasEx(0x0100000000253857,0x91500E337074616C,0x0,NoTopology,0,0,0)" | gfxutil
SasEx(0x0100000000253857,0x91500E337074616C,0x0,NoTopology,0,0,0)You didn't show the output from dumpallbootvars or from
nvram 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080 but I guess it doesn't matter now that it's been fixed and you get the "Boot option matches XML representation" message.
No it is the other way around. I only get "Boot option matches XML representation" during fresh firmware flash. In fact the XML file which is in the NVRAM disappears when I boot through OC. That is why it says it is broken, because it is no longer there. I have it somewhere posted and Alex commented on it.
Thanks for the clarification.
By the way, I am unable to boot to macOS recovery with OC enabled using CMD+R or via manual bless and I am not sure why. I have attached the log and would appreciate your input.
I also wish to contribute to the OC project by donating - are you guys accepting donations?
macOS 10.15 Catalina on Unsupported Macs
For that machine if you have a Metal GPU, after the beta update you need only "-no_compat_check" in nvram, that is already settled also in the script (catalinaswufix3) I wrote for Catalina OTA update, it's based on Pinarek OTA method (with ASentientBot tip for whitelisting), swupatch from...
forums.macrumors.com
CMD+R may bypass OpenCore depending on the time you press it. As for manual bless, I am not sure what you mean. However, selecting Recovery in OpenCore menu should work. Apple's original AppleBootPolicy protocol implementation has a bug, which resulted in missing trailing slash (\) in recovery paths. Most Macs have it fixed, but apparently your MacPro does not:
Code:
00:548 00:002 Entry 1 is Recovery at \ (T:2|F:0)
00:551 00:003 Entry 1 is Recovery at dp PciRoot(0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)/Msg(34,010000000025385581B47E4C)/HD(2,GPT,8C9F36E7-5B20-49EE-B527-9B54F03013AB,0x64028,0x77359260)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,0F1553FC50F13D4FA7CB613790CC778F)/FD54E2E0-499B-4752-B96B-9EBFCE583AE2
00:554 00:002 Trying to get label from \EFI\BOOT\.contentDetails
00:557 00:003 Trying to get label from \EFI\BOOT\.disk_label.contentDetails
00:560 00:003 Trying to detect Microsoft BCDFD54E2E0-499B-4752-B96B-9EBFCE583AE2 is a folder, but it is not recognised being so due to missing trailing slash. Therefore IsFolder is not set (F:0) and recovery is not recognised.
To workaround this force install OpenCore version of AppleBootPolicy protocol in the configuration (see UEFI → Protocols → AppleBootPolicy).
Can you please make sure the HEVC decode/encode and the DRM streaming works with this change and it is not reverting the changes made by -wegtree (if you use it). -wegtree is more universal than the direct change in the config file and also applies for cards installed in the slots other than slot one.
Yes, thanks, that of course is a reasonable way and an absolutly good idea!
But as I understood, updates provided by Apple are not even offered or displayed under "Software Update" in Catalina without OC and VM-Flag on an unsupportd Mac. Am i wrong?
If it is that way and not wrong, one will have to think of a way to get noticed about updates without a longer delay.
I could of course, being always very disciplined, boot with OC once a week or a month and check it. Some kind of an "update-day" marked in the calendar (not the worst idea).
To prevent the "-no_compat_check" disappearing for whatever reasons, i yet activated a plist in launchdaemons that sets this boot-arg when the mac shuts down, so as to ensure a native boot into catalina is always possible.
But of course i did hope that there might be a chance to always boot with OC, so you can just sit back and relax and pretend that the old mac is natively supported ;-)
But let me go back to another problem, maybe somebody here knows some further advice...
As you can read in a previous post #805, I had solved my problem with the OC bootpicker menu first showing only the systems on the ssd where OC is installed. This was solved by plugging the SSD with the OC and the Catalina APFS-container into Bay 1 of my MP5.1 and moved my current main system with Mojave from Bay 1 into Bay 4. After that I were able to see and select all the other bootable systems, too and also in startup disk preferences, so they all startet with OC.
See my correct & complete bootmenu in #805.
Yesterday after unblessing the OC EFI-volume i worked with my main old Mojave conventionally.
Today i wanted to do some new testing in Catalina with OC, so i blessed the EFI again. Booting the Mac bootpicker shows the bootmenue and ...outch!... again only the two, Catalina and recovery, were offered, missing again all the other system partitions on different drives. SSD with OC still in Bay 1, not altered anything. I did some SMC-Resets but that didn't helped. Did not try to change my drive order again to another configuration, but even if this may fix the issue once again, this can not be the way to go. What is happening here? What makes OC not see the other system volumes?
You need to include your boolog, otherwise no one knows what happens.
you could just add the flag to your com.apple.Boot.plist instead and it would always be there for this install.
Ok, i first have to learn how to write a bootlog... No worry, i will find out!
[automerge]1580081727[/automerge]
My daemon is running successfully. But yes, i will have a look to this plist. It might be a better idea to set it there. Thanks for this hint!
Last edited:
Ok, i hope i did it right, DisableWatchDog to true and Target to "81".
Result is only one Entry in the logfile:
00:000 00:000 OCB: Failed to fix the default boot Device Path
Made some thoughts about putting the "-no_compat_check" into com.apple.Boot.plist rather than to run an automated script at shutdown which is setting this boot-arg immediately prior the shutdown.
What i wanted to ensure is, that for whatever reason this boot-arg is deleted in nvram due to a process in the running system, maybe an update-process or similar, it would be surely set again prior to a reboot.
I'm afraid that, when a boot into catalina is started and in nvram this argument first is missing, the boot process will be denied even before the com.apple.Boot.plist is checked and the argument again is set. Am i wrong?
ok, yes, maybe my fear is groundless and the boot.plist is the very first to be executed before any other system file checkings take place, which do have an impact to booting beeing denied or allowed.
I did a diff between your file and Sample.plist 0.5.4, I see several sections removed which are easy to understand why. There are some changes you performed, for example ExposeSensitiveData set to 2 instead of 6, etc. How do you recommend me to proceed with the config.plist updates, should I compare Sample.plist changes between old/new version and apply them to your config?
Update:
First I changed my blessing command from
"sudo bless --mount /Volumes/EFI --setBoot"
to
"sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/BOOT/BOOTx64.efi".
After that the logfile was empty. That fixes the default Boot Path, but that of course didn't fix the issue with boot menu from #861. My OC Boot Menu still has only two entries instead of the correct 12.
But sorry, i didn't install the debug-release of OC. I've don that now with the result of a filled bootlog. See attachment. Did set the debug display level to "2151678017" in config.plist to catch all supportet debug messages...
As i myself (noob) can see, the filesystems of the other bootable systems are not mentioned in the bootlog, only those of the APFS Container with Catalina on the disk where OC resides... I attach a second file with diskname and uuid's where all my 12 bootable filesystems can be seen.
PS: Did set the debug display level to "2151678017" in config.plist to catch all supportet debug messages...
Oh yes, of course, scan policy is 0. Did write that in my first big post in #802.
My config.plist is attached there, too (is from that view days ago, so at that time not yet any debugging enabled, but the rest is still the same).
The issue occures with my first install with OC 0.5.3 and did not change by updating to 0.5.4. I think a new update to 0.5.5 will not fix that and 0.5.5 is not out as an official release. The problem is somewhere in my config or in my mac. I did not test it, but as it was first fixed by physically swapping disks (see #805), it probably will do again. But i don't want to swap my disks every second day in circles... :-(
What i noticed is, that the disk numbering changes without any further swapping. As i put my EFI-OC disk with the catalina from bay4 to bay1 it changes from disk1 to disk0. The EFI with OC then was disk0s1. The boot menu then suddenly was complete.
Today, the disk is still in bay1, but it is now disk3. The OC EFI now disk3s1. The boot menu now is incomplete again in the same way as before the diskswapping. Don't know what did cause this renumbering without altering the diskpositions and don't know, too, if this could affect the issue with the boot menu. What makes OC recognize my bootable volumes and what is inhibiting this? Does the physical order of the disks play a role when booting with OC?
Sorry, but it's me again. Still the "boot menu" theme.
Please is there anybody who has experienced something similar with the OC boot menu and knows some advice? I searched this whole "OC on MacPro"-Thread and didn't found something similar.
I have now done some more tests and have created logfiles to that.
First, with the initial situation where the boot menu is not complete, so OC does not completely cover my bootable systems.
Second, after I was able to create a situation where the boot menu shows all my bootable systems by swapping drives again. But this will probably only work for a short time again...
My initial setup:
- The SSD with the EFI on which the OC is installed is located in Bay 1 of my MP5.1. The Catalina is also installed on this SSD. EFI with OC is blessed.
- The SSD with my main system (Mojave) is in Bay 2.
- In Bay 3 & 4 are pure data disks without system.
- In the lower DVD drive bay ("Lower") i placed another data disc, but on this one there is also (as a kind of emergency rescue system) a recovery from an old High Sierra as Apple_Boot partition.
- On a SSD PCIe card is a SSD with additional system partitions:
> Sierra and High Sierra as HFS+ plus and a Apple_Boot Recovery HD
> Additionally in an APFS container a small Mojave with Recovery
Here first the case with the incomplete boot menu:
When booting, the following 2 contents appear on the screen:
1. Very very briefly:
2. the boot menu, for the time of the configured time out:
So the boot menu shows only the two systems from the APFS container on the SSD with the OpenCore in the EFI volume.
The corresponding logfile "opencore-2020-01-28-105828_prior_to_new_diskswapping.txt" is in the attachment.
Second case with correct boot menu:
Shutting down the computer. Then i exchanged the SSDs (what too had been successful for a short time days ago):
- The SSD with the EFI on which the OC is installed is placed now in "Bay 2".
- The SSD with my main system (Mojave) now in "Bay 1".
When booting it looks like this:
1. again only very briefly and without any changes to the previous start:
2. the boot menu, now actually complete again:
The "OSX" (that is my Mojave main system), which I selected in the startup disk preference pane, is now also correctly marked as a preselection in OC boot menu.
This is how it should be. But I had that before and it didn't last 2 days and probably won't this time either.
In the logfiles belonging to both cases at least I don't recognize anything suspicious, except that in the second logfile the "OcScanForBootEntries" now suddenly covers all system drives.
Here a comparison:
(on the left side computer startup 1 with the boot menu error and on the right side computer startup 2 with correct boot menu)
You can find both complete logfiles in the appendix plus my config.plist.
Does anyone have any idea what's not working right here? It can't be so strange only for me...
What is remarkable for me: Even without physically swapping disks, the disk numbering changes sometimes the last days and this may lead to a recurrence of the boot menu problem. For example, without a recognizable systematic connection, "disk1" and thus also "disk1s1" etc. suddenly became "disk3", "disk0" suddenly became "disk1" etc. This may have something to do with frequent changes of the startup disks, and blessing and unblessing etc., I don't know... I'm a bit at a loss on how to create a stable boot menu behaviour in OpenCore without permanent diskswapping.
Any help out there? Please...
Please is there anybody who has experienced something similar with the OC boot menu and knows some advice? I searched this whole "OC on MacPro"-Thread and didn't found something similar.
I have now done some more tests and have created logfiles to that.
First, with the initial situation where the boot menu is not complete, so OC does not completely cover my bootable systems.
Second, after I was able to create a situation where the boot menu shows all my bootable systems by swapping drives again. But this will probably only work for a short time again...
My initial setup:
- The SSD with the EFI on which the OC is installed is located in Bay 1 of my MP5.1. The Catalina is also installed on this SSD. EFI with OC is blessed.
- The SSD with my main system (Mojave) is in Bay 2.
- In Bay 3 & 4 are pure data disks without system.
- In the lower DVD drive bay ("Lower") i placed another data disc, but on this one there is also (as a kind of emergency rescue system) a recovery from an old High Sierra as Apple_Boot partition.
- On a SSD PCIe card is a SSD with additional system partitions:
> Sierra and High Sierra as HFS+ plus and a Apple_Boot Recovery HD
> Additionally in an APFS container a small Mojave with Recovery
Here first the case with the incomplete boot menu:
When booting, the following 2 contents appear on the screen:
1. Very very briefly:
2. the boot menu, for the time of the configured time out:
So the boot menu shows only the two systems from the APFS container on the SSD with the OpenCore in the EFI volume.
The corresponding logfile "opencore-2020-01-28-105828_prior_to_new_diskswapping.txt" is in the attachment.
Second case with correct boot menu:
Shutting down the computer. Then i exchanged the SSDs (what too had been successful for a short time days ago):
- The SSD with the EFI on which the OC is installed is placed now in "Bay 2".
- The SSD with my main system (Mojave) now in "Bay 1".
When booting it looks like this:
1. again only very briefly and without any changes to the previous start:
2. the boot menu, now actually complete again:
The "OSX" (that is my Mojave main system), which I selected in the startup disk preference pane, is now also correctly marked as a preselection in OC boot menu.
This is how it should be. But I had that before and it didn't last 2 days and probably won't this time either.
In the logfiles belonging to both cases at least I don't recognize anything suspicious, except that in the second logfile the "OcScanForBootEntries" now suddenly covers all system drives.
Here a comparison:
(on the left side computer startup 1 with the boot menu error and on the right side computer startup 2 with correct boot menu)
You can find both complete logfiles in the appendix plus my config.plist.
Does anyone have any idea what's not working right here? It can't be so strange only for me...
What is remarkable for me: Even without physically swapping disks, the disk numbering changes sometimes the last days and this may lead to a recurrence of the boot menu problem. For example, without a recognizable systematic connection, "disk1" and thus also "disk1s1" etc. suddenly became "disk3", "disk0" suddenly became "disk1" etc. This may have something to do with frequent changes of the startup disks, and blessing and unblessing etc., I don't know... I'm a bit at a loss on how to create a stable boot menu behaviour in OpenCore without permanent diskswapping.
Any help out there? Please...
Attachments
Ok, of course running catalina without OC (boot into OC then only for system updates) is a little off-topic here, but maybe the trick with the Boot.plist is interesting anyway, when it would work.
I've tested this now: "-no_compat_check" added to the com.apple.Boot.plist instead of running my "set -no_compat_check on shutdown"-script:
Did this in catalina with:
sudo /usr/libexec/PlistBuddy -c "Set :'Kernel Flags' '-no_compat_check'" "/Library/Preferences/SystemConfiguration/com.apple.Boot.plist"
So then I removed my script from launchdeamons and,too, deleted the boot-arg from nvram, so i have a "clean machine" now.
As suggested, the Mac should be able to boot into Catalina without OC now because of the setting of the "-no_compat_check" as a Boot.plist entry.
Catalina is still set as Startup Disk in the preference pane. Reboot...
But sorry, that was denied:
I rebooted three times... a fourth trial by starting with <option> into Apple Boot Menu and selecting catalina manually. None worked.
I then booted back into Mojave via Apple Boot Menu and installed my script again.
After that booting into Catalina without OC was successful again. After reinstalling the script in launchdemons of catalina and, just to be safe, manually deleting the boot-arg in nvram the reboot work, too.
It seems that my fear of com.apple.Boot.plist not read prior to the system check is justified?
Any other experiences?
