macOS 12 Monterey on Unsupported Macs Thread

[OKonnel]

HELP ME KINDLY, PLEASE!
After updating to Monterey Beta 9 the nVIDIA graphics acceleration no longer works and as you can see, from the LOG below with in Bold text, "OCLP Post Install Patch" detects conflicts and seems to have problems ...
I tried from OCLP 0.2.5 to OCLP a while ago the KEXTs are no longer copied to /System/Library/Extensions/ as happened with Beta 7.
So! In /System/Library/Extensions/ I don't see the nVidia KEXTs that the Patch should add.
I did a lot of tests, both by installing Beta 9 from the Application created with Install Assistant and by installing from USB-Key, always with OCLP 0.3.0
What am I doing wrong? I have used both OCLP TUI and GUI
Thanks

EDIT
I just found that the Monterey's Disk Utility now displays the system disk (Macintosh HD) in a different way. I don't know if because Apple has changedmodality or if it's a my issue.
Until now Monterey Disk Utility saw a long code as name of a Virtual disk (snapshot), but now Monterey sees its internal disk (Macintosh HD) differently, without a long Code name.
I attach a clip

The following patches will be applied:
- Add Legacy Nvidia Kepler Graphics Patch
Would you like to continue with Root Volume Patching?(y/n): y
- Continuing with Patching
- Verifying whether Root Patching possible
- Patcher is capable of patching
- Apple binaries missing
- Found local 12-Monterey zip, skipping download
- Duplicating into Apple.zip
- Download completed
- Unzipping download...
- Renaming folder
- Binaries downloaded to:
/private/var/folders/tj/399vw2z94z3f37q51l2g3w300000gn/T/_MEI9U47pf/payloads
Press [ENTER] to continue
- Found Root Volume at: disk2s5
- Root Volume is already mounted
- Running patches for iMac14,2
- Installing Kepler Patches
- Detected supported OS, installing Acceleration Patches
- Installing Kepler Acceleration Kext patches for Monterey
- Found conflicting kext, Deleting Root Volume's GeForce.kext
Password:
- Adding GeForce.kext
- Found conflicting kext, Deleting Root Volume's GeForceAIRPlugin.bundle
- Adding GeForceAIRPlugin.bundle
- Found conflicting kext, Deleting Root Volume's GeForceGLDriver.bundle
- Adding GeForceGLDriver.bundle
- Found conflicting kext, Deleting Root Volume's GeForceMTLDriver.bundle
- Adding GeForceMTLDriver.bundle
- Found conflicting kext, Deleting Root Volume's GeForceVADriver.bundle
- Adding GeForceVADriver.bundle
- Found conflicting kext, Deleting Root Volume's NVDAGF100Hal.kext
- Adding NVDAGF100Hal.kext
- Found conflicting kext, Deleting Root Volume's NVDAGK100Hal.kext
- Adding NVDAGK100Hal.kext
- Found conflicting kext, Deleting Root Volume's NVDAResman.kext
- Adding NVDAResman.kext
- Found conflicting kext, Deleting Root Volume's NVDAStartup.kext
- Adding NVDAStartup.kext
Press [ENTER] to continue with cache rebuild:
- Rebuilding Kernel Cache (This may take some time)
- Successfully built new kernel cache
Press [ENTER] to continue with snapshotting
- Creating new APFS snapshot
Can't use last-sealed-snapshot or create-snapshot on non system volume
- Unmounting Root Volume (Don't worry if this fails)
disk2s5 was already unmounted
- Patching complete

Please reboot the machine for patches to take effect
Press [ENTER] to continue

I add also diskutil APFS list

Vincenzo@iMac-Studio ~ % diskutil APFS list
APFS Containers (2 found)
|
+-- Container disk2 32444E9C-A6B7-4E8C-82FD-95770C79F07A
|   ====================================================
|   APFS Container Reference:     disk2
|   Size (Capacity Ceiling):      2000189177856 B (2.0 TB)
|   Capacity In Use By Volumes:   667856519168 B (667.9 GB) (33.4% used)
|   Capacity Not Allocated:       1332332658688 B (1.3 TB) (66.6% free)
|   |
|   +-< Physical Store disk0s2 9E30BB16-B827-42D4-8408-D3B59E241C2D
|   |   -----------------------------------------------------------
|   |   APFS Physical Store Disk:   disk0s2
|   |   Size:                       2000189177856 B (2.0 TB)
|   |
|   +-> Volume disk2s1 C0D6933E-2E9F-49A4-AAE2-FE2BDEEC8134
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk2s1 (Data)
|   |   Name:                      Macintosh HD - Dati (Case-insensitive)
|   |   Mount Point:               /System/Volumes/Data
|   |   Capacity Consumed:         648963731456 B (649.0 GB)
|   |   Sealed:                    No
|   |   FileVault:                 Yes (Unlocked)
|   |
|   +-> Volume disk2s2 0F3C085F-C0E8-49D1-94F4-BE1DC7418152
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk2s2 (Preboot)
|   |   Name:                      Preboot (Case-insensitive)
|   |   Mount Point:               /System/Volumes/Preboot
|   |   Capacity Consumed:         497557504 B (497.6 MB)
|   |   Sealed:                    No
|   |   FileVault:                 No
|   |
|   +-> Volume disk2s3 DB6EBBDD-A947-44AE-A265-9EF14336E28D
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk2s3 (Recovery)
|   |   Name:                      Recovery (Case-insensitive)
|   |   Mount Point:               Not Mounted
|   |   Capacity Consumed:         1094299648 B (1.1 GB)
|   |   Sealed:                    No
|   |   FileVault:                 No
|   |
|   +-> Volume disk2s4 21A5D6D3-3259-435F-8DA0-B3E4C90C2963
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk2s4 (VM)
|   |   Name:                      VM (Case-insensitive)
|   |   Mount Point:               /System/Volumes/VM
|   |   Capacity Consumed:         1069056 B (1.1 MB)
|   |   Sealed:                    No
|   |   FileVault:                 No
|   |
|   +-> Volume disk2s5 9018CC30-82C3-4491-B0E2-C45F3CA0E003
|       ---------------------------------------------------
|       APFS Volume Disk (Role):   disk2s5 (System)
|       Name:                      Macintosh HD (Case-insensitive)
|       Mount Point:               /Volumes/Macintosh HD 1
|       Capacity Consumed:         15490473984 B (15.5 GB)
|       Sealed:                    Broken
|       FileVault:                 Yes (Unlocked)
|       Encrypted:                 No
|       |
|       Snapshot:                  C4EE6397-3BAC-4535-83DA-E63238E54166
|       Snapshot Disk:             disk2s5s1
|       Snapshot Mount Point:      /
|       Snapshot Sealed:           Yes
|

 

[houser]

HELP ME KINDLY, PLEASE!

Hello. You probably don't want to hear it, but wiping the drive and going back to your backup is sometimes the least amount of work. I have probably done it 20 times during this beta cycle. Takes more time for the computer but less
time for you. FWIW.

 

[K two]

HELP ME KINDLY, PLEASE!
After updating to Monterey Beta 9 the nVIDIA graphics acceleration no longer works and as you can see, from the LOG below with in Bold text, "OCLP Post Install Patch" detects conflicts and seems to have problems ...
I tried from OCLP 0.2.5 to OCLP a while ago the KEXTs are no longer copied to /System/Library/Extensions/ as happened with Beta 7.
So! In /System/Library/Extensions/ I don't see the nVidia KEXTs that the Patch should add.
I did a lot of tests, both by installing Beta 9 from the Application created with Install Assistant and by installing from USB-Key, always with OCLP 0.3.0
What am I doing wrong? I have used both OCLP TUI and GUI
Thanks

EDIT
I just found that the Monterey's Disk Utility now displays the system disk (Macintosh HD) in a different way. I don't know if because Apple has changedmodality or if it's a my issue.
Until now Monterey Disk Utility saw a long code as name of a Virtual disk (snapshot), but now Monterey sees its internal disk (Macintosh HD) differently, without a long Code name.
I attach a clip

The following patches will be applied:
- Add Legacy Nvidia Kepler Graphics Patch
Would you like to continue with Root Volume Patching?(y/n): y
- Continuing with Patching
- Verifying whether Root Patching possible
- Patcher is capable of patching
- Apple binaries missing
- Found local 12-Monterey zip, skipping download
- Duplicating into Apple.zip
- Download completed
- Unzipping download...
- Renaming folder
- Binaries downloaded to:
/private/var/folders/tj/399vw2z94z3f37q51l2g3w300000gn/T/_MEI9U47pf/payloads
Press [ENTER] to continue
- Found Root Volume at: disk2s5
- Root Volume is already mounted
- Running patches for iMac14,2
- Installing Kepler Patches
- Detected supported OS, installing Acceleration Patches
- Installing Kepler Acceleration Kext patches for Monterey
- Found conflicting kext, Deleting Root Volume's GeForce.kext
Password:
- Adding GeForce.kext
- Found conflicting kext, Deleting Root Volume's GeForceAIRPlugin.bundle
- Adding GeForceAIRPlugin.bundle
- Found conflicting kext, Deleting Root Volume's GeForceGLDriver.bundle
- Adding GeForceGLDriver.bundle
- Found conflicting kext, Deleting Root Volume's GeForceMTLDriver.bundle
- Adding GeForceMTLDriver.bundle
- Found conflicting kext, Deleting Root Volume's GeForceVADriver.bundle
- Adding GeForceVADriver.bundle
- Found conflicting kext, Deleting Root Volume's NVDAGF100Hal.kext
- Adding NVDAGF100Hal.kext
- Found conflicting kext, Deleting Root Volume's NVDAGK100Hal.kext
- Adding NVDAGK100Hal.kext
- Found conflicting kext, Deleting Root Volume's NVDAResman.kext
- Adding NVDAResman.kext
- Found conflicting kext, Deleting Root Volume's NVDAStartup.kext
- Adding NVDAStartup.kext
Press [ENTER] to continue with cache rebuild:
- Rebuilding Kernel Cache (This may take some time)
- Successfully built new kernel cache
Press [ENTER] to continue with snapshotting
- Creating new APFS snapshot
Can't use last-sealed-snapshot or create-snapshot on non system volume
- Unmounting Root Volume (Don't worry if this fails)
disk2s5 was already unmounted
- Patching complete

Please reboot the machine for patches to take effect
Press [ENTER] to continue

Just reboot, you're good.

 

[khronokernel]

Can't use last-sealed-snapshot or create-snapshot on non system volume

It's an APFS bug introduced with Beta 7, where bless fails to recognize the snapshot is root and thus fails. This bug affects usage of Apple's own KDKs so hopefully will be fixed, but a clean installation will also fix this bug

 

[K two]

Just reboot, you're good.

 

[OKonnel]

It's an APFS bug introduced with Beta 7, where bless fails to recognize the snapshot is root and thus fails. This bug affects usage of Apple's own KDKs so hopefully will be fixed, but a clean installation will also fix this bug

Thanks. But by clean install you mean I should format the disk, install Monterey Beta 9, APPLY “OCLP Post Install Patch” and then restore from Time Machine? Assuming macOS lets me use Time Machine and doesn't tell me it belongs to another Mac ... In that case I would lose all my work ... The solution would be to copy everything to another HD with Carbon Copy Cloner, but then I would have to redo the Accounts, my software recordings, etc ... Well ... Patience

 

[houser]

Thanks. But by clean install you mean I should format the disk, install Monterey Beta 9, APPLY “OCLP Post Install Patch” and then restore from Time Machine? Assuming macOS lets me use Time Machine ...>>

As you probably know, you have to restore your time machine backup onto an install that has the same
version Mac OS as the Time Machine backup for it to work.
I have used Time Machine for this sort of thing without issues many times in beta cycles
so I trust it. As long as your Time Machine backup is in order you should be good but the usual caveats apply
and I will assume that you are responsible for your own actions and I am just attempting to assist

Oh and did I mention that if something is wrong with your Time machine backups I am not responsible..
If you have not restored from Time Machine before in a mission critical situation, it might be prudent to
do a test run of your time machine backup onto a spare drive if possible before you wipe the drive.
Very little work but time consuming for your computer of course..

Ah well.
Below are my notes for the process that has worked for me 100% FWIW. YMMV.
Not very time-consuming in terms of work but depending on speed of your time machine setup,
will take a while for the computer.

* From a working Mac, make a USB installer with the OS version you had working with the TM backup

* Install and build OCLP on to the USB installer drive if needed for booting in that OS
(I used Nightly OpenCore Patcher (TUI) 0.3.0 today's date but that could of course change)

* Boot from the USB installer and erase the drive from the USB installer with Disk Utility

* Create an AFPS partition for the OS of the size you want onto it

* Create a 200mb or so DOS partition for the OCLP EFI

This is what it should look like in Disk Utility AFTER installing the OS onto the partition.
This works for me where "11.xx" is the AFPS partition. Note the hierarchy.
Set Disk utility menu "View" to "view all devices" to see this:

* Install the Mac OS you had working with your backup onto the new AFPS partition

* Restore the backup from Time Machine onto the partition
( I ignore restoring settings as I have found this to sometimes mess with the restore and takes very little time
to do manually again)

* Then boot from the restored account and check that all is ok and working as before

* Eject USB installer

* Install and build OCLP again, this time to the small EFI partition you created in disk utility
I used Nightly OpenCore Patcher (TUI) 0.3.0 today's date but that could of course change)
I build to it's own small EFI partition as that has been more stable in my setup and experience and
have used these instructions: OCLP docs for multi boot
(just ignore the bit about windows if you have no need for that)

* Enroll your Mac at beta.apple.com again and download the beta access utility again

* Do the upgrade to Monterey beta 9 as usual via system preferences the usual way

* Do the root patch in OCLP.

* Restart

Bob's your uncle. Hopefully..
But a backup of the backup of the backup is of course never a bad idea. Good luck regardless.

 

[rehkram]

Purple & pink static on my MBP internal retina display after 2 hours away from desk. External display was fine. Rebooted, no problem since.

 

[MacRumors3590]

Purple & pink static on my MBP internal retina display after 2 hours away from desk. External display was fine. Rebooted, no problem since.

fluke

 

[TigerA]

Just wonder if anyone tried ProperTree on the beta-9 release? Mine has a black window on a iMac12,2 running the latest OCLP v030n (has AppleGVA patch set for HD3000 and EFICheckDisabler).

 

[MacRumors3590]

Just wonder if anyone tried ProperTree on the beta-9 release? Mine has a black window on a iMac12,2 running the latest OCLP v030n (has AppleGVA patch set for HD3000 and EFICheckDisabler).

same issue here

 

[TigerA]

@ASentientBot :
I've just noticed that the default apps like iMessages use up to 99% energy and is very sluggish for my non-metal iMac with the OCLP post-install patch applied. But they run well before the patch being applied. Obviously the non-metal acceleration is required for other applications like safari. I am just wondering if it is possible to selectively apply the non-metal acceleration so that we can also get the iMessages & the likes working as well?
Apologies in advance for my ignorance if not possible.

Add: I am mainly concerned about the iMessages. (FaceTime and Photos work well.) Others like Maps, News, ATV etc. are not important to me.

 

[OKonnel]

It's an APFS bug introduced with Beta 7, where bless fails to recognize the snapshot is root and thus fails. This bug affects usage of Apple's own KDKs so hopefully will be fixed, but a clean installation will also fix this bug

Eventually... I gave up on Monterey and on the internal 2TB drive I'm reinstalling Catalina.
I will reinstall Monterey to the 128GB drive (formerly part of the native Fusion Drive of my 27 '' 14.2 2013 iMac)
Can't go on with these serious Apple bugs (eg: bless and APFS) that suddenly pop up with the new Betas and prevent the Post Install Patch working well...
For now it is more important to have tranquility and to live peacefully, without regretting the good times when Steve was in control of everyone and everything.
Thank you all for the answers and for trying to help.

 

[macpro_mid2014]

Eventually... I gave up on Monterey and on the internal 2TB drive I'm reinstalling Catalina.
I will reinstall Monterey to the 128GB drive (formerly part of the native Fusion Drive of my 27 '' 14.2 2013 iMac)
Can't go on with these serious Apple bugs (eg: bless and APFS) that suddenly pop up with the new Betas and prevent the Post Install Patch working well...
For now it is more important to have tranquility and to live peacefully, without regretting the good times when Steve was in control of everyone and everything.
Thank you all for the answers and for trying to help.

I have Big Sur 11.6 (this is my day-to-day macOS and safe harbour) running and another Volume (not partition) with Monterey Beta + OC (I don't need to root patch anything).

I am quoting myself from another thread here:

"OTA from B8 to B9 took less than 40 min.

I really am considering the switch to Monterey when Apple releases it later this year. I am planning on keeping both Big Sur and Monterey running on the same SSD (2TB) with duplicate Data volumes for a while and then, around 12.1, get rid of Big Sur."


Thanks,

 

[Pri-est]

Hi to all!
Successfully updated my CMP 2009 from MacOS Monterey 12.0 Beta 8 to Beta 9, by OTA System Upadate, using latest OCLP 0.3.0 NB. System volume patched for Keppler GPU enable.
Issues - no issues,
Big Thanks to contributors!

 

[houser]

"I am planning on keeping both Big Sur and Monterey running on the same SSD (2TB) with duplicate Data volumes for a while and then, around 12.1, get rid of Big Sur."

I have been running multiboot on same SSD with Big Sur and Monterey on and off and it has not been stable for me with repeated corruption in boot and EFI partitions that has required reinstalls. So I gave up on that for now.
It might require some skill in setting up the shared EFI for these two as they currently appear to behave somewhat differently towards OCLP. At least that has been my experience. Multi boot with for example Linux or Windows is different as you can dedicate the EFi for it but I have not found a way for this with Multiboot with Monterey and any other Mac OS. And OCLP does not play with chain booting.
Ah well, if you can comment on how you plan to solve that I would be interested.

 

[KennyW]

I just keep the separate macOS (Catalina, Big Sur, Monterey) in separate discrete internal SSD independently.
With OCLP on a SD without installing it onto the SSDs, I can just update the SD once for any new version.
I boot from the OC BootPicker to choose among the different macOS with no problem.

It is too troublesome to run three different generations of macOS (among them one in unstable evolving beta) in partitions of a single HD/SSD in an officially UNSUPPORTED Mac. Too difficult to troubleshoot and any corruption or EFI interaction will have cascading disaster to the disk.

 

[AlexSakha67]

Hello! Thanks to the developers and just wonderful, good people, I was able to install 12.0 Beta (21A5543b) on MacPro3,1???
Later, maybe tomorrow I'll try to install over the installed Monterey beta8 system on MacBook 7,1?
My favorite hobby is "unsupported-macs" ??

Here are the video tutorials, helped for me?

 

[macpro_mid2014]

I have been running multiboot on same SSD with Big Sur and Monterey on and off and it has not been stable for me with repeated corruption in boot and EFI partitions that has required reinstalls. So I gave up on that for now.
It might require some skill in setting up the shared EFI for these two as they currently appear to behave somewhat differently towards OCLP. At least that has been my experience. Multi boot with for example Linux or Windows is different as you can dedicate the EFi for it but I have not found a way for this with Multiboot with Monterey and any other Mac OS. And OCLP does not play with chain booting.
Ah well, if you can comment on how you plan to solve that I would be interested.

This is my first experience with OC because my MBP still runs Big Sur natively.

But this is my plan: keep the EFI separate on a USB stick and use it only to boot Monterey. While in Monterey, I plan to keep the EFI on and when switching to Big Sur, first do an NVRAM reset then shut the computer down, remove the EFI stick and then turn on the MBP to Big Sur.
I have to keep Big Sur for as long as it is supported by Apple otherwise I risk missing the BootRom updates to my MBP model (if any) during that period. If Monterey works for me, I will keep Big Sur on an external SSD to minimize the problems you described.

Did you do the NVRAM reset every time you switch OS? Is it necessary?

I don't have enough experience running an unsupported macOS on the same SSD to comment further. If I encounter the same issues (system corruption, etc.) with my approach I will report them here.

Thank you for sharing.

 

[K two]

I just keep the separate macOS (Catalina, Big Sur, Monterey) in separate discrete internal SSD independently.
With OCLP on a SD without installing it onto the SSDs, I can just update the SD once for any new version.
I boot from the OC BootPicker to choose among the different macOS with no problem.

It is too troublesome to run three different generations of macOS (among them one in unstable evolving beta) in partitions of a single HD/SSD in an officially UNSUPPORTED Mac. Too difficult to troubleshoot and any corruption or EFI interaction will have cascading disaster to the disk.

Not sure that is entirely valid. With two drive bays in this Mini3,1 - Drive 2 is a 1TB Pioneer SSD w/ four partitions, 3 APFS and one HFS for High Sierra then Mojave, Catalina and Big Sur, all completely up-to-date. Drive 1 is an OWC 500GB w/only a Monterey Beta installed. The cascading crash effect commenced w/Beta 7 and persists to Beta 9. To fix, the RAM modules were replaced to no effect, as some have suggested, the SSD was completely erased and Beta 9 was installed fresh with createinstallmedia USB. Moved or installed apps manually after tedious Control Panel settings. OCLP Step #3, reboot. Ran overnight, sleep/wake perfect, no problems until quitting Safari. No other app would launch after that, eventually Force Quit quit entirely. Cold boot the only recovery. Both drives have latest OCLP_030 Nightly EFI installed.

The non-Monterey multi-boot SSD has NEVER exhibited a cascading crash on any partition. This is a post-Beta 6 Monterey issue, perhaps Webkit-related because the multi-app crash can be precipitated by simply quitting Safari after an hour or so of browsing, commenting, seeing if Otis won the Fat Bear Championship. ?

? . . . . . . . The point being - Multi-boot may not be a factor because mono-booting a Monterey fresh-install Beta 9 is still broken. Too bad because Beta 9 runs great until it doesn't. ?

 

[Alphamaleunic]

Congrats for installing Monterey on your MacBookAir7,1. I've got a late 2007 Macmini2,1 which is in the list of Macs that WILL NOT BE SUPPORTED in any capacity:
The specs are identical but the 256MB RAM video, Macmini2,1 has 64MB only. I've upgraded to 4GB RAM. Anyone why this wouldn't work with Monterey B8?

Anyone guys? macmini2,1 running Monterey?

 

[houser]

Did you do the NVRAM reset every time you switch OS? Is it necessary?

Well, no as I run a few Macs that need OCLP to run Big Sur also and wanted Multiboot with Big Sur and Monterey beta
as well as Win and Ubuntu on one big SSD, but was unable to make that stable. Worked perfect for a while but after a period disk errors galore on the Mac side. I assume as there was some sharing of the EFI there.
It can probably be done but it does not seem trivial.

 

[Larsvonhier]

Anyone guys? macmini2,1 running Monterey?

Well, no chance with the Merom based C2D in the Mini2,1. You'd at least need a Penryn C2D - which is not available in any socket compatible form. And even then you'd end up with non-accelerated graphics.

 

[cab_007]

Purple & pink static on my MBP internal retina display after 2 hours away from desk. External display was fine. Rebooted, no problem since.

I get a screen full of purple&pink static on mine waking up from sleep, but within 2 secs it restores to normal.

 

[macpro_mid2014]

I have been running multiboot on same SSD with Big Sur and Monterey on and off and it has not been stable for me with repeated corruption in boot and EFI partitions that has required reinstalls. So I gave up on that for now.
It might require some skill in setting up the shared EFI for these two as they currently appear to behave somewhat differently towards OCLP. At least that has been my experience. Multi boot with for example Linux or Windows is different as you can dedicate the EFi for it but I have not found a way for this with Multiboot with Monterey and any other Mac OS. And OCLP does not play with chain booting.
Ah well, if you can comment on how you plan to solve that I would be interested.

Something that just occurred to me: why don't you try to customize the EFI (kext, config, etc.) per macOS?
Create a customized EFI for Big Sur and put it on USB stick 1; then customize EFI for Monterey and put it on USB stick 2; even if both initial EFIs are identical at the beginning.
And every time you switch from one macOS to the other, do an NVRAM reset before booting the other macOS.

I don't know if this makes any sense, but this is something I would try in your situation.