Contribute
Register

X299 Big Sur Support

Joined
Dec 10, 2018
Messages
203
Motherboard
Asus Prime X299-A
CPU
i9-7960X
Graphics
RX 5700
Mac
  1. MacBook Pro
  2. Mac Pro
Mobile Phone
  1. iOS
this may have been fixed in 11.1.
I don’t personally use LuLu but I use Little snitch 5.0.4 instead.

apple has completely changed the way these things work and are now network filters instead of root level kexts.

i really think it is a OS bug as well, cause it never happened before beta 6 or 7

i’ll update and see. Anyone who’s on 11.1 beta and find it stable?
 
Joined
Feb 24, 2013
Messages
2,553
Motherboard
ASUS WS X299 SAGE/10G
CPU
i9-9980XE
Graphics
Radeon VII
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
i really think it is a OS bug as well, cause it never happened before beta 6 or 7

i’ll update and see. Anyone who’s on 11.1 beta and find it stable?
I’m on 11.1 public beta and it feels stable. Should be a couple of more weeks and we will get the final update.

I normally wouldn't even recommend betas or even .0 releases of macOS, but I feel comfortable recommending Big Sur in general.

But to be honest I haven't pushed Big Sur a lot yet in real world workflows, very lightly so far, but I can't give my 100% recommendation yet, but I do feel good about using it day to day.
 
Last edited:
Joined
Apr 18, 2011
Messages
1,075
Motherboard
ASUS WS X299 Sage/10G
CPU
i9-10980XE
Graphics
Radeon Pro W5500
Mac
  1. Mac Pro
Mobile Phone
  1. iOS
Is anyone else running into this? Trying to fix the PCI tab in System Report for GPUs but the Audio Device is duplicating the Display device information. The path looks to be correct in DeviceProperties.

Screen Shot 2020-12-03 at 15.08.30.png

Screen Shot 2020-12-03 at 15.10.19.png
 
Joined
Feb 24, 2013
Messages
2,553
Motherboard
ASUS WS X299 SAGE/10G
CPU
i9-9980XE
Graphics
Radeon VII
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
Joined
Jul 27, 2012
Messages
17
Motherboard
MSI Raider X299
CPU
Core i9-7860X
Graphics
Radeon RX Vega 64
Mac
  1. Mac mini
  2. Mac Pro
Mobile Phone
  1. iOS
PRELIMINARY METHOD FOR INSTALLING BIG SUR ON SYSTEM WITH BROKEN NVRAM

After much testing I think I have a reproducible method by which someone can do a fresh Big Sur install without having working NVRAM.

At least, this method is working reliably for me in my tests. I am testing a 'broken NVRAM' situation by clearing my NVRAM from the OpenCore picker after each reboot.

@rustEswan @amitbapat @oli.mathieu and anyone else with broken NVRAM, if one of you could try this method to confirm it works on a real board with no NVRAM, that would be great.

So far I have only tested this with a fresh Big Sur install. I will look at upgrades next. The same method likely also works for upgrades, but the script provided definitely won't. I hope to have news on upgrades in the next 24 hours.

THE METHOD

Please read and follow the method carefully.

Requirements: A Big Sur install USB stick, with EFI containing OpenCore 0.6.3 DEBUG version and suitable config capable of booting and running Big Sur on your system.

In order for this preliminary method to work, you must set Target = 65 in config.plist, which will enable debug boot logging. This will create opencore-<date>.txt logfiles in the root of the EFI partition on your USB.

In order to run the script necessary for generating the required NVRAM key, you must have another macOS system available. This could be a second Hack, a real Mac, or even the same X299 Hack if you reboot to an existing install (though in this test that would also require some disk swapping, as I'd like you to do the install with no other drives plugged in).

In future I hope to provide a method that requires no second system, but for now you need to run a command line script on macOS to generate the necessary NVRAM key, which is based on data in your OpenCore logfile.

Script: Download the script from this URL. Save it somewhere you can easily run it from Terminal, eg your home directory.

Preparation:
  1. Find a suitable SSD on which to do a test install of macOS. I have been using a spare 120GB SSD.
  2. Remove all other SSDs/NVMe drives from the machine during the install process. This shouldn't be necessary in future, but to ensure the success of this test run and my script for generating the key, I want to be sure no other drives are present that could affect anything.
  3. Get a USB stick prepared with the Big Sur installer, and your EFI partition.
    1. Please prepare the USB stick according to the Dortania guide, using gibMacOS: https://dortania.github.io/OpenCore.../mac-install.html#downloading-macos-modern-os
  4. The EFI partition must contain OpenCore 0.6.3 DEBUG version
  5. The config.plist must have Target = 65 set, so that debug logging will be written to the USB EFI.
  6. If you have any existing opencore-*.txt logfiles, please move or delete them, so you can be sure you know which log files were generated during the test run.
The method:
  1. Boot from USB and choose the Install Big Sur option from the USB drive.
  2. When the GUI appears, open Disk Utility.
  3. Format your target SSD as APFS / GUID. Give it any name.
  4. Now run the installation as normal.
  5. When it gets to "12 minutes remaining", the system will reboot.
  6. Let it reboot to OpenCore, but then do not select any option in the boot picker. Just get to the boot picker menu, then:
  7. SHUTDOWN THE SYSTEM AND REMOVE THE USB STICK.
    1. We will return to it in a moment. But first we need to edit the config.plist.
    2. It is vital it does not continue automatically into step two of the install, as if it starts and fails this process, you will likely have to start from step 1 again.
  8. Take your USB stick and mount the EFI on your secondary macOS machine.
  9. Look in /Volumes/EFI and note the most recent opencore-*.txtlogfile.
    1. We want the logfile that was generated by step 6 - when you rebooted after stage 1 of the install, and then shut down the system without selecting any option.
  10. Open Terminal.
  11. Change to the directory where you downloaded my script.
  12. First we need to make it executable, run:
    1. chmod +x GenNVRAMKey.command
  13. Now run it:
    1. ./GenNVRAMKey.command
  14. It will prompt you for the location of an OpenCore logfile. You can either type in the path, or just drag and drop the file from Finder, which will paste in the path. Then hit enter.
    1. For example: /Volumes/EFI/opencore-2020-11-30-151132.txt
  15. If it has worked correctly you will be given some code to put in config.plist, as in the following screenshot
    1. View attachment 499223
  16. Open your config.plistin a text editor:
    1. Scroll down to NVRAM -> ADD -> 7C436110-AB2A-4BBB-A880-FE41995C9F82
      1. This entry should already exist in your config.plist, as it's used to supply csr-active-config, amongst others.
    2. Paste in the two lines of code given by the script, and save the file.
    3. With the lines added, file should look something like this (your data value will differ, of course):
      1. View attachment 499229
  17. Unmount your EFI, and put the USB back in the X299 system.
  18. Boot again from the USB, and continue the install by choosing "macOS Installer" from the OpenCore menu, as your normally would. It won't be the default entry, due to your broken NVRAM.
  19. If the method has been successful, you expect the next stage of the install to take 10-20+ minutes, rather than rebooting immediately as it would have done before.
  20. It will reboot 3 more times before you reach the setup screen.
  21. Note that on one or two of the later reboots you might see that the progress bar is right back to the beginning, and doesn't move at all during that stage of the process. This is OK, don't abort it; it should still complete fine. I believe the progress bar level is set by another NVRAM variable, and without this it shows the bar right at the beginning. It's just cosmetic.
  22. Once you've (hopefully) reached the setup screen and created your account and logged in, you can confirm that diskutil apfs list shows "Snapshot Sealed: Yes" (though the filesystem itself will be 'Broken', as we were talking about in recent posts), and that the OS is running fine.
  23. You can then remove the new NVRAM key you added (msu-product-url) for subsequent boots. It won't work again for future upgrades, as a new key needs to be generated for that.

And that's it. Someone try it out and let me know if it works, and do report back if you have problems anywhere along the way.

Once it's confirmed to work on machines with real broken NVRAM, I'll start investigating the update process. And if/when I can get it working reliably for both installs and upgrades, I will contact Acidanthera and see if they'd be interested to add this method as a Quirk, to fix upgrade/install for anyone with non-working NVRAM. No guarantees they'll consider it suitable to add, but I'll have a go. At the very least, I'll look into making a Dortania guide for it in future.

But first we need to see if it works :)
Thanks for posting. I will try this over the weekend. I think this method will also work for "upgrade" from Catalina.
 
Joined
Mar 6, 2013
Messages
232
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
Vega 64
Mobile Phone
  1. Android
Thanks for posting. I will try this over the weekend. I think this method will also work for "upgrade" from Catalina.
It will, though it's much easier to get the necessary NVRAM key when doing an update. No need to parse OpenCore logs.

I'm working on a Python script at the moment which can be run on any Mojave or Catalina install, and generates the necessary key and optionally adds it to your OC config.plist.

Should be ready soon.

And I just realised that once a user is on Big Sur, they likely won't need this method again. Today I updated 11.1 beta1 to beta2, and of course it doesn't ever reboot at all. With the new snapshot SSV system, it applies the update live and only reboots at the end. So I don't think lack of NVRAM will prevent updates once a user is already on Big Sur. It's purely a problem when upgrading from an earlier macOS, or doing a fresh Big Sur install.
 
Joined
Feb 24, 2013
Messages
2,553
Motherboard
ASUS WS X299 SAGE/10G
CPU
i9-9980XE
Graphics
Radeon VII
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
It will, though it's much easier to get the necessary NVRAM key when doing an update. No need to parse OpenCore logs.

I'm working on a Python script at the moment which can be run on any Mojave or Catalina install, and generates the necessary key and optionally adds it to your OC config.plist.

Should be ready soon.

And I just realised that once a user is on Big Sur, they likely won't need this method again. Today I updated 11.1 beta1 to beta2, and of course it doesn't ever reboot at all. With the new snapshot SSV system, it applies the update live and only reboots at the end. So I don't think lack of NVRAM will prevent updates once a user is already on Big Sur. It's purely a problem when upgrading from an earlier macOS, or doing a fresh Big Sur install.

just did a beta 1 to beta 2 here too it rebooted once then again but to a black screen (most likely stuck at bios screen) so I did a hard reboot and all is fine.

Funnily enough it auto picks efi partition from the picker, which goes to another blank screen so have to choose the macos drive. Catalina and prior it would auto select the proper preboot drive during updates.

but so far update went smooth no issues other than above.
 
Joined
Mar 6, 2013
Messages
232
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
Vega 64
Mobile Phone
  1. Android
Interesting. I actually didn't watch the whole process. I started the install, and it was at "5 minutes left" when I went to dinner. Came back an hour later, sitting at the login screen, updated.

So I don't know how many reboots happened, just that they worked automatically without problems for me.

I'll be doing a 11.0.1 -> 11.1 beta upgrade in the next day or two, to confirm my assumption that the NVRAM key isn't needed for upgrades from Big Sur. I'll watch it more closely when I do.
 
Joined
Feb 24, 2013
Messages
2,553
Motherboard
ASUS WS X299 SAGE/10G
CPU
i9-9980XE
Graphics
Radeon VII
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
Interesting. I actually didn't watch the whole process. I started the install, and it was at "5 minutes left" when I went to dinner. Came back an hour later, sitting at the login screen, updated.

So I don't know how many reboots happened, just that they worked automatically without problems for me.

I'll be doing a 11.0.1 -> 11.1 beta upgrade in the next day or two, to confirm my assumption that the NVRAM key isn't needed for upgrades from Big Sur. I'll watch it more closely when I do.

Yeah it's definitely different compared to Catalina since we're basically live on the SnapShot and it can upgrade in the background, which definitely skips 1 process (where it would expand the APFS volume and then retract). It's definitely like iOS.

Sorry can't help with NVRAM issues, my SAGE10G has been nothing but problem free for a while now.
 
Joined
Jul 14, 2019
Messages
103
Motherboard
ASUS WS SAGE/10G
CPU
i9-10940X
Graphics
Radeon VII
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
@izo1 I'm running BS release w/o particular problems, only the DP audio of my R7 doesn't work. As I have the same system as yours, can you share your EFI? Do you remember? I made my 1st Catalina OC installation with your EFI last august ... :)
 
Top