MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[startergo]

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:

View attachment 891069

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:
View attachment 891070

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?

I don't know what plist buddy does, but if you break permissions, code sign it is not gonna work. Whereas if you enter sudo -s (root Mode) and edit the plist you should be fine. If you alredy broke the permissions you need to repair them.
Also change this in the config file:

<key>DisplayLevel</key>
            <integer>2147483714</integer>
            <key>Target</key>
            <integer>65</integer>
            
            
            
            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <dict>
                <key>boot-args</key>
                <string>-no_compat_check -v</string>
                <key>csr-active-config</key>
                <data>AAAAAA==</data>

[automerge]1580242751[/automerge]
You may want to do NVRAM reset first as your target mode of 81 may have written in the NVRAM area.

 

[startergo]

You can use gfxutil to view nvram variables or ioreg properties that are EFI paths

gfxutil
zsh: no such file or directory: /Volumes/Work/Programming/EFIProjects/gfxutil-1.80b_joevt3/DerivedData/gfxutil/Build/Products/Debug/gfxutil

 

[aacemyan]

Good news! I was able to upgrade to Catalina 10.15.3 today and wanted to report back that nothing broke in the process! As usual for dual CPU computers, make sure to delete the AppleIntelMCEreporter.kext package since it gets reinstalled after every point update.

 

[joevt]

gfxutil
zsh: no such file or directory: /Volumes/Work/Programming/EFIProjects/gfxutil-1.80b_joevt3/DerivedData/gfxutil/Build/Products/Debug/gfxutil

Was there a question? Just modify the setup script with the correct path.

 

[cdf]

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?

The "differences" document tells you exactly what has changed from one version to the next. That's what you should use. You should include any new property and decide on its value based on the manual.

 

[ohelio]

Maybe you have to add to Preboot also.

That could be the trick!
Thanks for that idea, i think this may point to a right direction. I will test it.
I searched a bit: The first "no_compat_check"-patch for Boot.plist came up with running Sierra on unsupported Macs. This was only HFS+. The new extra preeboot-volume shows up not until putting the system into a APFS container... So on Sierra all preboot information are read out from the main system-volume and patching the plist there at that time was enough.

I don't know what plist buddy does, but if you break permissions, code sign it is not gonna work. Whereas if you enter sudo -s (root Mode) and edit the plist you should be fine. If you alredy broke the permissions you need to repair them.
Also change this in the config file:

<key>DisplayLevel</key>
            <integer>2147483714</integer>
            <key>Target</key>
            <integer>65</integer>
           

            <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
            <dict>
                <key>boot-args</key>
                <string>-no_compat_check -v</string>
                <key>csr-active-config</key>
                <data>AAAAAA==</data>

[automerge]1580242751[/automerge]
You may want to do NVRAM reset first as your target mode of 81 may have written in the NVRAM area.

Yes, i change that target string. Dont know why i did set the bit for UEFI variable logging, too.
My "csr-active-config" setting i want to keep, because i want to ensure that SIP is deactivated. It's too cumbersome to boot into recovery to toggle that in case whatever process did enable SIP again. The OC key for csr offers an easy way to keep SIP disabled.

plist buddy:
i found that syntax in the "sierra on unsupported macs"-thread.

Because of your warning, I looked at the permissions of the so edited Boot.plist. Instead of root:wheel it is now actually changed to root:admin. I will correct this with chown and make a new test. The content with the added string under "Kernel Flags" seems to be correct. Or must there be added quotation marks or similar to it?

This is a pure text view of the edited file in addition to the XCODE view in my previous post:

----com.apple.Boot.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>Kernel Flags</key>
<string>-no_compat_check</string>
</dict>
</plist>
--------------------------------------

 

[startergo]

Also change this:

<key>Protocols</key>
        <dict>
            <key>AppleBootPolicy</key>
            <true/>

cd /Library/Preferences/SystemConfiguration
➜  SystemConfiguration ls -l com.apple.Boot.plist
-rw-r--r--  1 root  admin  248 Dec 30 20:04 com.apple.Boot.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>Kernel Flags</key>
        <string>-no_compat_check</string>
</dict>
</plist>

 

[ohelio]

Also change this:

<key>Protocols</key>
        <dict>
            <key>AppleBootPolicy</key>
            <true/>

OK, what does it do? This might fix my problems with OC Boot Menu?
OC conf-guide sais:
"Reinstalls Apple Boot Policy protocol with a builtin version. This may be used to ensure APFS compatibility on VMs or legacy Macs."

I will set that flag to "true" when the issue occures again. Today, after my recent diskswapping OC Boot Menu is still behaving correct (This probably will change soon...).

cd /Library/Preferences/SystemConfiguration
➜  SystemConfiguration ls -l com.apple.Boot.plist
-rw-r--r--  1 root  admin  248 Dec 30 20:04 com.apple.Boot.plist

Ooops, then it was right and not altered from the "plist buddy"-command. I have to revert my hastily manual change from "root:admin" to "root:wheel" back to "root:admin".
All other plists in that directory has "-rw-r--r-- 1 root wheel"...

Changed back to admin now, but it lists a bit different:
-rw-r--r--@ 1 root admin 248 28 Jan 18:53 com.apple.Boot.plist
-----------^
=> what does the "@" mean instead of the blank that normally occures at this place. Didn't found a way to get rid of this.

<?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>Kernel Flags</key>
        <string>-no_compat_check</string>
</dict>
</plist>

That looks exactly like mine, did it? But ok, so there is nothing wrong with my editing.

 

[startergo]

This is the patch code for "-no_compat_check":

@implementation PlatformCheck

-(id)init {
    self = [super init];
    [self setID:@"platformCheckPatch"];
    [self setVersion:0];
    [self setName:@"Platform Check Patch"];
    return self;
}
-(int)applyToVolume:(NSString *)volumePath {
    int ret = 0;
    NSString *dataVolPath = volumePath;//[@"/Volumes" stringByAppendingPathComponent:[self getDataVolumeForMainVolume:[volumePath lastPathComponent]]];
    NSMutableDictionary *bootPlist = [[NSMutableDictionary alloc]initWithContentsOfFile:[dataVolPath stringByAppendingString:@"/Library/Preferences/SystemConfiguration/com.apple.Boot.plist"]];
    NSString *kernelFlags = [bootPlist objectForKey:@"Kernel Flags"];
    if ([kernelFlags isEqualToString:@""])
    {
        kernelFlags = @"-no_compat_check";
    }
    else if ([kernelFlags rangeOfString:@"-no_compat_check"].location == NSNotFound)
    {
        kernelFlags = [kernelFlags stringByAppendingString:@" -no_compat_check"];
    }
    [bootPlist setObject:kernelFlags forKey:@"Kernel Flags"];
    [bootPlist writeToFile:[dataVolPath stringByAppendingString:@"/Library/Preferences/SystemConfiguration/com.apple.Boot.plist"] atomically:YES];
 
    NSString *prebootDisk = [[APFSManager sharedInstance] getPrebootVolumeforAPFSVolumeAtPath:volumePath];
    NSString *volumeUUID = [[APFSManager sharedInstance] getUUIDOfVolumeAtPath:volumePath];
    NSTask *mount = [[NSTask alloc] init];
    [mount setLaunchPath:@"/usr/sbin/diskutil"];
    [mount setArguments:@[@"mount", prebootDisk]];
    [mount launch];
    [mount waitUntilExit];
 
    [bootPlist writeToFile:[NSString stringWithFormat:@"/Volumes/Preboot/%@/Library/Preferences/SystemConfiguration/com.apple.Boot.plist", volumeUUID] atomically:YES];
 
    NSTask *unmount = [[NSTask alloc] init];
    [unmount setLaunchPath:@"/usr/sbin/diskutil"];
    [unmount setArguments:@[@"unmount", prebootDisk]];
    [unmount launch];
    [unmount waitUntilExit];
 
    return ret;
}

-(BOOL)shouldInstallOnMachineModel:(NSString *)model {
    NSDictionary *machinePatches = [macModels objectForKey:model];
    if (machinePatches) {
        return YES;
    }
    return NO;
}
@end

This implies that kernel flag is set to datavolume and this:

 [bootPlist writeToFile:[dataVolPath stringByAppendingString:@"/Library/Preferences/SystemConfiguration/com.apple.Boot.plist"] atomically:YES]

is set to both datavolume (above) and the preboot volume (below):

 [bootPlist writeToFile:[NSString stringWithFormat:@"/Volumes/Preboot/%@/Library/Preferences/SystemConfiguration/com.apple.Boot.plist", volumeUUID] atomically:YES]

It is probably best to run the PostInstallPatch only for this particular patch. This file can be modified adding all other custom boot flags, recompiled and run again.

 

[Charmandrigo]

big question, how do I update opencore? I just replace the files of the release.zip? I originally installed catalina with the previous release that was linked on this thread

 

[ohelio]

This is the patch code for "-no_compat_check":
....
....
This implies that kernel flag is set to datavolume and this:

 [bootPlist writeToFile:[dataVolPath stringByAppendingString:@"/Library/Preferences/SystemConfiguration/com.apple.Boot.plist"] atomically:YES]

is set to both datavolume (above) and the preboot volume (below):

 [bootPlist writeToFile:[NSString stringWithFormat:@"/Volumes/Preboot/%@/Library/Preferences/SystemConfiguration/com.apple.Boot.plist", volumeUUID] atomically:YES]

It is probably best to run the PostInstallPatch only for this particular patch. This file can be modified adding all other custom boot flags, recompiled and run again.

WOW and YES!
Did it not with dosdudes postinstall but manually by editing the files.
Placed the "-no_compat_check" in both Boot.plist's: System and Preboot. Shutdown, started again, resetted NVRAM with opt+cmd+p+r, then with opt into apple boot menu, selected Catalina and it starts booting!

After startup checked with nvram -p that no boot_arg is still set, selected Catalina in startup disk preferences (nvram-reset deletes this entry), rebooted and again it worked. No longer need to place the "-no_update_check" into nvram, when starting catalina without OC!

Now it will be interesting, when updating catalina to the scheduled 10.15.3 by booting in OC, if after update the Boot.plists return to there default or not...

But: With this you can do a nvram reset, when running catalina without OC and it will start!

 

[Ludacrisvp]

Good news! I was able to upgrade to Catalina 10.15.3 today and wanted to report back that nothing broke in the process! As usual for dual CPU computers, make sure to delete the AppleIntelMCEreporter.kext package since it gets reinstalled after every point update.

Or just use the disabler kext for it instead.

 

[astonius86]

Checking in here again... I'd really like to keep OpenCore active and be able to boot my UEFI Windows 10 install as well. I have an unflashed Vega 64, so I can't see boot screens. Is it possible with OpenCore 0.5.4 or 0.5.5 to boot into my Windows install without disabling OpenCore?

 

[Charmandrigo]

Checking in here again... I'd really like to keep OpenCore active and be able to boot my UEFI Windows 10 install as well. I have an unflashed Vega 64, so I can't see boot screens. Is it possible with OpenCore 0.5.4 or 0.5.5 to boot into my Windows install without disabling OpenCore?

I had to disable opencore and use the no_compat_check boot args instead to boot windows on legacy boot

 

[startergo]

Checking in here again... I'd really like to keep OpenCore active and be able to boot my UEFI Windows 10 install as well. I have an unflashed Vega 64, so I can't see boot screens. Is it possible with OpenCore 0.5.4 or 0.5.5 to boot into my Windows install without disabling OpenCore?

yes it is. Compile the latest OC ffrom the master branch. It is easier from the OC boot screen, becasuse when I selected the Windows from the startup disk it booted directly bypassing OC and went to "no boot disk" message. When I booted my OC drive through the bootpicker I saw that Windows was default boot option and when I let go it booted to Windows

 

[startergo]

When I try to update Catalina to 10.15.3 through OC I get a crash. If I try to boot the just initiated Catalina 10.15.3 from dosdude's install patcher I got the same crash:

Now I removed the OC USB drive and continued installation through dosdude's install method. So far no crashes.

 

[w1z]

When I try to update Catalina to 10.15.3 through OC I get a crash. If I try to boot the just initiated Catalina 10.15.3 from dosdude's install patcher I got the same crash:
View attachment 891329

Now I removed the OC USB drive and continued installation through dosdude's install method. So far no crashes.

I believe your system's crash is related to a non-working recovery through OC. Are you able to boot into recovery with OC enabled?
[automerge]1580388624[/automerge]

Checking in here again... I'd really like to keep OpenCore active and be able to boot my UEFI Windows 10 install as well. I have an unflashed Vega 64, so I can't see boot screens. Is it possible with OpenCore 0.5.4 or 0.5.5 to boot into my Windows install without disabling OpenCore?

Yes, it's doable as that's how I am booting my Windows 10 EFI install through Startup Disk. Compile latest version of OC from master and enable AppleBootPolicy in config.plist - see https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/post-28171314

If you can't see the Windows 10 drive or can't select it, disable Paragon NTFS if you have it installed and partially disable SIP (without NVRAM protection ie. csrutil enable –without nvram)

 

[startergo]

I believe your system's crash is related to a non-working recovery through OC

Recovery? What has recovery to do with a fresh install or update? And yes I beleive I can do Recovery from OC (at least I have done it before). So I finished installation through dosdude's Installer and now I can boot normally through OC no more crashes. So for 10.15.3 I cannot update through OC. Actually what I noticed is that if I enable VMM flag system crashes as well doing update. So it is with or without VMM flag the same crash.

 

[w1z]

Recovery? What has recovery to do with a fresh install or update? And yes I beleive I can do Recovery from OC (at least I have done it before). So I finished installation through dosdude's Installer and now I can boot normally through OC no more crashes. So for 10.15.3 I cannot update through OC. Actually what I noticed is that if I enable VMM flag system crashes as well doing update. So it is with or without VMM flag the same crash.

I updated to 10.15.3 with OC enabled - no problems. Previously, updating to 10.15.2 with OC enabled failed because I was not able to boot into recovery due to a bug which @vit9696 recently rectified. I was only able to update to 10.15.2 using the combo installer.

AFAIK, if you don't have a working recovery then installation of updates fail.

 

[ohelio]

...
Placed the "-no_compat_check" in both Boot.plist's: System and Preboot. Shutdown, started again, resetted NVRAM with opt+cmd+p+r, then with opt into apple boot menu, selected Catalina and it starts booting!
...
Now it will be interesting, when updating catalina to the scheduled 10.15.3 by booting in OC, if after update the Boot.plists return to there default or not...

Did the macos upgrade to 10.15.3 under OC. Works without problem on my MP5.1.

But after restart the both edited Boot.plists in System- and Preboot-Volume were resetted again to default without kernel-flags. So for running catalina without OC the solution with editing of the plists is not stable forever, same situation as with the setting of the boot_arg in nvram. But still it has advantages: You only have to set the kernel-flags once again after software-update. NVRAM resetting for whatever reasons does no harm... So be prepared to add the "-no_compat_check" right after software-update while still running under OC.

 

[ohelio]

Also change this:

<key>Protocols</key>
        <dict>
            <key>AppleBootPolicy</key>
            <true/>

OK, what does it do? This might fix my problems with OC Boot Menu?
OC conf-guide sais:
"Reinstalls Apple Boot Policy protocol with a builtin version. This may be used to ensure APFS compatibility on VMs or legacy Macs."

I will set that flag to "true" when the issue occures again. Today, after my recent diskswapping OC Boot Menu is still behaving correct (This probably will change soon...).

After the catalina-update under OC and several blessings and unblessings now the OC Boot Menu problem is back. So i activated AppleBootPolicy, as suggested. That didn't changed the Boot Menu behaviour.

But what i noticed:
Every time i start booting with OC by first going to Apple EFI Boot Menu and selecting "Boot EFI" there, the following OC Boot Menu shows all my bootable systems. But when starting with the blessed OC EFI Volume without detour through Apple Boot Menu then the OC Boot Menu wasn't complete again. That behaviour was reproducable... The difference between the tests with and without AppleBootPolicy-Flag could only be noticed in the contents of the logfiles due to obviously different mechanisms to scan for bootable partitions.

I still have no idea why this OC Boot Menu behaviour is happening. Does anyone has a clue or maybe wants to have look at the loggings?

 

[startergo]

AFAIK, if you don't have a working recovery then installation of updates fail.

I don't have a problem going to Recovery. In fact it goes to Recovery without request from me.

 

[ohelio]

I updated to 10.15.3 with OC enabled - no problems. Previously, updating to 10.15.2 with OC enabled failed because I was not able to boot into recovery due to a bug which @vit9696 recently rectified. I was only able to update to 10.15.2 using the combo installer.

AFAIK, if you don't have a working recovery then installation of updates fail.

For me, my update to 10.15.3 felt like an Software-Update within an supported i.e. Mojave. Starting from pref pane it loaded the installer (about 2,6 GB), and initiated a reboot. At reboot i could watch in OC Boot Menu that automatically a macos installer was selected into which the boot started (probably a mounted dmg?) and the completion of the installation followed (ca. 15 min...). No interaction from me necessary. Finally a second reboot started into the updated system, ready. No errors at all.

 

[astonius86]

yes it is. Compile the latest OC ffrom the master branch. It is easier from the OC boot screen, becasuse when I selected the Windows from the startup disk it booted directly bypassing OC and went to "no boot disk" message. When I booted my OC drive through the bootpicker I saw that Windows was default boot option and when I let go it booted to Windows

Thanks for the advice. I did download the master branch from GitHub and compiled OC 0.5.5. After installing I still can't get to Windows 10. Do I need to configure OC in a certain way? I do have the AdviseWindows key set to true, but I don't have anything in the FirmwareFeatures portion which may be required for UEFI installs?

Also, remember I don't have a flashed GPU, so I cannot see boot screens.

 

[vit9696]

After the catalina-update under OC and several blessings and unblessings now the OC Boot Menu problem is back. So i activated AppleBootPolicy, as suggested. That didn't changed the Boot Menu behaviour.

But what i noticed:
Every time i start booting with OC by first going to Apple EFI Boot Menu and selecting "Boot EFI" there, the following OC Boot Menu shows all my bootable systems. But when starting with the blessed OC EFI Volume without detour through Apple Boot Menu then the OC Boot Menu wasn't complete again. That behaviour was reproducable... The difference between the tests with and without AppleBootPolicy-Flag could only be noticed in the contents of the logfiles due to obviously different mechanisms to scan for bootable partitions.

I still have no idea why this OC Boot Menu behaviour is happening. Does anyone has a clue or maybe wants to have look at the loggings?

You have incorrect configuration for your Mac. Macs by default only connect the boot hard disk and do not initialise other disks. As a result you do not have other disks listed. To fix this UEFI → ConnectDrivers should be YES.