Contribute
Register

X299 Big Sur Support

Joined
Dec 12, 2013
Messages
178
Motherboard
aorus master x299x
CPU
I9 10900x
Graphics
vega 64
Mac
  1. Mac Pro
Mobile Phone
  1. iOS
seems my score is low ? i didn't overclock
 

Attachments

  • Capture d’écran 2020-11-30 à 10.52.30.jpg
    Capture d’écran 2020-11-30 à 10.52.30.jpg
    93.2 KB · Views: 53
Joined
Feb 24, 2013
Messages
2,669
Motherboard
N/A
CPU
N/A
Graphics
N/A
Mac
  1. MacBook Air
  2. Mac Pro
Mobile Phone
  1. iOS
seems my score is low ? i didn't overclock

Seems ok, GeekBench is not the end all be all for benchmarks. The 10900x is not going to be better than a 10900k which is fine tuned for single core performance (and hits 5Ghz on stock), but you can always drop in a 10980XE (which is slower than 9980XE, because of Intel's meltdown etc mitigations) for better multi-core performance.

Just be happy, that's a good score you have there.

I can personally push more on my system, but I chose silence/lack of fan noise over a few extra 5%-8% increase in performance on top of the OC I have going now.
 
Joined
Mar 6, 2013
Messages
273
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
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. 1606754326266.png
  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. 1606754752978.png
  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. The NVRAM key you added (msu-product-url) can either be removed or left in config.plist - it should work identically for future updates if any require it, however Big Sur to Big Sur upgrades use a new method, based on snapshots, so it may not be needed again.

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 :)
 
Last edited:
Joined
Jul 20, 2014
Messages
871
Motherboard
AsRock X299 Creator-1.50
CPU
i9-10900X
Graphics
RX 6800 XT
Mac
  1. MacBook 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 :)
Big Thanks
I will test that tomorrow :clap: and report
[EDIT]
It Worked Perfectly and exactly as you described
Well done

I didn't remove my NVMEs but there no OSes on them
I boot on the same mobo with catalina to run your script

[EDIT]
1 - I can't succeed to replicate the installation an another SSD !!! I'm stuck in the loop of the second boot.... like the modification (msu-product-url) of config.plist isn't working
2 - the first installation have an issue due to the Broken Seal:
capture 2020-12-01 at 10.19.07.jpg

I'm working on it
 
Last edited:
Joined
Mar 6, 2013
Messages
273
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
Great, glad to hear. I'm working on the upgrade process now.
 
Joined
Feb 26, 2011
Messages
126
Motherboard
ASUS PRIME X299-A II
CPU
i9 10940X
Graphics
AMD Radeon RX 6800 XT
Mac
  1. MacBook
  2. MacBook Pro
Mobile Phone
  1. iOS
Big Thanks
I will test that tomorrow :clap: and report
EDIT
It Worked Perfectly and exactly as you described
Well done

I didn't remove my NVMEs but there no Ones on them
I boot on the same mobo with catalina to run the you script
Great news - I too will be testing this method on my NVMe and I'll report back - amazing work @TheBloke

Thanks!

If this is repeatable I think it could be worth listing on the main post the boards we know have broken NVRAM and highlight that for anyone first coming to the thread with install problems which boards have this issue and of course we should also highlight and credit the workaround here, good work :)
 
Joined
Mar 18, 2017
Messages
1,032
Motherboard
ASUS ROG Rampage VI Extreme
CPU
i9-7940X
Graphics
2 X VEGA 56
Mac
  1. iMac
  2. Mac mini
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 :)
Just great ! :clap::thumbup:
 
Joined
Dec 12, 2013
Messages
178
Motherboard
aorus master x299x
CPU
I9 10900x
Graphics
vega 64
Mac
  1. Mac Pro
Mobile Phone
  1. iOS
Seems ok, GeekBench is not the end all be all for benchmarks. The 10900x is not going to be better than a 10900k which is fine tuned for single core performance (and hits 5Ghz on stock), but you can always drop in a 10980XE (which is slower than 9980XE, because of Intel's meltdown etc mitigations) for better multi-core performance.

Just be happy, that's a good score you have there.

I can personally push more on my system, but I chose silence/lack of fan noise over a few extra 5%-8% increase in performance on top of the OC I have going now.
 
Joined
Feb 24, 2013
Messages
2,669
Motherboard
N/A
CPU
N/A
Graphics
N/A
Mac
  1. MacBook Air
  2. Mac Pro
Mobile Phone
  1. iOS
Thanks keko. I'm starting to think that every Hack has a broken seal and I guess it's just normal at the moment.

I just re-read the Dortania guide (https://dortania.github.io/OpenCore-Install-Guide/extras/big-sur/#broken-seal) and I realised that actually it says to check that the Snapshot is sealed:

View attachment 498986

And we do have "Snapshot Sealed : YES". So we do check out OK according to Dortania.

I'd still like to understand why the main FS shows as Broken, which I assume must not be the case on a real Mac. But I guess it's probably not actually any problem, and that it is expected on a Hack.

More info here.

 
Joined
Dec 13, 2018
Messages
45
Motherboard
Asus X299-A Prime
CPU
i7-7800x
Graphics
RX 5700XT
Mac
  1. MacBook Pro
Mobile Phone
  1. Android
  2. iOS
All Apple apps will be optimized for sure, but Adobe is on another level when it comes to optimizations: they have the worst engineers in the industry.

FCP, Logic Pro, XCode etc are all going to work well from Day 1. Maybe even Davinci Resolve. But not other applications. I'll take a look at Apple Silicon again in 1 year.
I admit that the only app I really use is Xcode. Also, I want to get the opportunity to work (and eventually sell) multi-platform apps. I just experimented the power of Catalyst to "port" my TerminalWidget from iOS to macOS, an I had to say that they did a really good job with it. I had to change 0 lines of code to get it working. I only miss the CoreLocation support, but I guess it has to be with my Hackintosh rather than the app itself.

If anyone likes I can share the widget :)
Schermata 2020-12-01 alle 15.23.11.png

Simple answer: monopoly.

When you're the only game in town, you don't really need to work harder than anyone else. They really need to stop adding these crappy "features" in lets say Photoshop that no one really uses. They should be optimizing their software.

The fact that After Effects still doesn't take advantage of multi-core processors is insane. You have to run aerender in terminal and render out to an image sequence, or use something like BGRender/RenderGarden to max out your renders.

My main reason for getting rid of hackintosh is not the fact that I can't afford a real Mac, but the fact that I don't want to fiddle with computers all day. I only built this machine because at the time there was no Mac Pro, and now that Apple is switching processors yet again, we're stuck in limbo and it's a waiting game.

Yeah, I feel you. In the end I'm really unsure how long can a M1 last or what to expect from the next M1X or M2 and the best is probably wait and see the next 16" at least.
At the same time I thought this was the last opportunity to sell my 2015 13" Pro, since Big Sur will be the last supported os and the machine itself was very low-powered for my work. I selled this base model for the astonishing price of 450€ with the idea of picking a base air for an extra 600€, that sounded very little for the improvement. But than I opted for the pro with 16/512.
I hope to be right and not to waste the money...
 
Top