X299 Big Sur Support

[Loloflatsix]

I tried the alternative SSDT-PMC suggestion - again it looks good, no PMC1 device but does show just a single PMCR device but it still isn't holding variables unfortunately.

I feel like this is really close to being resolved...

Is there any way opencore could be resetting NVRAM on each boot? Like an incorrect setting in config.plist?

Maybe you've already read on Dartonia for Emulated Nvram, this creates nvram.plist on update volume (if I remember) :Emulated Nvram ?

 

[TheBloke]

I might be wrong, but I thought that emulated NVRam couldn't possibly work in an install/update procedure, because the method used for saving NVRam is a script, executed on shutdown:

This works OK with a normal day-to-day usage of macOS, because whenever you shutdown that script will run and save the current contents of NVRAM to nvram.plist.

But in an update/install scenario, that script will never execute. Therefore NVRAM will never be saved to nvram.plist?



I do have an idea for a theoretical workaround for enabling non-NVRAM X299 users to update/install:

1. Someone with working NVRAM could do an upgrade or install
2. After each reboot during the process, they check the current contents of NVRAM, and make a list of any new or changed NVRAM variables
3. Someone with broken NVRAM could then try to do an update/install via the following method:
   1. Start the install normally for the first stage
   2. At the first reboot, edit config.plist and add any NVRAM variables that should be present at this stage
   3. At the second reboot, edit config.plist again if there are any new/changed NVRAM variables expected at this point
   4. Repeat for each reboot

In theory - and it's only theory at the moment - this would allow the install/update to work, because config.plist would be used to manually provide all the expected NVRAM variables, at the right time.

It would be a bit inconvenient editing config.plist multiple times for multiple reboots, but it might still be quicker and easier than having to do the update on a completely different system. And for people who don't have a second hack or real Mac, this might enable them to do the update/install.

I have confirmed that I am able to list all EFI variables by booting from an Ubuntu USB stick. So I do have a way to record what variables are present, and their current values.

When I have time, hopefully later today, I will try a Big Sur install or upgrade and will record the variables at each stage of the process, and see if I can find variables being added or changed. If so, I'll see if I can prepare some config.plist files that a non-NVRAM X299 user could test an install with.

Of course this is no replacement for properly working NVRAM. But it might get some X299 users on Big Sur until a way is found to get NVRAM properly working on X299.

 

[Loloflatsix]

I might be wrong, but I thought that emulated NVRam couldn't possibly work in an install/update procedure, because the method used for saving NVRam is a script, executed on shutdown:

View attachment 498095

This works OK with a normal day-to-day usage of macOS, because whenever you shutdown that script will run and save the current contents of NVRAM to nvram.plist.

But in an update/install scenario, that script will never execute. Therefore NVRAM will never be saved to nvram.plist?



I do have an idea for a theoretical workaround for enabling non-NVRAM X299 users to update/install:

1. Someone with working NVRAM could do an upgrade or install
2. After each reboot during the process, they check the current contents of NVRAM, and make a list of any new or changed NVRAM variables
3. Someone with broken NVRAM could then try to do an update/install via the following method:
   1. Start the install normally for the first stage
   2. At the first reboot, edit config.plist and add any NVRAM variables that should be present at this stage
   3. At the second reboot, edit config.plist again if there are any new/changed NVRAM variables expected at this point
   4. Repeat for each reboot

In theory - and it's only theory at the moment - this would allow the install/update to work, because config.plist would be used to manually provide all the expected NVRAM variables, at the right time.

It would be a bit inconvenient editing config.plist multiple times for multiple reboots, but it might still be quicker and easier than having to do the update on a completely different system. And for people who don't have a second hack or real Mac, this might enable them to do the update/install.

I have confirmed that I am able to list all EFI variables by booting from an Ubuntu USB stick. So I do have a way to record what variables are present, and their current values.

When I have time, hopefully later today, I will try a Big Sur install or upgrade and will record the variables at each stage of the process, and see if I can find variables being added or changed. If so, I'll see if I can prepare some config.plist files that a non-NVRAM X299 user could test an install with.

Of course this is no replacement for properly working NVRAM. But it might get some X299 users on Big Sur until a way is found to get NVRAM properly working on X299.

Yes you'r right with these explanations : the method used for saving NVRam is a script, executed on shutdown : you must therefore complete the installation procedure before :

 

[dank0]

One more question - after updating VirtualSMC and SMCProcessor and SMCSuperIO, i am getting weird numbers in minimum and maximum RPM. Is there some Patch to fix those values? Also is there way to manage GPU fan speeds?

 

[rustEswan]

If so, I'll see if I can prepare some config.plist files that a non-NVRAM X299 user could test an install with.

Of course this is no replacement for properly working NVRAM. But it might get some X299 users on Big Sur until a way is found to get NVRAM properly working on X299.

I really like this idea - if you can get it to work it could be a good option for those not wanting to mess with custom UEFI BIOS hacks...

Still could potentially break on major upgrades but it could be worth it for people to at least get installed if they don't have a working Mac on hand

 

[shutterbug168]

If you do it this way it only wants to reboot once, when it does that just unplug the drive at reboot and let your real Mac boot as normal back into MacOS then plug it back in, mount the EFI partition, copy over your EFI folder and then go and plug it into your hack.

SO CLOSE... yet so far After the first reboot finished on my cMP5,1 (the "last minute" lasted more like 15/20 mins), I unplugged the drive... And copy the EFI over and connect it to my X299. The installer showed up on bootpicker, and I let it finish this last step -- no Apple status bar showing up here, just a lot verbose texts scrolling through. And the machine rebooted and the BS drive shows up! But I am still stuck here... Any idea on what the problem is? Many thanks!

 

[TheBloke]

I'm still not sure that you should transfer the drive until the install is complete. Nothing I've read indicates that the Big Sur sealing process is connected to a particular system. The sealing process creates a checksum for each file on the disk - a snapshot. I've not seen any mention that this checksum is system dependent.

So if you transfer the drive before all reboots are complete, I'd think you're likely to still hit the NVRAM issue.

If it were me I would do it the way I described before: install Big Sur on the other hack up to the point of the first login / create account screen, and confirm the install is complete. Only then transfer the drive.

I'm currently installing Big Sur on a fresh 128GB SSD on my X299, to test a fresh install. When it's done I'll try and confirm what I said above for myself, by seeing if that drive will boot in my X58 system (assuming the X58 is even capable of Big Sur - not sure on that yet!)

Then I'm going to try an install in which I've disabled NVRAM, to confirm I see the same issues you all describe. Then finally I'll try the method of recording NVRAM after each step of a successful install, and see if my theoretical method of manually applying those NVRAM variables via config.plist is workable.

 

[rustEswan]

I'm still not sure that you should transfer the drive until the install is complete. Nothing I've read indicates that the Big Sur sealing process is connected to a particular system. The sealing process creates a checksum for each file on the disk - a snapshot. I've not seen any mention that this checksum is system dependent.

Yeah I agree - I might have got lucky, I've only had to do it once and it worked out fine but it would make sense to just finish the installer completely before moving to the other machine.

@shutterbug168 - The other thing to note is that if its a SATA SSD you might need to make sure you have the Catalina AHCI kext added to your EFI/config.plist.
When connected to the other machine via USB it would of course work fine but if you attach to SATA on Big Sur you might be having a problem there. Don't forget you can use the "min. Kernel version = 20.0.0" property to only load that kext on Big Sur if you have older installations on the same machine.

@TheBloke - Really interested to those results with disabled NVRAM and your method to try and make it work. For now I'm going to try and clone my Big Sur install that's currently on a spare SATA SSD over to my main NVME drive and keep this install on SATA as a testbed - once an update comes out I'll try it on this install first to see if it survives the reboots

 

[TheBloke]

The other thing to note is that if its a SATA SSD you might need to make sure you have the Catalina AHCI kext added to your EFI/config.plist.

I've not heard of this. I've done a Catalina -> Big Sur update on two SATA3 SSDs now and it worked fine. I've not actually install Big Sur on NVMe yet, as I'm saving that for when I'm upgrading to Big Sur for good.

Does the need for that kext vary by motherboard maybe?

Right now I'm doing a fresh install of Big Sur - first one I've done, as the other two were updates - on a third SATA3 SSD, so I'll see if that's any different. But so far it seems to be running OK.

 

[amitbapat]

I tried exactly same approach for my MSI X299 Raider based Hackintosh. I have a real MacPro (2013, old and slow) that I used to install Big Sur 11.0.1 on the SSD connected to USB, then transferred it back to the Hackintosh and added the EFI folder. Boots just fine into Big Sur.

Another update - this only worked for my SATA SSD. When I tried to update my NVME SSD (via NVME-USB adapter) - it did not work. My NVME SSD when used via USB never becomes bootable, so the installation never completes. So stuck now on 10.15.7 until a solution is found.