macOS 10.14 Mojave on Unsupported Macs Thread

[highvoltage12v]

I'm still having the kernel panic waking from sleep on my 2011 iMac with the 780m installed. This problem was occurring on the last beta as well. Its most likely related to Nvidia Graphics, I do not have this issue in High Sierra. (dual booted) There are no Video patches installed.

 

[Luckygreek]

So is the correct version of Mojave beta? sorry if I missed it in an earlier post.

 

[highvoltage12v]

So is the correct version of Mojave beta? sorry if I missed it in an earlier post.

2018/07/16 Developer Beta 4 = 14.0.14

Yes it is.

 

[0403979]

So is the correct version of Mojave beta? sorry if I missed it in an earlier post.

Yes, that is the latest.

 

[Luckygreek]

Yes, that is the latest.

Thanks guys

 

[0403979]

Thanks guys

You’re welcome.

 

[arqueox]

I'm still having the kernel panic waking from sleep on my 2011 iMac with the 780m installed. This problem was occurring on the last beta as well. Its most likely related to Nvidia Graphics, I do not have this issue in High Sierra. (dual booted) There are no Video patches installed.
View attachment 771146

I have kernel Panic while installation procedure...i have Intel HD 3000 graphics... Don't know what it is...

 

[highvoltage12v]

I have kernel Panic while installation procedure...i have Intel HD 3000 graphics... Don't know what it is...

Mine only happens waking from sleep. The 780m is still a supported Nvidia card, I don't understand what could be causing this I tried fixing graphics power management in the last beta.

 

[arqueox]

I have a MacBook pro 8,1 late 2011... With Intel HD 3000 graphics. I have Panic kernel while in installation procedure in about 15 minutes after it Started...everytime. i can't install the os on my ssd
... Any thoughts? Anybody else with this?
[doublepost=1531861296][/doublepost]

Mine only happens waking from sleep. The 780m is still a supported Nvidia card, I don't understand what could be causing this I tried fixing graphics power management in the last beta.

I can't install the os... I Saw that MacBook pro 8,2 was full compatible... But i can't pass the installation procedure with the 12th version of the Mojave patcher...

 

[Luckygreek]

I got prompted to update via software, new version Mojave beta, I believe in an earlier post it's not recommended to update via sys software, so anyone have a final verdict, I know I'll have to run the patch afterward.

 

[jackluke]

Just trying Mojave beta 4 from a supported Mac here are the news I notice:

- Not only Dashboard's Weather but every Dashboard Widget have black/white borders instead of transparency
- Font smoothing in dark mode are optimized
- Dynamic Desert Wallpaper seems to work and there is a new dynamic wallpaper "Solar Gradients" very nice
- Maps support dark mode

If I notice other things will report editing this post.

edit:
There is a new Corebrightness framework unix binary sized 718 KB

I will clone this partition to test Mojave beta 4 on unsupported Macbook7,1 and see if the old patches still work. At first sight seems some new patches could be required.

Ok, after manually replace patched GeforceTesla*, AppleHDA*, IOUSB*, telemetry.plugin trying booting new Mojave beta 4 from MB7,1

I got an instantly panic, I've checked it seems due to the only High Sierra IOUSBHostFamily.kext, so this time to avoid a quick KP all the IOUSB*** from HS are needed replacing for Mojave beta 4.

Ok after replaced them rebuilding prelinkedkernel then booted again but get a KP later before the stage2 apple logo, it seems from the panic that last kext loaded was NVAStartup, I'm continue to test.

Ok after deep investigation, applying all known patches I got this KP just before the stage2 apple logo (don't know why but seems linked to the IOUSB*** replaced kexts):

*** Panic Report ***
mp_kdp_enter() timed-out on cpu 0, NMI-ing
mp_kdp_enter() NMI pending on cpus: 0 1
mp_kdp_enter() timed-out during locked wait after NMI;expected 2 acks but received 1 after 18100314 loops in 1194621273 ticks
panic(cpu 0 caller 0xffffff801e2d1a7d): Kernel trap at 0xffffff801e2e3bc0, type 13=general protection, registers:
CR0: 0x000000008001003b, CR2: 0x00007fffa1311f50, CR3: 0x0000000202ca7000, CR4: 0x00000000000026e0
RAX: 0x0000000034be87ff, RBX: 0xffffff801ea0c8c0, RCX: 0x000000000000030a, RDX: 0x000000000000fffd
RSP: 0xffffff80fea32e90, RBP: 0xffffff80fea32ea0, RSI: 0x0000000000000001, RDI: 0xffffff801ea0d6d0
R8:  0x0000000000000001, R9:  0x00000011fd0207a4, R10: 0x0000000000000000, R11: 0x0000000000000000
R12: 0xffffff801ec47580, R13: 0xffffff801e2e3b30, R14: 0xffffff801ea0d6d0, R15: 0xffffff912a4abe70
RFL: 0x0000000000010002, RIP: 0xffffff801e2e3bc0, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x00007fffa1311f50, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 1, VF: 0

Backtrace (CPU 0), Frame : Return Address
0xffffff801df4c290 : 0xffffff801e1a641d mach_kernel : _handle_debugger_trap + 0x48d
0xffffff801df4c2e0 : 0xffffff801e2dfde3 mach_kernel : _kdp_i386_trap + 0x153
0xffffff801df4c320 : 0xffffff801e2d185a mach_kernel : _kernel_trap + 0x4fa
0xffffff801df4c390 : 0xffffff801e153cd0 mach_kernel : _return_from_trap + 0xe0
0xffffff801df4c3b0 : 0xffffff801e1a5e37 mach_kernel : _panic_trap_to_debugger + 0x197
0xffffff801df4c4d0 : 0xffffff801e1a5c83 mach_kernel : _panic + 0x63
0xffffff801df4c540 : 0xffffff801e2d1a7d mach_kernel : _kernel_trap + 0x71d
0xffffff801df4c6b0 : 0xffffff801e153cd0 mach_kernel : _return_from_trap + 0xe0
0xffffff801df4c6d0 : 0xffffff801e2e3bc0 mach_kernel : _mt_microstackshot_start_arch + 0x100
0xffffff80fea32ea0 : 0xffffff801e2da963 mach_kernel : _mp_cpus_call_cpu_init + 0x2b3
0xffffff80fea32f10 : 0xffffff801e2da673 mach_kernel : _cpu_signal_handler + 0x2a3
0xffffff80fea32f50 : 0xffffff801e2d9563 mach_kernel : _lapic_interrupt + 0x43
0xffffff80fea32f70 : 0xffffff801e2d0fef mach_kernel : _interrupt + 0x12f
0xffffff80fea32fd0 : 0xffffff801e153e7d mach_kernel : _hndl_allintrs + 0x11d
0xffffff912a552ff0 : 0xffffff7f9f1f78fd com.apple.security.sandbox : _match_pattern + 0x92
0xffffff912a553030 : 0xffffff7f9f1f5ac7 com.apple.security.sandbox : _eval + 0x132e
0xffffff912a5532c0 : 0xffffff7f9f1f82c4 com.apple.security.sandbox : _static_storage_class_for_vnode + 0x23
0xffffff912a5532e0 : 0xffffff7f9f1f803a com.apple.security.sandbox : _derive_vnode_storage_class + 0x49e
0xffffff912a553690 : 0xffffff7f9f1f5c50 com.apple.security.sandbox : _eval + 0x14b7
0xffffff912a553920 : 0xffffff7f9f1f44b1 com.apple.security.sandbox : _sb_evaluate + 0xd3
0xffffff912a553980 : 0xffffff7f9f1ec6f7 com.apple.security.sandbox : _cred_sb_evaluate + 0x3c
0xffffff912a5539b0 : 0xffffff7f9f1ef9ce com.apple.security.sandbox : _hook_vnode_check_getextattr + 0x62
0xffffff912a553b00 : 0xffffff801e8cc98f mach_kernel : _mac_vnode_check_getextattr + 0x8f
0xffffff912a553b50 : 0xffffff801e418c78 mach_kernel : _vn_getxattr + 0x88
0xffffff912a553c70 : 0xffffff801e4111f6 mach_kernel : _getxattr + 0x346
0xffffff912a553f40 : 0xffffff801e7af29d mach_kernel : _unix_syscall64 + 0x26d
0xffffff912a553fa0 : 0xffffff801e154496 mach_kernel : _hndl_unix_scall64 + 0x16
      Kernel Extensions in backtrace:
         com.apple.security.sandbox(300.0)[4CE5C4D8-A89F-34AB-9413-BEB56AC54ECF]@0xffffff7f9f1e8000->0xffffff7f9f217fff
            dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[3ED80A57-15DD-34FE-9A8A-7902AF825531]@0xffffff7f9ef82000
            dependency: com.apple.kext.AppleMatch(1.0.0d1)[E02F2B44-1494-3432-8D43-48FB11F5028A]@0xffffff7f9f1e3000
            dependency: com.apple.iokit.IOStorageFamily(2.1)[75B6AF84-BEA5-3D99-994D-7CA156029ACF]@0xffffff7f9ed7d000

BSD process name corresponding to current thread: kextd
Boot args: -no_compat_check keepsyms=1 -v

 

[0403979]

I got prompted to update via software, new version Mojave beta, I believe in an earlier post it's not recommended to update via sys software, so anyone have a final verdict, I know I'll have to run the patch afterward.

You can install it and it should work fine.

 

[Luckygreek]

You can install it and it should work fine.

Thanks, Julian, worked in the previous update, just reading many are having issues with the "new" beta. This version has been remarkably stable, some UI glitches, however, that's to be expected. Not 1 k/p, hope that doesn't bite me.

 

[TimothyR734]

Actually remember SWUSwitcher from the the HS days. He ( cvad ) has a 1.0.3 version update. May be worth a try. Thanks.

if you see the post above there is a link to the updated version Dev beta 4 is working well on my iMac 9,1

 

[Luckygreek]

if you see the post above there is a link to the updated version Dev beta 4 is working well on my iMac 9,1

I read earlier you were having some major issues with the new beta, what was the solution?
I was out of the loop for a bit, working with Developer to get WhatRoute working on Mojave, which it does, sorta, seems as if Sparkle threw a wrench into it.

 

[Czo]

Hi @Czo - is the source for the latest Faker available? The last version I remember (a while ago now) "faked" being an iMac 10,1 and VMM. So very old. I don't mind recompiling a new lib myself and I'm not sure which one dosdude1 has.

Thanks.

You don't need to recomile, because apple only checking VMM.

According to @pkouame it works by spoofing the machine identifiers.

It's runtime modify Apple's update checking process, to check FPU existence instead of VMM. If you check any updates, that are released for 10.12 or 10.13 or 10.14 beta, Apple checking machine identifiers and cpu flags. If VMM are found in it, skipping machine id checking. So i simply wrote a patch, that alters this check, to check FPU not VMM. I think, it's the best we can, because too risky to spoof some real machine ids, because sometimes apple releasing things (special drivers or firmwares) specially for some Macs. The next part is to remove firmware and recovery 10.13 updates from the definition xml (because it's exactly matching for 10.13recover, it's not skipping 10.14 recovery updates, currently i can't known it's good or not. I need some more updates to clarify it).

 

[pkouame]

You don't need to recomile, because apple only checking VMM.


It's runtime modify Apple's update checking process, to check FPU existence instead of VMM. If you check any updates, that are released for 10.12 or 10.13 or 10.14 beta, Apple checking machine identifiers and cpu flags. If VMM are found in it, skipping machine id checking. So i simply wrote a patch, that alters this check, to check FPU not VMM. I think, it's the best we can, because too risky to spoof some real machine ids, because sometimes apple releasing things (special drivers or firmwares) specially for some Macs. The next part is to remove firmware and recovery 10.13 updates from the definition xml (because it's exactly matching for 10.13recover, it's not skipping 10.14 recovery updates, currently i can't known it's good or not. I need some more updates to clarify it).

@Czo - Thank you! I did a little sleuthing myself and realized the newer version(s) is a considerable overhaul from the original. Now I understand how you get away from checking machine identifiers, like iMac10,1 and it still works in Mojave and a new unsupported device list. Mystery solved. Keep us posted if and when a new stable version is available.

Thanks in advance for all this work and being open and transparent about your great utility! Best of luck...

 

[redheeler]

Success with beta 4 (18A336e). There are a few additions / changes, but performance seems to be mostly the same from what I can tell.

Interestingly, when comparing this to my previous screenshot of beta 3, it looks like the menu bar and window shadow got darker. (Provided this change also happened on supported Macs, would be applicable to the "Little Things" thread.)

 

[Luckygreek]

Success with beta 4 (18A336e). There are a few additions / changes, but performance seems to be mostly the same from what I can tell.

View attachment 771158

Interestingly, when comparing this to my previous screenshot of beta 3, it looks like the menu bar and window shadow got darker. (Provided this change also happened on supported Macs, would be applicable to the "Little Things" thread.)

Did you upgrade via System Prefs or install from patcher?

 

[TimothyR734]

I read earlier you were having some major issues with the new beta, what was the solution?
I was out of the loop for a bit, working with Developer to get WhatRoute working on Mojave, which it does, sorta, seems as if Sparkle threw a wrench into it.

the issues were fixed with the new Mojave Patcher version 12 Thanks a bunch dosdude1 I uploaded the version of the SWUSwitcher I had I didn't know there was a new version my thinking was someone with more brain power than me might be able to get switch the catalog to macOS Mojave for those who wish to test the developers beta

 

[Czo]

@Czo - Thank you! I did a little sleuthing myself and realized the newer version(s) is a considerable overhaul from the original. Now I understand how you get away from checking machine identifiers, like iMac10,1 and it still works in Mojave and a new unsupported device list. Mystery solved. Keep us posted if and when a new stable version is available.

Thanks in advance for all this work and being open and transparent about your great utility! Best of luck...

I found the original link in the 10.12 forum: #4160, the source for the new version inside the SUFaker folder (the old version, for sierra is C the newer version for HS is ObjC), and can be build with the build-new.sh. I don't know if it will be build fine with current Xcode versions or not.

 

[redheeler]

Did you upgrade via System Prefs or install from patcher?

Used @Czo's solution (SUVMMFaker.dylib) as linked above by @0403979 and finally got it to show up in System Preferences > Software Update to do the update without a supported Mac. Afterward I had to re-modify PlatformSupport.plist with the unsupported Mac's model + board id and it was bootable.

 

[Luckygreek]

Used @Czo's solution (SUVMMFaker.dylib) as linked above by @0403979 and finally got it to show up in System Preferences > Software Update to do the update without a supported Mac. Afterward I had to re-modify PlatformSupport.plist with the unsupported Mac's model + board id and it was bootable.

It's showing up on my Mac, just had read some users were experiencing problems, so just wanted to be reasonably sure of which way to go. The previous update was thru System Pref and it went pretty smooth, we'll see how this one goes, thanks for the info redheeler.

 

[ASentientBot]

You don't need to recomile, because apple only checking VMM.


It's runtime modify Apple's update checking process, to check FPU existence instead of VMM. If you check any updates, that are released for 10.12 or 10.13 or 10.14 beta, Apple checking machine identifiers and cpu flags. If VMM are found in it, skipping machine id checking. So i simply wrote a patch, that alters this check, to check FPU not VMM. I think, it's the best we can, because too risky to spoof some real machine ids, because sometimes apple releasing things (special drivers or firmwares) specially for some Macs. The next part is to remove firmware and recovery 10.13 updates from the definition xml (because it's exactly matching for 10.13recover, it's not skipping 10.14 recovery updates, currently i can't known it's good or not. I need some more updates to clarify it).

That's genius. I always saw the check for "VMM" in the installationCheck but I never thought of that. Going to download this right now

 

[pkouame]

I found the original link in the 10.12 forum: #4160, the source for the new version inside the SUFaker folder (the old version, for sierra is C the newer version for HS is ObjC), and can be build with the build-new.sh. I don't know if it will be build fine with current Xcode versions or not.

Excellent, will download the latest code and see if it builds with the latest Xcode.

Unfortunately the dosdude/mojave version did not trigger an update for me (from h to e) I bounced the process, rebooted a few times and even logged in and out of App Store to no avail.

Let me check out your source code. Thanks!