No, I didn't, but thanks for the tip. I was able to use LuisN's suggestion above to get it to work. Unfortunately, battery health on my 2011 MacBook Air appears to have declined from around 80% to 60% over a few months, so I'm afraid it may not be usable for the three years I had hoped to get out of it.
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
No, I didn't, but thanks for the tip. I was able to use LuisN's suggestion above to get it to work. Unfortunately, battery health on my 2011 MacBook Air appears to have declined from around 80% to 60% over a few months, so I'm afraid it may not be usable for the three years I had hoped to get out of it.
That is good news. A change of usb stick often solves installation problems. I was worried you might be using a later AMD card that Mojave cannot use on our Mac Pro 3.1s. Your GTX 760 should be happy using the built in drivers for Nvidia in Mojave so unless you need CUDA you should be fully operational. My macpro 3.1 is also running very well on mojave using a GTX680.
Not sure if this is a troll or just rude.
That Mac is ancient. But really ancient. It is not really sane to ask for 2018 OS to run on like 12-13 year old hardware.
CPUs that the Mac Pro 1,1 and 2,1 are capable of using do not support a required sub-set of of instructions (SSE 4.2). The last incarnation of macOS that those machines are capable of running is El Capitan 10.11.6, and that only via Pike R. Alpha's BOOT.EFI hack.
And that works like a charm if you're careful with software updates
Just saw this. Listing for Mojave XNU sources added to Apple Open Source page.
Wondering if this'll allow somebody (smarter than me) to add SSE4.2 emulation to the kernel, enabling newer AMD cards on MacPro3,1?
Just figured I'd mention this in case anybody missed it.
Wondering if this'll allow somebody (smarter than me) to add SSE4.2 emulation to the kernel, enabling newer AMD cards on MacPro3,1?
Just figured I'd mention this in case anybody missed it.
Hi there!!
Some updates
I received the chip Friday 28th! And wait a quiet home to do the surgery this evening.
Please, enjoy these 3 pictures of the before, after and « set up » !!
I'll install Mojave soon, but on SSD HFS+
This is irrelevant for 99% of you guys, it relates to the com.apple.telemetry kernel panic that @jackluke and I fixed a while ago. Feel free to ignore...
Skip to the end for TL;DR.
As far as I know, nobody ever figured out why that file caused a panic, but removing/replacing it fixes the problem, so whatever. At the time, I wrote an AppleScript that disassembles system binaries and searches them for SSE4.2 instructions, and that wasn't one of the files it found. So I always maintained the opinion that it was something else.
But... according to this post I just found on a German site, it was SSE4.2-related. They also provided a command to replace a byte string in the file, apparently fixing it. Unfortunately, that string doesn't match anything in the current version of the plugin.
So I searched for another way to check for SSE4.2 opcodes, and I found this. After a bit of trouble installing it, I ran it on the plugin.
And... no SSE4.2.
I am confusion. Either the Germans are wrong about SSE4.2, which seems unlikely since they made a working patch, or this tool isn't working right.
Going to keep investigating. I'll test the byte replacement command against different versions of the plugin until I find one where it works, and then I can compare the binaries and see what it's doing. This is bothering me. If I can figure this out, it might be relevant to other issues in future macOS releases, as well as providing a cleaner patch for this system.
Sorry for the long and irrelevant message. Just keeping to my "always document things" rule. Hope you all are having a good day!
Edit: Testing on a file found by my AppleScript confirms that the tool does work:
Anyways, I'll edit this comment if I find anything else, so as to not spam the thread.
Edit 2: Found where the patch originated. Looks like it applies to DP3. Almost there!
Edit 3: So, the patch does work, but it's built on a faulty assumption that the first difference between the High Sierra and Mojave bundle is the only one. Its creator seems to think it makes the Mojave plugin identical to the HS one... which it doesn't.
It actually just alters one field in the mach-o header: the size of the load commands. It changes it from 1836 to 1732. That's all. What does that even do? Presumably it basically truncates the readable area of the file? And in the process, somehow skips the panicky code? How does that even work?
Edit 4: I'm beginning to think this patch just breaks the codesigning on the plugin and stops it from loading altogether... checking that now.
Edit 5: One mystery solved! I was kind of right. This "patch" in fact corrupts the executable enough that it can't even load. Completely useless, might as well just delete it outright. So much for this being a lead on why that thingy was KP'ing my Penryn MacBook for a month...
This might remain a mystery forever.
TL;DR: I thought some InsanelyMac people and/or Germans figured out why the infamous telemetry plugin was crashing our Macs with old CPUs. Turns out their "patch" is nonsense and they don't know either.
If anybody actually read all this, thank you for your time, and sorry for wasting it.
Skip to the end for TL;DR.
As far as I know, nobody ever figured out why that file caused a panic, but removing/replacing it fixes the problem, so whatever. At the time, I wrote an AppleScript that disassembles system binaries and searches them for SSE4.2 instructions, and that wasn't one of the files it found. So I always maintained the opinion that it was something else.
But... according to this post I just found on a German site, it was SSE4.2-related. They also provided a command to replace a byte string in the file, apparently fixing it. Unfortunately, that string doesn't match anything in the current version of the plugin.
So I searched for another way to check for SSE4.2 opcodes, and I found this. After a bit of trouble installing it, I ran it on the plugin.
And... no SSE4.2.
Code:
will$ ./elfx86exts com.apple.telemetry
MODE64 (push)
CMOV (cmove)
SSE2 (ucomisd)
SSE3 (haddpd)
CPU Generation: Intel CoreI am confusion. Either the Germans are wrong about SSE4.2, which seems unlikely since they made a working patch, or this tool isn't working right.
Going to keep investigating. I'll test the byte replacement command against different versions of the plugin until I find one where it works, and then I can compare the binaries and see what it's doing. This is bothering me. If I can figure this out, it might be relevant to other issues in future macOS releases, as well as providing a cleaner patch for this system.
Sorry for the long and irrelevant message. Just keeping to my "always document things" rule. Hope you all are having a good day!
Edit: Testing on a file found by my AppleScript confirms that the tool does work:
Code:
Zoe:~ will$ ./elfx86exts /sbin/fsck_cs
MODE64 (push)
SSE1 (movaps)
CMOV (cmove)
SSE42 (crc32)
SSE2 (movq)
CPU Generation: NehalemAnyways, I'll edit this comment if I find anything else, so as to not spam the thread.
Edit 2: Found where the patch originated. Looks like it applies to DP3. Almost there!
Edit 3: So, the patch does work, but it's built on a faulty assumption that the first difference between the High Sierra and Mojave bundle is the only one. Its creator seems to think it makes the Mojave plugin identical to the HS one... which it doesn't.
It actually just alters one field in the mach-o header: the size of the load commands. It changes it from 1836 to 1732. That's all. What does that even do? Presumably it basically truncates the readable area of the file? And in the process, somehow skips the panicky code? How does that even work?
Edit 4: I'm beginning to think this patch just breaks the codesigning on the plugin and stops it from loading altogether... checking that now.
Edit 5: One mystery solved! I was kind of right. This "patch" in fact corrupts the executable enough that it can't even load. Completely useless, might as well just delete it outright. So much for this being a lead on why that thingy was KP'ing my Penryn MacBook for a month...
This might remain a mystery forever.
TL;DR: I thought some InsanelyMac people and/or Germans figured out why the infamous telemetry plugin was crashing our Macs with old CPUs. Turns out their "patch" is nonsense and they don't know either.
If anybody actually read all this, thank you for your time, and sorry for wasting it.
Last edited:
I did that but the problem is that my OS El Capitan doesn't support 4k gopro video.
I guess both root86 and insanelymac (and many many other websites) follow this place carefully and being inspired by this thread on this forum, they didn't discovered those "ultimate" Mojave fixes, but reading this forum, I repeat, they are skilled in using perl programming language (or whatever else) to compare and patch binary files creating another version of the fixes. Your manual fixes to me are unbeatable. This is my point of view.
And even if you don't own a mac with AMD graphics, thanks for your effort in debugging SSE4.2 CPU Instruction.
Last edited:
Why is that? Not even with vlc? Or just convert the files to *.mov container and use QuickTime.
We´ll see about that. The last chapter of that book is not written yet.
(Considering myself quite "sane") ;-)
HEVC playback is only supported on relatively new systems running High Sierra or later.
Macbook – 2016 or newer
Macbook Pro – 2016 or newer
iMac – 2017 and newer
iMac Pro – 2017 or newer
27-inch 5K iMac (2015-2017)
Edit: Elmedia Player (available from the app store) supports playback of 4K GoPro video on my Mac Pro 2,1 running El Capitan, but it extracts a heavy toll on the processors.
Last edited:
I don't know yet... Just make sure you have a bootable patched USB installer on hand to restore the system if it doesn't work. Also, the patcher tool may need to be updated in order to make 10.14.2 installer drives. If this ends up being the case, I'll have an update out within a few hours.
I've updated my MacBook Pro Pro 2011 13'' with the final 10.14.2 without problem ;-)
Just patch again with USB stick and macOS Mojave Patcher 1.2.3
Just patch again with USB stick and macOS Mojave Patcher 1.2.3
First of all, a big thank you to @dosdude1 and all the people involved in making it possible to install Mojave on unsupported Macs.
I just installed Mojave 10.14.1 on my MBP 5,3 with no drama at all using Mojave's Patcher. Setup went fine and everything works as expected (including the known issues, hehe).
I have a couple of questions:
1) Is the choice between APFS and HFS+ related to the ability to install OTA software updates?
2) Any warnings in regards of Software updates other than the fact that 10.14.x updates could break something?
3) Performance-wise what would be the best choice of file system?
Thanks!
I just installed Mojave 10.14.1 on my MBP 5,3 with no drama at all using Mojave's Patcher. Setup went fine and everything works as expected (including the known issues, hehe).
I have a couple of questions:
1) Is the choice between APFS and HFS+ related to the ability to install OTA software updates?
2) Any warnings in regards of Software updates other than the fact that 10.14.x updates could break something?
3) Performance-wise what would be the best choice of file system?
Thanks!
How exactly did you patch this? I tried to follow this guide but couldn't really do it properly. I tried to follow it with High Sierra btw.
Runs just fine on a MBP 9,1 Mid 2012 with Mojave..
Tried to play it on my cMP 2,1 running El Capitan but QuickTime Player automatically converts it (as expected).
With VLC, HEVC 1080p will play smoothly, 2160p is laggy though.
I guess it would be better to convert it.
The gpu on my 2,1 is a Radeon HD 7950 providing 3840 x 2160 @ 60 Hz
EDIT: Works flawlessly on my nMP 6,1 with High Sierra.
So apparently older machines do support HEVC 4K as long as High Sierra is running.
Last edited:
You can use my "cbpatcher" binary to patch the CoreBrightness binary. Its arguments are as follows:
Code:
./cbpatcher <path/to/CoreBrightness binary> <output/file/path>Of course, make sure you code sign the modified binary, otherwise the system will fail to boot with it in place.
APFS is fast for SSD's. Users with HDD's are actually recommended to stay on HFS+ because APFS can create a noticeable slowdown.
Also, even if an update "breaks your machine", your data is still safe -- just boot from another drive and copy it off. Having a booting OS is irrelevant to having your files. Although backups are always important!
Last edited: