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.
K two - i have similar machine laying in my closet :) Do you think it will be good, stable enough to use it a server and some browsing ? Thank you !
With three Mini3,1 some usefully running ANY version of MacOS or OSX from Snow Leopard to Monterey (see the signature below), the answer is yes. At this writing, Big Sur may be the best choice as Monterey is a WIP but still completely useful, nevertheless. Recommend a SSD and at least 6GB RAM, no matter what macOS chosen. ;)
 
Last edited:
  • Like
Reactions: dwnldr and rehkram
With three Mini3,1 all usefully running ANY version of MacOS or OSX from Snow Leopard to Monterey (see the signature below), the answer is yes. At this writing, Big Sur may be the best choice as Monterey is still a WIP but still completely useful. Recommend a SSD and at least 6GB RAM, no matter what macOS chosen. ;)
Well alrighty then. Time for me also to dig out the old mini I have in a box in the spare room.
 
  • Like
Reactions: K two
There have been "over the top" Monterey installs that have failed; I had two of them. The major symptom of this is when the installation completes its final reboot you find the machine is still on Big Sur 11.6.1. Could be worse, at least the machine is still running, and no rollback is required.

I had to do clean installs to get to Monterey 12.0.1. There are various theories as to why this happens, one possibility is not enough space on the drive, but I had plenty.
Have you tried a fresh OCLP install then shut-down to cold-boot then <control> select OCLP with the target boot disk previouly selected in the Startup Disk CP? Stopped the loopdeloop, here. YMMV :cool:
 
  • Like
Reactions: rehkram
Have you tried a fresh OCLP install then shut-down to cold-boot then <control> select OCLP with the target boot disk previouly selected in the Startup Disk CP? Stopped the loopdeloop, here. YMMV :cool:
Thank you. I did not think to try that, will do so next time it (or something similar) happens.

After finally getting it installed 12.0.1 has been very stable so far, touch wood. I'm holding off installing any more beta Montereys on my unsupported m/c until OCLP with the monteRAND patch goes GA (as opposed to grabbing a nightly build).
 
  • Like
Reactions: K two
Thank you. I did not think to try that, will do so next time it (or something similar) happens.

After finally getting it installed 12.0.1 has been very stable so far, touch wood. I'm holding off installing any more beta Montereys on my unsupported m/c until OCLP with the monteRAND patch goes GA (as opposed to grabbing a nightly build).
macOS 12.1b2 does not require the rdrand (monteRAND) ?version, only b1. App memory management improved, noticeably in macOS 12.1, btw. :cool:
 
Will do and report back! Thanks
Finally got to boot in verbose mode and I was wrong: It does not take 2 minutes to boot but actually 4:30 minutes :)

Just as a brief recap: Mid 2012 10,1 15” Retina MacBook Pro running 12.0.1. Used Micropatcher for BigSur and now switched over to OCLP for Monterey. Did not install over but created new partition for Monterey. Once booted everything is super snappy and fast. Just the bootup takes „forever“.

Attaching screenshots with timeout errors. Here are some that stand out at first glance:

ACPI Error: Method parse/execution failed…
ACPI Error… Namespace lookup failure, AE_NOT_FOUND…
HE2N_Key Does Not Exist

disk1s3:device is not readable

busy timeout [8], (60s): ‘SDXC’


Appreciate your guys‘ help with this!
 

Attachments

  • C1211AC2-6F14-4A7A-99C2-5C40F65AB5C6.jpeg
    C1211AC2-6F14-4A7A-99C2-5C40F65AB5C6.jpeg
    747.3 KB · Views: 82
  • 4CCB7AD6-AB24-454A-B284-C71D2C9E2952.jpeg
    4CCB7AD6-AB24-454A-B284-C71D2C9E2952.jpeg
    1.1 MB · Views: 71
Last edited:
There have been "over the top" Monterey installs that have failed; I had two of them. The major symptom of this is when the installation completes its final reboot you find the machine is still on Big Sur 11.6.1. Could be worse, at least the machine is still running, and no rollback is required.

I had to do clean installs to get to Monterey 12.0.1. There are various theories as to why this happens, one possibility is not enough space on the drive, but I had plenty.

I had this happen to me when testing Monterey, but only on an external SSD, never the internal drive. I've always suspected that it has to do with the wrong partition being chosen when the system performs a reboot during the upgrade process. The update (as well as the clean installation) creates what appears to be a temporary partition that is used as the installation media during the install process. But if this partition is not chosen at boot time then the system boots the default OS partition. After a prolonged wait the systems seems to wipe any traces of the attempted system update. I've managed to get around this issue by waiting for the partition selection screen to show up in OCLP when the system reboots for the first time, there choosing the installation partition, after which to installation proceeds as normal. Never once have I been low on drive space. But perhaps I misunderstood the failures you were referring to.
 
  • Like
Reactions: rehkram and K two
?AHOY! macOS 12.1b2, OCLP_032 current nightly and BRCM2046 Macs w/Apple Bluetooth KB. Caps_lock light and battery gauge now work as intended. However, BT only becomes functional with the Desktop, absent during OpenCanopy. The Apple B/T KB is now completely functional after BT runs. An appreciated BIG improvement. :)
 
Last edited:
  • Like
Reactions: pippox0 and hvds
I had this happen to me when testing Monterey, but only on an external SSD, never the internal drive. I've always suspected that it has to do with the wrong partition being chosen when the system performs a reboot during the upgrade process. The update (as well as the clean installation) creates what appears to be a temporary partition that is used as the installation media during the install process. But if this partition is not chosen at boot time then the system boots the default OS partition. After a prolonged wait the systems seems to wipe any traces of the attempted system update. I've managed to get around this issue by waiting for the partition selection screen to show up in OCLP when the system reboots for the first time, there choosing the installation partition, after which to installation proceeds as normal. Never once have I been low on drive space. But perhaps I misunderstood the failures you were referring to.
A correctly installed OCLP will only boot from the Startup Disk CP selection if unattended. ;)
 
I tried 12.0.1. - do you see a chance that b1 has solved HASH MISMATCH issue in APFS?
This issue happens even on supported system starting approximately with Big Sur 11.3. If you get only the message you may ignore it. Neither reinstallation nor complete recreating of all APFS file systems could solve this. There might be a connection to FeatureUnlock. But even this is still under observation. If apps start to crash the sudo purge command from the terminal app may help.

Checking the open and closed issues on GitHub and searching this thread could have lead you to the same information.
 
Last edited:
The "hash mismatch" message seems like a spurious error. I've seen it a few times on Big Sur releases and (I think) once on Monterey. Nothing has ever come of it, so far. Being cautious, I do a cold restart after getting it.
 
  • Like
Reactions: hvds and K two
I am using my iMac12,2 right now and noticed the location services are not working, like the default Apple Maps, Weather widget, etc. It worked 12 hours ago (the weather widget). The location services are enabled in Privacy settings.
Note1: I've never checked this before the upgrade to K3100M card. And I've not checked on my other 2 iMacs. Just wonder if this is a known issue, or only my iMac12.2?
Note2: using latest OCLP 0.3.2n, no spoofing.

Add: After clicking the WiFi icon on the menu bar, the location services are back in business? It might have been related to the fact that this iMac is also connected with an Ethernet cable to a router.
 
Last edited:
Im starting to think this issue is correlated to the process mds since it always is on fail reports from the turn on onwards View attachment 1909150
I've seen this mds crash a few months ago running Big Sur / Monterey with pre-Metal graphics iMac. "mds" is for indexing function. By disabling index may help preventing the frequent crash. But I never bothered looking into it because there was no much point for me to run Big Sur / Monterey with these Macs: too sluggish for some default apps like Messages, etc.
 
Last edited:
  • Like
Reactions: JoinMeinHeaven
This is really incredible, many thanks for still working on making it a more perfect GUI experience for us pre-Metal GPU Mac owners. It works nicely using the current nightly build on my MBP4,1.
I'd concur your sentiment. It would be even better if @ASentientBot can fix the sluggish Messages app issue with pre-Metal GPU Macs so that my iMac10,1 with GeForce 9400 can also run Big Sur / Monterey.
P.S. I really need the Messages app, which is one of the main reasons for me to start learning macOS since earlier this year.
 
I'd concur your sentiment. It would be even better if @ASentientBot can fix the sluggish Messages app issue with pre-Metal GPU Macs so that my iMac10,1 with GeForce 9400 can also run Big Sur / Monterey.
P.S. I really need the Messages app, which is one of the main reasons for me to start learning macOS since earlier this year.
There may be other problems with that iMac? On a 2 GHz Mini with the same GPU, Messages performs as expected w/o issues. Use it numerous times, daily. :cool:
 
  • Like
Reactions: hvds and TigerA
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.