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.15 Catalina on Unsupported Macs
- Thread starter 0403979
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Does that mean that we should wait a little bit more before updating to 10.15.4 ?
You can use any installer, doesn't matter which OS version as long as it's 10.11 or later. You need to run "csrutil disable", as SIP MUST remain disabled at all times.
Unfortunately that doesn't work for me. System integrity protection was already disabled (I can see from the crash log). I have also tried manually signing the apps that fail but it doesn't work. I don't get why some fail and others don't.
same problem here... office keeps crashing
Exception Type: EXC_CRASH (Code Signature Invalid)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace CODESIGNING, Code 0x1
kernel messages:
I have just released version 1.3.6 of Catalina Patcher, which should fix the issue where some third-party applications wouldn't launch. If you have been having this issue, you can either use the latest Catalina Patcher version, or run "sudo nvram boot-args=amfi_get_out_of_my_way=0x1" in Terminal, and then reboot.
[automerge]1585672919[/automerge]
[automerge]1585672919[/automerge]
Run "sudo nvram boot-args=amfi_get_out_of_my_way=0x1" in Terminal then reboot. That should take care of that issue.
In fact, using only the disablelibraryvalidation.plist even if allowed to boot 10.15.4 given many warnings on SkyLight and CoreDisplay signatures during a verbose boot.
As far as I know, this is due to the lack of Metal support on older processors (see post #6,871 for a workaround). This sort of question comes up often enough where it might deserve a separate thread. This isn't the only issue you'll run into in Catalina as more and more apps are updated to take advantage of Metal.
Important note for users of Catalina on Mac Pro 3,1 (AND Mac Pro 4,1/5,1)
I successfully installed 10.15.4 (19E266) to a blank SSD on my MP3,1 (as always, thanks @dosdude1). While the system was still relatively virgin, I did a scan for newer instructions (including SSE 4.2, AVX, AVX2, and AVX-512) in the system executables. What I found surprised me - my scan located several hundred MacOS executables that contain SSE 4.2 instructions and/or AVX+ instructions. Beyond the AMD video drivers, SSE 4.2 instructions appear in the Intel graphics drivers, the APFS kext & framework, the VideoProcessing framework, the PhotoImaging framework, the HEVC video plug-in, and numerous other places. The number of AVX+ instructions found by my scan is probably too high (due to false positives because it's a complex scan), but I have manually confirmed that AVX+ instructions appear in multiple ProRes codecs, the HEVC video plug-in, the Dock, the backup daemon, the System UI server, the Finder, the login window app, and the core kernel itself. (The AVX+ scan is still ongoing as I write this.)
Because of the sheer number of these, it's going to take a while to figure out which ones are troublesome and which ones are irrelevant (i.e. in some cases, the program checks for SSE4.2/AVX+ presence and only uses those instructions if they're available; in other cases, the program just blindly uses them). I'm hoping to adapt MouSSE to handle all of the SSE4.2 cases, but as I've stated in the past, it's simply impractical to try and emulate AVX+ on a system that lacks the relevant registers.
Just because a program contains one of these instructions doesn't automatically mean it won't work - it's possible that the instruction only gets executed under certain conditions, or when performing certain actions. Symptoms might include unexpected termination, general odd behavior, data corruption, intermittent misbehavior, system panics, or no visible symptoms at all. A codec might work for 1000 videos in a row, but if the 1001st contains a certain data sequence, it might die a horrible death. The Dock might be flawless until you try pinning a program with a certain set of attributes. Without a lot more analysis, it's hard to even guess what would happen, or under what conditions, for any given program.
This exercise has also exposed a few bugs in the last released version of MouSSE. I already had a new version in closed beta, which I had hoped to release soon, but now I'm planning to wait until I resolve the newly-found bugs and (hopefully) add more functionality to help with the increased usage of SSE4.2 in MacOS. Look for a new release of MouSSE in the coming weeks/months. (If you have a Mac Pro 3,1 and you're interested in beta-testing the new version when it's ready, drop me a PM.)
Mac Pro 4,1 and 5,1 users: AVX was introduced with Sandy Bridge (2011), AVX2 was introduced with Haswell (2013), AVX-512 was introduced with Knights Landing (2016). MP4,1 and 5,1 use Westmere CPUs, which don't support any of these instructions - so, even though your CPUs do support SSE4.2, much of the above probably affects you as well. I don't see a good solution at this point, but knowing what (and where) the issues are can be helpful (i.e. if a given app or piece of OS functionality isn't working for you, knowing it's probably an AVX+ issue can save you from wasting a lot of time trying to diagnose or fix an unfixable problem, and look for a workaround instead).
All in all, this is just a "heads-up" that Apple is using a lot more of the newer instructions in MacOS, and that's likely to only get worse as time goes on. We're (collectively) going to need to get more creative (or at least fault-tolerant ;-) if we're going to keep these old machines chugging along...
(This analysis is a work in progress; I'll post updates as I refine my findings. This will include a detailed list of programs/libraries/etc. that definitely contain SSE4.2 and/or AVX+ instructions. And before anybody asks, I have not performed this level of analysis on any MacOS prior to 10.15.4, which includes Mojave and High Sierra. I've done spot checks and localized scans, but never a system-wide scan. It would be interesting to compare 10.15.4 to prior versions of both Catalina and Mojave, to see the progression of these instructions and when they were introduced, but that's a task for another day and/or someone else.)
Update 1: preliminary list of Catalina executables containing SSE 4.2 instructions.
Update 2: preliminary list of Catalina executables containing AVX/AVX2/AVX-512 instructions.
I successfully installed 10.15.4 (19E266) to a blank SSD on my MP3,1 (as always, thanks @dosdude1). While the system was still relatively virgin, I did a scan for newer instructions (including SSE 4.2, AVX, AVX2, and AVX-512) in the system executables. What I found surprised me - my scan located several hundred MacOS executables that contain SSE 4.2 instructions and/or AVX+ instructions. Beyond the AMD video drivers, SSE 4.2 instructions appear in the Intel graphics drivers, the APFS kext & framework, the VideoProcessing framework, the PhotoImaging framework, the HEVC video plug-in, and numerous other places. The number of AVX+ instructions found by my scan is probably too high (due to false positives because it's a complex scan), but I have manually confirmed that AVX+ instructions appear in multiple ProRes codecs, the HEVC video plug-in, the Dock, the backup daemon, the System UI server, the Finder, the login window app, and the core kernel itself. (The AVX+ scan is still ongoing as I write this.)
Because of the sheer number of these, it's going to take a while to figure out which ones are troublesome and which ones are irrelevant (i.e. in some cases, the program checks for SSE4.2/AVX+ presence and only uses those instructions if they're available; in other cases, the program just blindly uses them). I'm hoping to adapt MouSSE to handle all of the SSE4.2 cases, but as I've stated in the past, it's simply impractical to try and emulate AVX+ on a system that lacks the relevant registers.
Just because a program contains one of these instructions doesn't automatically mean it won't work - it's possible that the instruction only gets executed under certain conditions, or when performing certain actions. Symptoms might include unexpected termination, general odd behavior, data corruption, intermittent misbehavior, system panics, or no visible symptoms at all. A codec might work for 1000 videos in a row, but if the 1001st contains a certain data sequence, it might die a horrible death. The Dock might be flawless until you try pinning a program with a certain set of attributes. Without a lot more analysis, it's hard to even guess what would happen, or under what conditions, for any given program.
This exercise has also exposed a few bugs in the last released version of MouSSE. I already had a new version in closed beta, which I had hoped to release soon, but now I'm planning to wait until I resolve the newly-found bugs and (hopefully) add more functionality to help with the increased usage of SSE4.2 in MacOS. Look for a new release of MouSSE in the coming weeks/months. (If you have a Mac Pro 3,1 and you're interested in beta-testing the new version when it's ready, drop me a PM.)
Mac Pro 4,1 and 5,1 users: AVX was introduced with Sandy Bridge (2011), AVX2 was introduced with Haswell (2013), AVX-512 was introduced with Knights Landing (2016). MP4,1 and 5,1 use Westmere CPUs, which don't support any of these instructions - so, even though your CPUs do support SSE4.2, much of the above probably affects you as well. I don't see a good solution at this point, but knowing what (and where) the issues are can be helpful (i.e. if a given app or piece of OS functionality isn't working for you, knowing it's probably an AVX+ issue can save you from wasting a lot of time trying to diagnose or fix an unfixable problem, and look for a workaround instead).
All in all, this is just a "heads-up" that Apple is using a lot more of the newer instructions in MacOS, and that's likely to only get worse as time goes on. We're (collectively) going to need to get more creative (or at least fault-tolerant ;-) if we're going to keep these old machines chugging along...
(This analysis is a work in progress; I'll post updates as I refine my findings. This will include a detailed list of programs/libraries/etc. that definitely contain SSE4.2 and/or AVX+ instructions. And before anybody asks, I have not performed this level of analysis on any MacOS prior to 10.15.4, which includes Mojave and High Sierra. I've done spot checks and localized scans, but never a system-wide scan. It would be interesting to compare 10.15.4 to prior versions of both Catalina and Mojave, to see the progression of these instructions and when they were introduced, but that's a task for another day and/or someone else.)
Update 1: preliminary list of Catalina executables containing SSE 4.2 instructions.
Update 2: preliminary list of Catalina executables containing AVX/AVX2/AVX-512 instructions.
Last edited:
On my MacPro 3,1 with GTX680, after purging out AAAMouSSE.kext, the only ill-behaved software is the TV.app playing streamed content. My understanding is that AAAMouSSE.kext advertises availability of SSE4,2 support to OS. So the fact that it is incomplete emulator of the full SSE4,2 extensions would seem to be more likely to be problematic than not using it.
I tried with a 10.5.3 installer patched :
csrutil enable --no-internal : stil Apple internal enabled
csrutil disable : still Apple internal enabled
I'ill try the patcher 1.3.6...
Serviteur
Actually, MouSSE doesn't "advertise" anything at all. I couldn't find a reasonable way to trap the CPUID instruction to modify the SSE4.2 flag (and I wouldn't have done so unless/until the emulator was complete), so MouSSE simply catches any SSE4.2 instructions that actually get executed - if a program tests CPUID for SSE4.2, that test will fail whether MouSSE is installed or not. Beyond that, MouSSE is passive, and its "incompleteness" is irrelevant - it handles the instructions it knows, and it passes everything else on to the kernel, which does whatever it would have done without MouSSE installed. As I noted, it does have a few bugs, but those shouldn't be noticeable for those using MouSSE just for the AMD drivers. And if you don't have an AMD video card, you shouldn't bother loading MouSSE (unless you have another SSE4.2 application that MouSSE might help, such as World of Warcraft).
Thank you so much for your answer.
I did that and is not bad idea, the problem is with pictures with 16:9 or more panoramic in full Screen crashed, it's also for Metal? or this have any solution? I read some page of this thread but is bigger. I think like you, it might deserve a separate thread.
I updated all my computers to 10.15.4, but i notice a failure in my macbook 5.2. (but this problem was in 10.15.3 in this computer too).
The webcam works well in Photoboth, but in facetime i can't see the webcam. I only see a black square. The cam only can't work in facetime.
But the mystery is the following: if I shut down the computer with the facetime app opened and i reboot, the facetime app will open at start and... The cammera works!!. If I close facetime and i start it again, the cammera doesn't work. But it still works if I open the Photoboth app.
I deleted all preference files of facetime with preferencecleaner, but it do nothing.
Any idea about how to solve it?
Regards.
The webcam works well in Photoboth, but in facetime i can't see the webcam. I only see a black square. The cam only can't work in facetime.
But the mystery is the following: if I shut down the computer with the facetime app opened and i reboot, the facetime app will open at start and... The cammera works!!. If I close facetime and i start it again, the cammera doesn't work. But it still works if I open the Photoboth app.
I deleted all preference files of facetime with preferencecleaner, but it do nothing.
Any idea about how to solve it?
Regards.
jhoawarth
I wondered about that, but Apple themselves suggest that all machines that support Metal also support Mojave and Catalina. Is this only an issue for Macs where the graphics card has been upgraded?
Anyway, thanks for the clarification.
Weird :
csrutil status with a recovery method (booting from a 10.15.3 installer) : Apple Internal : disabled
csrutil status with a "normal" method (booting from my SSD 10.15.4 patched 1.3.5) : Apple Internal : enabled
Just for info...
Serviteur,
csrutil status with a recovery method (booting from a 10.15.3 installer) : Apple Internal : disabled
csrutil status with a "normal" method (booting from my SSD 10.15.4 patched 1.3.5) : Apple Internal : enabled
Just for info...
Serviteur,
I am currently downloading and installing 10.15.5 beta 1, if will work with ASentientBot wrappers, I'll release the method to allow the APFS OTA update installer also for non-APFS machines.
To those who are using CatalinaOTAswufix, don't worry, the funny apple has introduced during OTA stage2 a full black loading bar, but don't discourage just wait on the black bar for 10 minutes and OTA installer with Catalina circle will proceed smoothly.
To those who are using CatalinaOTAswufix, don't worry, the funny apple has introduced during OTA stage2 a full black loading bar, but don't discourage just wait on the black bar for 10 minutes and OTA installer with Catalina circle will proceed smoothly.
Attachments
I have a very unusual issue, hoping some of you may know how to fix.
Yesterday I converted yet another Mac Pro to Catalina (did a few 5.1 and 4.1 in the past).
I used open core to update the Mac, and then completely removed open core again trying to narrow down a very strange problem. It is now running with boot-args only, no patches or changes to MacOs
The problem:
My Mac Pro 5.1 enters the clamshell mode, making the connected display useless! It is a dual cpu, 12 core, max config Mac with a Macvidcards NVIDIA GTX 780 3GB.
The Mac did run without any issues on Mojave for quite some time, and this problem showed up right after updating to Catalina. I also had to set the Monitor to protocol version 1.1 from 1.2, which never was an issue before.
The monitor is connected via DP to DP cable.
In the console I get the log message: PMRD: Clamshell enabled
Any ideas how to fix this?
Many thanks in advance for any hints.
Yesterday I converted yet another Mac Pro to Catalina (did a few 5.1 and 4.1 in the past).
I used open core to update the Mac, and then completely removed open core again trying to narrow down a very strange problem. It is now running with boot-args only, no patches or changes to MacOs
The problem:
My Mac Pro 5.1 enters the clamshell mode, making the connected display useless! It is a dual cpu, 12 core, max config Mac with a Macvidcards NVIDIA GTX 780 3GB.
The Mac did run without any issues on Mojave for quite some time, and this problem showed up right after updating to Catalina. I also had to set the Monitor to protocol version 1.1 from 1.2, which never was an issue before.
The monitor is connected via DP to DP cable.
In the console I get the log message: PMRD: Clamshell enabled
Any ideas how to fix this?
Many thanks in advance for any hints.
Arduino: still works in 10.15.4, with the usual replacement of AppleUSBACM.kext in /System/Library/Extensions/ with the one from High Sierra.
Thanks again ASentientBot!
Thanks again ASentientBot!
DisplayPort does not work on nVidia cards under any Catalina version, for some reason. You will need to use either HDMI or DVI to connect your monitors.