Try the links on this page https://mrmacintosh.com/macos-big-sur-full-installer-database-download-directly-from-apple/
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
Yes. With Monterey, Software Update has become more picky about Secure Boot, initially requiring the x86legacy Secure Boot model and now requiring an additional identifier corresponding to the spoofed board ID. Perhaps enabling the VMM flag with SecureBootModel set to default (x86legacy) would work.
I don’t think so. I used to have beta 5 on a Parallels virtual machine and system update wouldn’t work. Even if you reinstalled the developer profile, the “update” it downloaded was still beta 5. In order to update to beta 6, I actually had to download https://swcdn.apple.com/content/dow...nq80a0ml1xatj8iv1hfw5ors/InstallAssistant.pkg. After that, software update exhibits the normal behavior. I think the problem was in beta 5.
The issue is deeper, it's T2 related and MacPro5,1 is affected indirectly via the iMacPro1,1 or MacPro7,1 SMBIOS.
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
Not sure if is this relevant to this guide, I would personally open a new thread.
Interesting. Thanks @tsialex.The issue is deeper, it's T2 related and MacPro5,1 is affected indirectly via the iMacPro1,1 or MacPro7,1 SMBIOS.
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...
I'll try this with the next beta. For Beta 6 when I found I couldn't use the 'Software Update' I downloaded a full installer with the MDS app. The installation from that point was straightforward - I set the app running, went out for less than an hour, and came back to find the login screen for beta 6.
I've always had some stability issues with my UAD TB3 interface so I tried looking for a fix. Someone recommended that I go back to this version of OC 0.5.7:
https://forums.macrumors.com/threads/testing-tb3-aic-with-mp-5-1.2143042/post-28370189
I tried it but didn't see any improvements so I went back to 0.7.2. Once I rebooted, I was barraged with warnings that a plugin that I've used fora while now (From High Sierra to Catalina) was malware and would harm my computer if it wasn't removed. I ignored the warning and after cancelling the prompt about 6-7 times it finally stopped. I opened Pro Tools and that plugin which had no issues prior to switching to 0.5.7 can no longer be recognized as a valid 64-bit plugin. I'm not expecting anyone to be a pro on AAX plugins but does anyone know what differences in the 2 versions of OC could've caused this? Bonus points if you can help me fix it!
https://forums.macrumors.com/threads/testing-tb3-aic-with-mp-5-1.2143042/post-28370189
I tried it but didn't see any improvements so I went back to 0.7.2. Once I rebooted, I was barraged with warnings that a plugin that I've used fora while now (From High Sierra to Catalina) was malware and would harm my computer if it wasn't removed. I ignored the warning and after cancelling the prompt about 6-7 times it finally stopped. I opened Pro Tools and that plugin which had no issues prior to switching to 0.5.7 can no longer be recognized as a valid 64-bit plugin. I'm not expecting anyone to be a pro on AAX plugins but does anyone know what differences in the 2 versions of OC could've caused this? Bonus points if you can help me fix it!
The Monterey update issue might have been resolved. Needs testing to confirm:
github.com
No OTA updates available for some SMBIOS, T2 related, server side, also for all SMBIOS with VMM flag · Issue #1769 · acidanthera/bugtracker
Hello, I'm testing monterey and I noticed no ota update available from beta 5 to beta 6. I thought about an error on my end, even if I verified multiple times, then I upgraded from a full installer...
github.com
@cdf
In my limited experience, the issue of not being able to update Monterey beta 5 to beta 6 is NOT related to OpenCore as such, and probably not truly related to T2 hardware. Up to now, I've refrained from installing Monterey on a physical Mac, and I've been happy to run it on a Parallels virtual machine (running on my Mac Pro 5,1). As I've said before, the beta 5 Software Update showed an unusual message when trying to update to anything (something like the administrator wouldn't let it go beyond its current situation), and when I reinstalled the developer profile, it would search for a Monterey update, download that, in fact, was version 5, install it and get exactly to the same spot, with version 5 in place after more than one hour of this nonsense. After installing the version 6 pkg, the update was successful, and now the odd message that beta 5 used to show is no longer there. Again, this has nothing to do with OpenCore or T2 hardware.
In my limited experience, the issue of not being able to update Monterey beta 5 to beta 6 is NOT related to OpenCore as such, and probably not truly related to T2 hardware. Up to now, I've refrained from installing Monterey on a physical Mac, and I've been happy to run it on a Parallels virtual machine (running on my Mac Pro 5,1). As I've said before, the beta 5 Software Update showed an unusual message when trying to update to anything (something like the administrator wouldn't let it go beyond its current situation), and when I reinstalled the developer profile, it would search for a Monterey update, download that, in fact, was version 5, install it and get exactly to the same spot, with version 5 in place after more than one hour of this nonsense. After installing the version 6 pkg, the update was successful, and now the odd message that beta 5 used to show is no longer there. Again, this has nothing to do with OpenCore or T2 hardware.
Because the update system now requests additional identifiers, it's conceivable that like spoofed T2 systems, virtual machines are affected. In fact, they use the x86legacy model, which is central to the issue (as explained on the Acidanthera bugtracker). For spoofed T2 systems, the solution will come from OpenCore providing the missing identifiers. That's the relation with OpenCore.
About an Monterey Update B4->B6
Booting into B4 or B5 with my iMacPro1,1 spoofing (T2) offers no Monterey update at all.
Last night I changed the OC config to spoof an iMac19,1 (non T2), rebooted into a Monterey B4 installation, got the Beta6 OTA upgrade (2,2 GB) offered, started the download and changed back in parallel the OC to use iMacPro1,1 (T2) on the next reboots.
The download and preparation took these usual 20+ minutes and thereafter the next installation steps with several reboots happend successfully.
BTW: The iMac19,1 did not enable the GPU acceleration for Polaris+ AMD dGPU (in my case a RX480 mobile).
EDIT:
- Added picture of boot into Monterey 21A5304g (Beta 5) with iMac19,1 spoofing...
- Adding VMWare CPU flags to iMacPro1,1 spoofing 0.7.2 does not work
EDIT2:
- This method does not work in an iMac11,2 with an metal NVIDIA card. On boot of Monterey or Big Sur I get an annoying text screen message similar to this: "This version of macOS is not supported on this platform: Mac-AA95B1DDAB278B95" while Catalina can be started???
Booting into B4 or B5 with my iMacPro1,1 spoofing (T2) offers no Monterey update at all.
Last night I changed the OC config to spoof an iMac19,1 (non T2), rebooted into a Monterey B4 installation, got the Beta6 OTA upgrade (2,2 GB) offered, started the download and changed back in parallel the OC to use iMacPro1,1 (T2) on the next reboots.
The download and preparation took these usual 20+ minutes and thereafter the next installation steps with several reboots happend successfully.
BTW: The iMac19,1 did not enable the GPU acceleration for Polaris+ AMD dGPU (in my case a RX480 mobile).
EDIT:
- Added picture of boot into Monterey 21A5304g (Beta 5) with iMac19,1 spoofing...
- Adding VMWare CPU flags to iMacPro1,1 spoofing 0.7.2 does not work
EDIT2:
- This method does not work in an iMac11,2 with an metal NVIDIA card. On boot of Monterey or Big Sur I get an annoying text screen message similar to this: "This version of macOS is not supported on this platform: Mac-AA95B1DDAB278B95" while Catalina can be started???
Attachments
Last edited:
Nice. I'm sure we'll see a fix, but if worst comes to worst, we'll just need to temporarily change the spoofed board ID to a non T2 model to get the updates. This is similar to how we toggled the VMM flag to get updates in Catalina for the Mac Pro 5,1. In fact, I'm wondering if the VMM flag (combined with the recent OC update and ApECID=0) could also work in this case.
That might explain why the beta 5 Software Update prompt gave the peculiar message I mentioned above, but, since that odd message hasn't reappeared after applying beta 6, it still seems to me there was something wrong in beta 5, unless we assume the message was a purely cosmetic issue that has been solved in beta 6, whereas the assumed underlying issue remains the same (?).
I've got a slight problem - I have opencore running - it's on the original Macintosh HD (which has Mojave on it) while my main install is Big Sur 11.2.3 on a Samsung SSD.
If I take out the old HDD (which I want to do), then it won't boot at all - no bootloader, nothing. I've tried to move the EFI from one to the other but just went nowhere.
Which step did I miss?
If I take out the old HDD (which I want to do), then it won't boot at all - no bootloader, nothing. I've tried to move the EFI from one to the other but just went nowhere.
Which step did I miss?
Did you bless the new EFI partition that contains OpenCore? It should be blessed from outside OpenCore itself, like from the Recovery partition.
I did - but it still wants the original HDD in there. When it is in, I'm seeing a second EFI drive on the bootloader.
So it looks like I've got two of them, but the one on the old HDD is loading first. If I take the files out of the one on the SSD, then I don't get the second EFI drive.
i've spent most of the evening on Google, this site and various Youtube videos regarding this, I must be missing something simple.
It appears that the blessing operation is being routed through your original instance of OC. See below.
If you are referring to the OC boot picker, then RequestBootVarRouting must be disabled first, otherwise you're telling the original instance of OC to boot the new one by default, which will just end up booting the original, because OC will not boot another instance of itself.
Yes, completely outside OC, which is to say, a supported Recovery (Mojave or earlier) booted natively, otherwise the situation will be as explained above. Alternatively, disable RequestBootVarRouting first.
I wonder if native blessing from within OC without having to turn off RequestBootVarRouting might be a feature worth adding to OC for Macs that don't have the native boot picker. Perhaps @Bmju could comment on the feasibility of adding such a feature.