[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[djx8605]

I've never installed kext in /L/E/ folder before. Even with nacOS 10.15.1 Catalina. Even when I updated from Mojave to Catalina through System Preferences > Software Updates > Catalina install/update app.

But sure, if it works, why not. I mean, to each their own.

I've never even used TonyMac tools for Clover before. I guess it installs to /L/E/, too.

So do you install them to S/L/E? or do you have them injected each time? Hopefully you are not just using injection

 

[CODYQX4]

If you have multiple drives installed at installation time, and you are using the Windows setup, Windows will try to create its EFI boot files on whatever drive it finds with an existing EFI partition. Otherwise, it may try to find the lowest drive number and create its EFI files in that EFI partition, if the drive is GPT. If it can't do this, it will sometimes display the dreaded "Windows cannot be installed to this drive" error.

Depending on what you are trying to accomplish, you could do one or the other:
1. (easy way) let Windows set itself up on whatever drive it wants, then alter the path of the bootloader using bcdedit. This should let you point windows loader to clover, so instead of windows booting itself, it would think it's loading itself but would really be loading clover.
You could do this from a windows command prompt like so: bcdedit /set {bootmgr} path \EFI\Clover\Clover.efi
This command assumes Clover and the Windows loader are on the same EFI...

2. you can use BCDBoot to create the EFI partition for booting on any partition you'd like. On my laptop for example, I manually created the EFI partition, then a second fat32 partition, then the 2 main OS partitions for macOS and Windows. I then placed clover on the normal "EFI" partition, and to avoid Windows from messing with it, I used BCDBoot to create the EFI boot files on the second fat32 partition. Then I tell Clover to load the bootmgfw.efi from there, and everything works as expected!

In your case, if what you want is for windows to dump EFI boot files into a partition, then mount the partition you want to put the files in using diskpart like so:
Assume that the files are going to the first partition of drive 0, so:
sel disk 0
sel part 1
assign letter=w
then run MyNewPartitionLetter:\Windows\System32\bcdboot.exe MyNewPartitionLetter:\Windows /s W:
This should work, and will place all the required boot files into partition W: which can be whoever partition you mount to that letter... The reason your bcdboot command was probably failing is because you didn't have whatever partition you wanted to copy to mounted, or you didn't indicate what that partition was after the /s switch.

The trick to all this is to not remove Windows or invalidate its loader, otherwise Windows will forcefully create a new loader entry and add it to NVRAM. This is why you may see multiple Windows loader entries, or get the Windows constantly resetting itself as the default loader/os when you boot it... By creating its EFI setup on a separate fat32 partition, or altering the bootloader path, Windows thinks everything is fine with its bootloader, so it doesn't make any NVRAM modifications or alterations to the boot orders...

Finally, an FYI (just in case you or anyone else is not aware) since you are manually applying the windows image using dism, you don't even need to run the windows setup, unless you want all the extra partitions created. I usually just use Diskpart to clean the disk, create my own partition layout, apply the required windows image, create boot files, then boot. As you discovered, this will continue Windows setup once it reboots. I have found that doing things this way let's me have more control over the entire process, which comes in handy to keep both macOS and Windows happily living together (no MS reserved partitions to deal with or recovery partitions etc.) of course if you want these then just run setup to have it create them, or use diskpart to create them yourself...

HTH

I do like to have Windows create the standard partition layout which is why I do that there.

I was able to get everything working though, and avoided rebooting to move EFI. What you described in option 2 was what I had planned, but I wasn't sure if Windows was going to allow it until I tried.

I ran the command bcdboot to dump EFI folder on the Windows partition instead of the EFI folder on the Windows drive, and then I just went back into diskpart, assigned a letter to the EFI partition, and then moved the files across partitions. It then worked when I rebooted.

My Windows drive letter was F. I did partition 2 as standard setup layout places the recovery partition at partition 1.

diskpart
select disk 0
select partition 2
assign letter="S"
exit

xcopy F:\EFI S:\EFI\ /S /E
rmdir /Q /S F:\EFI

Now I have a clean Windows install setup and I won't ever have to remove my SSD again.

In the process of testing I tried other workarounds. Knowing that OpenCore, unlike Clover, applies ACPI patches regardless of OS, I tried to hide the SSD with an SSDT patch unsuccessfully. I was able to hide the Windows SSD in macOS though, which is good because it solved a bug with Boot Camp Assistant (was trying to download the drivers and noticed it never worked) where it fails when not macOS is not booted and run from disk0. Given that I just BitLocker it anyway there's nothing I'm missing out on by hiding it.

 

[djx8605]

I do like to have Windows create the standard partition layout which is why I do that there.

I was able to get everything working though, and avoided rebooting to move EFI. What you described in option 2 was what I had planned, but I wasn't sure if Windows was going to allow it until I tried.

I ran the command bcdboot to dump EFI folder on the Windows partition instead of the EFI folder on the Windows drive, and then I just went back into diskpart, assigned a letter to the EFI partition, and then moved the files across partitions. It then worked when I rebooted.

My Windows drive letter was F. I did partition 2 as standard setup layout places the recovery partition at partition 1.

diskpart
select disk 0
select partition 2
assign letter="S"
exit

xcopy F:\EFI S:\EFI\ /S /E
rmdir /Q /S F:\EFI

Now I have a clean Windows install setup and I won't ever have to remove my SSD again.

In the process of testing I tried other workarounds. Knowing that OpenCore, unlike Clover, applies ACPI patches regardless of OS, I tried to hide the SSD with an SSDT patch unsuccessfully. I was able to hide the Windows SSD in macOS though, which is good because it solved a bug with Boot Camp Assistant (was trying to download the drivers and noticed it never worked) where it fails when not macOS is not booted and run from disk0. Given that I just BitLocker it anyway there's nothing I'm missing out on by hiding it.

Nicely done! Now that you have it working, you *shouldn't* have any issues.

Funny you mentioned disabling via SSDT, I'm actually attempting to do the same, but with the HD630. Windows insists on installing Intel crap just because the IGPU is present... I've read about others disabling NVIDIA from macOS using SSDT, so I'm wondering if the same can be done with the IGPU. We disable DGPU on laptops using SSDT, so I'm optimistic lol... But that's another topic for another thread, still researching

 

[totototo]

So do you install them to S/L/E? or do you have them injected each time? Hopefully you are not just using injection

Why not? I know the recommendations too, but from my own testing I could not find the reason not to inject and keep all necessary kexts in one location (EFI). I would be curious to know what test can I run to prove myself wrong.

 

[djx8605]

Why not? I know the recommendations too, but from my own testing I could not find the reason not to inject and keep all necessary kexts in one location (EFI). I would be curious to know what test can I run to prove myself wrong.

The only thing I ever personally encountered was back on 10.11, installing ethernet kext on K/O (EFI/Clover) the kext name would not show, and the ethernet port would not always be n0, which could caused issues with iMessage. Placing the kext in the L/E folder would cause everything to show up fine and the ethernet port would always be n0. Moreover, a real mac doesn't load kexts from anywhere else except L/E or S/L/E AFAIK, so why feed it kexts from elsewhere?

Not sure what tests you can run nowadays to prove one or the other, but in case you haven't seen them, check these posts out:

[Guide] Booting the OS X installer on LAPTOPS with Clover

Overview One of the first challenges you'll face in installing OS X to your laptop will involve getting the OS X installer to boot from USB. This guide is for those wishing to use Clover (and in fact the only bootloader supported here). Both installing using Clover UEFI and Clover legacy are...

www.tonymacx86.com

@RehabMan wrote:
"You should install all kexts you need (including FakeSMC, VoodooPS2Controller, etc) to /Library/Extensions (/L/E) or /System/Library/Extensions (/S/L/E) for 10.10.x and prior using a kext installer or Terminal. Think carefully about "kexts you need". For example, if you needed HPRAIDInjector.kext for a SATA chip locked in RAID mode, you'll need to install it in order to boot (without it, the system would be unable to mount root and would get stuck early in the boot process).

Of course, essential kexts should be installed to EFI/Clover/kexts/Other as they are needed to boot the installer (during updates) or the recovery partition.

It is a mistake to install everything to Clover/kexts. Contrary to popular hackintosh myth, it does not result in a cleaner install (the opposite is true). Many kexts will not work from Clover/kexts, so installing them to /S/L/E where they can be included in kernel cache is the best approach.

People often ask me why I install kexts to /S/L/E (or /L/E on 10.11).

I have many reasons:
- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.
- if you develop kexts, error checking is very important!
- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)
- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality
- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)
- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac) ........."

I tried googling for it but couldn't find it, but years ago I read somewhere that cached kext would load faster than having Clover inject kext each time the system boots. (not sure if that was or still is true, but it could be)
O! and that reminds me, on laptops we would always have that issue with having to load Clover without caches to get the patched audio kext injected into cache and then reboot twice etc... and then redo it if something broke or cache got updated or macOS got update......... That was a crazy mess lol.

Here's another post (which you've probably seen) that also tackles the issue:

[GUIDE] Installing 3rd Party Kexts - El Capitan, Sierra, High Sierra, Mojave, Catalina

Installing 3rd Party Kexts in /Library/Extensions Note: This guide was originally written to support MacOS Mojave and older versions (< r5200) of the Clover boot-loader. The methods detailed here are now considered legacy methods and should only used with older versions of MacOS as detailed...

www.tonymacx86.com

@jaymonkey wrote:
".........
It seems that many users are under the impression that you can simply copy all 3rd Party Kexts into EFI/Clover/kexts/Other and allow Clover to Inject the kexts by setting Clover -> System Parameters -> Inject Kexts to "Yes" which will result in a maintenance free and more native MacOS install.

This assumption is completely wrong ...

[Why should I use /Library/Extensions over Clover Injected kexts ?]

Contrary to Hackintosh myth, having Clover inject all the 3rd party kexts does not result in a cleaner install, in fact the exact opposite is true.
•Injected Kexts live outside of "protected MacOS memory" *
•Injecting a large amount of kexts can result in an unstable system.
•Many 3rd party kexts will not work correctly when injected by Clover.
•Injected Kexts are not included in the kernel cache and thus are excluded form MacOS error checking.
•Installing kexts in /Library/Extensions is the Apple endorsed and recommended location for all 3rd Party kexts.
If you purchase a piece of hardware that requires the installation of a manufactures MacOS driver, the kexts will be installed in /Library/Extensions so why treat hackingtosh kexts any different ?

* Note: I use the term "protected MacOS memory" in this guide as a generic descriptive term. In reality kext's installed in /L/E are loaded into MacOS's kernel memory which is 'protected' (IE: segregated) form application memory and execution memory. Everything running in kernel memory (including kexts) is actively managed and monitored by MacOS. ........."

I'm sure others can chime in and give more info/details of their own experiences regarding this topic For me personally, I just figure if the veteran hackintoshers advise doing things that way (and it makes logical sense to me), then I should be wise and listen lol.

 

[totototo]

The only thing I ever personally encountered was back on 10.11, installing ethernet kext on K/O (EFI/Clover) the kext name would not show, and the ethernet port would not always be n0, which could caused issues with iMessage. Placing the kext in the L/E folder would cause everything to show up fine and the ethernet port would always be n0. Moreover, a real mac doesn't load kexts from anywhere else except L/E or S/L/E AFAIK, so why feed it kexts from elsewhere?

Not sure what tests you can run nowadays to prove one or the other, but in case you haven't seen them, check these posts out:

[Guide] Booting the OS X installer on LAPTOPS with Clover

Overview One of the first challenges you'll face in installing OS X to your laptop will involve getting the OS X installer to boot from USB. This guide is for those wishing to use Clover (and in fact the only bootloader supported here). Both installing using Clover UEFI and Clover legacy are...

www.tonymacx86.com

@RehabMan wrote:
"You should install all kexts you need (including FakeSMC, VoodooPS2Controller, etc) to /Library/Extensions (/L/E) or /System/Library/Extensions (/S/L/E) for 10.10.x and prior using a kext installer or Terminal. Think carefully about "kexts you need". For example, if you needed HPRAIDInjector.kext for a SATA chip locked in RAID mode, you'll need to install it in order to boot (without it, the system would be unable to mount root and would get stuck early in the boot process).

Of course, essential kexts should be installed to EFI/Clover/kexts/Other as they are needed to boot the installer (during updates) or the recovery partition.

It is a mistake to install everything to Clover/kexts. Contrary to popular hackintosh myth, it does not result in a cleaner install (the opposite is true). Many kexts will not work from Clover/kexts, so installing them to /S/L/E where they can be included in kernel cache is the best approach.

People often ask me why I install kexts to /S/L/E (or /L/E on 10.11).

I have many reasons:
- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.
- if you develop kexts, error checking is very important!
- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)
- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality
- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)
- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac) ........."

I tried googling for it but couldn't find it, but years ago I read somewhere that cached kext would load faster than having Clover inject kext each time the system boots. (not sure if that was or still is true, but it could be)
O! and that reminds me, on laptops we would always have that issue with having to load Clover without caches to get the patched audio kext injected into cache and then reboot twice etc... and then redo it if something broke or cache got updated or macOS got update......... That was a crazy mess lol.

Here's another post (which you've probably seen) that also tackles the issue:

[GUIDE] Installing 3rd Party Kexts - El Capitan, Sierra, High Sierra, Mojave, Catalina

Installing 3rd Party Kexts in /Library/Extensions Note: This guide was originally written to support MacOS Mojave and older versions (< r5200) of the Clover boot-loader. The methods detailed here are now considered legacy methods and should only used with older versions of MacOS as detailed...

www.tonymacx86.com

@jaymonkey wrote:
".........
It seems that many users are under the impression that you can simply copy all 3rd Party Kexts into EFI/Clover/kexts/Other and allow Clover to Inject the kexts by setting Clover -> System Parameters -> Inject Kexts to "Yes" which will result in a maintenance free and more native MacOS install.

This assumption is completely wrong ...

[Why should I use /Library/Extensions over Clover Injected kexts ?]

Contrary to Hackintosh myth, having Clover inject all the 3rd party kexts does not result in a cleaner install, in fact the exact opposite is true.
•Injected Kexts live outside of "protected MacOS memory" *
•Injecting a large amount of kexts can result in an unstable system.
•Many 3rd party kexts will not work correctly when injected by Clover.
•Injected Kexts are not included in the kernel cache and thus are excluded form MacOS error checking.
•Installing kexts in /Library/Extensions is the Apple endorsed and recommended location for all 3rd Party kexts.
If you purchase a piece of hardware that requires the installation of a manufactures MacOS driver, the kexts will be installed in /Library/Extensions so why treat hackingtosh kexts any different ?

* Note: I use the term "protected MacOS memory" in this guide as a generic descriptive term. In reality kext's installed in /L/E are loaded into MacOS's kernel memory which is 'protected' (IE: segregated) form application memory and execution memory. Everything running in kernel memory (including kexts) is actively managed and monitored by MacOS. ........."

I'm sure others can chime in and give more info/details of their own experiences regarding this topic For me personally, I just figure if the veteran hackintoshers advise doing things that way (and it makes logical sense to me), then I should be wise and listen lol.

Lots of good argumentation here. I've seen most of it. I just can't argue with my own empirical experience. I've had stable and reliable Mojave install and now Catalina (so far all good), so no reason to change despite all the good science quoted above (which I do not question btw.)

 

[MuffinCrumbs]

So do you install them to S/L/E? or do you have them injected each time? Hopefully you are not just using injection

I've hackintoshed for a decent amount of years. I've used S/L/E and L/E long before with other hack. But noe I only use injection for Clover it is in Clover/Kext/Other for OpenCore it is in OC/Kexts.

I have my reasons to why I only inject. Reasons I probably won't discuss, because it'll take time and it might overtake other important topics in the thread. But all works fine, over many years now. In specific to the rig with Gigabyte Z390 Designare, everything works fine even after updating using this method.

That said, I certainly hope I don't need to rely on L/E or S/L/E, Specially with unsigned kexts. The way I've researched and talked to other developers, gotten knowledge, I do not feel there is a need to install to L/E and S/L/E.

 

[digitaldendrite]

It's possible that the Install macOS Mojave application is corrupt. You should first delete this from the Applications folder, empty the trash, then re-download the full combo installer by clicking here.

When the download is complete, locate Install macOS Mojave in the Applications folder and launch it. How far does it go?

I would also strongly encourage you at this time to review the first part of the build guide -- from Installation Overview to Final Steps in Post-Installation. This was designed to help users become more comfortable with the process.

Hi Casey. I appreciate the effort so far. I am still puzzled, though, by your instructions above, and I want to be 100% sure we're on the same page. I have 10.14.4 installed and running (for 8 months or so?) just fine. I am trying to move to 10.14.6 (and then the supplimental update). I feel like launching the full installer will REINSTALL my OS, which I do not want to do.

So, I want to be sure of 2 things:

1, your instructions above are to have the full installer of Mojave in the applications folder (NOT the combo updater or anything like that...)

2, you want me to launch this and run the installer from my regular, 10.14.4 desktop (via terminal or without, I'm not sure it matters).

I really want to be 100% sure because I'd rather not have to erase the drive and re-clone if it's not necessary. I have a working cloned backup, yes, but still...

Thanks again.

 

[ohHenry]

Hi All--

I followed the instructions before attempting to update to 10.15.1 (as well as copying over the latest versions of VirtualSMC, AppleALC, and Lilu). After which, I have attempted running the the upgrade multiple times. Each time, the system does a reboot, and after I log back in, the 10.15.1 upgrade notification reappears and prompts me to update.

Any thoughts?

Cheers!

 

[skittlebrau]

Hi All--

I followed the instructions before attempting to update to 10.15.1 (as well as copying over the latest versions of VirtualSMC, AppleALC, and Lilu). After which, I have attempted running the the upgrade multiple times. Each time, the system does a reboot, and after I log back in, the 10.15.1 upgrade notification reappears and prompts me to update.

Any thoughts?

Cheers!

Make sure you select 'Boot macOS Install from Macintosh HD' (or whatever you've named your system drive) at the Clover boot selection screen whenever you install an update.