zearp / OptiHack

Dell OptiPlex 7020/9020 Hackintosh Stuff
https://zearp.github.io/OptiHack/
155 stars 53 forks source link

macOS won't work after CPU Upgrade #73

Closed TheRedHugo closed 2 years ago

TheRedHugo commented 2 years ago

Hey, I need some help because I can't figure out a solution by myself.

I recently upgraded my OptiPlex 7020 from an i3-4150 to an i7-4770 and since then macOS won't boot into the installer. I tried the latest release of OptiHack and also an older one I had backed up, which I knew worked for Catalina. I tried the Recovery Image for Catalina, Big Sur, Monterey and neither would boot to macOS. I redid all the steps from the tutorial and also tried a UEFI Reset as specified in the guide. I also noticed that after upgrading the CPU some new options appeared in the UEFI Settings, but I've disabled these. I also included a screenshot which is the only thing that shows from trying to boot macOS, before rebooting.

screenshot

zearp commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

JohnAker33 commented 2 years ago

@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.

zearp commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

TheRedHugo commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

TheRedHugo commented 2 years ago

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 commented 2 years ago

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.