Gigabyte X299X - Catalina Support

[TheBloke]

Hey guys.. you're not going to believe this.

I think I've found the fix for our Designare 10G boot bug. A vanilla OpenCore fix, not requiring @JTR 's patch.

Set ConnectDrivers to false. That's it.

I've only tested it a couple of times, and only in the latest OpenCore 0.6.8. But I've booted from both USB and SSD using this change, and it boots absolutely fine with normal BIOS settings. No reset after 10 seconds, no safe mode.

From the manual:
"ConnectDrivers: This option is useful for loading drivers following UEFI driver model as they may not start by themselves. Examples of such drivers are filesystem or audio drivers. While effective, this option may not be necessary for drivers performing automatic connection, and may slightly slowdown the boot. Note: Some types of firmware, particularly those made by Apple, only connect the boot drive to speed up the boot process. Enable this option to be able to see all the boot options when running multiple drives."

So without this set I suppose there could theoretical be some side effect, like not being able to boot from certain drives. But I've not noticed anything yet - I get my normal macOS (NVMe drive 1) and Windows (NVMe drive 2) boot entries. It also saw the EFI on my USB stick.

Further time and testing is needed to ensure it definitely solves the problem forever. But so far it's looking great.

EDIT: This does cause at least one problem. With ConnectDrivers=false, it appears not to be possible to boot the macOS installer from a USB drive. You can boot from a USB EFI OK, but it won't find the "Install macOS Big Sur" DMG on the USB. Therefore if you were going to use this parameter for a new install, you'd first need to boot with ConnectDrivers=true (and thus hit the BIOS safe-mode issue, and proceeding at stock speeds with no XMP). Once macOS was installed, you could then set ConnectDrivers=false and booting would be fine after that.

Having thought about this more overnight I've realised that it probably should have been obvious that this parameter would affect things, as @JTR 's patch is to OcDriverConnectionLib, which is I believe disabled by ConnectDrivers=false. So setting that parameter bypasses the issue, but at the expense of the ability to boot from a USB installer. Whereas JTR's patch fixes the issue completely - but currently at the cost of requiring an external patch to standard OpenCore.

 

[lx23]

Hey guys.. you're not going to believe this.

I think I've found the fix for our Designare 10G boot bug. A vanilla OpenCore fix, not requiring @JTR 's patch.

Set ConnectDrivers to false. That's it.

I've only tested it a couple of times, and only in the latest OpenCore 0.6.8. But I've booted from both USB and SSD using this change, and it boots absolutely fine with normal BIOS settings. No reset after 10 seconds, no safe mode.

This is not a new config parameter - it's been there since at least 0.5.7. I don't know if anyone has tried this unsuccessfully before and its behaviour has changed in recent versions, or if this was just staring us in the face for some time. Regardless, I'd not have thought to try it now were I not re-reading JTR's patch and his work on diagnosing the problem as being related to "driver connection".

I had seen in 0.6.7 there was a new parameter DisableSecurityPolicy which was a "UEFI quirk to workaround driver loading" which sounded like it was worth trying with regard to our problem. Didn't get around to until today, and then when searching for it I noticed ConnectDrivers. I tried that first, and.. it works

From the manual:
"ConnectDrivers: This option is useful for loading drivers following UEFI driver model as they may not start by themselves. Examples of such drivers are filesystem or audio drivers. While effective, this option may not be necessary for drivers performing automatic connection, and may slightly slowdown the boot. Note: Some types of firmware, particularly those made by Apple, only connect the boot drive to speed up the boot process. Enable this option to be able to see all the boot options when running multiple drives."

So without this set I suppose there could theoretical be some side effect, like not being able to boot from certain drives. But I've not noticed anything yet - I get my normal macOS (NVMe drive 1) and Windows (NVMe drive 2) boot entries. It also saw the EFI on my USB stick.

Further time and testing is needed to ensure it definitely solves the problem forever. But so far it's looking great.

Even if this does solve the problem, thanks again to JTR for all his work on diagnosing the problem and creating the patch. Without that work the last few months would have been unbearable, and I'd probably never have thought to try ConnectDrivers in the first place.

If everything is still looking good tomorrow I'll upload a vanilla 0.6.8 OpenCore EFI with updated kexts, and this config value set.

@TheBloke Hi, I have try set ConnectDrivers to false to install big sur, boot success but not found the install usb disk.But after install success, set ConnectDrivers to false works well.

 

[TheBloke]

@TheBloke Hi, I have try set ConnectDrivers to false to install big sur, boot success but not found the install usb disk.But after install success, set ConnectDrivers to false works well.

Ahh yes, interesting. I see the same. It will boot from USB, but it can't see the DMG macOS installer from USB with ConnectDrivers=false. It does see the Recovery DMG on my NVMe without problems.

What's interesting is that it does see a full macOS install on USB. I plugged in an SSD via USB-to-SATA3 converter, and it found both the macOS install and the Recovery DMG on that external SSD:

OpenCore 0.6.8, booted from NVMe EFI, with ConnectDrivers = false:

It finds: macOS + Recovery on one NVMe; Windows on the other; a Big Sur installation + Recovery on SSD connected via USB; and the EFI from an "Install macOS Big Sur" flash drive. So everything has been detected OK except the macOS installer DMG on the USB stick. I wonder what's different about that.

As I've put in my edit to my post from last night, in hindsight I guess it should have been obvious that ConnectDrivers would have an effect on our issue given JTR's patch is to OcDriverConnectionLib, and I think ConnectDrivers=false disables this library entirely.

So there definitely is still a use for the patch in order to get full functionality. But I'm glad I've belatedly realised that it's also now possible to run day-to-day with a vanilla OpenCore, as until that patch gets submitted and integrated into OC it's always going to be a worry that one day it will no longer be possible to merge JTR's code.

 

[teosoft]

Just FYI - setting ConnectDrivers=false under 0.6.6 fails validation.
My configuration is different though. I suppose it'll only work if no drivers are loaded in /UEFI/Drivers, unless something changed in OC from 0.6.6 to 0.6.7
On the other hand, I load OpenRuntime.efi as a driver, to speed up boot process.

Set ConnectDrivers to false. That's it.

I've only tested it a couple of times, and only in the latest OpenCore 0.6.8. But I've booted from both USB and SSD using this change, and it boots absolutely fine with normal BIOS settings. No reset after 10 seconds, no safe mode.

 

[BerndVP]

All good news, I have almost all the components, just the CPU and RAM

 

[byteminer]

Some good news from me as well:
- The ConnectDrivers thing seems to work on my end, too, haven't encountered the previous issues thus far. Fingers crossed.
- I finally got around to mapping my USB ports properly, which resolved most of my USB issues. I used Hackintool for this, which made the process very simple.

 

[TheBloke]

Just FYI - setting ConnectDrivers=false under 0.6.6 fails validation.
My configuration is different though. I suppose it'll only work if no drivers are loaded in /UEFI/Drivers, unless something changed in OC from 0.6.6 to 0.6.7
On the other hand, I load OpenRuntime.efi as a driver, to speed up boot process.

Yes, true:

HFS+ filesystem driver is loaded at UEFI->Drivers[1], but UEFI->ConnectDrivers is not enabled!

I have three drivers loaded via UEFI -> Drivers:

• HFSPlus.efi - for loading HFS filesystems, eg DMG Recovery images
• OpenRuntime - vital for many UEFI related tasks
• OpenCanopy - the OC GUI

The OpenCore logs claims that all are loading fine:

00:293 00:001 OCABC: Awaiting rendezvous with OpenRuntime r12
00:299 00:001 OC: Driver OpenRuntime.efi at 0 is being loaded...
00:305 00:003 OCABC: Got rendezvous with OpenRuntime r12
00:309 00:001 OC: Driver OpenRuntime.efi at 0 is successfully loaded!
00:310 00:001 OC: Driver HfsPlus.efi at 1 is being loaded...
00:315 00:002 OC: Driver HfsPlus.efi at 1 is successfully loaded!
00:316 00:001 OC: Driver OpenCanopy.efi at 2 is being loaded...
00:327 00:001 OC: Driver OpenCanopy.efi at 2 is successfully loaded!

However I just checked my EFI logs from before I set ConnectDrivers=false, and I see there's an extra log line in those related to HfsPlus:

00:302 00:001 OC: Driver HfsPlus.efi at 1 needs connection.

So yes, as ocvalidate says, HfsPlus.efi can't load with ConnectDrivers=false, which is why "Install macOS Big Sur" can't be found: that's an HFS+ filesystem. Whereas the main OS Recovery can be loaded, because that comes from the APFS Recovery partition, and APFS support is built-in to OC.

Fortunately our system doesn't need any other UEFI drivers, but yes it is a bit of an annoyance not to be able to load HFS+ support for when it's occasionally required.

I looked through the OC code and confirmed that ConnectDrivers=false disables the code that JTR had to patch in order to fix the problem (Library/OcDriverConnectionLib/OcDriverConnectionLib.c), so it's obvious in hindsight that ConnectDrivers=false would also resolve the problem (albeit with a downside) if the system remained bootable, which fortunately it does.

- I finally got around to mapping my USB ports properly, which resolved most of my USB issues. I used Hackintool for this, which made the process very simple.

Glad you got it working finally. You could have used the USBMap.kext I included in my 0.6.7 EFI a month or so ago, but yes it's better to know how to do it oneself as well (Personally I prefer USBMapper to Hackintool though.)

 

[byteminer]

I had a different SMBIOS, which I believe prevents that from being an option IIRC. I also had less ports active which I actually needed. I did try yours, but it didn't help with my particular situation, so I figured I'd bite the bullet and attempt my own version, which did eventually lead to a good result. Either way, thanks for all the hard work you've put into this already!

 

[BerndVP]

only thing I now need to complete the system: the CPU xD

 

[manpower]

Anyone know how to control the fan? I already set the the fan in bio to 'Silent' but when I do even just some simple graphic and iStats only show cpu just around 40 degree, but the fan run so loud, some say this board is noisy is that true?