[Release] macOS 10.15.4 is out!

[MorenoAv]

Before I migrated from Clover 5108 to OpenCore 0.5.7 I did have the same problem. After migrating I made the 2 updates easily and all is well now...

[deeveedee]

16 minutes ago, MorenoAv said:

Before I migrated from Clover 5108 to OpenCore 0.5.7 I did have the same problem. After migrating I made the 2 updates easily and all is well now...

 

I need to check out OpenCore.

[deeveedee]

1 hour ago, Hervé said:

3) on Wolfdale C2D Dell Vostro 200 (GeForce GT730); Clover r5107

-> straight update; worked perfectly as would normally be expected.

-> BIOS settings/CMOS reset issue still present

 

Do you have a real or fake EC on your Vostro 200?

 

[deeveedee]

15 minutes ago, Hervé said:

@tonyx86, 

 

Your E6410 installation was probably different in that I guess you used Dosdude1's patcher.

 

The Catalina 10.15.4 installer behaves the same (same errors) whether I use DosDude patcher or vanilla Catalina installer.  

 

When using the DosDude patcher on my Latitude E6410, I set my SMBIOS MacModel to MacBookPro6,2.  When using a vanilla installer, I set my SMBIOS MacModel to iMac14,2 and no NVidia Injection.

Edited April 9, 2020 by tonyx86

[madicineman]

Got problems with the March-update. Apple logo with bar stuck at 80%. Verbose mode reveiled igpu problem (see pic, i7) and firmware-problem . -disablegfxfirmware resulted in Black screen after first boot sequence. Same after disabling internal gpu or „automatic“ setting in bios of MB (Z170 Gaming 7). All clover graphic injections made no change. Clover is new. Too me it looks like firmware loading blocks boot if igpu is enabled in bios. Disabling igpu in bios uncovers that the RX 580 does  not kick in. Could you please help me, please?

[deeveedee]

There is a report in another forum that the BIOS reset problem is still present in 10.15.5.

 

Does anyone whose DSDT has a "real EC" have the BIOS reset problem?

Edited April 11, 2020 by tonyx86

[deeveedee]

I created a 10.15.4 installer USB with an expanded Basesystem.dmg and replaced /S/L/E on the 10.15.4 installer with the 10.15.3 /S/L/E.  The installer doesn't boot, but it still resets my CMOS/BIOS.  I'm not certain, but I believe this indicates that the CMOS/BIOS reset problem is not caused by a kext in /S/L/E.  Maybe this offers a clue to people who know more about this stuff than I do?

[deeveedee]

CMOS reset happens when booting 10.15.4 installer USB in safe mode, too.  The installer aborts and reboots prematurely when booted in safe mode, but the CMOS reset happens anyway.

 

EDIT: Someone in another forum reported that adding Clover boot-arg "slide=0" fixed the CMOS reset problem for them.  This did not work for me - reporting here in case it helps someone.

 

EDIT2: Whatever is causing the CMOS reset is happening very early in the Catalina 10.15.4 boot cycle.  If I reboot my desktop when the Apple appears (before the progress slider appears), CMOS reset has already occurred.

Edited April 11, 2020 by tonyx86

[deeveedee]

2 hours ago, Hervé said:

Ok, 'found the culprit: it's boot.efi (in /S/L/CoreServices).

 

Great detective work!

[kode54]

On 4/6/2020 at 8:26 AM, CMMChris said:

Yes because you forced software decoding and the shiki-hack for this likely got broken in this update.

I thought I forced hardware decoding, but you're welcome to tell me otherwise. Forcing hardware decoding now sort of works, but again, results in signature checks validating the patched library and it crashes due to signature mismatch. Apple TV+ sometimes works if I force hardware decoding, but sometimes randomly crashes. Netflix in Safari crashes within 5-10 seconds of playback.

 

If I remove the shikigva option, or set it to 128, I just get no hardware decoding at all, and DRM is broken, but videos "play" with a flashing red and black picture. I guess the patches need adjustment for newer systems.

[CMMChris]

2 hours ago, kode54 said:

DRM is broken, but videos "play" with a flashing red and black picture. I guess the patches need adjustment for newer systems.

No, it's an AMD Hackintosh issue as I already told you. The problem has been around for years. On some machines you just can't get hardware acceleration to work properly for whatever reason. There are no issues at all on Intel based machines. On iMacPro1,1 it just works without any shiki boot args or Whatevergreen.

 

2 hours ago, kode54 said:

I thought I forced hardware decoding

By using iMacPro1,1 you are already forcing hardware decoding and encoding through your dGPU. No boot args necessary for that. Your shiki boot args forces software decoding. Read the reference to understand what the numbers are doing.

[el_charlie]

16 hours ago, Hervé said:

Ok, 'found the culprit: it's boot.efi (in /S/L/CoreServices).

 

Obviously, something was quite different in 10.15.4 with all those new early info lines when booting in verbose mode so I replaced 10.15.4's boot.efi by 10.13.6's since I still have a separate High Sierra partition on my Vostro 200. 10.15.4 still booted properly thereafter and I was able to reboot repeatedly without CMOS reset. I recovered 10.15.3's own boot.efi and achieved the same success with it.

 

I guess we would need to try and hex compare (or disassemble compare) both boot.efi files to see if the difference can be sussed out in order to develop an eventual patch rather than a rollback but there is an additional 17KB of code in 10.15.4's file so I'm quite doubtful about this... Rollback will probably prevail anyway, especially as the number of affected people probably isn't huge.  

• good: 10.15.3_boot.efi.zip
• bad: 10.15.4_boot.efi.zip

 

Change file ownership to root:wheel upon replacement.

 

 

Well, I replaced my 10.15.3 boot.efi to my other 10.15.4 partition and I still get a CMOS reset. Of course on .3 I don't get a reset, it's just on .4. I use legacy BIOS (P55 motherboard).

 

What could it be? @Hervé

[deeveedee]

My HackPro5,1 (full specs below) does not boot 10.15.4 the first time unless I temporarily add boot-arg "amfi_get_out_of_my_way=1".  Without this additional boot-arg, Catalina 10.15.4 boots to a "prohibited" sign.  After booting once with "amfi_get_out_of_my_way=1" I no longer need this boot arg.

 

My boot-args = -no_compat_check

 

My system is as follows:

• macOS: Catalina 10.15.4.02
• SMBIOS MacModel MacPro5,1
• Clover (Legacy) r5109
• Socket 1156 / H55 Chipset / Xeon X3460
• Graphics: Sapphire Pulse RX580

 

Edited April 13, 2020 by tonyx86

[deeveedee]

I have been using SMBIOS MacModel MacPro5,1 on my rig for High Sierra, Mojave and now Catalina.  With this correct MacModel (closest match to my system), my system CPU Power Management is perfect.  No need for any Clover CPU configs.  Through 10.15.3, I had no need for amfi_get_out_of_my_way=1 and didn't find this necessary until 10.15.4.  Without this, 10.15.4 boots to a prohibited sign.

 

I won't be changing to a different MacModel, so amfi_get_out_of_my_way=1 is very relevant to my system and works perfectly.  Thanks for finding the boot.efi trick.

 

Also, despite the fact that Catalina has "officially" dropped support for the MacPro5,1, MacPro5,1 is still included in Catalina's IOUSBHostFamily.kext.

Edited April 12, 2020 by tonyx86

[deeveedee]

Just now, Hervé said:

I can only guess that you must have made a Dosdude1's patched installation on this workstation. To me, it's not required, a bog standard installation would work perfectly with 1) a supported SMBIOS or 2) a patched SupportPlatform.plist or 3) the -no_compat-check flag.

 

I see absolutely no reason to use Dosdude1's patcher on that rig (other than the obvious) and no reason why you would need amfi_get_out_of_my_way=1 boot parameter; it's for legacy GPU such as, say, nVidia Tesla as you must have gathered in the MacRumors 10.15.4's thread that you closely follow on a very regular basis.

 

 

I don't need DosDude patcher on this rig - it's an RX580.  I do use DosDude patcher on my Latitude E6410 (NVidia) and it works great.  I don't know what to say.  amfi_get_out_of_my_way=1 does the trick for me with this vanilla Catalina installation.  You know more about this stuff than I do, so I have nothing else to add.

[Rocky12]

                          

                           hervé you are absolutely fantastic

 

               ladies and gentlemen the man of the day hervé  RTC  killer 

 

                  all the credit goes to you my friend no more cmos reset  

 

           working on my X58 Clover 5103 Cat 10.15.5 applied clover rtc patch and replaced the boot.efi

                  

Edited April 13, 2020 by Rocky12

[deeveedee]

1 minute ago, Hervé said:

The reference to IOUSBHostFamily kext is totally irrelevant here. It makes absolutely no difference and bears no link to the fact that MP5,1 is an unsupported platform for Catalina. It may have been a simple oversight for all we know.

 

Ugghh.   Always a pleasure, Herve.  IOUSBHostFamily kext provides the EHC1 and EHC2 USB power properties.  I was only mentioning it to indicate that Catalina still supports MP5,1 albeit not officially.  

 

I give up.  No sense in trying to have a civilized conversation is there.

[jsl2000]

On 4/12/2020 at 7:39 AM, Hervé said:

Ok, 'found the culprit: it's boot.efi (in /S/L/CoreServices).

 

Obviously, something was quite different in 10.15.4 with all those new early info lines when booting in verbose mode so I replaced 10.15.4's boot.efi by 10.13.6's since I still have a separate High Sierra partition on my Vostro 200. 10.15.4 still booted properly thereafter and I was able to reboot repeatedly without CMOS reset. I recovered 10.15.3's own boot.efi and achieved the same success with it.

 

I guess we would need to try and hex compare (or disassemble compare) both boot.efi files to see if the difference can be sussed out in order to develop an eventual patch rather than a rollback but there is an additional 17KB of code in 10.15.4's file so I'm quite doubtful about this... Rollback will probably prevail anyway, especially as the number of affected people probably isn't huge.  

• good: 10.13.6_boot.efi.zip
• good: 10.15.3_boot.efi.zip
• bad: 10.15.4_boot.efi.zip

 

Change file ownership to root:wheel upon replacement.

 

Thanks for your solution which works by booting with Clover r5107 of 10.15.4, but not working by booting with Legacy OpenCore.

Can you confirm whether it also working at 10.15.5 beta or booting by OpenCore too ?

[jsl2000]

1 hour ago, Hervé said:

Nope, not using either of those.

 

Re: Clover, it's not related to r5107 at all. The Vostro200 on which I worked this out runs r5093.

I can confirm that your solution also worked at 10.15.5 beta with Clover r5107, but not worked with OpenCore yet.

[telepati]

@Hervé could you please read this;

https://github.com/acidanthera/bugtracker/issues/765#issuecomment-612739325

[jsl2000]

12 hours ago, Hervé said:

@jsl2000, does it mean that with OC, boot.efi is not loaded?

 

There is a field in Clover called "Default loader". I've often seen it with "boot.efi" specified there. I've tried to play with it to no avail. I don't really know what this field actually does so I can't say if this could be used as an alternative to replacing boot.efi in /S/L/CoreServices.

 

Yes, I think boot.efi was not loaded with OpenCore bootloader.

No such an option as "Default loader = boot.efi" found in OpenCore setting I have tried to find. Hope that OC team can fix it as soon as possible.

[Edit]

Maybe another boot.efi located in /usr/standalone/i386 need to be changed with OpenCore bootloader to work ?

Edited April 14, 2020 by jsl2000

[el_charlie]

On 4/12/2020 at 1:47 PM, Hervé said:

Boot in single-user mode and tell us what you see right when the boot start. Try and take a picture if you can. Restart your computer once you reach single-user prompt and tell us if CMOS reset has occurred or not.

• 10.15.4's boot.efi results in a screenful of somehow slowly displayed lines starting with [EB] that end with a line of +++++++++ before the screen goes black and the usual verbose stuff gets rapidly displayed as system boots.
• 10.15.3's boot.efi results in 1 x quick line of +++++++++ before the screen goes black and the usual verbose stuff gets rapidly displayed as system boots.

Make sure to repair file ownership after replacement. You could also try 10.13.6's boot.efi (as I did initially), I've added it to my post above. If, despite all this, you still get CMOS reset then yours is not boot.efi related which would mean there's a different use case for you; I won't be of much assistance then because I won't be able to reproduce and analyze, sorry.

 

 

Like many people has posted here, I also can confirm that my CMOS reset is gone with Clover. I have a Clover r5107 USB drive and booted with it and with the 10.15.3 boot.efi and no more CMOS reset. I experienced a reset with OpenCore 0.5.7. Now it's their turn to chime in.

 

Thanks for such and important finding.

[jsl2000]

16 hours ago, el_charlie said:

 

Like many people has posted here, I also can confirm that my CMOS reset is gone with Clover. I have a Clover r5107 USB drive and booted with it and with the 10.15.3 boot.efi and no more CMOS reset. I experienced a reset with OpenCore 0.5.7. Now it's their turn to chime in.

 

Thanks for such and important finding.

Maybe another boot.efi located in /usr/standalone/i386 need to be changed with OpenCore bootloader to work ?

[Edit]

It can NOT be fixed by this method for OpenCore bootloader.

Edited April 14, 2020 by jsl2000

[jsl2000]

1 minute ago, Hervé said:

Good point. The boot.efi located there certainly appears to be the same at that located in /S/L/CoreServices. Give that a try.

It can NOT be fixed yet by this method.

[jsl2000]

1 hour ago, Hervé said:

What makes say that it can NOT be fixed that way?

 

What does your preboot.plist (in /usr/standalone/i386) show as Default Bless Path (for hfs and/or apfs)? On my Vostro200, it was set to /S/L/CoreServices for both...

Yes, my preboot.plist show as yours:

Default Bless Path for both to /System/Library/CoreServices/ too.

After booting with OpenCore at 10.15.4 or 10.15.5 beta reboot always got CMOS BIOS reset !

No such an issue if booting with Clover r5107.

Edited April 14, 2020 by jsl2000