I just created the patched USB, and it created just fine.
Does - what you say - mean I cannot use that USB to upgrade my installation to Big Sur?
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.
macOS 11 Big Sur on Unsupported Macs Thread
- Thread starter dosdude1
- WikiPost WikiPost
- Start date
-
- Tags
- 10.16 macos unsupported
- Sort by reaction score
- Status
Does - what you say - mean I cannot use that USB to upgrade my installation to Big Sur?
Awesome... micro patcher was able to update system from 11.2 to 11.2.1 with no issues on late iMac 2013
Works perfectly with barrykn's micropatcher on my MBP mid 2012.
I can give some updates on this.
In @jackluke's mostly excellent original config, setting SMBIOS/BoardProduct as well as Generic/SystemProductName was a minor error. His config uses PlatformInfo/Automatic=true. If that setting is true, the board-product-id is generated for you by OC, based on SystemProductName in the Generic section (which will revert to your own machine's value if you do not specify anything). Therefore SMBIOS/BoardProduct is really being ignored in that config. More generally, no settings from the SMBIOS section are used at all (only the Generic section), when Automatic=true. (So, including that setting was harmless, but confusing.)
The only reason not to use the @jackluke config was because of the firmware bricking issue. (Also: that was caused by Apple, not OC - it was bricking older, supported Macs with no OC involved, too! OC had to work out how to block it.) Therefore, any config based off @jackluke's, but using OC 0.6.6 or higher and with MaxBIOSVersion set to true is now safe. (NB This is for Automatic=true, which @jackluke uses. If false you need a slightly different setting, see the @cdf docs in the MacPro thread.) (I know I'm just confirming what you're saying about this bit, @Ausdauersportler!)
Last edited:
About OS update terminology! Are people agreed that:
1 Getting an update using the system preferences pane (which may also be downloaded for you in the background, if you leave your Mac on) is an OTA update?
2. Then, there are two types of OTA update, delta and full. Delta is about 2.8GB, and means the updater has decided it can safely patch your clean, signed, existing OS. Full is about 12.2GB, and means all OS files will be fully replaced, not patched in place. (Full takes longer to download - obviously - but also takes quite a lot longer to install than delta, in my experience.)
3. The alternative to an OTA update is a manual update, in which you a) get hold of the InstallAssistant.pkg file yourself, b) open it which creates an OS installation app, c) manually run
Additional wrinkle: you can do a manual update using a full OS installer which the OTA system has downloaded and expanded into an installation app for you! (If and when it has, and if you cancel the rest of the OTA install process.)
That's how I'm now using these terms. Anyone want to point out that that's not what other people have sometimes meant? Or else like or reply if it's okay?
1 Getting an update using the system preferences pane (which may also be downloaded for you in the background, if you leave your Mac on) is an OTA update?
2. Then, there are two types of OTA update, delta and full. Delta is about 2.8GB, and means the updater has decided it can safely patch your clean, signed, existing OS. Full is about 12.2GB, and means all OS files will be fully replaced, not patched in place. (Full takes longer to download - obviously - but also takes quite a lot longer to install than delta, in my experience.)
3. The alternative to an OTA update is a manual update, in which you a) get hold of the InstallAssistant.pkg file yourself, b) open it which creates an OS installation app, c) manually run
createinstallmedia from inside that app's directory to create an OS installer. The *end result* of this is like a full OTA update, but the difference is, the system preferences pane isn't doing any of the installation for you. (It is the only option if the system isn't offering you OTA updates.)Additional wrinkle: you can do a manual update using a full OS installer which the OTA system has downloaded and expanded into an installation app for you! (If and when it has, and if you cancel the rest of the OTA install process.)
That's how I'm now using these terms. Anyone want to point out that that's not what other people have sometimes meant? Or else like or reply if it's okay?
Last edited:
Actually, for reasons which used to matter more, but now don't (since OC can now prevent Big Sur style firmware updates), the end result of a manual update is *not* quite like an full OTA update; because (for reasons which I don't think are clear to anybody?) a full manual update never attempts to do a firmware update (the cause of a potential bricking, when not prevented), whereas a full or delta OTA update will attempt it, if not blocked (e.g. by OC).
Last edited:
Hi all,
I'm trying to use OCLP on my Mac Pro 3,1 starting from my actual macOS Catalina 10.15.7.
I have partitioned my SSD disk in two 512GB partitions (both APFS formatted).
On the first partition I have macOS Catalina and I want to install macOS Big Sur on the second partition).
I have created the config as described in the readme file and then, I have installed the config package (EFI and OC directories) inside my EFI partition on the boot HD (macOS Catalina ASPF formatted) before install macOS Big Sur.
When I reboot the Mac Pro and hit the Alt key, OC does not appear.
I see always the standard Mac picker.
I have tried to reset the PRAM but without success.
I miss something?
I'm trying to use OCLP on my Mac Pro 3,1 starting from my actual macOS Catalina 10.15.7.
I have partitioned my SSD disk in two 512GB partitions (both APFS formatted).
On the first partition I have macOS Catalina and I want to install macOS Big Sur on the second partition).
I have created the config as described in the readme file and then, I have installed the config package (EFI and OC directories) inside my EFI partition on the boot HD (macOS Catalina ASPF formatted) before install macOS Big Sur.
When I reboot the Mac Pro and hit the Alt key, OC does not appear.
I see always the standard Mac picker.
I have tried to reset the PRAM but without success.
I miss something?
Did you use the bless command to make Open Core the default boot?
Alternatively, you can do the following:
Hold the alt key when the startup chime happens or the display turns gray. When the cursor appears, you can release the alt key. All the startup options should appear. OC may be called "EFI Boot". Select that and press the Return key to boot (or hold the Control key and press the Return key to set it as the default and boot).
Fun fact:
When I was doing the iMac 2011 experiment I did this *wrinkle* manual update because the full automatic update failed with this message (second attached picture) using a spoofing like this (SMBIOS spoofing, only - first attached picture).
I had to change the spoofing to use the DataHub Generic and there only the SystemProductName (as you pointed out the board-ID will be added automatically by then, last attached picture).
Attachments
Last edited:
Hi @joevt , thank you for your answer.
I have mounted the EFI partition where I have installed OC and typed this command:
Code:
sudo bless --folder /Volumes/EFI --setBootIs this correct? Because it does not work.
When I power on the Mac it start directly to macOS Catalina and, if I press ALT, it does not show me the OC selector.
Thanks
Check this thread and get one of the OC packages from there and you will find a tool called Bless OpenCore.
Just noticed:
11.2.1 update (OTA) is build 20D74 whereas
11.2.1 full installer is build 20D75
The full installer corrects the Big Sur not enough free space issue.
11.2.1 update (OTA) is build 20D74 whereas
11.2.1 full installer is build 20D75
The full installer corrects the Big Sur not enough free space issue.
The reason is that both FirmwareFeatures and FirmwareFeaturesMask must be specified when changing any SMBIOS properties in manual mode (Automatic=false). As a failsafe, these properties are set to 0, and upon detecting the absence of firmware features, the installer indicates that a firmware update is needed.
In automatic mode, OpenCore uses a database to set many SMBIOS properties (including FirmwareFeatures and FirmwareFeaturesMask) based on the chosen product name.
Hi Guys, I am using the micro patcher and have a 2012 MacBook Pro on BS 12, how can I enable it to do the upgrades via the system preference pane?
I have tried also with the Bless OpenCore but it does not work.
If I select the EFI device after hit the Alt key, the Mac Pro hang and the only thing I can do is power off.
If I power on normaly, it start macOS Catalina in verbose mode.
No way, except adding OpenCore! Unsupported means no updates and no booting without patching the installer.
You can move on to the OCLP (which is based on OpenCore) to achieve updates, too. This is a completely different approach.
There is a complete thread about OpenCore on MacPro. I do not know if you own a EFI flashed RX580. I do not see how to force an EFI Boot screen at all using the alt/option key on a not EFI Boot screen capable GPU - I never spent time and so never figured out how to make OC react on keys on boot, if possible.
However, if you get the OC running and if you have enabled OpenCanopy and installed the Resources then you get the OpenCore GUI on boot.
Hello everybody,
I have successfully installed Big Sur version 11.2.1.
I only had a small problem when I had to enable WiFi.
After rebooting Big Sur for the first time with the main disk, I rebooted the Macbook Pro with the external stick, but the first time I was unable to execute the "patch-kexts.sh" command.
I had to reboot a second time and then I was able to run the command.
Do you know what it can depend on?
I have successfully installed Big Sur version 11.2.1.
I only had a small problem when I had to enable WiFi.
After rebooting Big Sur for the first time with the main disk, I rebooted the Macbook Pro with the external stick, but the first time I was unable to execute the "patch-kexts.sh" command.
I had to reboot a second time and then I was able to run the command.
Do you know what it can depend on?
Succesfully installed with barrykn's micropatcher to my iMac27 late 2013 and MBPr15 2012. Thank you very much!
I am currently using OpenCore on my hackintosh desktop, is it much different
For FAT and EFI volumes and volumes that are not HFS+ or APFS, use the
--mount variant:sudo bless --mount /Volumes/EFI --file /Volumes/EFI/Boot/Bootx64.efi --setBootUse the
dumpallbootvars before and after the command to see how the boot variables change.https://gist.github.com/joevt/477fe842d16095c2bfd839e2ab4794ff
I think the
--folder variant is more for HFS+ or APFS volumes. Only those types of volumes have finder bless info.
Code:
sudo bless --info /Volumes/Lion
finderinfo[0]: 1134 => Blessed System Folder is /Volumes/Lion/System/Library/CoreServices
finderinfo[1]: 2149125 => Blessed System File is /Volumes/Lion/System/Library/CoreServices/boot.efi
finderinfo[2]: 0 => Open-folder linked list empty
finderinfo[3]: 0 => No alternate OS blessed file/folder
finderinfo[4]: 0 => Unused field unset
finderinfo[5]: 1134 => OS X blessed folder is /Volumes/Lion/System/Library/CoreServices
64-bit VSDB volume id: 0x9AD88B883496739C
sudo bless --info /
2355 => Blessed System File is /Volumes/Preboot/23DC9494-8D50-4085-A389-493878A2404B/System/Library/CoreServices/boot.efi
2225 => Blessed System Folder is /Volumes/Preboot/23DC9494-8D50-4085-A389-493878A2404B/System/Library/CoreServices
The blessed volume in this APFS container is "/".
No blessed APFS snapshot for this volume.
source "~/Downloads/gfxutil.sh"
sudo $directbless --info /
1152921500312424068 => Blessed System File is /System/Library/CoreServices/boot.efi
1152921500311931670 => Blessed System Folder is /System/Library/CoreServices
Couldn't find a valid volume UUID in the boot path
diskutil mount Preboot
sudo $directbless --info /Volumes/Preboot
2355 => Blessed System File is /Volumes/Preboot/23DC9494-8D50-4085-A389-493878A2404B/System/Library/CoreServices/boot.efi
2225 => Blessed System Folder is /Volumes/Preboot/23DC9494-8D50-4085-A389-493878A2404B/System/Library/CoreServices
These paths are associated with the volume "/".
Could not lookup blessed APFS snapshot for / - No such processI was wondering, what were you thinking of? Specifically, what is it that is putting you off using it on your MacBook Pro, especially if you're already familiar with it?
I wonder, it may be because there's a perception (I believe, incorrect!) that OpenCore is somehow more hacky, because it comes from the Hackintosh universe?
Don't forget:
- OpenCore is an incredibly clean and well-written program
- In the end, either approach has to change something (and the more, the more incompatible your machine is - you have a very compatible machine)
- The basic key to fixing any larger incompatibilities (i.e. using non-Apple kexts, and patches) is the *same* in both OC and in the micropatcher, and also in the legacy Mac and the Hackintosh world!
- So it's not OC that makes your unsupported Mac partially a Hackintosh - in some sense - it's that you're running an unsupported OS on it. (Already!)
- The clearest difference between OC and a patcher is that, in OC, any changes are not permanently applied to the OS on the disk, i.e. 'patching', but instead are applied by 'injection': any changes needed are applied on the fly, as you boot up, from the completely clean, unmodified OS which remains on disk (this is NOT the case, in the patcher)
(OCLP is one easy way to get and configure OC; probably by far the easiest, in fact; but not the only way.)
