Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Using OpenCore:

Before starting this use the RomTool and backup your Apple Mac firmware and save it to an external storage device. In any case of trouble you can write it back using a CH341A clip programmer. Okay, this would be a real operation but far better then having a brick on the desk.

Always check if your OpenCore has the NVRAM variable run-efi-updater set to value No - the No is important - it is not no or 0 (zero) or NOT - it is No.
Hi Ausdauersportler, can you give me the Password from the zipped RomTool?

Regards Schmalen
 
Hello. Just the fourth time. So, download Big Sur from the forum. Then created the usb stick with createinstallmedia. Run Micropatcher 0.4.4. Install Big Sur. No error messages until then. Then comes this error message.
Thanks. What I think we'll need is the Terminal commands you used after the initial 'createinstallmedia' command. Specifically the exact 'micropatcher.sh' sequence you entered, more importantly 'install-setvars.sh' command, plus any of the options (like -e, that I use). It may be possible that you put in an extra space or left one out in setting up the SIP and ARV security. And last, did you start up from EFI Boot to use Barry's setvars EFI utility. Most of us have made some if not all of these errors!
 
Thanks. What I think we'll need is the Terminal commands you used after the initial 'createinstallmedia' command. Specifically the exact 'micropatcher.sh' sequence you entered, more importantly 'install-setvars.sh' command, plus any of the options (like -e, that I use). It may be possible that you put in an extra space or left one out in setting up the SIP and ARV security. And last, did you start up from EFI Boot to use Barry's setvars EFI utility. Most of us have made some if not all of these errors!
Hello. Thank you for the quick answer. I think it's because of the USB sticks. I'll try it tomorrow with a new stick. I think the EFI boat has been overwritten too many times.
 
Thanks. What I think we'll need is the Terminal commands you used after the initial 'createinstallmedia' command. Specifically the exact 'micropatcher.sh' sequence you entered, more importantly 'install-setvars.sh' command, plus any of the options (like -e, that I use). It may be possible that you put in an extra space or left one out in setting up the SIP and ARV security. And last, did you start up from EFI Boot to use Barry's setvars EFI utility. Most of us have made some if not all of these errors!
Hi, just asking how to add in (-e) on 'install-setvars.sh' command ?
Thanks
 
  • Like
Reactions: TimothyR734
It seems it could be a good practice to make a bootrom backup before trying to install Big Sur on unsupported (i)Macs, just in case. To be able to flash back the bootrom with a clip.
:( and apparently I didn't know this myself before I started installing Big Sur way back. If I didn't backup my bootrom and I need to get back to my previous bootrom, am I screwed? I have a feeling this most recent update to 11.0.1 is really messing with my iMac because I'm having issues seeing my Windows Boot Camp external drive now in the Startup Utility and my bluetooth is sometimes not connecting to the Apple Keyboard when I boot the machine.

I saw the post about Bootroms, but haven't read through it all yet. Would this help my situation if I needed to 'revert' back to the old bootrom?
 
  • Like
Reactions: TimothyR734
I have just released Big Sur Micropatcher v0.5.0. Release notes:
If you have already installed Big Sur successfully using a previous version of Big Sur Micropatcher, you do not need to update immediately, but I would suggest updating the patcher before upgrading to any future Big Sur betas or releases.
  • unpatch-kexts.sh has been replaced by a -u option for patch-kexts.sh. This way, the unpatching can now reuse as much of the patching code as possible. As a neat effect of the increased code reuse, kext unpatching no longer requires booting from the installer USB first.
  • patch-kexts.sh now automatically detects whether the Mac has an 802.11ac WiFi card and, if so, skips installation of the WiFi patch. Thanks to Ausdauersportler for creating the initial implementation of this feature. (My implementation of this feature is not 100% identical, but it is highly similar and based on Ausdauersportler's.)
  • patch-kexts.sh has undergone some code refactoring. In the process, error checking was improved considerably and several minor bugs were fixed.
  • A patch-kexts.sh bug has been fixed that could, under some circumstances, cause kernel panics during boot on Big Sur beta 10 (and probably subsequent releases) on 2011 or earlier Macs. (As a side effect, LegacyUSBInjector.kext may no longer work properly on beta 4-9. However, it works on beta 10.)
  • LegacyUSBInjector.kext has been updated to account for a USB-related kernel change that happened in Big Sur beta 3.
  • The README has been updated.
Unfortunately, there is some stuff going on in my life right now that is absolutely nuts -- nothing really bad per se, but certainly introducing tremendous uncertainty into scheduling/time management matters. (And not related at all to the US election, by the way.) As a result, I may not be able to work on the patcher again (or catch up on posts in this forum thread) until late in the week or the upcoming weekend. I realize this is bad timing, with the Apple event and probably the Big Sur release early-mid next week, but this is beyond my control. Sorry.

 
I have just released Big Sur Micropatcher v0.5.0. Release notes:

Unfortunately, there is some stuff going on in my life right now that is absolutely nuts -- nothing really bad per se, but certainly introducing tremendous uncertainty into scheduling/time management matters. (And not related at all to the US election, by the way.) As a result, I may not be able to work on the patcher again (or catch up on posts in this forum thread) until late in the week or the upcoming weekend. I realize this is bad timing, with the Apple event and probably the Big Sur release early-mid next week, but this is beyond my control. Sorry.

Its just not good enough, Barry. Just who do you think you are, having *other things to do*?

JESUS CHRIST ALMIGHTY.

Just joking, crazy times - really hope everything is ok for you, man.

Joking aside, you’ve done so much for this particular topic, I can’t imagine the hours you’ve put in, examining logs and scrambling your brain in response - but in the grand scheme of things sure please look after yourself and take care of whats *really* important.
 
Last edited:
I have just released Big Sur Micropatcher v0.5.0. Release notes:

Unfortunately, there is some stuff going on in my life right now that is absolutely nuts -- nothing really bad per se, but certainly introducing tremendous uncertainty into scheduling/time management matters. (And not related at all to the US election, by the way.) As a result, I may not be able to work on the patcher again (or catch up on posts in this forum thread) until late in the week or the upcoming weekend. I realize this is bad timing, with the Apple event and probably the Big Sur release early-mid next week, but this is beyond my control. Sorry.

Hey Barry, writing my very first post on macrumors.com just to tell you how much we appreciate the amount of dedication you've put into getting our old machines running Big Sur! Take all the time you need--you more than deserve it.
 
:( and apparently I didn't know this myself before I started installing Big Sur way back. If I didn't backup my bootrom and I need to get back to my previous bootrom, am I screwed? I have a feeling this most recent update to 11.0.1 is really messing with my iMac because I'm having issues seeing my Windows Boot Camp external drive now in the Startup Utility and my bluetooth is sometimes not connecting to the Apple Keyboard when I boot the machine.

I saw the post about Bootroms, but haven't read through it all yet. Would this help my situation if I needed to 'revert' back to the old bootrom?
you can find bootrom files if you google well. just make sure it is exactly the same model number like MBA5,2 for MBA5,2 not MBA5.1. the only side effect may be that your serial number may change.
 
  • Like
Reactions: TimothyR734
I have just released Big Sur Micropatcher v0.5.0. Release notes:

Unfortunately, there is some stuff going on in my life right now that is absolutely nuts -- nothing really bad per se, but certainly introducing tremendous uncertainty into scheduling/time management matters. (And not related at all to the US election, by the way.) As a result, I may not be able to work on the patcher again (or catch up on posts in this forum thread) until late in the week or the upcoming weekend. I realize this is bad timing, with the Apple event and probably the Big Sur release early-mid next week, but this is beyond my control. Sorry.

thanks barry for all that you have done so far. The .5.0 works well on MBA5,2 with upgraded wifi to 802.11ac. take your time to clear stuff off your plate well. cu next time.
 
  • Like
Reactions: TimothyR734
Hi, just asking how to add in (-e) on 'install-setvars.sh' command ?
Thanks
Sorry to make you wait -- In Terminal drag and drop 'install-setvars.sh' into Terminal just as you do to run 'micropatcher.sh'. Type one space, then type '-e' so the command looks like this with some path info before the install-setvars:
Code:
install-setvars.sh -e
Now: type one space after the -e. Then drag and drop the icon of your USB installer stick onto the Terminal window and key 'return'.

Basically, it looks very similar to the rest of the drag and drop commands -- just be sure to surround whatever option you need with single spaces.
 
Sorry to make you wait -- In Terminal drag and drop 'install-setvars.sh' into Terminal just as you do to run 'micropatcher.sh'. Type one space, then type '-e' so the command looks like this with some path info before the install-setvars:
Code:
install-setvars.sh -e
Now: type one space after the -e. Then drag and drop the icon of your USB installer stick onto the Terminal window and key 'return'.

Basically, it looks very similar to the rest of the drag and drop commands -- just be sure to surround whatever option you need with single spaces.
Thank every much. will try. thanks again.
 
  • Like
Reactions: TimothyR734
Hi all,
I need your help because my iMac (2012) doesn’t boot anymore. I was using BS beta 10 without any problem and I tried to upgrade to the last beta by booting with my USB key OpenCoreAPFSloader4s1. The update was detected and after the download my iMac tried to do a restart but the display was black and now it is always black (not white). I tried to reset the SMC, vram and pram but nothing changes and I’m not sure the reset was done as I saw nothing or no change. Do you know what I can do?
Thank you.

You used my USBOpenCore4s1 that is a spoofing setup to iMac15,1 (supported BigSur Mac)

First before send flashing again the EFI EEPROM chip (that surely will fix your unbootable iMac) check this:
https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-29142202

Mainly try to remove the RAM from slot and CMOS CR2032 battery (iMac logic board picture example attached) unplug power cable and let unplugged for an hour, then try use an apple wired original genuine keyboard (because I guess after the EFI update the bluetooth one is unpaired) to make PRAM reset, not sure if your iMac has also a CMOS battery that could be removed on the logic board to reset the stored nvram configuration.
Otherwise you could even remove your internal hard disk, then copy to external USB my earlier opencore version that had a feature to reset PRAM even without an undetected keyboard from apple startup manager:
https://forums.macrumors.com/threads/macos-10-15-catalina-on-unsupported-macs.2183772/post-28354120

Searching on internet you can find already programmed EFI BIOS chip in your case a 21.5 inch A1418 EMC 2544 or 27 inch A1419 EMC 2546 , then with proper tools you can fix it (in some machines soldering skills are required).

Then let me explain how my USBOpenCore spoofing config is made :

Spoofed machine is iMac15,1 Haswell architecture (enough similar to Ivy Bridge than T2 chip Mac) but keeping stock your machine serial number (on my USBopencore it’s not used any spoofed serial number and it’s weird that apple continued the stage2 OTA firmware update even checking that serial number is not from a supported BigSur Mac)

run-efi-updater No is already set on csr-active-config of my config.plist but to make this feature more effective you should select the OTA stage2 installer “macOS Installer” from opencore menu rather than from apple startup manager (that is automatically selected after reboot), because often when exiting from opencore (simplying reboot) the nvram is cleared (even if opencore is installed internally the BigSur stage1 installer automatically sets as default booting device the "macOS Install Data" so opencore should be manually selected).

As you know you updated correctly with my USBopencore4s1 setup OTA method from BigSur beta6 to beta10 , but maybe apple with 11.0.1 beta changed some firmware post script to include the ARM BridgeOS and so something went wrong.

At this point I advise others to don’t use more any opencore spoofing with BigSur, because don’t know the changing behaviour of Update Volume, probably apple now schedule a firmware update in nvram (after stage1 installer Preparing Update), moreover I read on other threads that some reported even on Catalina supported Mac after Catalina update a blank screen (that is a corrupted EFI firmware), but even if an EFI chip is enough cheap, I guess Apple charges many money for repairing.

From my earlier Mojave EFI brick and reflashing I used a WinBond EEPROM Chip 64 MB (the binary size of many non Metal apple firmware is less than 4 MB), while for Metal Mac I guess at least 8 or 16 MB is required, you could use even a different vendor chip example Macronix MX , Micron or Amtel with higher size, if the firmware is correctly flashed on chip it will boot the Mac anyway, to flash the firmware with tools you might require a Windows PC that has more user friendly software and USB drivers , otherwise recently there are advanced external tools to fix EFI solderless plugging some adapters to an apple service port.
 

Attachments

  • 8203302A iMac board RAM battery.jpg
    8203302A iMac board RAM battery.jpg
    150.1 KB · Views: 258
  • 8203302A iMac board EFI chip MXIC MX 25L6408E.jpg
    8203302A iMac board EFI chip MXIC MX 25L6408E.jpg
    171.1 KB · Views: 227
Last edited:
So who encountered those kmutil issues updated a patched Mojave or Catalina (not advisable also apple suggested to use a separate container), for my testing when a "BigSur OTA AssetData update" or "full InstallAssistant" is on stage2 installer, only the APFS System Volume is erased and overwritten, while the Data Volume is kept , that's why I guessed that kmutil could fail with AuxiliaryKernelExtensions especially when kext are similar to Extensions already present on BKE or SKE .
Made one more exercise with kexts in Library/Extensions.
As said earlier, I had deleted all files from Library/Extensions of my BS installation, to let patch-kexts proceed after installing 11.0.1beta over 11.0beta10. The resulting system booted and worked fine. Most files in Library/Extensions were obviously put there by migration assistent, taken from Catalina 10.15.7.

Then repeated the install-over to see what happens. The Library/Extensions, empty before installation, now contained the three files (screenshot). But this time they did NOT hinder patch-kexts from working correctly. The files are newer than the ones I had deleted from Library/Extensions before.

As said earlier, on my legacy-USB MBP5,2, I use jackluke's BigSur BaseSystem legacy usb fix b9 instead of BarryKN's micropatcher.sh to patch the result of createinstallmedia. The files used by jackluke method for patching Basesystem.dmg don't contain the three found after installation in Library/Extensions. The three must come from Apple's installation process and are OK.
Next time I run a migration to BS, and before subsequent installation of a newer BS over it, I'll just delete all files from Library/Extensions. Doesn't hurt at least in my case.
 

Attachments

  • Bildschirmfoto 2020-11-02 um 08.19.01.png
    Bildschirmfoto 2020-11-02 um 08.19.01.png
    72.3 KB · Views: 248
  • IMG_4937.jpeg
    IMG_4937.jpeg
    540.1 KB · Views: 202
  • IMG_4938.jpeg
    IMG_4938.jpeg
    668.9 KB · Views: 220
Last edited:
Hi all,

Late 2013 iMac, updated to Big Sur 11.0.1 yesterday from Beta 10. Had some strange issues after this where I couldn't get into the Startup Utility while holding Option at boot. Needed to do this as I have my Big Sur installation on a seperate APFS volume to my main volume running 10.15.7 and wanted to get back to my main OS (I also have Boot Camp on a external hard drive so need startup manager to boot into that). I resolved the issue by booting into MacOs Recovery (Command-R) and selecting the Startup Utility from there and then choosing my main Macintosh HD volume

Edit: I may have spoken too soon about this. I just tried to restart my machine to get the startup utility holding option and even tried the same after shutting down my iMac and turning it back on and holding Option, but still no startup utility. I have an Apple Magic Keyboard and although I didn't try plugging it into USB yet, I wonder if its not picking up the keyboard during boot? I can't even get into recovery now following a restart or shutting down and turning back on. Could the update have caused this?

2) After this update, I noticed the Startup sound has changed and is now lower in pitch! I always heard it since I'm on the pre-T2 chip iMacs, but noticed the difference as soon as it booted back up after completing the update. I actually kind of like this change!

For BigSur OTA updates do you used your custom Opencore setup or my setup USBOpenCore4s1 ?

If the startup chime lower pitch sound is this:

musically the T2 chime it's a F Chord , while almost any previous Catalina supported Mac and earlier machines used a chime F# Sharp Chord

Then I guess your EFI SMC firmware has been updated through the BigSur 11.0.1 OTA firmware update , on previous post @Bmju reported a similar behaviour after BigSur 11.0.1 OTA update, in his case the screen for Prohibitory Symbol changed showing support.apple.com/mac/startup

@webg3 pointed that if you select opencore to continue the BigSur "macOS Installer" OTA stage2 installer, then no firmware update is issued, this could be correct, because "run-efi-updater is kept No" when targeting opencore even if you are continuing to spoof a supported Mac, but this is valid unless apple don't schedule the firmware update after the Preparing Update that is after completed the OTA stage1 installer.

Anyway after reading these many post about BigSur EFI firmware updates, I advise to don't use more any opencore spoofing methods to update your BigSur installation, use instead an InstallAssistant.pkg with micropatcher or ASentientBot method to replace the UpdateBundle/AssetData with an OTA full package.
 
Last edited:
The mystery of the 'no entry' screens continues. (I know what the 'no entry' screen is and I know how to get past it. This is not about that.)

After a normal, everyday partitioning disaster 😬😱 I needed to re-install Big Sur.

1. I got Catalina using internet recovery and then used OpenCoreAPFSloader4s1 to try to get the 11.0.1 beta full upgrade as a developer seed software update. However (Mystery #1) after downloading (still 100% within an OpenCore boot), this failed with "InstallAssistant.pkg does not meet the gatekeeper policy" (not the exact wording). I tried this twice, same result.

2. So instead I got Big Sur 11.0 beta 10 from a direct download link and used createinstallmedia.

At second stage install I saw this screen, which I have never seen before:

d455f243-39c5-4b20-acd0-f2cc008f2af3.jpeg


(What exactly is this, anyone?)

It hung at the stage shown for about half an hour. I did a reboot, PRAM reset, NVRAM reset and ... Mystery #2 ... I had my old 'no entry' screen back (thicker lines on the no entry symbol itself, and no link). Was this a firmware downgrade?

I passed the no entry symbol as normal (using boot-args) and the beta 10 install continued fine.

3. Since I had already previously installed 11.0.1 beta as an OTA upgrade using the side loader and it hadn't permanently killed my machine, I did it again. (NB this is NOT advised.)

This time ... Mystery #3 ... there were no hangs and no black screens, but all the same I had my 'no entry' screen changed again, back to the new one as shown in my last post.

What's going on? As a minor issue (since it's easy to get round it) I was surprised that I couldn't run 11.0.1 beta from Catalina using the side loader. I thought it might be worth mentioning. As the main point of this post: I'm definitely surprised that my firmware (if changing that 'no entry' image definitely is the firmware) went back again, temporarily, when temporarily downgrading from 11.0.1 beta to 11.0 beta 10!
 
Last edited:
  • Like
Reactions: TimothyR734
...

It hung at the stage shown for about half an hour. I did a reboot, PRAM reset, NVRAM reset and ... Mystery #2 ... I had my old 'no entry' screen back (thicker lines on the no entry symbol itself, and no link). Was this a firmware downgrade?
...
I've realised that it was probably/likely my install of Catalina which reset my 'no entry' symbol. Which tends to imply that if you can boot the machine at all (maybe on a old/different HD/SSD), then a re-install of a supported OS might be one way to fix the problems. (Though admittedly if the machine's really bricked, normal booting probably isn't an option...)
 
I've realised that it was probably/likely my install of Catalina which reset my 'no entry' symbol. Which tends to imply that if you can boot the machine at all (maybe on a old/different HD/SSD), then a re-install of a supported OS might be one way to fix the problems. (Though admittedly if the machine's really bricked, normal booting probably isn't an option...)

I guess during this unwanted BigSur firmware crossflashing, I suppose that EFI firmware contains also "some drivers" for basic Graphics, SSD drives, bluetooth, ethernet, Wifi, USB devices and shortcut keys for apple keyboards (CMD+R, PRAM reset, alt-option key).

But fixing the blank screen even without a responsive alt-option key, would be also possible through removing the internal SSD that on many Ivy Bridge is a kind of mini pciexpress (not SATA) M2 disk, then plugging an external USB with for example El Capitan Installer, should allow to boot anyway the machine.

Anyway I advise to don't use more OpenCore4s1 or any opencore spoofing OTA updates methods for BigSur.
 
HI! @Barry K. Nathan Repatched beta 11.0.1 installer with 0.5.0 (--2010, was 0.5.0-C) . Same behavior on Mac mini 2010: USB keyboard and mouse work fast and stable, but only with CMD + S. Errors on kmutil rebuilding boot & system collections.
hi i thought the instruction on barry's page said to install on a newer mac and then boot up with the usb install stick and run patch-kexts.sh --2010. then i imaged that external usb HDD to the internal 2010 HDD. i used Carbon Copy Cloner. that is the only way i got it to work on MBP5,3. i used MBA5,2 to install and patch. then imaged it to MBP HDD it was the simplest easy to understand way for me.
 
The mystery of the 'no entry' screens continues. (I know what the 'no entry' screen is and I know how to get past it. This is not about that.)

After a normal, everyday partitioning disaster 😬😱 I needed to re-install Big Sur.

1. I got Catalina using internet recovery and then used OpenCoreAPFSloader4s1 to try to get the 11.0.1 beta full upgrade as a developer seed software update. However (Mystery #1) after downloading (still 100% within an OpenCore boot), this failed with "InstallAssistant.pkg does not meet the gatekeeper policy" (not the exact wording). I tried this twice, same result.

2. So instead I got Big Sur 11.0 beta 10 from a direct download link and used createinstallmedia.

At second stage install I saw this screen, which I have never seen before:

View attachment 977964

(What exactly is this, anyone?)

It hung at the stage shown for about half an hour. I did a reboot, PRAM reset, NVRAM reset and ... Mystery #2 ... I had my old 'no entry' screen back (thicker lines on the no entry symbol itself, and no link). Was this a firmware downgrade?

I passed the no entry symbol as normal (using boot-args) and the beta 10 install continued fine.

3. Since I had already previously installed 11.0.1 beta as an OTA upgrade using the side loader and it hadn't permanently killed my machine, I did it again. (NB this is NOT advised.)

This time ... Mystery #3 ... there were no hangs and no black screens, but all the same I had my 'no entry' screen changed again, back to the new one as shown in my last post.

What's going on? As a minor issue (since it's easy to get round it) I was surprised that I couldn't run 11.0.1 beta from Catalina using the side loader. I thought it might be worth mentioning. As the main point of this post: I'm definitely surprised that my firmware (if changing that 'no entry' image definitely is the firmware) went back again, temporarily, when temporarily downgrading from 11.0.1 beta to 11.0 beta 10!
i got to that screen and let it finish at 45 minutes. then it rebooted and continued the installation. i progress bar on my installed didn't update but i trusted it would continue to the next step like it did. do give it enough time to make sure it completes.
 
I guess during this unwanted BigSur firmware crossflashing, I suppose that EFI firmware contains also "some drivers" for basic Graphics, SSD drives, bluetooth, ethernet, Wifi, USB devices and shortcut keys for apple keyboards (CMD+R, PRAM reset, alt-option key).

But fixing the blank screen even without a responsive alt-option key, would be also possible through removing the internal SSD that on many Ivy Bridge is a kind of mini pciexpress (not SATA) M2 disk, then plugging an external USB with for example El Capitan Installer, should allow to boot anyway the machine.

Anyway I advise to don't use more OpenCore4s1 or any opencore spoofing OTA updates methods for BigSur.
in my experience on MBP5,3 and MBA5,2 the serial number and wifi/bt (pcie card) information was saved in the firmware.

its a good idea to remove the drive to get past the white (or black) screen of death and waiting for the folder mark to show up on the screen.

it does seem like opencore could cause a crossflash problem. good to have backup rom file just for safety anyways.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.