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

[JedNZ]

I messed up in my update from 12.6.4 to 12.6.5. I was in a hurry, and having just done the 12.6.4 update the night before, I thought I had all the steps in my head. Wrong!! I was using the VMM/SecureBootModel disabled approach, but I forgot to run the plutil steps to format my changes before copying back to the ESP (at least that is the one step that I'm pretty sure I screwed up, there may have been others....)

Anyway, long story short, it downloaded the update to 12.6.5 and started processing it. I got bored and wandered off while it still said it had ten minutes to go. Came back later, and the machine had re-booted into Monterey as expected, so I restored my usual config.plist (that removes VMM and restores SecureBootModel to 'Default'). I thought, I better check that it succeeded, and then found that I was still on 12.6.4!

So, I rebooted, and noted that now I have a MacOS Installer entry in the list of boot options. I tried selecting it manually and letting it do its thing, but every time after the automatic reboot it comes back in the boot list (and I'm still on 12.6.4). So, the question is, how do I get back to a state where I can try the update again cleanly? Do I have to find and delete that disk image of the MacOS Installer somewhere to make System Update recognize that I still need the 12.6.5 update? Thank you for your advice.

I’ve done the same myself before - I just switched back to the VMM version of OpenCore, booted into the macOS Install update option in the picklist and continued and it continued from where it last left off. I can’t guarantee it’ll work for you, but it did work for me that one time.

 

[flaubert]

I’ve done the same myself before - I just switched back to the VMM version of OpenCore, booted into the macOS Install update option in the picklist and continued and it continued from where it last left off. I can’t guarantee it’ll work for you, but it did work for me that one time.

Sadly, this does not appear to be working for me. When I select MacOS Installer as the boot volume manually, it gets to about 20% completion fairly quickly (about 30 seconds), stalls for another 20 seconds or so, and then the screen goes black as part of the reboot process.

I found this interesting writeup from, who else, Howard Oakley:

Inside the new macOS update log

The restore.log file on the Update volume contains details of all macOS updates installed since 11.0.1. Here’s a quick guide to its contents and use.

eclecticlight.co

Searching in the restore.log for "process_update_result_state: Successful Update" I was able to find the area documenting my successful update to 21G526, which a search reveals is 12.6.4.

Searching for an error that would explain what looks like an abort to reboot process, I find this interesting tidbit:

"Skipping preflighting since we're not on supported hardware"

As Howard notes, the log contains many instances where the installer reports back to Apple on the status of the update, so Apple is perfectly aware of which machines are running Monterey on unsupported hardware, interesting.

At the end of the file I find a repeating pattern, where there is probably one iteration of the pattern for each of the many times I've rebooted and selected the MacOS Installer as the boot item:

056ee000 : setSystemTargetUUID will use / as the target
056ee000 : Found update container: LPAPFSContainer: AppleAPFSMedia, UUID: 71D04835-7AA5-4EEC-BD25-5227610BEDF8
056ee000 : Found update volume: LPAPFSVolume: Update, Mount: /System/Volumes/Update
056ee000 : Will open restore file at: /System/Volumes/Update/restore.log
056ee000 : Opened: /System/Volumes/Update/restore.log
056ee000 : Cleaning up unused prepared updates
056ee000 : Configuring update volume.
056ee000 : Found update container: LPAPFSContainer: AppleAPFSMedia, UUID: 71D04835-7AA5-4EEC-BD25-5227610BEDF8
056ee000 : Found update volume: LPAPFSVolume: Update, Mount: /System/Volumes/Update
056ee000 : Will not erase update volume.
056ee000 : msu_delete_nvram_variable_if_exists: NVRAM target-uuid not found..Nothing to do

056ee000 : Saving log file /System/Volumes/Update/patchd-1681191094.log
1890e600 : Opened: /System/Volumes/Update/restore.log
1890e600 : process_update_result_state: Boot UUID is different - 1st run after reboot
1890e600 : process_update_result_state: No boot manifest hash in the system - assuming same OS
074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-uuid not found..Nothing to do

074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-breadcrumbs not found..Nothing to do

074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-submission-url not found..Nothing to do

074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-os-version not found..Nothing to do
(followed by many more msu_delete_nvram_variable_if_exists entries of various flavors)

Nothing in that block jumps out at me as a big failure, but something is clearly failing. I'm enclosing my config.plist in case anyone wants to take a crack at guessing where I've gone off the rails; what's odd is that the same exact plist file worked fine in the update to 12.6.4 the night before. The plist was generated with @TECK 's excellent plistlib generator program; it might be easier to see my customizations in that source file, also included.

Edit: sharp eyed readers will notice that Flaubert.py file doesn’t have the SecureBootModel and VMM edits; I haven’t figured out how to add the long string for “AAAAxxx” needed for VMM to the python file yet, so I edit setup.plist manually after the plist file is generated.

 

[sfalatko]

Sadly, this does not appear to be working for me. When I select MacOS Installer as the boot volume manually, it gets to about 20% completion fairly quickly (about 30 seconds), stalls for another 20 seconds or so, and then the screen goes black as part of the reboot process.

I found this interesting writeup from, who else, Howard Oakley:

Inside the new macOS update log

The restore.log file on the Update volume contains details of all macOS updates installed since 11.0.1. Here’s a quick guide to its contents and use.

eclecticlight.co

Searching in the restore.log for "process_update_result_state: Successful Update" I was able to find the area documenting my successful update to 21G526, which a search reveals is 12.6.4.

Searching for an error that would explain what looks like an abort to reboot process, I find this interesting tidbit:

"Skipping preflighting since we're not on supported hardware"

As Howard notes, the log contains many instances where the installer reports back to Apple on the status of the update, so Apple is perfectly aware of which machines are running Monterey on unsupported hardware, interesting.

At the end of the file I find a repeating pattern, where there is probably one iteration of the pattern for each of the many times I've rebooted and selected the MacOS Installer as the boot item:

056ee000 : setSystemTargetUUID will use / as the target
056ee000 : Found update container: LPAPFSContainer: AppleAPFSMedia, UUID: 71D04835-7AA5-4EEC-BD25-5227610BEDF8
056ee000 : Found update volume: LPAPFSVolume: Update, Mount: /System/Volumes/Update
056ee000 : Will open restore file at: /System/Volumes/Update/restore.log
056ee000 : Opened: /System/Volumes/Update/restore.log
056ee000 : Cleaning up unused prepared updates
056ee000 : Configuring update volume.
056ee000 : Found update container: LPAPFSContainer: AppleAPFSMedia, UUID: 71D04835-7AA5-4EEC-BD25-5227610BEDF8
056ee000 : Found update volume: LPAPFSVolume: Update, Mount: /System/Volumes/Update
056ee000 : Will not erase update volume.
056ee000 : msu_delete_nvram_variable_if_exists: NVRAM target-uuid not found..Nothing to do

056ee000 : Saving log file /System/Volumes/Update/patchd-1681191094.log
1890e600 : Opened: /System/Volumes/Update/restore.log
1890e600 : process_update_result_state: Boot UUID is different - 1st run after reboot
1890e600 : process_update_result_state: No boot manifest hash in the system - assuming same OS
074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-uuid not found..Nothing to do

074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-breadcrumbs not found..Nothing to do

074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-submission-url not found..Nothing to do

074b7000 : msu_delete_nvram_variable_if_exists: NVRAM ota-os-version not found..Nothing to do
(followed by many more msu_delete_nvram_variable_if_exists entries of various flavors)

Nothing in that block jumps out at me as a big failure, but something is clearly failing. I'm enclosing my config.plist in case anyone wants to take a crack at guessing where I've gone off the rails; what's odd is that the same exact plist file worked fine in the update to 12.6.4 the night before. The plist was generated with @TECK 's excellent plistlib generator program; it might be easier to see my customizations in that source file, also included.

You need to make sure the VMM/SecureBoot settings are correct for the install. It appears that they are not and hence you are getting the "not on supported hardware".

 

[cdf]

I was using the VMM/SecureBootModel disabled approach

If your firmware chip is healthy, I strongly recommend the vanilla method (option 2 in the guide) for a seamless experience. Because toggling SecureBootModel can sometimes prevent booting (resulting in multiple boot attempts before getting back into macOS), it might be best to keep SecureBootModel disabled at all times if the VMM method (option 1 in the guide) is going to be used.

It might be nice if there were a line in the first post wiki that said something like, "this is the point at which you jump off from Mojave onto a later system."

I'm currently booting Mojave through OpenCore, and paused at the start of "Complete your setup," on the second machine.

I've added some clarifications. The idea is to go through the "Complete your setup" section to decide what you need for upgrading.

As Howard notes, the log contains many instances where the installer reports back to Apple on the status of the update, so Apple is perfectly aware of which machines are running Monterey on unsupported hardware, interesting.

They could even know more than that: macOS contains an explicit check for the opencore-version nvram variable! Even more intriguing: shortly after this check was discovered, OpenCore removed the option to completely disable that variable!

 

[flaubert]

I wonder if the problem is that I’m not booting through the instance of OpenCore that I think it should be booting through? When I jump OC versions I leave the old ESP behind on a disk that is still in the system, and then boot to recovery mode and bless the newly updated ESP on a different disk. I’m super careful typing in that bless command (using tab completion to make sure that I get the paths correct, double-checking that I’m using double dashes for the options, and proper capitalization on setBoot). I’ve read so much about the fragility of the NVRAM that I think that I have the option ‘WriteFlash’ set to false (I’m not at my OpenCore computer at the moment to double-check); could it be that each time I’ve been blessing the ESP in recovery mode it simply is not being recorded in NVRAM as the new boot target?

I’ve also been leaving my emergency OpenCore CD in the drive while doing this work; I do hear a brief moment of CD activity when rebooting; I had assumed that was just the boot process enumerating the boot possibilities, but maybe that is actually serving as my OpenCore booting instance, hmm? That would explain a few things, like the fact that it isn’t automatically switching to boot the MacOS Installer volume.

If your firmware chip is healthy, I strongly recommend the vanilla method (option 2 in the guide) for a seamless experience

As usual, I’ve probably been overthinking things.

 

[cdf]

could it be that each time I’ve been blessing the ESP in recovery mode it simply is not being recorded in NVRAM as the new boot target?

Are you doing this when booted through OpenCore? In that case, the blessing of the other instance is being re-routed through the original. In other words, the original remains natively blessed.

 

[TECK]

No issues upgrading to 12.6.5 with Plistlib Generator 2.0.11 (see notable changes).

 

[flaubert]

Are you doing this when booted through OpenCore? In that case, the blessing of the other instance is being re-routed through the original. In other words, the original remains natively blessed.

YES! I am doing the blessing in Recovery after booting through OpenCore! I better go read the first post carefully again. Are the only ways to change the location of the ESP location to a new drive these two then?

1. Return to natively supported Mojave booting via the procedure in post #1, and then enter Recovery Mode from there, then bless the ESP on a different drive.

or

2. Utilize Bootkicker, as outlined in post 1. (I'm starting to see why Bootkicker is such a big deal)

@cdf , thanks so much for clearing this up for me.

 

[TECK]

@flaubert do a NVRAM reset (3 chimes) and bless the proper disk in Recovery. That's what I do when I refresh every 3 months the reconstructed ROM made by @tsialex. As a side note, I never remove the NVMe drives where OC is installed, and boot from the Mojave SSD installed on first slot.

 

[cdf]

Are the only ways to change the location of the ESP location to a new drive these two then?

There are several other ways, but the state of the art now is to get native boot screen support with EnableGop (as described in the Appendix).

@flaubert do a NVRAM reset (3 chimes) and bless the proper disk in Recovery.

Unfortunately, this doesn’t work in general. On some setups, OC will be picked up by default after an NVRAM reset.

 

[flaubert]

OK, so I think I have gotten my machine to where it is booting OpenCore from a known source ESP (the only source possible!). For compatibility with the way that I originally started the update process that ESP is set up with the VMM/SecureBootModel disabled. When I reboot it now it automatically selects MacOS Installer as the default boot target, so that is some progress. However... I get the same behavior of unsuccessful resolution of update, it just tries for a little while, moves the progress bar 20%, and then reboots again. I think that the real failure occurred at the very start of the update process when I initiated the update with that preflight abort due to unsupported hardware, and so it will never resolve.

So, I think that I have to either somehow reset the update process and make it forget that it got partway into the 12.6.5 update (which sounds kind of fiddly/delicate), or I have to boot into recovery mode and re-install latest Monterey on top of the existing disk. Or do a fresh install onto a new disk, and use Migration Assistant to copy data over. Any thoughts?

 

[MacNB2]

They could even know more than that: macOS contains an explicit check for the opencore-version nvram variable! Even more intriguing: shortly after this check was discovered, OpenCore removed the option to completely disable that variable!

Do you mean this variable: 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version ?

It is on by default:

MacPro-02:~ MacNB$ nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    DBG-091-2023-04-03
MacPro-02:~ MacNB$

 

[cdf]

Yes, that's the variable, and it's actually always on. The only option is to not expose its value.

 

[hwojtek]

Which process in MacOS checks for this variable?

 

[cdf]

Here is the source:

macOS 12.0 Beta 6 SecureBoot requirements for T2 models · Issue #471 · dortania/OpenCore-Legacy-Patcher

With macOS 12.0 Beta 6 (21A5506j), Apple changed what data is passed through Pallas to receive deltas. Previously only the machine's Board ID was passed through, however with Beta 6 and newer, Pall...

github.com

 

[hwojtek]

Here is the source

I laughed imagining that somewhere in the Apple HQ there is a guy with a company 5,1 under his desk, searching the Internet for tips on how to set up Open Core.

 

[prefuse07]

Actually this makes me wonder now -- has any reporter ever brought up Open Core to Tim Cook during any of his interviews?

I'd love to read his thoughts on the community that is keeping the 4,1 and 5,1 alive via Open Core, despite apple's hostile attempt to cripple it via "unsupport".

Going to look into it now, but if anyone knows of anything, could you please post a link?

 

[tsialex]

despite apple's hostile attempt to cripple it via "unsupport".

It's difficult to know when you are joking, this seems one. Apple usually support Macs with new macOS releases for 6 years, but sometimes not even that and the drop schedule seems to be accelerating with the move to Apple Silicon. Said that, do you honestly think that Apple as a business entity that answer to shareholders should support a 11/13/14 years old Mac with current macOS releases indefinitely?

Just to compare one metric, today even the cheapest 2022 MacBook Air - does not even have have a CPU fan - have a Geekbench score that is more than 4x the single core performance of a dual CPU X5690, 2560 versus ~622 and 9560 versus ~6370 for multi-core.

Back in Big Sur 11.3 days race condition and the AVX requirements of VMWare Fusion I thought that we were approaching the end of workarounds, but thx to OC developers, Syncretic and others now two years after we are still running all Monterey Software Updates and people that accept the Ventura compromises running without an AVX v2 supported processor can even run it.

It was a very good and long run, now is time to accept that the end is near.

 

[prefuse07]

It's difficult to know when you are joking, this seems one. Apple usually support Macs with new macOS releases for 6 years, but sometimes not even that and the drop schedule seems to be accelerating with the move to Apple Silicon. Said that, do you honestly think that Apple as a business entity that answer to shareholders should support a 11/13/14 years old Mac with current macOS releases indefinitely?

Just to compare one metric, today even the cheapest 2022 MacBook Air - does not even have have a CPU fan - have a Geekbench score that is more than 4x the single core performance of a dual CPU X5690, 2560 versus ~622 and 9560 versus ~6370 for multi-core.

Back in Big Sur 11.3 days race condition and the AVX requirements of VMWare Fusion I thought that we were approaching the end of workarounds, but thx to OC developers, Syncretic and others now two years after we are still running all Monterey Software Updates and people that accept the Ventura compromises running without an AVX v2 supported processor can even run it.

It was a very good and long run, now is time to accept that the end is near.

Why does it have to be 6 years though? Why is that acceptable?

The fact that modern macOS' still run well on these older machines (Monterey and before, not Ventura) is proof enough that these machines should've never lost support from the get go... Barring Ventura, it doesn't seem that these machines had any hardware issues that would've prevented them from continuing to be supported. That's how I look at it. What hardware-requirement differences are there between Monterey and Mojave? Metal? Simple, throw a metal supported GPU into the machine and you're good. the RACE and VMWare Fusion issues could've been handled by apple's devs, the same way that the OC devs handled them, could they not?

All i'm saying is their forced-obsolescense-forced-upgrade tactic is very aggressive, and i'm not sure it was totally necessary, especially if there are no hardware-requirement differences to warrant it. Of course now with AVX2 as a requirement moving forward, it is indeed time to move on and accept that the end is here, and I have already moved on to a 7,1.

Plus, how much work would've really been required on apple's part to keep these machines "supported"? Couldn't they have rolled out a model such as: If you have older hardware (>6 years old), and you want to keep it supported, you can pay to upgrade your macOS (to a certain point of course, maybe 10 years?). This would finance the dev work to keep the OS "supported" on older machines, would generate $$$ for apple, since Timmy loves that, and would keep their customers happy (those of us who hold the 4,1/5,1 dearly).

Of course, with Ventura they could then say "alright, we are moving to new hardware standards (AVX2), so NOW your machines will no longer be supported because of the architecture/hardware" and that's that. But again, did Monterey have any hardware-requirement differences that Mojave did not have? I am unaware of any, but there may be some?

I don't want to derail this thread, and I'm going to stop here, but would welcome more discussion via PM if you'd like to continue I like your perspective.

 

[startergo]

Those intel processors were dropped from support by intel a while ago and in theory you should be running with mitigation enabled (I.e) loss of performance. There is you hardware requirement set a while back.

 

[prefuse07]

Those intel processors were dropped from support by intel a while ago and in theory you should be running with mitigation enabled (I.e) loss of performance. There is you hardware requirement set a while back.

Thank you -- I'm going to update both of my posts, and shut up

 

[TECK]

On some setups, OC will be picked up by default after an NVRAM reset.

That is because OC is installed on a slot disk? I have OC installed on NVMe and I never had any issues. What if I have Mojave installed on slot1 and OC on slot2, is this possible to interfere if slot1 is looked at by default?

 

[cdf]

That is because OC is installed on a slot disk?

No. There’s no general rule. It depends on the particular hardware configuration. In my case, it’s a PCIe AHCI M.2 disk that gets boot priority, even with bootable entries on SATA disks in the drive bays. The best practice is to identify the boot priority for your particular setup.

 

[TECK]

The best practice is to identify the boot priority for your particular setup.

What's the correct way to identify the boot priority?

 

[cdf]

What's the correct way to identify the boot priority?

Experimentation I suppose. In your case, you already that know that your NVMe drive on which OC is installed doesn’t have priority, because when you reset the NVRAM, your Mojave installation (on an SATA drive in one of the drive bays?) starts up (correct?).

Note that identifying the boot priority is not as important as it once was. With EnableGop, we can now enable native boot screens. That means you can just hold the Option key to access the native boot picker before OC starts.