macOS 12 Monterey on Unsupported Macs Thread

[mwidjaya]

seems like in some cases installing an unsupported macOS like Monterey alongside a supported one, simply on a different volume will work

It works until it doesn't...

Put it this way, I would not be running an iMac in that state, like @algernonpule.

APFS is optimised for SSD and fusion drive is known to be slow for modern macOS.

- invest in an external SSD for running latest macOS (eg. unsupported ones like Monterey using OCLP)
- keep the supported macOS for that iMac on the factory fusion drive
- possibly un-fuse the fusion drive (120GB SSD is sufficient to run Catalina)
- 1TB HDD can act as internal back up drive (maybe time machine use)

 

[Tockman]

.

 

[makra]

If you still have the hard disk, it is so easy to place it back on a 2012 MBP.

So you're saying, that just the physical disk does it? Although it's been reformatted?

 

[Jean_JD]

Hello.
I have a problem with Monterey or Big Sur on my iMac 14.2.
When the system is post-patched (new System Snapshot created as boot system) create a clone with CCC, SuperDuper or asr command is impossible (error 49197).

The state of play

The list of System Snapshots :

diskutil ap listsnapshots /

Snapshots for disk9s2s1 (2 found)
|
+-- A9742E48-FB1B-4566-9EEA-2CDE0CB68E0F
| Name: com.apple.os.update-52789EBE26897E601E6D85ED97C1C94E59D8181D900028E5CAA085F2339E524E
| XID: 49
| Purgeable: No
|
+-- D64BBC99-2B81-4B66-9F33-9882FB5B7C3D
| Name: com.apple.bless.D68BB6D7-D6B9-452E-A352-237149B7AB1F
| XID: 3292 (Will root to (boot from) this snapshot)
| Purgeable: Yes
| NOTE: This snapshot limits the minimum size of APFS Container disk9
|

The thirst one has been created by the System installation without post-install patch.
The second has been created by the post-install system patcher. We can see that apart from the name the big difference is the purgeable status to yes.

Now trying clone the system :

sudo asr --source /dev/disk9s2s1 --target /dev/disk11 --erase

Password:
Validating target...done
Validating source...done
Erase contents of /dev/disk11 ()? [ny]: y
Replicating Volume replication failed - erreur 49197

Other test with the SnapshotName :

sudo asr --source /dev/disk9s2 -toSnapshot com.apple.bless.D68BB6D7-D6B9-452E-A352-237149B7AB1F --target /dev/disk11 --erase

Password:
Validating target...done
Validating source...done
Erase contents of /dev/disk11 ()? [ny]: y
Replicating Volume replication failed - erreur 49197

The right test with the original Snapshot :

sudo asr --source /dev/disk9s2 -toSnapshot com.apple.os.update-52789EBE26897E601E6D85ED97C1C94E59D8181D900028E5CAA085F2339E524E --target /dev/disk11 --erase

Password:
Validating target...done
Validating source...done
Erase contents of /dev/disk11 ()? [ny]: y
Replicating ....10....20....30....40....50....60....70....80....90....100
Replicating ....10....20....30....40....50....60....70....80....90....100
Restored target device is /dev/disk11s2.
Restore completed successfully.

What's work to clone, but don't boot on the target system.

Someone as the same problem?

Thanks for reading me.


Resolved


Trying boot -> give message ending with "Waiting for remote debugger connection.".
So booting on original Monterey I've try recreate the system Snapshot on the cloned volume :
1) mount the System Volume (the one without - Data extention)

diskutil mount /diskXsY

2) mount it in RW mode :

sudo mount -uw /Volumes/Clone_Name

3) create the Snapshot (in verbose mode to verifie) :

sudo bless --folder /Volumes/Clone_Name/System/Library/CoreServices  --bootefi --create--snapshot  --verbose

And the cloned System boot well.

That I've not found is how to rename the Clone name in EFI boot choice.

 

[hwojtek]

I believe this is exactly what Mike Bombich describes in his CCC notes regarding bootable clones in Big Sur and later. Please note you can make the backup bootable by reinstalling the MacOS from USB to the backup disk.

 

[Jean_JD]

I believe this is exactly what Mike Bombich describes in his CCC notes regarding bootable clones in Big Sur and later. Please note you can make the backup bootable by reinstalling the MacOS from USB to the backup disk.

Yes I know that, but I've no problem with asr or CCC cloning on a Big Sur or Monterey "OCLP" not "post-install" patched.
I think there is a problem with the System Snapshot created with bless or apfs_systemsnapshot (/System/Library/Filesystems/apfs.fs/Contents/Resources).

 

[hvds]

I believe this is exactly what Mike Bombich describes in his CCC notes regarding bootable clones in Big Sur and later. Please note you can make the backup bootable by reinstalling the MacOS from USB to the backup disk.

Yes, that works well.
Usually I do „clean“ installs this way. Make a CCC data clone to an erased disk and then install macOS on it. As an alternative to a really clean install with migration.

 

[mwidjaya]

Yes I know that, but I've no problem with asr or CCC cloning on a Big Sur or Monterey "OCLP" not "post-install" patched.

Just a stab in the dark.

The OCLP root patch (post install) breaks the SSV. Only Apple has the private key to sign it proper.

With broken SSV, will that cause issue with asr?

 

[thatguywill]

make sure you use the latest OCLP release version: which is 0.4.2 for now.

My problem too, I found it crashing less on OCLP 0.4.2. Still happening occasionally mind

 

[samiqa]

Monterey 12.2.1 OCLP 0.4.2

I have a problem with NVRAM boot args
I can use the nvram command in terminal without errors like read/write " SIP disabled"
my default boot args built with OCLP "keepsyms=1 debug=0x100 -v"
when I run this commands :
sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"

or

sudo nvram boot-args="keepsyms=1 debug=0x100 -v serverperfmode=1"

Immediately i run nvram -p I can see : boot-args keepsyms=1 debug=0x100 -v serverperfmode=1

after reboot and running nvram -p :

boot-args keepsyms=1 debug=0x100 -v

the new argument serverperfmode=1 is not saved !

do I have to edit my nvram boot-args in different way with OCLP ? is there a file that I need to edit ??

thanks

 

[K two]

Update to macOS 12.2.1 atop 12.2 OTA via OCLP_043N, hands-free on it's very own partition. Runs better than expected.

 

[alphascorp]

Monterey 12.2.1 OCLP 0.4.2

I have a problem with NVRAM boot args
I can use the nvram command in terminal without errors like read/write " SIP disabled"
my default boot args built with OCLP "keepsyms=1 debug=0x100 -v"
when I run this commands :
sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"

or

sudo nvram boot-args="keepsyms=1 debug=0x100 -v serverperfmode=1"

Immediately i run nvram -p I can see : boot-args keepsyms=1 debug=0x100 -v serverperfmode=1

after reboot and running nvram -p :

boot-args keepsyms=1 debug=0x100 -v

the new argument serverperfmode=1 is not saved !

do I have to edit my nvram boot-args in different way with OCLP ? is there a file that I need to edit ??

thanks

Hi
Maybe you should add the argument in the OCLP config.plist
Like this:

<key>NVRAM</key>
    <dict>
        <key>Add</key>
        <dict>
            …

                <key>boot-args</key>
                <string>keepsyms=1 debug=0x100 -v serverperfmode=1</string>
                …

 

[JoinMeinHeaven]

Is there a problem with Monterrey 12.3 ? It's very odd the lack of people in this update

 

[hvds]

Is there a problem with Monterrey 12.3 ? It's very odd the lack of people in this update

12.3b2 working fine on MBP5,2. Used it with OCLP 0.4.2 and with latest 0.4.3n.
The 12.2.1 release may distract a little from this beta.

 

[serafin79]

anyone else having iMessage crash using nightly OCLP on 12.2.1
I'm on MBP 8,1

Thanks,

 

[5tracks]

The notes are fine, but I can see how someone without good computer knowledge may have trouble understanding.

One way to put it:

a. Spoofing - present as a newer mac, that is supported for newer macOS
Newer mac have different HW config, so patching has to overcome that and make sure correct software bits are turn on for the older HW.

b. Spoof-less - hide behind VM install mode
Present underlying HW as is. Software bits get correctly turn on.

In both approach, root patching(post install) is still required if correct software bits are already removed from newer macOS package.

Overall, spoof-less is a more elegant solution, which is why OCLP devs have adopted it.

Don't overthink it.

Thanks for distilling it down for a dummy like me?

So the bottom line is what I was thinking originally, it’s just a different solution to the same problem. One is not really better than the other; if everything works with spoofing there’s no reason to switch.

 

[K two]

Is there a problem with Monterrey 12.3 ? It's very odd the lack of people in this update

macOS 12.3b2 runs as expected but contains some significant changes which may not function on some unsupported Macs.

Shown is b1 before the update to b2. Uses more overhead compared to 12.2, 4GB machines will need more RAM. ?

 

[rehkram]

Hello,
We have the same computer and basic setup so as SilenKnight says there is a later EFI version:
Mac model MacBookPro10,1
EFI version found 421.0.0.0.0
expected 425.0.0.0.0

Are you seeing the same or do you have the expected 425.0.0.0.0 EFI? If so did you run a firmware updater?
My system is running ok, so just curious if I should look at that.

Cool, yes, Silent Knight finds exactly the same exception on mine. That sent me on a search for more info on firmware versions. No resolution as yet; I'm wondering on how to force a firmware upgrade to 425.0.0.0.0

I'd be prepared to blow the disk away and clean install if it makes sense to do so. I found some blog posts from Howard (the Silent Knight developer) on his excellent site but they were discussing things pre-Monterey.

Maybe I should wait for a new macOS release- or security update carrying a firmware update.

Another exception flagged was SIP. It's saying "SIP enabled, SSV disabled".
csrutil status says "custom configuration" (i.e. status not immediately determinable), with these detail settings:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled. ... all others enabled. I have installed the OCLP post install patches.

Same for you?

 

[K two]

anyone else having iMessage crash using nightly OCLP on 12.2.1
I'm on MBP 8,1

Thanks,

Edit - Can confirm Messages indeed crashes but restarts OK, runs until it re-crashes, later. Attached is a grab of the crashlog, a portion anyway. Looks like the Catalyst fixes may be involved?

 

[shafez]

I am done with Monterey, back safely to Big Sur, Volume Hash Mismatch did it.
Can't stand it happening in the middle of work, application stops responding and have to restart.

 

[samiqa]

Hi
Maybe you should add the argument in the OCLP config.plist
Like this:

<key>NVRAM</key>
    <dict>
        <key>Add</key>
        <dict>
            …

                <key>boot-args</key>
                <string>keepsyms=1 debug=0x100 -v serverperfmode=1</string>
                …

editing the config.plist make oclp refuse to install and showing error messages about the config.

if editing the already installed file the changes not respected.

 

[Ausdauersportler]

editing the config.plist make oclp refuse to install and showing error messages about the config.

What a weird approach! The config.plist is generated from a template on the fly after running some hardware detection. So the template will be changed in any case.

if editing the already installed file the changes not respected.

This may be true for you, but I do exactly this all the time since OCLP has been published and it works perfectly. And this is the only way to change the working config.

Are you sure to have only a single OC instance installed within a single unique EFI partition on your system?

 

[cab_007]

Cool, yes, Silent Knight finds exactly the same exception on mine. That sent me on a search for more info on firmware versions. No resolution as yet; I'm wondering on how to force a firmware upgrade to 425.0.0.0.0

I'd be prepared to blow the disk away and clean install if it makes sense to do so. I found some blog posts from Howard (the Silent Knight developer) on his excellent site but they were discussing things pre-Monterey.

Maybe I should wait for a new macOS release- or security update carrying a firmware update.

Another exception flagged was SIP. It's saying "SIP enabled, SSV disabled".
csrutil status says "custom configuration" (i.e. status not immediately determinable), with these detail settings:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled. ... all others enabled. I have installed the OCLP post install patches.

Same for you?

Same for my 10,1 though I'm on an even older firmware 262.0.0.0.0. Please post back when you figure out how to update, I'm planning to install the latest "Supported" (at least officially) of Catalina on a USB to see if it'll update my firmware which may not work since its not the built in ssd.

 

[headlessmike]

I am done with Monterey, back safely to Big Sur, Volume Hash Mismatch did it.
Can't stand it happening in the middle of work, application stops responding and have to restart.

The Hash Mismatch seems to occur somewhat randomly, irrespective of OS. I’ve had it on different machines under both Big Sur and Monterey. It never caused any noticeable problems though, other than a nagging notification every time I woke up a machine with the issue.

 

[shafez]

The Hash Mismatch seems to occur somewhat randomly, irrespective of OS. I’ve had it on different machines under both Big Sur and Monterey. It never caused any noticeable problems though, other than a nagging notification every time I woke up a machine with the issue.

I never had this before Monterey, it stops app responding and have to restart to fix the problem. Unfortunately usually looses unsaved data.
Anyways, not much difference between Big Sur and Monterey for my late 2013 MBP, just few cosmetic changes.