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.
Your input is highly appreciated. I am NOT criticizing it in any shape or form. My points are as follows:
HFS "Recovery HD" was not fixed by dosdude1 in patcher v.1.2.1, I don't know for v1.2.2
To me it seems way too big of an effort trying to fix APFS GUI Recovery if one plans to do serios patching and manipulations to the system in general. The safest is to perform it, while booted in the patched USB installer (which carries the same goodies as the regular Recovery).
For rather small changes (on the go) one can use a Single User Recovery (since the patched USB is not around). Also although I completely agree with your point 3), if one has successfully installed and booted in Mojave, than in 99% Single User Recovery has been already made functional by the USB patched installer.

Again, partially agree with your (second) argument, dosdude1 has fixed the HFS Recovery with Post-Install "Recovery partition patch", and on point 3) you missed a little detail, either the HFS and APFS Recoveries if not "patched" with the fresh generated system prelinkedkernel (HFS Recovery) and immutablekernel (APFS Recovery), won't be functional, this step must be done only manually to have them working with CMD+R or CMD+S+R.

While HFS Recovery has a "fixed mount folder" position and can be patchable through scripts, APFS Recovery is tricky and located on a random-UUID different from any machine, for sure could be doable through some gpt commands with grep get-UUID, but I guess it is "easier" doing through my steps.

However I found agree on the part that a "single user mode Recovery" is power as terminal+disk utility, probably more too, but having a little GUI is useful sometimes.
 
  • Like
Reactions: TimothyR734
Again, partially agree with your (second) argument, dosdude1 has fixed the HFS Recovery with Post-Install "Recovery partition patch", and on point 3) you missed a little detail, either the HFS and APFS Recoveries if not "patched" with the fresh generated system prelinkedkernel (HFS Recovery) and immutablekernel (APFS Recovery), won't be functional, this step must be done only manually to have them working with CMD+R or CMD+S+R.

While HFS Recovery has a "fixed mount folder" position and can be patchable through scripts, APFS Recovery is tricky and located on a random-UUID different from any machine, for sure could be doable through some gpt commands with grep get-UUID, but I guess it is "easier" doing through my steps.

However I found agree on the part that a "single user mode Recovery" is power as terminal+disk utility, probably more too, but having a little GUI is useful sometimes.
Can’t you just delete the packages folder to save space on the patched installer?
 
  • Like
Reactions: TimothyR734
Can’t you just delete the packages folder to save space on the patched installer?

Yes, you can, however that's an HFS "Recovery", while "patching" mine is a native APFS Recovery, and till now you can't have an APFS Recovery outside of an APFS container.

Of course HFS and APFS Recoveries do the same things, but it's just to make functional an obliged APFS Recovery inside a mandatory APFS Scheme.

Anyway agree on the fact that if you delete the packages you will have a slim Recovery in disk space, but I guess that less than 600 MB for a stock APFS Recovery (561 MB) is unbeatable, it's less even than stock HFS Recovery HD (650 MB).
 
  • Like
Reactions: TimothyR734
The link to the 5 kexts is on page 351 I used kext utility that is also included in the link
Thanks very much guys !
You're ingenious !
Now its working fine and I have to stress, that rarely I experienced a community that helpful and competent !

A question: Is there a way to implement these kexts to the installer, so that one doesn't have to do this process every time by installing Mojave ?

Again thanks very much !
Cheers
 
Hey folks- sorry if this has come up - I have a Mac Mini Mid 2011 - was top of the line at the time,SSD etc ...has the ATI Radeon HD 6630M 256 build - I'm reading that some people are installing via the Patch tool and disabling the HD accelaration - I use the machine for basic media server (plex) and some youtube viewing, and somes the media player/visualizer

Is there some kind of patch that would enable the ATI card acceleration?

If I disable the accelaration, I'm assuming the system is still functional? Just want to avoid critical performance issues. Any info appreciated. Thanks!
 
  • Like
Reactions: TimothyR734
Thanks very much guys !
You're ingenious !
Now its working fine and I have to stress, that rarely I experienced a community that helpful and competent !

A question: Is there a way to implement these kexts to the installer, so that one doesn't have to do this process every time by installing Mojave ?

Again thanks very much !
Cheers

Good question, the general thought here is patching less kext possible so I guess into the Installer there are only 2 IOUSB***, however me too, I always replaced all the 5 IOUSB*** since Mojave beta 2 never had an issue about.
 
  • Like
Reactions: TimothyR734
Yes, you can, however that's an HFS "Recovery", while "patching" mine is a native APFS Recovery, and till now you can't have an APFS Recovery outside of an APFS container.

Of course HFS and APFS Recoveries do the same things, but it's just to make functional an obliged APFS Recovery inside a mandatory APFS Scheme.

Anyway agree on the fact that if you delete the packages you will have a slim Recovery in disk space, but I guess that less than 600 MB for a stock APFS Recovery (561 MB) is unbeatable, it's less even than stock HFS Recovery HD (650 MB).
Normal recovery partirons can download the os from the internet. These classic installers can’t tho.
 
  • Like
Reactions: TimothyR734
Apart the 5 IOUSB***.kext perhaps there are others involved:

AppleHIDKeyboard.kext
AppleHIDMouse.kext
AppleMultitouchDriver.kext
AppleUSBMultitouch.kext
AppleUSBTopCase.kext

But I really don't know exactly them.

I am only 100% sure that the 5 IOUSB***.kext are needed to make them working.

Hello,

I just install 10.14.1 beta 3.

Im.jpg

I always wondered if each time I had to reinstall the five OUSB*** kexts, or are they already present in the patcher? I always used dosdude1 patcher, never done it manually.

For the CoreBrightness: it's ok, I replace it after each update. After replacement I have Nightshift again. Thank you.
 
The problem is that:
1. ALL 32 bit apps cannot be opened in normal mode.
2. ALL 32 bit apps CAN be open in safe mode.
3. When trying to launch the app's main executable from a command line, there is no output, no errors.
4. No errors in Console app. It is like the 32 app thread goes to sleep doing nothing.
5. People who have Mojave on supported hardware can open the 32 bot apps normally.

These may suggest that there may be something wrong with the unsupported patches.

Okay. Whoa. That is very strange. There is a lot of misinformation and confusion on this thread at times and I thought this was just another example of that. I'm sorry. A few questions:
- Have you tried making a separate user account and testing from there?
- Have you tried re-installing the OS?
- Which patches are you using? Are you using any non-standard patches, like pkouame's AppKit modifications?
- Have you tested a non-GUI 32-bit executable?

One other thing -- I remember in the release notes for one of the Mojave betas, there was a mention of a boot flag that would cause this behavior, for testing, since 32-bit support will be removed soon. You obviously didn't intentionally set that, but have you tried clearing NVRAM and/or explicitly setting that flag as false?
 
Hello,

I just install 10.14.1 beta 3.

View attachment 793558

I always wondered if each time I had to reinstall the five OUSB*** kexts, or are they already present in the patcher? I always used dosdude1 patcher, never done it manually.

For the CoreBrightness: it's ok, I replace it after each update. After replacement I have Nightshift again. Thank you.

If for you both usbs and webcam are working with dosdude1 tool, then no need all the five iousb kext, however I see you updated to 10.14.1 beta 3 it means that 10.14.1 kernel is still compatible with mb7,1 good to know.
 
Thanks very much guys !
You're ingenious !
Now its working fine and I have to stress, that rarely I experienced a community that helpful and competent !

A question: Is there a way to implement these kexts to the installer, so that one doesn't have to do this process every time by installing Mojave ?

Again thanks very much !
Cheers
I never had to reinstall the kexts so fingers crossed you won't have to
 
Okay. Whoa. That is very strange. There is a lot of misinformation and confusion on this thread at times and I thought this was just another example of that. I'm sorry. A few questions:
- Have you tried making a separate user account and testing from there?
- Have you tried re-installing the OS?
- Which patches are you using? Are you using any non-standard patches, like pkouame's AppKit modifications?
- Have you tested a non-GUI 32-bit executable?

One other thing -- I remember in the release notes for one of the Mojave betas, there was a mention of a boot flag that would cause this behavior, for testing, since 32-bit support will be removed soon. You obviously didn't intentionally set that, but have you tried clearing NVRAM and/or explicitly setting that flag as false?

- Yes, I made new admin user accounts, in safe mode too. They had same problem.
- I have not tried reinstalling the OS. Using the patched installer went all smoothly, reinstalling wouldn't probably help. I have not tried a fresh install, I prefer not to due to all the extra hassles.
- I simply used dosdude1's installer, the only extra patch I used was https://github.com/julian-poidevin/MBPMid2010_GPUFix, which I have been using for a long time without any issues.
- Testing a non-GUI 32 bit is an interesting idea. Is there such an app out there to try out?

Yes I used an NVRAM flag:

nvram boot-args="-no_compat_check"

Without that flag, when I got to the login page I got GPU kernel panic. Could that be related to 32 bit apps problem?
 
  • Like
Reactions: TimothyR734
OK. Thank you.

I would be a bit cautious with flashing that. One thread indicates it might be possible....

https://forums.macrumors.com/threads/2011-imac-graphics-card-upgrade.1596614/

but another indicates no luck...

http://forum.netkas.org/index.php?topic=8422.0

Unlike a MacPro, you likely won't have the option of booting from a second video card to unbrick the video card by restoring the original PC firmware should things go wrong. As for the GTX 680 in a MacPro 3,1, I used the recipe from...


except I booted from the fully powered card and didn't use the original for video during the flash.
 
- Yes, I made new admin user accounts, in safe mode too. They had same problem.
- I have not tried reinstalling the OS. Using the patched installer went all smoothly, reinstalling wouldn't probably help. I have not tried a fresh install, I prefer not to due to all the extra hassles.
- I simply used dosdude1's installer, the only extra patch I used was https://github.com/julian-poidevin/MBPMid2010_GPUFix, which I have been using for a long time without any issues.
- Testing a non-GUI 32 bit is an interesting idea. Is there such an app out there to try out?

Yes I used an NVRAM flag:

nvram boot-args="-no_compat_check"

Without that flag, when I got to the login page I got GPU kernel panic. Could that be related to 32 bit apps problem?
Please just repair your system correctly, which will rid you of any GPU kernel panic issues.
 
- Yes, I made new admin user accounts, in safe mode too. They had same problem.
- I have not tried reinstalling the OS. Using the patched installer went all smoothly, reinstalling wouldn't probably help. I have not tried a fresh install, I prefer not to due to all the extra hassles.
- I simply used dosdude1's installer, the only extra patch I used was https://github.com/julian-poidevin/MBPMid2010_GPUFix, which I have been using for a long time without any issues.
- Testing a non-GUI 32 bit is an interesting idea. Is there such an app out there to try out?

Yes I used an NVRAM flag:

nvram boot-args="-no_compat_check"

Without that flag, when I got to the login page I got GPU kernel panic. Could that be related to 32 bit apps problem?

The -no_compat_check flag has nothing to do with the GPU. It just bypasses the prohibitory sign (\) or "this version of Mac OS X is not supported" message.

I don't believe this has anything to do with the graphics issue that @dosdude1 mentioned (great video, by the way, just watched it!). Most likely this is a software glitch and a re-install will fix it...

Just compile a simple "hello world" program with -arch i386 (if I remember correctly).
 
Please just repair your system correctly, which will rid you of any GPU kernel panic issues.

Thanks for pointing this out. The problem is that, I do not have the means to fix the hardware myself. It's not that I do not want to!

There are hundreds of thousands of us out there, if not millions, who were screwed up by Apple selling us an expensive laptop with the wrong capacitor, and we cannot fix the hardware by ourselves or find someone nearby to do so. For our group, the software patch works perfectly. It simply keeps the GPU temperature at a medium level, which has perfectly blocked the kernel panic for us.
 
The -no_compat_check flag has nothing to do with the GPU. It just bypasses the prohibitory sign (\) or "this version of Mac OS X is not supported" message.

I don't believe this has anything to do with the graphics issue that @dosdude1 mentioned (great video, by the way, just watched it!). Most likely this is a software glitch and a re-install will fix it...

Just compile a simple "hello world" program with -arch i386 (if I remember correctly).

Could not compile it with cc, 10.14 removed multi arch support!:

Code:
ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
ld: dynamic main executables must link with libSystem.dylib for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

So I used Go language to compile a 32 bit hello world and... it got stuck again. No output, no error, no nothing! Even attaching a debugger gets stuck. The only thing I get in Console app after cancelling the stuck app is:

kernel sleep interrupted

Clearly the OS puts all 32 bit apps into sleep.

Looks like I need to give up. For the past 8 years I only upgraded the OS on this MBP, never needed to have a fresh install.
 
Has anyone done a Mojave upgrade on a Mac Mini with HD6xxxx video card? Re-reading the thread sticky, it sounds like it would make the system 'almost unusable' - but this is referring to iMacs - I think the Mac Mini's may be in a similar boat.
 
Hello friends! Could someone help point me in the right direction? I have an early 2008 iMac but I cannot boot up the patched Mojave installer after following the detailed instructions. I get a "NO" symbol when starting up from the patched USB drive even though I do have the required hardware and I even updated my WiFi card to a Broadcom AirPort Extreme (0x14E4, 0x112). I verified that my partition was formatted correctly as OS X Extended Journaled and bootable; and I have also disabled SIP. Anyone have any ideas why I can't get the patched Mojave Installer to boot?

Mojave Patcher: 1.2.2
Mojave OSX version 14.0.22

EDIT: I just solved my problem. It turns out my External USB Hard Drive and USB Flash Drive were the culprit. I purchased a new 16GB Flash Drive and I was able to boot the Mojave Patched Installer on my 2008 iMac 8,1. Finally installing the new digital wonderment :)
 
Last edited:
  • Like
Reactions: TimothyR734
- Yes, I made new admin user accounts, in safe mode too. They had same problem.
- I have not tried reinstalling the OS. Using the patched installer went all smoothly, reinstalling wouldn't probably help. I have not tried a fresh install, I prefer not to due to all the extra hassles.
- I simply used dosdude1's installer, the only extra patch I used was https://github.com/julian-poidevin/MBPMid2010_GPUFix, which I have been using for a long time without any issues.
- Testing a non-GUI 32 bit is an interesting idea. Is there such an app out there to try out?

Yes I used an NVRAM flag:

nvram boot-args="-no_compat_check"

Without that flag, when I got to the login page I got GPU kernel panic. Could that be related to 32 bit apps problem?

I have the same mac and I also have installed only GPU Fix on top of the default patches from the USB. Mine works just fine with any app, be it 64bit, or 32bit. Of course those MBP mid 2010 are a ticking bomb on its own. Any of those would die as soon as the dreadful capacitor fails. I plan on getting aluminum polymer like the EEF-SX0E331ER, or a ceramic one as a replacement to the tantalum trash. So, the moral goes, for my hard-earned money apple gave me a nice looking yet at the time of purchase already outdated hardware, with a defect by design, which they won't acknowledge nor fix today. They won't give further software updates, so we are forced to go the unsupported route. If you ask a "Genie" for advise, the best would be to dump the old hardware and give more money to apple. No way in hell, thank you very much.
 
  • Like
Reactions: TimothyR734
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.