macOS Monterey support

[zearp]

None of the SMBIOS we use will work for it so it may be needed to either patch the installer to get it to work like we do to install macOS on unsupported Macs. Another option is to disable compatibility checks and such but I rather stay away from that route. Yet another option is moving to another SMBIOS (Broadwell) and see how that goes.

The beta can be downloaded right now and I will be testing it out sometime this week. I'm personally still on Catalina because I don't like how Big Sur looks but thats just a taste thing. Big Sur works perfectly fine and my guess is that Monterey will run fine too. How is another question.

I'll be updating this issue with my findings. Feel free to post yours so we can work on a test EFI that can install Monterey on Haswell.

[TheRedHugo]

Someone on Reddit has got macOS Monterey running on a Haswell Processor. Maybe this will help :D https://www.reddit.com/r/hackintosh/comments/num2t6/monterey_installed_oc_065_i54670_rx_580_imacpro11/

He also published his config.plist https://cdn.discordapp.com/attachments/504490016735494145/851580091673739304/config.plist

[zearp]

I see they're using the iMac Pro SMBIOS. I'll have to prepare some empty disks for testing as my machines are running 24/7 on Catalina right now. My little Dell cluster haha. I'm confident it will work, though not all features may work. There's a list at the very bottom of this page.

Just like now some features like SideCar aren't working properly. This is really due to hardware limitations. But Apple doesn't always stop supporting models cuz the hardware can't cope.

A great example of this is Apple dropping support for the iMac 14,3 but keeping 14,4 whilst the latter is a worse specced computer just sold a bit later. Sold as cheaper alternative to the 14,3 model. Apple works in mysterious ways!

Somewhat unusually, rather than "refresh" the entire iMac line with an across the board upgrade of all models, Apple decided to release a new lower-end, cheaper entry-level "Mid-2014" iMac -- source

I'm not too upset about it since staying on 14,3 means you don't get any Big Sur upgrade nags, the ones you can't really disable anymore because Apple also decided to disable the function to ignore upgrades to major OS releases. But thats a whole different rant lol.

[zearp]

It seems just adding -no_compat_check to the boot flags will make the installer boot and install without any issues. After installation this flag can be removed. As far as I know the only time it checks if the model is applicable is when booting into the installer itself.

It is also an option to patch the installer itself and remove the check or add our SMBIOS to allowed list. I prefer not touching the macOS installer itself. Keep the installer vanilla and just disable the check via a boot flag.

Both clean installs and upgrades from either Catalina or Big Sur should work ok. I only tested a clean install and an upgrade from Catalina.

A caveat might be that we don't receive any updates due to the model not being supported but only time will tell. There haven't been any updates to beta 1 yet.

I'm currently waiting for my upgrade to finish. The install seems to take a lot longer than with Catalina. Big Sur also takes its time. I guess this is mainly due to the sealing of the file system which can take forever if you got lots of data on the disk.

More updates to follow but for now seems the boot is the best option after all. I don't really fancy using another SMBIOS, unless there is one for a Haswell machine that is getting Monterey. I don't think any real Mac on Haswell is getting this update and some new features may not work as they either depend on newer cpu features or even M1.

[zearp]

I'm still using SMBIOS 14,3 to stop Big Sur upgrade notifications, but it will work the same for 15,1. I'll have a look at all the Haswell models Apple made and see if any is still getting Monterey support, if so then we can change to that SMBIOS given it does the same h/w wise as the others. Most importantly the iGPU clock speeds which are way too high on some SMBIOS.

All in all this new macOS will run just fine on our machines.

[zearp]

There is as far as I can find only one Haswell Mac that is getting official Monterey support: Mac mini late 2014 aka Macmini7,1 -- I'll have to do some testing, specially the base clocks for iGPU need to be correct. But it is promising and if it's working as well as 14,3 or 15,1 I don't mind moving to that one and then we can stop upgrade nags to Big Sur by using 14,3 or update nags to Monetrey by using 15,1 haha. The only caveat I see is that the Mac mini unlike 14,3 or 15,1 uses a mobile Intel platform. In later models iMacs also use a mobile Intel platform. Not sure if that matters.

[zearp]

Spend some time messing around in a clean install using the Mac mini SMBIOS and all seems very good expect the base clock for the iGPU being 750mhz when idle. This might not be an issue but I prefer it running around 300-350mhz.

Not sure if we should switch to it but at least we have the option to run Monterey without much fuss just by generating a new serial combo and change the SMBIOS. I will add a section to the readme about it though.

I must say the installation time really went up even compared to the already slower Big Sur. It's due to the file system sealing and such but sure takes its time. Then after the install its also not very fast with a bunch of background tasks running. But after an hour or so everything was fine.

[zearp]

Monterey testing branch: https://github.com/zearp/OptiHack/commit/0766e58f4b0310e51e4ae5f8cdf685ee80ca78a8

Current issues are weird graphical glitches when using Screen Sharing (Apple's remote desktop) in windowed mode but its fine in full screen. On the machine itself there are no glitches, it may have to do that I connect to a Monterey machine from Big Sur/Catalina machines. There might be some changes in the underlaying protocol or just bugs haha.

As I still didn't find a DP dongle that can really do 4k @ 60hz I can't do much testing there. But it may be too early for that given we only have beta 1 to go by which even on real Macs has bugs and issues like with wireless and bluetooth.

All in all it looks promising with the Mac mini 7,1 SMBIOS, going to be moving my build stuff to the machine so it will be running VMs and doing compile duties and such. Should be a good real life test.

[zearp]

The windowed-mode Screen Sharing glitches seems to have gone. Undervolting works fine, idle temps look about the same to me. It might run a little bit cooler but that could be due to ambient temps. Performance is on par with the 14,3/15,1 SMBIOS. Don't notice any differences anywhere, all feels about as fast/slow as in Big Sur. I still prefer Catalina myself but it shouldn't be a problem to run Monterey on these cheap little beasts.

I made some changes to the config in the testing branch but nothing major, mostly cosmetics regarding PCI devices and some other stuff. I also got the old MacBook Air cards to work again. It was just a matter of adding AirportBrcmFixup and change the driver it loads by default. I found some of these BCM943224PCIEBT2 cards for $5 on eBay.

Still a pretty good deal if you don't need the speed but do need bluetooth HID proxy to work (I'm a big fan of this feature) or just want 100% native wifi/bt. Without the HID proxy I can't use my bluetooth keyboard to get into the BIOS. They work great in a pci-e converter card that costs twice as much haha.

@mgrimace If you got the time I'd love to hear your experience with the Mac mini SMBIOS and/or Monterey in combination with your 4k screen. The current test branch still uses the old platform-id but can also use the Mac mini 7,1 one which has a different port layout. So might need connectors setup. The Mac mini itself only has a hdmi output. I also wanna look into the other Haswell platform-id's and see if there's something to be had there. One from a model that comes with dual DP connectors would be nice! I'm still bummed out there's no proper DP dummy plug so I can test 4k on a budget.

[zearp]

Found another hdmi to DP plug which seems to be able to use my 4k hdmi dummy when used in the top DP port with nothing in the bottom. Not full DCI 4k but UHD "only" -- maybe this is the best as it can get? Could be a limitation of the hdmi <-> DP converter plug cuz the dummy goes up to 4096x2160.

"4K" refers to horizontal resolutions of around 4,000 pixels. The "K" stands for "kilo" (thousand). As things stand, the majority of 4K displays come with 3840 x 2160 pixel (4K UHDTV) resolution, which is exactly four times the pixel count of full HD displays (1920 x 1080 pixels). There are also 4096 x 2160 pixel (DCI 4K) displays for the film industry that are referred to as 4K displays.

According to Eizo.

I will tinker and try to trim the Framebuffer config as much as possible and then also try the test branch in regards to 4k with Catalina/Big Sur if I got some extra time.

[zearp]

Experiencing some sleep issues. Sleep is prevented a bunch of stuff, lot of background processes, most if not all are iCloud related. It may have to do its post-install "optimisation" stuff before it all works. Bluetooth does sort of work but it is buggy; a few times my paired mouse just disappeared and it was also preventing sleep. No such issues using the same Apple wifi/bt card with Big Sur or Catalina. I don't know if this is a kext/EFI issue or an Apple bug. Beta 2 should be out next week.

[zearp]

Quick update, the sleep issues were caused by one of the PCI devices I added. Added them for cosmetic reasons as functionality wise everything is good. Not sure which one it was or why it causes sleep issues but since they're not needed they're gone now and sleep is working again.

[TheRedHugo]

I'm currently using iMac17,1 in my SMBios and it worked just fine on Monterey, but it's good to know that you can use the boot flag to bypass the compatibility check. But since this is only the first beta of macOS Monterey, could Apple add something to macOS that could block booting if it's detecting an "incompatible" model after the installation or remove the function of the boot flag? I also had an issue, where opening the checkra1n.dmg would result in a kernel panic. I don't know if it has something to do with OpenCore or if it's a MacOS bug. But I switched back to macOS Big Sur since some tools I use don't work on macOS Monterey and because I'm using macOS as a daily driver for school and everything else. Also there's a weird issue that when I plug in my iPad for any use it shows up for a few seconds and then disconnects and repeats it. The only way it worked was by using a USB Hub. When I tried to restore my iPhone it keept being connected but errors out when I try to restore it, unless I use a USB Hub. It's not just Monterey, but also Big Sur and Catalina. I don't know if this really fits in here but I wanted to share my experience with macOS on the Dell Optiplex 7020 :D

[zearp]

The iMac17,1 SMBIOS is for Skylake platform. Which shouldn't be an issue in theory but it's best to use one that matches your platform for the 7020 that's Haswell. Only one Haswell based Mac is getting Monterey as far as I could find out. The Mac mini7,1. Disabling compatibility checks is not needed if the SMBIOS you used is supported by Monterey. I would only use that when there's no other way to install. Luckily the Mac mini SMBIOS works perfectly and is from a Mac with a Haswell cpu.

SMBIOS does a lot of things I don't know about but it does regulate for example the base clock speed of the iGPU. I also think it does voltages and such. So I always try to stay within the same platform if possible. If only to prevent weird issues from any platform specific stuff Apple could be doing.

I've not experienced any panics with jailbreaking my iPhone, so I don't know why that happens to you. The panic log should lead to come clues about it. Did you keep it around?

The iPad getting in some kind of charge-loop is a weird and hard one to crack indeed. I've also experienced it and thought it could be a current thing and tried experimenting with them here but it didn't fix anything. Maybe it needs something done at ACPI/BIOPS level. Didn't find anything relating to power and currents hidden in the BIOS so maybe some custom ACPI patch can solve it. But first have to find out what's actually going on lol.

When having the iPad system log open in the Console app the same block is spammed over and over when it cycles the charge state but nothing useful in there to me.

default 02:25:46.644645+0200    wifid   manager->wow.lpasSetting 1 CFSetGetCount(manager->wow.wowClients) 2 isWowActivityRegistered=0 manager->wow.overrideWoWState 0 manager->externalPower 1 manager->iokit.battery.chargeLevel 67
default 02:25:46.645087+0200    wifid   Posting metrics for AJ
default 02:25:46.645195+0200    wifid   External power state is 1
default 02:25:46.645498+0200    wifid   External power state is same as before 1, bailing out
default 02:25:46.645858+0200    thermalmonitord <Notice> Charger type is 10
default 02:25:46.645967+0200    powerd  posted 'com.apple.system.powermanagement.poweradapter'
default 02:25:46.650893+0200    sharingd    Sync action handler called
default 02:25:46.651004+0200    sharingd    Default paired device: no
default 02:25:46.651036+0200    UserEventAgent  handle battery state update: isExtChg=1->1, enableHalogenMitigationsAndUI 1
default 02:25:46.651053+0200    UserEventAgent  _hook_currentLimitChanged() called!
default 02:25:46.651072+0200    UserEventAgent  _hook_currentLimitChanged: (usbCurrentLimitMA: 1200ma, previousUSBCurrentLimitMA: 1100ma)
default 02:25:46.651484+0200    locationd   {"msg":"adapter details", "adapterDescription":"usb host", "batteryChargerType":"kChargerTypeUsb", "level":67, "family":3758112768, "fullyCharged":0}
default 02:25:46.651659+0200    wifid   manager->wow.lpasSetting 1 CFSetGetCount(manager->wow.wowClients) 2 isWowActivityRegistered=0 manager->wow.overrideWoWState 0 manager->externalPower 1 manager->iokit.battery.chargeLevel 67

The only change is the current itself. It fluctuates between a few numbers, you can try this and see if you get similar results.

default 02:21:01.515808+0200    UserEventAgent  _hook_currentLimitChanged: (usbCurrentLimitMA: 1900ma, previousUSBCurrentLimitMA: 1800ma)

If I charge my iPhone or iPad on a power bank that shows current draw they both draw about the same voltage and amps so really odd the iPad is making a fuss and the iPhone isn't, and only when connected directly. It might be some kind of communication mess up when it negotiates the power and such. Which explains why it works with a hub in between. I really didn't do much research into it but I would guess others have ran into this issue too and might have found a fix.

[zearp]

I think I found the cause. As always it's something I only test cuz it happens too often: cables.

I got 3 original lightening cables from my drawer. They all came with retail iDevice I got over the years. 1 out of 3 cables give me the charge cycling, two work fine.

If you have other cables please try with those and let me know. Also try both front and back ports. Either way the usb power thing is a bit off topic in here but I think Monterey support is pretty much sorted other than some fine tuning and waiting for beta 2. Been using it on my build machine for a few days now without issues.