Gigabyte X299X - Catalina Support

[P1LGRIM]

i have this when OC is loading how can i fix it

Remove those invalid items from your config.plist.

 

[Thekeko]

Remove those invalid items from your config.plist.

??? don't see it

 

[TheBloke]

Delete these two entries, or set Enabled = false

 

[Thekeko]

Delete these two entries, or set Enabled = false

thank you

 

[beltzak]

Ok, now we need to get rid of all possible SSDT's, yeah!!! That's wonderful lol I like this approach thou. I am amazed how fast all the hackintosh world can change with a simple change your systems boot, now it does not

I have got a lot work to do in my hackintosh now. Thanks everybody! Wonderful people here!

 

[byteminer]

Unfortunately I didn't have much time over the last week or so, but I'm quickly reporting in with my current situation.
I took a look at the EFI @TheBloke posted and merged it with my own as much as possible. We're running relatively similar setups anyway, so it worked out alright.

I'm now booted into the latest Big Sur release (11.1) without any problems. All kexts appear to work fine. I did an in-place upgrade to the newest OS release (starting from one of the Dev Betas) and the upgrade process went off without a hitch, too.

My ethernet is also now working fine without any hiccups. Turns out that the powerline adapter I was using had some setup problems that resulted in a weird situation where directly connecting to it would put my ethernet controllers into a broken state, but connecting it to a router and then connecting my Hackintosh to that would work. I've fixed those now (by resetting it and reconfiguring the adapter), and since then I haven't had any further issues with Ethernet.

Still running iMacPro1,1 which seems to do me well thus far, no complaints.

I've done a bit more digging on the bios reset thing, but so far no new information has turned up. I'll keep looking into it when I have time, maybe there's something we can do to fix it, but chances remain slim.

 

[TheBloke]

Ok, now we need to get rid of all possible SSDT's, yeah!!! That's wonderful lol I like this approach thou. I am amazed how fast all the hackintosh world can change with a simple change your systems boot, now it does not

Yup lots to learn! I'm not sure I'll end up removing all SSDTs. But I'm definitely interested to see how Ellybz achieved that. As he said, there's lots of different ways to do things, and not necessarily one 'correct' way.

I do like having cosmetic stuff configured via DeviceProperties, as it's all immediately visible in the config.plist. Just seems cleaner that way.

What I'm yet to really understand is whether it matters what devices are called from an ACPI level. To take one example - our X550 NICs. Using dolgarrenan's SSDTs, they get renamed to XGBE and XGBF. If that SSDT is not loaded, they're called ethernet1 and PXSX (I think).

So what I'd like to know is.. does that matter? Is there any benefit to having them called the same thing at an ACPI/IoReg level as they would be on a real Mac?

Knowing that would help to understand how important it is to have SSDTs/DeviceProperties/etc. Whether it actually matters for functionality, or if it's just a nice-to-have.

I'm now booted into the latest Big Sur release (11.1) without any problems. All kexts appear to work fine. I did an in-place upgrade to the newest OS release and the upgrade process went off without a hitch, too.

Good to hear. Have you enabled SecureBootModel for BigSur? I'm a bit unsure about that. Dortania's guides seem to indicate it's practically required, at least for install and updates. But then Ellyby's BigSur config had it Disabled.

I just ordered one of the new AMD 6800 GPUs, so I'll need to upgrade to BigSur 11.1 in order to use that.

I've done a bit more digging on the bios reset thing, but so far no new information has turned up. I'll keep looking into it when I have time, maybe there's something we can do to fix it, but chances remain slim.

Yeah, I don't think we're going to get anywhere without some expert/developer help. To that end I posted in an official OpenCore thread on another site. I won't link it as it'll probably get flagged or something. As I rather feared, no responses after several days.

My feeling is that it's definitely a BIOS bug - or at least a BIOS peculiarity - and may well require a special quirk/tweak, ie one that doesn't yet exist. Meaning an OpenCore dev would have to write it. And will they be interested to do that if it only affects this one board? Probably not.

I will keep asking around and might approach an OpenCore developer directly. But mostly I'm resigning myself that we'll just have to live with it. At least it never effects normal booting. It only affects me when I need to boot from USB instead of NVMe, and that's rare now that I've got my config mostly working. And even if I do need to boot from USB, I can do so with only one extra reboot. So it's not the end of the world.

By the way, I'd highly recommend that you all familiarise yourself with OpenShell, and make sure it's enabled in your config. It's very useful for making quick changes and fixes to your config.plist.

For example: you want to test a new or different config.plist setting. On another motherboard you'd probably test this on USB, so as to leave your NVMe config unaffected. But that's a pain on this board, because of the boot failure issue. So instead you go ahead and change it directly on the NVMe. You try and boot, and the boot fails because of the new config.

Now, instead of reverting to your USB backup (and the extra reboots and BIOS F10 required by the boot failure issue), instead you can boot into OpenShell, from the OpenCore menu on your NVMe EFI.

Load OpenShell from OpenCore, then:

1. Type fs0: or fs1: depending on whether your EFI is on the first or second NVMe/SSD. If
2. Type cd EFI\OC
3. Now you can copy files around, eg to restore a backup.
4. So if you kept a backup of your config.plist from before you tried the most recent change, you can do something like: cp good.config config.plist to overwrite config.plist with your backup copy (called 'good.config' in this example).
   1. It will prompt you to confirm the overwrite with Y
5. Or, you can directly edit your config with edit config.plist
   1. Here you can make quick text changes, change a 'true' to 'false' or whatever
   2. In the editor, the most important hotkeys are:
      1. Control-E = get help, which lists all the hotkeys
      2. F1 = go to line number
      3. F2 = save
      4. F3 = exit
      5. F4 = search
6. When you're done, type reset and the system will reboot, and your restored/edited config will activate.

If you get into the habit of making a quick backup of your config.plist within the same EFI folder prior to making any change, it's quick and easy to revert that change via OpenShell. Or for small text changes you can edit them in yourself.

I now use this method quite often when I want to try new changes. It saves having to put up with the boot failure any time I try and boot from USB. It's not quite as good as having Clover's built in config picker and parameter editor, but it's quicker than having to reboot multiple extra times because of the boot failure, and keep having to re-apply BIOS settings each time that happens.

 

[byteminer]

Good to hear. Have you enabled SecureBootModel for BigSur?

Yeah, I'm running with the SecureBoot value for iMacPro1,1 and it seems to be working just fine. The Airport kexts also work, but personally I don't use them much so currently they're disabled.

For example: you want to test a new or different config.plist setting. On another motherboard you'd probably test this on USB, so as to leave your NVMe config unaffected.

The thing that I do when testing EFI changes multiple times in a short time period is to go into the BIOS and disable all boot options except for my USB stick. That way I can unplug, change and re-plug without having to go through the BIOS/boot menu, circumventing the issue entirely. Once I'm done I copy the EFI to my actual drive and reenable it in the BIOS.

 

[TheBloke]

The thing that I do when testing EFI changes multiple times in a short time period is to go into the BIOS and disable all boot options except for my USB stick. That way I can unplug, change and re-plug without having to go through the BIOS/boot menu, circumventing the issue entirely. Once I'm done I copy the EFI to my actual drive and reenable it in the BIOS.

Ah yeah that's a good idea, I'll have to try that if I find myself iterating a lot on config again.

One reason I prefer NVMe boot is for the verbose logging. I found I had to turn off OpenCore debug for USB because it was just so slow. So I prefer to boot from NVMe if possible so I can keep OC logging enabled.

But yeah, when lots of changes are being tried it's nice to use USB which allows for adjusting the config on a second machine while the main is unavailable.

 

[Thekeko]

who's able to upgrade OC 0.6.3?