Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS 12 Monterey on Unsupported Macs Thread

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.
@jackluke I assumed you already noticed this but your tests regarding HD 4000 are a bit flawed. With macOS Big Sur, Apple moved basically all userspace binaries into the dyld cache including Metal bundles. This means that porting over the .bundles that you did are actually empty folders. You'd need to either back port from Catalina or figure out a way to safely remove them from the dyld cache in Big Sur without corrupting them
 
  • Like
Reactions: nandor690, ASentientBot, jackluke and 1 other person
khronokernel said:
@jackluke I assumed you already noticed this but your tests regarding HD 4000 are a bit flawed. With macOS Big Sur, Apple moved basically all userspace binaries into the dyld cache including Metal bundles. This means that porting over the .bundles that you did are actually empty folders. You'd need to either back port from Catalina or figure out a way to safely remove them from the dyld cache in Big Sur without corrupting them
Click to expand...

I just installed today Monterey, but I noticed that for any non metal or metal HD4000 things are more complicated, also that even with a working "mount -uw /" from single user mode, typing "update_dyld_shared_cache -force" is deprecated.

khronokernel said:
Does the latest OpenCore Legacy patcher not resolve sleep issues with iMacs with Kepler GPUs? We specifically disable the HD 4000 to allow for no root patching
Click to expand...

I understand this, because you rightly through OCLP want to enable any security feature and provide small OTA updates feature.

But I suggested this IntelHD4000 replacement methods only to those with a dualGPUs Kepler and that installed Monterey through ASentientBot HaxLib or similar micropatcher methods without OC.
 
The only thing I've noticed is booting is quite slow. I've disabled ShowPicker, but there is still a considerable delay until the Apple logo appears. Is there a way to speed this up? Thanks.
 
  • Like
Reactions: webg3
uGeen said:
Are the two ethernet ports working?
What WIFI/BT card do you have installed?
Click to expand...
Both Ethernet ports are working fine. Here is the link for the WI-FI/BT.
www.ebay.com

Mac Pro 4,1 5,1 Genuine Apple WiFi Upgrade Kit 802.11ac a/b/g/n/ac Bluetooth 4.2 | eBay

Mac Pro 2009 2010 2012 Wifi & Bluetooth Upgrade Kit Genuine Apple WiFi 802.11 a/b/g/n/ac and Bluetooth 4.2 card. Upgrade to802.11ac faster WiFi. Upgrade to Bluetooth4.2 (with AirDrop, Handoff and Continuity supported, more compatible, secure and faster than Bluetooth 4.0).
www.ebay.com
 
Great news from BenSova: GitHub page.

Wait, where's the UI?!​

This in no way is the squal to Patched Sur. This will only be a terminal-based patcher (coming sometime this week).

I have this so I can play with Monterey without building a full UI patcher. Which will come out before the full release of Monterey with many previews and betas along the way.

So yeah... that's what this will be. Monterey, here we come!

github.com

GitHub - Ursinia/Mini-Monterey-Patcher: A mini patcher for macOS Monterey

A mini patcher for macOS Monterey. Contribute to Ursinia/Mini-Monterey-Patcher development by creating an account on GitHub.
github.com github.com
 
alphascorp said:
Yes I upgraded the cMP5.1 WiFi card with BCM94360CD, so I don't need to add kexts.

About the script "patch-kexts.sh" it is necessary to modify the lines concerning Big Sur in the code part below:

Code: 
# Make sure this script is running as root, otherwise use sudo to try again
# as root.
[ $UID = 0 ] || exec sudo "$0" "$@"

IMGVOL="/Volumes/Image Volume"
if [ -d "$IMGVOL" ]
then
RECOVERY="YES"
else
RECOVERY="NO"
# Not in the recovery environment, so we need a different path to the
# patched USB.
if [ -d "/Volumes/Install macOS Big Sur" ]
then
IMGVOL="/Volumes/Install macOS Big Sur"
elif [ -d "/Volumes/Install macOS Big Sur Beta" ]
then
IMGVOL="/Volumes/Install macOS Big Sur Beta"
else
# if this is inaccurate, there's an error check in the next top-level
# if-then block which will catch it and do the right thing
IMGVOL="/Volumes/Install macOS Beta"
fi
fi

With this (but I'm not really sure)

Code: 
# Make sure this script is running as root, otherwise use sudo to try again
# as root.
[ $UID = 0 ] || exec sudo "$0" "$@"

IMGVOL="/Volumes/Image Volume"
if [ -d "$IMGVOL" ]
then
RECOVERY="YES"
else
RECOVERY="NO"
# Not in the recovery environment, so we need a different path to the
# patched USB.
if [ -d "/Volumes/Install macOS Monterey" ]
then
IMGVOL="/Volumes/Install macOS Monterey"
elif [ -d "/Volumes/Install macOS 12 Beta" ]
then
IMGVOL="/Volumes/Install macOS 12 Beta"
else
# if this is inaccurate, there's an error check in the next top-level
# if-then block which will catch it and do the right thing
IMGVOL="/Volumes/Install macOS Beta"
fi
fi

The "remount-sysvol.sh" script should also be modified because it checks the version year of macOS, (replace "20" by "21") in the line of code below:

Code: 
if echo $SVPL_BUILD | grep -q '^20'
Click to expand...
It would be more easy if your fork the micropatcher and maintain your changes there.
 
PG7 said:
hello good afternoon Jackluke,

would it be possible to make it compatible with MonteRey?

thanks

it would be for me to do tests with HD4000 and Nvidia GT320M

Google Translate !
Click to expand...

Which method you used to install Monterey and which error you get when launching BigSurmountsrw ?

Currently even if Nvidia Tesla kext can be installed without kmutil errors, GT320M can't boot yet Monterey desktop, same applies to HD4000 if it's a single GPU then can't boot Monterey desktop with Metal acceleration .
 
  • Like
Reactions: PG7
jackluke said:
I was trying to fetch those icons from Applications Utilities System Information Resources Assets.car (then using ThemeEngine) , where do you find these ? Could you find one for Monterey dark mode ?
Click to expand...
Hi @jackluke

Yes, usually I find them in the same place as you, but as we are in Beta versions, they are not there yet...
So I made them myself...

Here is the dark version:
 

Attachments

  • ProductPageIcon Dark.icns.zip
    1.2 MB · Views: 105
VKondakoff said:
I have exactly the same issue: booted from
OpenCore Legacy Patcher v0.1.7 #
# Selected Model: iMac15,1 #
# Target OS: macOS 12.0.

There were no errors and now the screen resolution is 3840 x 2160 instead of 5120 x 2880.

Patched:

Non-patched:

System Information still recognizes my display correctly:

Any chance to fix this?
Click to expand...
Well, hate that you’re running into trouble as well, but it’s good to know I'm not alone on this.

I’ve skimmed the thread but is there anyone with an iMac15,1 who patched successfully without this issue?
 
chechugarriga said:
Good afternoon, glad you succeeded OKonnel.
Allow me a question.
We are on the very same computer like yours, but with i5 CPU late 2013 27".
On our actual computer Big Sur was installed with the micropatcher approach, without any additional changes.
Where you in need of using OCLP 0.1.6 to run the installer of Monterey Beta?
Thanks in advance. Regards.
Click to expand...
I used Micropatcher in the beginning, but then I switched to OpenCore Legacy Patcher from long time now as it allows our iMac 14.2 (Late 2013) to be accepted as if they were iMac 15.1 2015 WITHOUT add any system changes. Everything work, including OTA Updates and the Boot Recovery commands.
Using OCLP is super easy!
To install macOS Monterey I used the latest OCLP 0.1.7 version.
On the OCLP website I always prefer to download the Code version and start the .command file. But you need to know how to bypass macOS quarantine protection to all root folder contents you get by unzipping the .ZIP file containing the code.
If you don't know how to do it, you can download the latest version of the night version of OpenCore Patcher 0.1.7 in application format and use it to insert it into the EFI partition of the disk.
READ the instructions on the OCLP site FIRST to familiarize yourself, as I assure you it's simple and its creators are exceptional and selfless people.
It's important.
If your Big Sur was currently installed with Micropatcher, perhaps it would be best to start from scratch with an USB key created with OCLP. In fact, OCLP does not alter any files on the macOS system, but Micropatcher yes.
I add also that this morning, after inserting the latest OCLP 0.1.7 version in the disk Partition EFI and rebooted the Mac, I started the Monterey installation directly from Big Sur and not from a USB stick... Practically as if my iMac is a true supported iMac...
 
  • Like
Reactions: chechugarriga, Chumnick and Ausdauersportler
Ausdauersportler said:
It would be more easy if your fork the micropatcher and maintain your changes there.
Click to expand...
Hi @Ausdauersportler

I understand, I had some problems with G___l_Drive, I could not upload the micropatcher but it's done, here is the link:



I hope I didn't make a mistake in correcting the scripts, please let me know in this case.

EDIT

Monterey-micropatcher based on Barry's big-sur-micropatcher v0.5.1 on this page:
 
Last edited:
  • Like
Reactions: Ausdauersportler
alphascorp said:
Hi @Ausdauersportler

I understand, I had some problems with G___l_Drive, I could not upload the micropatcher but it's done, here is the link:

Monterey-micropatcher - Google Drive

drive.google.com drive.google.com

I hope I didn't make a mistake in correcting the scripts, please let me know in this case.
Click to expand...
Thanks, but: No, no, and no!

I meant you sign in to Github.com, look up the current micropatcher page (or my fork), press on the fork button and change the code online on Github.com. That way all people can download the whole product (which contains 99% of original code and your 1% changes) in the same way as the did it before.

Even the docs are linked in. And if you are going to change the readme on your page the people see your version.

Copying code fragments and move it over to other online storage services is nice but not the way software collaboration is meant or planned to work. Especially when the source is already located on Github.com :)

It is not that complicated!
 
  • Like
Reactions: iMac-iPad
alfon_sico said:
Mac mini 2012 works with micro patcher. First look, it is very slow. Not sure maybe a mix of causes, first beta, graphics kext etc, by the moment it’s unusuable

I can’t apply kext patch for wifi, it needs more time to investigate
Click to expand...
It doesn't work on my 2012 MM, I got as far as (almost) the login screen, but it's looping, same text in verbose mode or a spinning wheel each and every 10-20 seconds.

I get this in verbose mode:


Screenshot.jpg
 
Ausdauersportler said:
Thanks, but: No, no, and no!

I meant you sign in to Github.com, look up the current micropatcher page (or my fork), press on the fork button and change the code online on Github.com. That way all people can download the whole product (which contains 99% of original code and your 1% changes) in the same way as the did it before.

Even the docs are linked in. And if you are going to change the readme on your page the people see your version.

Copying code fragments and move it over to other online storage services is nice but not the way software collaboration is meant or planned to work. Especially when the source is already located on Github.com :)

It is not that complicated!
Click to expand...

Sorry, I didn't understand what you meant exactly and I didn't dare ask you for more explanation. But here it is clearer, thank you.

It's done! I modified the scripts for Monterey (and only modified the README header) on this page:
 
  • Like
Reactions: Ausdauersportler
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back