macOS won't work after CPU Upgrade about optihack

[JohnAker33]

@TheRedHugo did you replace the original CMOS battery ? If not I would do that. If it's the original it's 8 years old and may not be holding the changes to UEFI you are making. I've seen this quite of few times on these older Dells. The CMOS battery hasn't completely failed but it's too weak to hold an adequate charge.

[TheRedHugo]

Monterey is also working normally now, I changed SecureBootModel back to default and it's also working so I'm not really sure what's going on🤨

Maybe it's a dying HDD which I'll check tomorrow, since this time I have installed macOS on a portable SSD

I also found out why there were no Debug Logs. You need to change the following in the config.plist
Misc>Debug>Target>67

Thank you for your help :D

I also wanted to say thank you for providing, constantly updating and documenting OptiHack so well. It's a really good way to get started with Hackintosh on a DELL, especially when you don't understand much of it. It makes it way easier to learn it all.

[zearp]

Have you tested if swapping the old CPU back makes it boot again?

Also try booting a fresh download of the EFI from a usb stick. Just to mak sure the EFI on the disk is not damaged.

It is very very unlikely the EFI can't boot your specific 4th gen i7 CPU or that the solution is somewhere in the EFI.

Your bootlog shows errors relating to power managed/sleep. Try replacing the OpenCore binaries with debug versions so you get a more useful bootlog.

https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/debug.html

I also noticed that after upgrading the CPU some new options appeared in the UEFI Settings, but I've disabled these.

Which options exactly?

[zearp]

This DEBUG build matches the latest release on the repo:
https://github.com/dortania/build-repo/releases/download/OpenCorePkg-c7844da/OpenCore-0.8.0-DEBUG.zip

It will produce a better log and places it in the EFI root folder.

I've swapped all my i3's for i5's or i7's and have not run into this issue myself. Not sure if I got one with the exact same i7 as yours.

[TheRedHugo]

I was using the latest EFI, I only use the backup to transfer the PlatformInfo so I don't lose it.
I've also written an exact step by step of what I was doing so maybe that helps too :D

I noticed the following new UEFI Settings:

Performance> Intel Turbo Boost> Enable Intel Turbo Boost(Default: YES)
Performance> HyperThread control> HyperThread control(Default:YES)
Virtualization Support> VT for Direct I/O>Enable VT for Direct I/O(Default:YES)
Virtualization Support>Trusted Execution>Trusted Execution(Default:NO)
-Requires TPM, Virtualization, Direct I/O to be enabled

-Downloaded the latest OptiHack release and replaced the following binaries:

/Drivers/HfsPlus.efi ---> /Drivers/OpenHfsPlus.efi (DEBUG)
/Drivers/OpenRuntime.efi ---> /Drivers/OpenRuntime.efi (DEBUG)
/OpenCore.efi ---> /OpenCore.efi (DEBUG)

-Entered the following into config.plist:

MLB, ROM, SystemSerialNumber, SystemUUID
SystemProductName: Macmini7,1

I also did another UEFI Reset according to the guide
After that I changed the following settings in UEFI:

Date and Time
General>Advanced Boot Options> Enable Legacy Option ROMs> YES (from NO)
System Configuration> Integrated NIC> Enabled (from Enabled w/ PXE)
Performance>Intel Turbo Boost> Enable Intel Turbo Boost> NO (from YES)
Performance>HyperThread control> HyperThread control>NO (from YES)
Virtualization Support> VT for Direct I/O>Enable VT for Direct I/O>NO (from YES)

Applied all setup variables with modGRUBShell.efi
Tried booting macOS BaseSystem using the i7-4770
Failed booting with the same result as shown in the beginning

Swapped CPU with i3-4150 which has originally been used for macOS on this PC
Tried booting macOS BaseSystem
Failed booting with the same result as shown in the beginning

Took out one of the three ram sticks which recently got upgraded
No changes in result

Conclusion:

OpenCore didn't save any logs to the EFI Partition!
The problem is consistent across both CPUs so I think the problem seems to be something else

[zearp]

Given both CPU's give the same results (which I expected) it is fair to conclude the issue must be somewhere else. The OpenCore log is very cryptic. I used to have a list with all the abbreviations and what they means but I don't have it handy at the moment.

What I suspect is a RAM thing. Try reseating the sticks, maybe clean them and swap them too. If other operating systems boot fine then it could be software somewhere but I wouldn't know where as clearing BIOS.NVRAM didn't help you. There's not much else that could mess with it or cause such an early boot failure.

If your BIOS settings are ok and UEFI edits are made correctly then you should be able to boot. Does the same happen with older releases of the EFI?

For me it's difficult because I can't reproduce the issue or ran into it myself. Also weird the debug version didn't save the boot log. It should save it in the root of the EFI partition OpenCore was booted from.

[zearp]

@JohnAker33 Very good point! They are likely very worn being office machines and all. I always replace them with a new one by default.

[TheRedHugo]

@TheRedHugo did you replace the original CMOS battery ? If not I would do that. If it's the original it's 8 years old and may not be holding the changes to UEFI you are making. I've seen this quite of few times on these older Dells. The CMOS battery hasn't completely failed but it's too weak to hold an adequate charge.

I changed the CMOS battery not too long ago so that can't be the issue

[JohnAker33]

It should be tested with a multimeter and read at least 3.3v. I've bought supposedly new CMOS batteries on Amazon that had been on the sellers shelf for years. They didn't work, tested with my multimeter and they weren't adequate under load. So I replaced it again and then things worked.

[TheRedHugo]

It should be tested with a multimeter and read at least 3.3v. I've bought supposedly new CMOS batteries on Amazon that had been on the sellers shelf for years. They didn't work, tested with my multimeter and they weren't adequate under load. So I replaced it again and then things worked.

Okay I will try it

[TheRedHugo]

Okay so I changed the CMOS Battery with a new one, but it's the same problem :(

[TheRedHugo]

I have made some Progress.
I have generated a new SSDT-PLUG.aml and SSDT-EC.aml using SSDTTime according to the official OpenCore Guide and put it into the OptiHack EFI. I was able to boot into Catalina Recovery and I'll try to install it now

[TheRedHugo]

So it only booted into Recovery and started installation but after the reboot it resulted in almost the same error as in the beginning. I now changed SecureBootModel to Disabled and continued the Catalina installation

[TheRedHugo]

Okay I have Catalina running perfectly now, I will try Monterey or at least Big Sur shortly

[zearp]

I'm glad its fixed! Still weird you got the error. I know resetting NVRAM from the OpenCore menu doesn't really purge everything in there. Maybe something left behind there caused some kind of weird conflict with SecureBoot and disabling it made that go away and once macOS sorted NVRAM out enabling it worked again. If it ever happens again it would be interesting to have a full NVRAM dump. I'll also look into if there's any tools that can fully wipe NVRAM clean. Too late for you now but might be good to have in the future.