Contribute
Register

X299 Big Sur Support

Status
Not open for further replies.
Asked this in the Buying Advice section but it's probably better to ask here.

I'm thinking of buying an Asus x299-a ii to build a new Hackintosh. It's one of the only ATX refresh boards.

Does anyone have any experience with this MB? good or bad?

Thanks
 
Screenshot 2020-11-22 at 14.44.34.png



So....

(I'll get around to how in a second, but I'm not recommending it...)

What does this tell us?
  • Big Sur can be made to work on refresh X299 boards at least inc MSI X299 PRO (maybe others)
  • My EFI/SSDT's are working (I haven't checked everything yet and it may need adjusting/fine tuning)
  • Our problem must be related to the installer failing or some part of the install process not completing successfully due to either our hardware or configs.
How did I get it up and running? I forgot that I have a cheap £5 USB-C to SATA adapter - I plugged it into my MacBook with a spare SATA SSD, ran the Big Sur installer, pointed it at the external drive, at the first reboot I just unplugged it from my MacBook then plugged it into my PC on an internal SATA port and used my untouched working Catalina EFI to boot first time without so much as a hiccup. Completed the install and here we are.

However, the idea that any future update could very easily break it again does worry me. I would consider this a very rough workaround at this point and the installer failing definitely needs more investigation.

I spotted a definite error last time I tried from the USB installer "unable to get fs for /Volumes/Big Sur/MacOS Install Data" - googling that turned up several posts about similar issues on real Mac's failing to create APFS volumes during the install and needing to use MacOS online recovery. I think further investigation of the installer failure is our best bet for a long term solution in case it is something to do with a configuration setting or something specific to our hardware.

Thoughts?
 
Last edited:
The plot thickens...

So the SATA SSD I just managed to get everything working on was a separate disk I'd not tried before.

I was wondering if the installer failure was related to the actual hardware - the type of disk which I had been trying to install on. So I unplugged my intel SSD that I was using as my Big Sur target (that had been through the failed install) and attached it to my MacBook using the USB-C to SATA adapter thinking I would just wipe it and see if it completes an install.

I first used disk utility to reformat as APFS and I can't - I get this message:

Screenshot 2020-11-23 at 00.07.22.png



And I'm sure some of the error messages I see in the installer log point to "UpdateBrainService" or something - I swear I've seen it somewhere in this troubleshooting process - but I have a strong suspicion this is related to the installer issue.


Edit: Take that with a grain of salt - 4th attempt after unplugging/replugging it has now successfully formatted... and anyway this is obviously referring to a local process on a different machine - got a bit excited there, probably unrelated!
 
Last edited:
The Error 97 when restarting the PC has now disappeared again. After making some improvements in the BIOS and the OpenCore settings in relation to Big Sur (20b29), it works again.
Do you know what you changed? The mainboard still reports Error 97 (or a different error code prior to the POST screen). It happens every second reboot. What's left then is a non-blinking cursor (as seen in the picture) and the only salvation is a complete power cycle.

1606091224043.png
 
@rustEswan ➧ MSI X299 PRO
@shutterbug168 ➧ Asrock X299 Creator
@Compact ➧ What is your mobo brand and model ?
@oli.mathieu ➧ Asrock X299 Creator
We have all the same issue:
is it an issue that the USB installer reboots when "12 min remaining" ?
I did also encounter the same situation.
What I've done to conquer this is "Completely format the destination disk (not the partition, but the entire disk) with APFS using DiskUtility".
For some reason, HFS+ is not working here.
Maybe I am wrong. But you guys should give this a try.
At least, this solve my problem.
Good Luck!
 
I did also encounter the same situation.
What I've done to conquer this is "Completely format the destination disk (not the partition, but the entire disk) with APFS using DiskUtility".
For some reason, HFS+ is not working here.
Maybe I am wrong. But you guys should give this a try.
At least, this solve my problem.
Good Luck!
Thanks
I already did that
I'll do it again ..to be sure
 
Depends where you live?

I'm in the UK, and I got my 6800 from Overclockers.co.uk. They're charging more than MSRP; I paid £600 for the 6800, which is the suggested price of the XT! I was within 3 minutes of getting the XT last Wednesday - people who ordered around 14:30 got them, my order at 14:33 did not. They had major technical problems that caused their site to go down repeatedly, and the cards not to even appear on the lists for many people (me included for a long time). It was so bad that they didn't actually receive any orders until 14:20, despite putting the cards live at 14:00. Then their system didn't automatically take the order button down, so they took something like 1000 orders when they only had 100-200 cards. I was one who managed to place an order and so thought I might get a card, only to get a refund some hours later.

But the upshot of all that chaos was that they ended up disabling ordering before they'd sold all the 6800s, so they put some back on sale the next day, Thursday, and only announced it in their forum, which is how I got one.

Apparently a lot of people have managed to get one direct from amd.com. You can check that site wherever you live in the world. It doesn't even list the 6800s whenever I go look, but apparently if they're available to buy, they will show up and you can order from them direct.

AIBs will go live at 14:00 local time on Wednesday 25th. So be ready for then, have a bunch of possible sites open, get an auto-refresh script running on each site, and hope to have a lot of luck :) Oh, and pay by debit/credit card if you can, instead of Paypal. I learned that Paypal orders can take 10+ minutes to get confirmed as paid, and the site may use the 'paid' time as your place in the queue, not the time you actually completed checkout.

Note however that overclockers.co.uk said that although they'd go on sale on Wednesday 25th, they wouldn't actually have any stock until end Nov or early Dec. So even if you do get lucky, there will probably be a 1-3 week wait. I don't know if that applies to all retailers or just some.

Of course there's also the 6900XT on the 9th :) But at $1000 MSRP, that's a bit too rich for me..
You are lucky to be able to order one in your country: here they are not available anywhere.
 
to all having problems with stock on install / reboot: do you have a ssdt with:

External (_SB_.AWAC, DeviceObj)
External (STAS, IntObj)
Scope (_SB.AWAC)
{
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
If (_OSI ("Darwin"))
{
STAS = One
}
}
}

this helps me to install without problems...

edit: forgott --- External (STAS, IntObj)
 
Last edited:
Ah, interesting. Have you tried agdpmod=pikera boot argument? I think this is needed for the RX580 GPU you have, but I heard it is not needed on MacPro7,1 - which could explain why that SMBIOS works for you?

Since I wrote to you earlier I have been doing some investigation on the MacPro 7,1 memory notification issue, and I have made some theoretical progress:

In Catalina, I have successfully removed the "invalid memory" notification, without using MacProMemoryNotificationDisabler.kext.

The method used was not pretty :) In order to do this, I had to manually patch a file on the write-protected /System partition: /System/Library/CoreServices/MemorySlotNotification

What I did was look at the source code for MacProMemoryNotificationDisabler.kext to see what kind of binary patch the author was making, and to which file. Then I manually made the same patch to the same file, direct on disk. In other words, I made a static, permanent version of the same patch that MacProMemoryNotificationDisabler.kext makes dynamically via Lilu's patching facilities.

In order to do this on Catalina, I only had to mount the / partition read-write (mount -uw /). Possibly I needed to disable SIP as well, but I always have that disabled anyway via OpenCore.

Of course on Catalina there is no need for all this, because Lilu's userspace patching works fine, so the MacProMemoryNotificationDisabler.kext works and is much preferable to making a permanent patch on /System.

It's on Big Sur that this method might actually be useful, at least as a last resort.

I haven't yet tested it on Big Sur, but I believe it should work there too. Unfortunately making this change on Big Sur is a lot more hassle. From what I have read, I believe the following steps will be required to make the same patch on Big Sur:
  1. Disable SIP - csrutil disable (or via OpenCore config.)
  2. Disable SSV - csrutil authenticated-root disable
  3. Reboot
  4. Make a temporary mount location: sudo mkdir /mnt
  5. Mount the / drive read-write (example command): sudo mount -o nobrowse -t apfs /dev/disk1s5 /mnt
  6. Copy the patched file to /System/Library/CoreServices/MemorySlotNotification
  7. Re-snapshot and bless the modified root partition: sudo bless --folder mnt/System/Library/CoreServices --bootefi --create-snapshot
  8. Reboot: sudo reboot
I copied these commands from a blog post linked earlier in this thread, that explains how to edit a plist file to avoid the bug/issue with Little Snitch firewall not being able to block Apple services in Big Sur: https://tinyapps.org/blog/202010210700_whose_computer_is_it.html

I don't yet have a Big Sur install, so I can't test this immediately. But I will be doing a test upgrade to Big Sur in the next few days, and will test it then.

TLDR: I believe I may have a workaround/hack for the MacPro 7,1 memory notification problem that will work on Big Sur. However, it will require patching a file direct on /System, and therefore requires disabling SIP and SSV, rebooting, and then re-snapshotting the filesystem. I believe it also requires running without SSV and SIP from then on.

It's far from ideal! Personally, if I couldn't use iMacPro SMBIOS, then I'd be happy doing these steps. I've had SIP disabled forever anyway, and I wouldn't care about also disabling SSV (which no previous macOS even had). But not everyone may be so keen on such methods.

Anyway, I'll report back once I've actually confirmed it does work on Big Sur :) Then I can explain how to do the patch, and you and others can decide if it's something you're interested to do on your system.

This is a good find, but it's best to not modify system files, as they usually get overwritten by OS updates anyway.

The Mac Pro memory notification is annoying and I hate having an extra kext just to fix that cosmetic issue, but once it's in the EFI, I forget about it. :thumbup:
 
This is a good find, but it's best to not modify system files, as they usually get overwritten by OS updates anyway.

The Mac Pro memory notification is annoying and I hate having an extra kext just to fix that cosmetic issue, but once it's in the EFI, I forget about it.
You're absolutely right - the kext is far preferable.

But the reason I started this research is that the MacProMemoryNotificationDisabler.kext does not work on Big Sur at this time. The userspace patching tools it requires, provided by Lilu, are not working in Big Sur, due to changes in Big Sur's kernel.

Therefore currently there is no solution at all for the Mac Pro memory notification on Big Sur. Loading the kext will not work.

This is why I investigated this hacky method :) Which as you say, would have to be re-applied on every update.

The other way is to avoid the problem entirely by switching to iMacPro 1,1 SMBIOS, and I think that is what most people are doing.
 
Status
Not open for further replies.
Back
Top