Contribute
Register

X299 Big Sur Support

Status
Not open for further replies.
I use UL850's (2 of them) and I love them. I had 2 38" Ultrawide LGs but they weren't full retina and Ultrawide is a gimmick in my opinion. I paid around $500 each.

I saw the UL600's for $279 per recently, not sure if it's still the same price, but it's the same exact panel, except it doesn't have some features like USB-C, built in speakers (they are not that great anyway) and tilting on the stand (I think)...

Yep it's still $279 at Best Buy. I have two and a UK600.
 
I use UL850's (2 of them) and I love them. I had 2 38" Ultrawide LGs but they weren't full retina and Ultrawide is a gimmick in my opinion. I paid around $500 each.

I saw the UL600's for $279 per recently, not sure if it's still the same price, but it's the same exact panel, except it doesn't have some features like USB-C, built in speakers (they are not that great anyway) and tilting on the stand (I think)...
Yep it's still $279 at Best Buy. I have two and a UK600.

I finally ended up buying 2 x Dell UltraSharp U3219Q 32" 4K IPS HDR400. They are a lot more bright than the LGs you listed (300 nits vs 480nits) and better image quality overall (it's pretty much the same to the LG UL950). Obviously it costs a lot more at around 900€, I bought 2 :headbang:
 
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 :)

Sorry this has taken all week to get around to testing, been busy with work.

Anyway - worked like a charm - good clear instructions @TheBloke thanks again for your work on this. Now installed and running great on my NVMe drive.

One tip I have for anyone struggling to edit their config.plist with the new key: Make sure to use a text based editor or open in Xcode and click "view > Show code review" then you can manually type/cut and paste the two lines from GenNVRAMkey.command.
Reason I mention this, I had got used to just using Propertree for all my .plist edits but adding a new child in the correct section and choosing type as "Data" doesn't allow us to enter the trailing non-hex "=" character at the end of the key.

Also just confirming the expected in that I now have:
  • Sealed: Broken
  • Snapshot Sealed: Yes
So both being "Yes" previously, was almost certainly related to completing the install to SSD from a real Mac.

With the exception of my NVRAM I think this is a great build and is working well enough to be my daily driver. A few cosmetic bits to tidy up with device properties but otherwise very happy.

...now to track down an RX 6800...
 
Last edited:
Good to hear, thanks for the report.
One tip I have for anyone struggling to edit their config.plist with the new key: Make sure to use a text based editor or open in Xcode and click "view > Show code review" then you can manually type/cut and paste the two lines from GenNVRAMkey.command.
Reason I mention this, I had got used to just using Propertree for all my .plist edits but adding a new child in the correct section and choosing type as "Data" doesn't allow us to enter the trailing non-hex "=" character at the end of the key.
Good point. My script assumes the user will add it in manually with a text editor. As you say, adding with ProperTree isn't accounted for by the script as ProperTree requires it in hex, and I didn't think to output it in that format.

I've been working on a Python script that will automate all this, including directly adding it to the user's config.plist so they don't need to edit anything manually. I keep getting side tracked onto other things, but hopefully I'll release a beta here by the beginning of next week. It will support both new installs of Big Sur and upgrades from Mojave and Catalina.

...now to track down an RX 6800...

Still no acceleration as of 11.1 beta 2. I'm somewhat optimistic that by the time 11.1 is gold, it will be working. So you have a few weeks for F5 bashing :)
 
Last edited:
With the exception of my NVRAM I think this is a great build and is working well enough to be my daily driver. A few cosmetic bits to tidy up with device properties but otherwise very happy.

...now to track down an RX 6800...
We still need to test if updates work without NVRAM support ;)
I'm also tracking down an RX 6800 XT :crazy:
 
Yeah - I plan to do that test soon, before I release the tool.

If they don't, hopefully at least the tool can help. Or in fact, it's possible that even if NVRAM is required, the same variable that works for updates from Mojave/Catalina to Big Sur would also work for Big Sur -> Big Sur. The NVRAM variable contains the UUID of the APFS Data partition. This won't change between updates.

Meaning you could add it to your config.plist permanently, and thereafter it would enable all future updates. At least unless/until you changed your active SSD/NVMe drive.

That is if NVRAM is even required - I think it might well not be needed once you're on Big Sur.

I'll let you know when I've had a chance to test.
 
After quite time consuming fiddling and the help from some EFI folders in this thread i would say i made the full transition to OpenCore as well as Big Sur. Finally...

Im using an ASRock X299E-ITX/ac with AMD Radeon Vega 56 and an original Apple Airport Extreme BCM94360CS2 card. All 3 SSD slots are populated. I reused my USB-Kext from my old clover setup and think it works.

This EFI folder is based on OpenCore 0.6.3 Release without verbose boot messages. And i too can attest that OpenCore is fast. Nice!

I installed Big Sur (i write it out because BS reads like b*llsh*t for me ;) ) using a real 2014 MacBookPro on a NVMe Drive in an external enclosure and afterwards transferred my settings with migration assistant. That is after i installed it in the Hack, of course.

System specific data in config.plist under PlatformInfo -> Generic is removed, so please fill in with your data.

Bildschirmfoto 2020-12-06 um 00.28.09.png
 

Attachments

  • EFI.zip
    2.6 MB · Views: 140
Last edited:
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 :)
I was able to successfully upgrade my Catalina Hackintosh (MSI Raider X299 Motherboard, with broken NVRAM) to Big Sur.
1. Boot into Catalina. System Preferences -> Software Update -> Upgrade to Big Sur. Run through Big Sur install.
2. When system reboots, use the USB stick with OpenCore 0.6.3 DEBUG version as @TheBloke described in the post.
3. After OpenCore boot menu appears, shutdown the Hackintosh. Take USB to another Mac, mount the EFI feed the log file to the GenNVRAMKey.command script to get the msu-product-url value.
4. Update config.plist and add msu-product-url value.
5. Take the USB back to Hackintosh and boot. Select "macOS installer". Boots fine, and install continues.
6. After 2-3 reboots (I continued using the USB to boot) - install was successful.
7. Removed USB and let the system boot from the NVMe drive's EFI.

Everything worked perfectly and I have Big Sur installed on my machine. I'm still awaiting my replacement X299 board I ordered (ASUS X299-E) and will swap out my MSI board when it arrives.

Thank you @TheBloke for all the help!!
 
Yeah - I plan to do that test soon, before I release the tool.

If they don't, hopefully at least the tool can help. Or in fact, it's possible that even if NVRAM is required, the same variable that works for updates from Mojave/Catalina to Big Sur would also work for Big Sur -> Big Sur. The NVRAM variable contains the UUID of the APFS Data partition. This won't change between updates.

Meaning you could add it to your config.plist permanently, and thereafter it would enable all future updates. At least unless/until you changed your active SSD/NVMe drive.
Okay , I understand. Clever :thumbup:
I'll let you know when I've had a chance to test.
Thanks
 
Yeah - I plan to do that test soon, before I release the tool.

If they don't, hopefully at least the tool can help. Or in fact, it's possible that even if NVRAM is required, the same variable that works for updates from Mojave/Catalina to Big Sur would also work for Big Sur -> Big Sur. The NVRAM variable contains the UUID of the APFS Data partition. This won't change between updates.

Meaning you could add it to your config.plist permanently, and thereafter it would enable all future updates. At least unless/until you changed your active SSD/NVMe drive.

That is if NVRAM is even required - I think it might well not be needed once you're on Big Sur.

I'll let you know when I've had a chance to test.
Great project, thanks for your work. :clap::thumbup:
 
Status
Not open for further replies.
Back
Top