Closed TheRedHugo closed 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?
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.
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
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.
@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.
@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 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
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.
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
Okay so I changed the CMOS Battery with a new one, but it's the same problem :(
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
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
Okay I have Catalina running perfectly now, I will try Monterey or at least Big Sur shortly
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.
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.
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.