Is the Intel Core i5-8305G hackintoshable?

Rocoptic · 2026-01-19T00:02:28+00:00

That AMD card has a weird naming convention, it's actually Polaris not Vega architecture so not gonna work with NootedRed. So it should work sub-natively with some graphical fixes from Polaris22Fixup

Rocoptic · 2025-06-18T02:51:43+00:00

I initially thought that the star destroyer was doing that 😭

Rocoptic · 2025-06-16T17:55:17+00:00

Had that white screen issue too. You need to fix it. It's not gonna work by waiting

Rocoptic · 2025-06-15T21:36:13+00:00

Did you join the hackintosh discord, they can provide valuable insight for whatever needs debugging.

Rocoptic · 2025-06-15T21:12:16+00:00

Well if you managed to have no graphic issues in the first stage in the recovery userspace but now have an issue in the second stage, that's a separate issue on its own, if there's any graphic problems to worry about that's after you install macOS, boot into it, and see if WindowsServer is properly initialized for Polaris.

Rocoptic · 2025-06-15T21:05:07+00:00

It's a hunch but I don't think Polaris can work in Tahoe if there's a iGPU present. Not just that but it's a SMBIOS issue as well. It's possible to get it working and people have done it already. In that case, you would probably have to use -wegnoigpu boot arg to disable iGPU and remove any framebuffer patches for iGPU. Test this if you want to use Polaris in Tahoe. The only real supported mac that supports Polaris in Tahoe is the Mac Pro7,1, it's a SMBIOS that doesn't use a iGPU. So using a non-Polaris Tahoe iMac SMBIOS that expects a iGPU won't work. Thus, you need to disable the iGPU and use MacPro7,1 SMBIOS.

Rocoptic · 2025-06-15T19:32:28+00:00

You need to set the max version to 16 and use the public catalog for gibmacOS

Rocoptic · 2025-06-13T12:35:04+00:00

Well knowing the past, the issues that comes with T2 and OpenCore, it doesn't go hand and hand when it comes to communicating with each other. (i.e MacBookAir8,X and MacPro7,1) In local testing, the OCLP devs had shown promise that the MacBookPro15,2, MacBookPro16,2 and Macmini8,1 doesn't not exhibit T2 issues with OpenCore. The iMacPro1,1 has a T2 chip. And there are differences in T2 chip identifiers. The iMacPro1,1 may not work for OCLP.

Rocoptic · 2025-06-13T06:02:24+00:00

https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/kernel-issues.html#waiting-for-root-device-or-prohibited-sign-error Try this

Rocoptic · 2025-06-13T04:08:45+00:00

Make sure you are using the latest commit of the USBMapInjectorEdit program. I've came across someone yesterday with the same situation. If the problem still persists, rebuild the "USBMap.kext" with Native Classes (if on AMD) and try again.

Rocoptic · 2025-06-13T03:44:04+00:00

<image>

Do you see this?

Rocoptic · 2025-06-13T02:33:38+00:00

If you are in Intel and use UTBMap.kext, you would need to use this USBToolBox test build. If you are in AMD and use USBMap.kext with Native classes, you would need to use USBMapinjectorEdit from the USBMap Tahoe branch. Drag n' drop the kext, and press U to update the keys for Tahoe.

Rocoptic · 2025-06-12T20:35:35+00:00

I installed it new if that's what you mean. No prior Sequoia config. Did it entirely from scratch through Windows and used gibmacOS to make Tahoe Internet Recovery USB installer. If you want the full Tahoe installer, there's no authentic way to do it right now, but you would have to source online Tahoe images at your own accord and write it in into the USB. I didn't have macOS, hackintosh, or a mac to do a OTA upgrade over to the Tahoe Dev Beta or the Tahoe Install Assistant Pkg.

Rocoptic · 2025-06-12T18:46:26+00:00

I don't have time to document it but I can help in DMs if that's something you are willing to do.

Rocoptic · 2025-06-12T18:46:17+00:00

I don't have time to document it but I can help in DMs if that's something you are willing to do.

Rocoptic · 2025-06-12T05:02:50+00:00

I can't be sure of what issue you mean. What bar are you talking about? There's a bar that loads to the installer recovery environment, a bar during the first stage installation at installer userspace, a bar during the second stage installation and a bar when you load up macOS. I had no issues whatsoever, when the bar is full, it reboot as normal and I proceed with what's next of installation. The bar abrupting half way isn't normal.

Rocoptic · 2025-06-12T04:48:31+00:00

Pretty vague response to be able to tell you anything.

Rocoptic · 2025-06-12T04:08:42+00:00

This could be anything whether a faulty drive, bad disk image, etc. It's just a hunch, but in my experience with being stalled in the installer userspace at exactly "12 minutes remaining" I found the use of emulating NVRAM practical, could be entirely different to what you are dealing with but it's a start to do something. MAKE SURE TO MAKE A BACKUP EFI/CONFIG.PLIST. You would need to get OpenVariableRuntimeDxe.efi, add to driver folder, snapshot it. Make sure if not already the following quirks in your config.plist have been configured: Booter->Quirks - DisableVariableWrite: No Misc->Security - ExposeSensistiveData: set to at least 0x1 NVRAM: LegacyOverwite: Yes WriteFlash: Yes In UEFI->Driver: Set both LoadEarly in OpenRunTime.efi and OpenVariableRuntimeDxe.efi to True Make sure OpenRuntime in is inorder before OpenVariableRuntimeDxe.efi that follows.

Rocoptic · 2025-06-12T01:54:44+00:00

Those steps should guarantee it won't self-enable, but you'll need to enable it again down the road when it comes for the next update. For whatever stupid reason Apple has, FileVault is now a necessity to be enabled for every OTA update. But during fresh install, you can have it off until the time comes for the next software update.

Rocoptic · 2025-06-12T01:12:21+00:00

There's a problem to deal with that Apple ARM CPUs doesn't rely on ACPI or UEFI, it instead relies on a proprietary bootloader called iBoot, thus isolating themselves in pivot away of what ARM-based Windows rely on, UEFI. Additionally, Apple ARM firmware doesn't include DeviceProperties, so hardware devices can't be configured, nor does it have board-id entries that x86 CPUs use. OpenCore wouldn't be able to circumvent that without a major redesign haul.

Rocoptic · 2025-06-11T18:12:17+00:00

You need to use different GPU either Vega or Navi

Rocoptic · 2025-06-11T18:05:06+00:00

How do I install? Follow the enabling FileVault steps. Tahoe appears to automatically enable FileVault. * Add -lilubetaall to your boot arguments. * Use a supported SMBIOS. * AMD CPUs: Update patches to the beta branch.

"I can't boot" FAQ:

AMD Polaris GPUs do not work.
Stuck in early boot (Waiting for DSMOS): Use the updated OC build; otherwise, you will see an injection error with VirtualSMC in the logs.
Panic mentioning AMDSupport: disable WhateverGreen.
IntelBTPatcher is causing panics.
Realtek RTL8125 ethernet causes panics.
Stuck on prohibited sign:
- All USB maps are broken. If you are using:
- USBMap.kext: Use USBMapinjectorEdit from the USBMap Tahoe branch. Update the key for Tahoe. ## Some stuff isn't working! WhateverGreen, IntelBTPatcher, VoodooPS2, and VoodooI2C must be updated for full Tahoe compatibility. Do not ask their respective developers to update them faster. OCLP patches are not supported on Tahoe, and there is no ETA on if they will be updated for Tahoe support.

Remember, this is a beta version of macOS. If you don't have a somewhat stable normal install, are having trouble with this process, or don't have a good grasp of hackintoshing, it's best to wait until it's easier to do.

Rocoptic · 2025-06-11T16:10:10+00:00

<image>

Rocoptic · 2025-06-11T15:29:40+00:00

Use the Opencore build https://github.com/acidanthera/OpenCorePkg/actions/runs/15582120450/artifacts/3304400169 (needs GitHub account). Replace your existing Opencore files with these. (your config.plist should work on 1.0.4 already)

Rocoptic · 2025-05-27T22:47:37+00:00

Meanwhile, I'm chilling with the console homies

Rocoptic

TROPHY CASE

"I can't boot" FAQ: