Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 10.14 Mojave on Unsupported Macs Thread
- Thread starter dosdude1
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
The instructions are on the page but the "installation" requires that user can operate in the terminal. Even if you are not, just read and follow instructions and you should be fine. Basically you are going to open terminal, use terminal to backup existing UI files, copy over the moded UI files (change names to what the original files were named), and then reboot.
@jackluke and @ASentientBot
Compared .4 and .5beta (latest - 18F108f) GPUWrangler binaries. There is only one 4 byte difference in the code and it has to do with Framebuffers. Specifically the following call: "_GPUWranglerGPUGetFramebufferRegistryEntryID:"
From my read, it compares its own Wrangler GPU Type ID to one that CF (Core Foundation) returns and computes and ID or 0. The computation between .4 and .5 is a little different. Attached are the Hopper (v4.5.9) disassemblies. and respective pseudo-codes. Worth taking a look at or just a red herring? What do you think? This should have some bearing on gpu acceleration decision logic.
[doublepost=1554833009][/doublepost]
Compared .4 and .5beta (latest - 18F108f) GPUWrangler binaries. There is only one 4 byte difference in the code and it has to do with Framebuffers. Specifically the following call: "_GPUWranglerGPUGetFramebufferRegistryEntryID:"
From my read, it compares its own Wrangler GPU Type ID to one that CF (Core Foundation) returns and computes and ID or 0. The computation between .4 and .5 is a little different. Attached are the Hopper (v4.5.9) disassemblies. and respective pseudo-codes. Worth taking a look at or just a red herring? What do you think? This should have some bearing on gpu acceleration decision logic.
[doublepost=1554833009][/doublepost]
I wouldn't bet on it. At first blush, this is meant to control third party app/extension development/customization and non-AppStore distributed apps. I think it stinks and may not bode well for us. I hope I'm wrong.
That's cool news. Thank you! Will try and report back...
EDIT:
Modified the plist to include the MB4,1, started the machine with enabled flash access (long press, blinking LED) and patched the ROM. Reboot, voila, works as advertised!
Last edited:
Infact when I downgrade the GPUWrangler on a metal mac it cuts off the Metal Acceleration too, so is used only GPU Framebuffer, but I guess there is also some kind other matching check with AGC kext mostly its plugins as AGDC , AGDP and AppleMuxControl (for dual GPUs systems).
But for sure we can consider "valid" for legacy OpenGL acceleration all the .4 kexts and frameworks.
I got also on .5beta2 some unresolved symbol about "getFramebuffer" if I use the stock .5beta2 AGDP kext and AMC kext, they still boot but without Framebuffer so as a "safe mode" GPU lets say.
I also noticed that downgrading those kext, allow me to prelink the Framebuffer and the brightness control HUD does show and work but backlight LCD remains the same (maybe this AGDCBacklightControl.kext?).
So apparently it worked better with .5 beta1.
Last edited:
Thanks, but it does nothing. I'm just curious about where this unpatched version comes from at boot. I'm running a raid0 APFS volume with two SSD disks partitioned as follow:
Code:
diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *240.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_RAID 239.7 GB disk0s2
3: Apple_Boot Boot OS X 134.2 MB disk0s3
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *240.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_RAID 239.7 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +479.4 GB disk2
1: EFI 209.7 MB disk2s1
2: Apple_APFS Container disk3 479.2 GB disk2s2
/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +479.2 GB disk3
Physical Store disk2s2
1: APFS Volume MacDisk 163.9 GB disk3s1
2: APFS Volume Preboot 44.7 MB disk3s2
3: APFS Volume Recovery 513.9 MB disk3s3
4: APFS Volume VM 4.3 GB disk3s4--EDITED: PROBLEM SOLVED--
I added my solution to the updated original post.
Last edited:
In 10.14.5b2 all my unsigned or self-signed kexts still load with SIP turned off, so it seems to be coupled to SIP.
That would be great. Do we know if it’s implemented/enforced in the betas?
[doublepost=1554840528][/doublepost]
Do you know where you got the invalid symbol? Do you have a log?
I don't think have a log of this, since I got them just before verbose lines "IOConsoleUsers lockstate", this "_Z15agdcGTraceTokenPK13IOFramebuffertbthtytyty" both from AppleGraphicsDevicePolicy and AppleMuxControl .5 beta2 but boot continues without Framebuffer, if I use .4 ones symbol resolved, Framebuffer detected but still no OpenGL accel.
I noticed also CoreFoundation.framework dependency with OpenGL.framework.
Last edited:
I was wondering, do the new hybrid mode patches fix the dark mode corner graphics anomalies? thanks a lot.
Hi all , a HYBRID MODE UPDATE (transparency and vibrancy fixes for Mojave Light Mode)...
Mojave 10.14.3 and 10.14.4 compatible Hybrid Mode updates are now available for download:
For 10.14.4 : https://github.com/SpiraMira/HybridMode-Public/releases/latest
For 10.14.3 : https://github.com/SpiraMira/HybridMode-Public/tree/v1.4.2
All the gory details screenshots , credits and installation (+recovery) instructions are available here as usual:
https://github.com/SpiraMira/HybridMode-Public
Hybrid Light Mode with vibrancy
Hybrid Dark Mode with vibrancy
NOTE: not everything was (or can be) fixed and some trade offs had to be made that affected mostly the menu bar across both Light and Dark Mode. Still in a work in progress...
Enjoy.
Mojave 10.14.3 and 10.14.4 compatible Hybrid Mode updates are now available for download:
For 10.14.4 : https://github.com/SpiraMira/HybridMode-Public/releases/latest
For 10.14.3 : https://github.com/SpiraMira/HybridMode-Public/tree/v1.4.2
All the gory details screenshots , credits and installation (+recovery) instructions are available here as usual:
https://github.com/SpiraMira/HybridMode-Public
Hybrid Light Mode with vibrancy
Hybrid Dark Mode with vibrancy
NOTE: not everything was (or can be) fixed and some trade offs had to be made that affected mostly the menu bar across both Light and Dark Mode. Still in a work in progress...
Enjoy.
Yes a lot of dependencies everywhere
Which machine are you testing on? I think you're currently at the stage of "no acceleration in any configuration" but bootable with the .5 wrangler but no graphics - bootable with .4 wrangler on single gpu machine but just framebuffer. Both configurations hand crafted without using the patcher...I've probably got that all wrong but just trying to keep things straight
Do I upgrade...or not?? I have a MB Air 3,1 that has been upgraded to 10.14.3 using Dosedude1's patcher. I watch this forum and see lots of users having issues with .4 and reverting back to .3 for stability. Is upgrading to .4 problem free on the MBA? My Mac skill level allows me to follow directions such as with Dosedude1's patcher. It does NOT allow me to mess with Terminal or do stuff where you actually have to know what you're doing. Should I leap to .4 or just hold here at .3. Thanks in advance for your thoughts.
My Mac mini 5.1 (mid 2011) shut down unexpectedly today, if there is a log or something some one wants to see to help them diagnose, or to fix a potential problem, let me know. It restarted fine and so far, no problems.
Mac mini 3,1 & Kernel Panics update
I have now done 3 different Late 2009 Mac mini's, 2 with APFS SSD's and 1 with HFS 5400 RPM's
I was the first to post feedback about the KP's so many experienced, after updating to 10.14.4 Post #13159
on Page 527, and Post #13172
So
Thought I would provide an update on what has thoroughly worked, to bring 2 of the 3 Mac mini 3.1's to a super stable state of 10.14.4. The third mini now seems stable, but something seems off, because of the very long boot up time.
On the first mini w/APFS SSD & replaced Wifi module, that was crashing every 10 to 15 minutes like clockwork, I ran the Onyx utility Maintenance option, inclusive of ticking on Spotlight Index, and under cleaning options, ticking on, Saved application states, Audio units plug-ins cache & Java/Java applets cache
After reboot, re-applied patches from tool, and force rebuild cache
I just checked iStat menus and my daily grinder has been up and running 13 days, 11 hours without even a hiccup. & Beautifully smooth with SSD and 8GB Ram.
On the second Mac mini w/HFS 5400 and original Broadcom BCM4321 module, I had to do Two complete rounds of the above. This second Mac mini had two user accounts. One Admin, One Standard. ...and there was something weird going on, ....when logging into the primary user, Standard account, then came the subsequent crashes. While the little used Admin account, seemed stable. I decided to change the Standard to an Admin account for the primary user, and delete the original Admin account. Ran the Onyx routine & Tool re-patch, and that Mac mini has been rock solid going on 8 continuous, daily-machine days.
On a third Mac mini, w/APFS SSD & replaced wifi module, I have run the above Onyx/Patch re-apply routine 3 complete times and while the mini has not KP'd in 2 days, I ran it the third time because it took So Long for every boot up. ...really long for an SSD machine. ....like ~8 minutes. ...But after the last, very long boot up, I left it alone and it has been stable for 2 days. Primary use is VMware running Windows 10 tax software & Teamviewer to a Windows machine running tax software. It supports dual displays with one display streaming DirecTV smoothly while the other display is VMWare/Windows and Teamviewer working smoothly.
I am starting to think the very, very long boot up time, is due to a very cramped 500GB SSD
Anyway, don't give up on those trusty Mini's and Mojave 10.14.4
Of course, I wait eagerly for @dosdude1 revisions/improvements of the patches, to better support the install of 10.14.4 and beyond !! ...THANK YOU. ..and thank you to All, who have contributed.
I have now done 3 different Late 2009 Mac mini's, 2 with APFS SSD's and 1 with HFS 5400 RPM's
I was the first to post feedback about the KP's so many experienced, after updating to 10.14.4 Post #13159
on Page 527, and Post #13172
So
Thought I would provide an update on what has thoroughly worked, to bring 2 of the 3 Mac mini 3.1's to a super stable state of 10.14.4. The third mini now seems stable, but something seems off, because of the very long boot up time.
On the first mini w/APFS SSD & replaced Wifi module, that was crashing every 10 to 15 minutes like clockwork, I ran the Onyx utility Maintenance option, inclusive of ticking on Spotlight Index, and under cleaning options, ticking on, Saved application states, Audio units plug-ins cache & Java/Java applets cache
After reboot, re-applied patches from tool, and force rebuild cache
I just checked iStat menus and my daily grinder has been up and running 13 days, 11 hours without even a hiccup. & Beautifully smooth with SSD and 8GB Ram.
On the second Mac mini w/HFS 5400 and original Broadcom BCM4321 module, I had to do Two complete rounds of the above. This second Mac mini had two user accounts. One Admin, One Standard. ...and there was something weird going on, ....when logging into the primary user, Standard account, then came the subsequent crashes. While the little used Admin account, seemed stable. I decided to change the Standard to an Admin account for the primary user, and delete the original Admin account. Ran the Onyx routine & Tool re-patch, and that Mac mini has been rock solid going on 8 continuous, daily-machine days.
On a third Mac mini, w/APFS SSD & replaced wifi module, I have run the above Onyx/Patch re-apply routine 3 complete times and while the mini has not KP'd in 2 days, I ran it the third time because it took So Long for every boot up. ...really long for an SSD machine. ....like ~8 minutes. ...But after the last, very long boot up, I left it alone and it has been stable for 2 days. Primary use is VMware running Windows 10 tax software & Teamviewer to a Windows machine running tax software. It supports dual displays with one display streaming DirecTV smoothly while the other display is VMWare/Windows and Teamviewer working smoothly.
I am starting to think the very, very long boot up time, is due to a very cramped 500GB SSD
Anyway, don't give up on those trusty Mini's and Mojave 10.14.4
Of course, I wait eagerly for @dosdude1 revisions/improvements of the patches, to better support the install of 10.14.4 and beyond !! ...THANK YOU. ..and thank you to All, who have contributed.
you can reinstall 10.14.3 over the top of 10.14.4 without losing your data
Hi - would love to but my only "unsupported" test box is dedicated to .3 and .4 hybrid mode development right now. So I simply download .5 distributions and static analyze to see if I can help. Will probably migrate to a .5 beta next week sometime.Just play around with the if .. else statement, flip output and see what happens....
Greetings all...I have a question regarding MIDI:
I have a 3,1 Mac Pro and thanks to dosdude1's patcher I successfully updated from El Capitan to High Sierra last month. I use Logic Pro for music and wanted to move up to the latest version, which left El Capitan behind.
With High Sierra working so well I thought I'd give Mojave a try and so far v10.14.3 has been solid for me. I've run into a problem with MIDI, however, and was wondering if it might be due to my 3,1 Mac Pro, and if so, if there might be a patch of some kind to fix it.
Briefly the problem is my latest MIDI keyboard, which is class compliant, does not appear in Audio MIDI Setup, and won't work in Logic or any other music app. When I boot into my High Sierra drive, however, running the same version of Logic, the keyboard automatically shows up in AMS and works fine with my music apps.
I haven't read all 500+ pages in this thread but I did a search and didn't see anything about MIDI keyboards not working, so I thought I'd ask. If anyone has any helpful info I'd appreciate it.
Thanks in advance! RD
*Update: MIDI issue solved! See post #14158 on page 567.
I have a 3,1 Mac Pro and thanks to dosdude1's patcher I successfully updated from El Capitan to High Sierra last month. I use Logic Pro for music and wanted to move up to the latest version, which left El Capitan behind.
With High Sierra working so well I thought I'd give Mojave a try and so far v10.14.3 has been solid for me. I've run into a problem with MIDI, however, and was wondering if it might be due to my 3,1 Mac Pro, and if so, if there might be a patch of some kind to fix it.
Briefly the problem is my latest MIDI keyboard, which is class compliant, does not appear in Audio MIDI Setup, and won't work in Logic or any other music app. When I boot into my High Sierra drive, however, running the same version of Logic, the keyboard automatically shows up in AMS and works fine with my music apps.
I haven't read all 500+ pages in this thread but I did a search and didn't see anything about MIDI keyboards not working, so I thought I'd ask. If anyone has any helpful info I'd appreciate it.
Thanks in advance! RD
*Update: MIDI issue solved! See post #14158 on page 567.
Last edited:
Well I am back with 10.14.2 I used an very old Mojave Patcher which installed 14.0.14 then since it said I was up to date when checking for updates I installed the beta profile I upgraded to 14.0.21 then to my current one but it hung at the first stage of the boot process white screen apple logo let the it sit for about 30 mins then rebooted back into my 1.3.0 patcher did a disk check it said my APFS numbers didn't match I don't remember them all but it said mine need with 102 and should be 101 set my startup disk rebooted and get into my desktop. I have always applied the apfs patch
Stay right where you are. It was obvious since the betas of the 10.14.4 that 10.14.3 marks the end of an era. However keep checking this thread.
Yes a lot of dependencies everywhere
Which machine are you testing on? I think you're currently at the stage of "no acceleration in any configuration" but bootable with the .5 wrangler but no graphics - bootable with .4 wrangler on single gpu machine but just framebuffer. Both configurations hand crafted without using the patcher...I've probably got that all wrong but just trying to keep things straight
MB7,1, MBP6,2, MBP8,1, you can use all the .5 beta2 kext/framework for both dualGPUs and singleGPU machines but only without Framebuffer, to allow framebuffer only on singleGPU is needed to downgrade GPUWrangler, AGDP kext, IOAccel*, IOGraphicsFamily and IONDRVSupport.
edit:
It seems I am unable to boot more .5 beta2 from dual GPUs, while I succeeded with .5 beta1.
In any case from single GPU .5 beta2 will boot anyway.
I am almost giving up my .5 beta dare, since I neither use 10.14.4 as my main system. So near to drop.
Last edited:
Maybe it's a USB problem.
I had a big problem for several weeks with a Pioneer DJ controller on a Mac Pro 3.1 after installing Mojave. The controller simply was unusable. With High Sierra this controller had no problems.
After spending a lot of time to find out what could cause the trouble I did a new installation of Mojave. On the post installation procedure I didn't add the LegacyUSBInjector and USBOHCI Support Patches.
Now the controller works as expected.
The Mac Pro so far doesn't show any issues without these patches, I'm very relieved ...
I do not have a MIDI device but there're several members who have experienced problems with the mp3.1 USB and Mojave. The problem has not yet been identified and appears a bit random. In my case, the usb keyboard would not connect during boot up so I was unable to get at the boot screen. The keyboard was connected via a hub (Apple LED Cinema Display) and the hub was not powering up until Mojave was fully loaded. Connecting the keyboard directly to the Mac solved my problem. Others have reported problems with various USB devices. Here are a few suggestions that may help:
1. If you have the MIDI connected via a hub then connect directly to one of the mp3.1 native USB ports.
2. Reinstall Mojave but this time do not patch LegacyUSBInjector and USBOHCI. Some members have been running their mp3.1 without these patches with no problems and it solved their connectivity problems. I tried running mine without these patches and all was well except my isight camera (Apple LED Cinema Display) did not work. I used patch updater to install the USBOHCI patch and all is well again. I am still not running the LegacyUSBInjector patch with no ill effects. It is always easier to add patches than remove them. If you try this route watch out for the patch updater (once Mojave is running) asking to install the missing USB patch.