SATA Controller is not being recognised - SATA M.2 SSD

[Vitoli-o]

Hi,

I am using the latest commits (debugs) of OpenCore 0.6/WhateverGreen 1.4.1/Lilu 1.4.6/VirtualSMC 1.1.5 from here (Saturday 05:44) and it turns out that SATA controller from Intel is not being recognised correctly when booting macOS 11 / Big Sur Beta 2 installers.

This configuration works fine in Catalina, without any problems.

At first, I thought this was Big Sur-related, but I believe it has to do with OpenCore, as it does not allow the kext to be loaded correctly and prompts an error when retrieving the HDD disks.

Please find attached EFi folders and screenshots.

Thanks for your support
EFI.zip

[vit9696]

At first, I thought this was Big Sur-related, but I believe it has to do with OpenCore, as it does not allow the kext to be loaded correctly and prompts an error when retrieving the HDD disks.

Where do you see this? You probably forgot to attach the OpenCore log and point us to these lines.

[Vitoli-o]

I was not able to dump a log as Terminal shows on Big Sur installer:

Connection to logs failed

However, here is a video of the installation with logs boot-args: https://we.tl/t-JhaB6hJFns

The reason why I think it is related to OpenCore is because the SATA controller works with Catalina, but not with Big Sur using the same EFI folder.

As OpenCore is still in development stage for Big Sur, Apple might have brought changes to the way it handles APFS and SATA devices, which might need implementing with the next release of OpenCore? (Just guessing here, not a professional!)

Thanks for your help!

[vit9696]

Like I said, what am I supposed to look at? The only thing I remember about 10 series SATA driver is that started to name the Intel 10 Series Controller as Generic Controller in 11.0, yet I have no idea what you want from me. You say that OpenCore does not inject particular kexts, but you provide no proof on that and provide me with videos with no clear issues. Closing due to the lack of technical information.

[Vitoli-o]

@vit9696 : Many thanks for your support, again.

So the problem is that updating from OpenCore 0.5.9 to OpenCore 0.6.0 breaks SATA support.

Now, my EFI configuration has not changed.

This is what I am trying to show you.

You can see that OpenCore cannot see the volumes on the video and returns an error from IOAHCIBlockStorageDriver.

I am happy to provide more information if needed, just let me know what you would like to see.

[vandroiy2013]

@mr-vito Try to read carefully what @vit9696 wrote you and provide OpenCore debug log with 0.5.9 and 0.6.0!!!

[vit9696]

So the problem is that updating from OpenCore 0.5.9 to OpenCore 0.6.0 breaks SATA support.

Updating OpenCore or something else? Listen, nobody will bother finding the regression with you step by step. If you want to report a regression, please report the project and the commit where it happened.

[Vitoli-o]

Hi @vandroiy2013 @vit9696 , many thanks for your replies. I am trying to get my head around the issue, so please forgive me if I am not an expert on this field. I managed to dump a text log, where the system booted successfully.

I managed to re-create the EFis as followings:

1. (Debugs) OC 0.6.0 + Lilu 1.4.6 + VirtualSMC 1.1.5 + WhateverGreen 1.4.1 + AppleALC 1.4.6

2. (Releases) OC 0.5.9 + Lilu 1.4.5 + VirtualSMC 1.1.4 + WhateverGreen 1.4.0 + AppleALC 1.4.6

The EFI is simply HaC Mini 2.10, which is designated to work on Intel Nuc. The SATA controller is pci8086,a103 according to Hackintool. This is spoofed as pci8086,a102 by default and works well with Catalina and Mojave, never had any issues. Changing it to pci8086,a103 does not make a difference.

Booting Big Sur with EFI 2 ends in an error (as expected): https://we.tl/t-YVMrE85FtA

Booting Catalina with EFI 2 works (as expected): https://we.tl/t-6h34lf81mf https://we.tl/t-ok7r01mrAM (log)

Booting Big Sur with EFI 1 works, but there is no SATA drives/internal disks (not as expected): https://we.tl/t-FdYPJmppn8

Booting Catalina with EFI 1 ends in a Kernel Panic (not as expected, but instead boots fine in EFI 2 has no changed have been made to any kexts or config a part from the ones mentioned above): https://we.tl/t-qfqlIgYMMh

Now, if the problem was in fact Big Sur regarding the SATA controller, Catalina should boot successfully with both EFI 1 and EFI 2, but that is not the case as I have mentioned above.

Is it at all possible that the new OC has broken support for SATA for Intel 10 Series Chipset (pci8086,9d03/a103/a102)?

Multiple users on InsanelyMac are reporting the same issue. One user, reports a Generic AHCI controller in Big Sur vs Intel in Catalina:

I hope I have made myself clear around this issue?

Let me know if you have further questions.

[vit9696]

Yes, the steps are clear, yet just checking two EFI folders is not how it is supposed to be done to locate the exact issue:

• OpenCore, Lilu, VirtualSMC, WhateverGreen, AppleALC, and all the other drivers — are entirely separate products, which are quite complex and are developed independently by in fact slightly different teams.
• Major versions (like 0.5.9) are only valid for releases, when the tag (ready for manufacturing) is created and the binaries are uploaded. Before the tag is made there are many commits, which represent the "revision" part of the version. If you check e.g. https://github.com/acidanthera/OpenCorePkg/commits/master, you will see values like b7e99c1. So the version built from this commit is actually pre-release 0.6.0 b7e99c1.

What we need from you is to do the following on Catalina:

1. Find the product that caused the problem: you can independently upgrade and downgrade OpenCore and all the kexts.
2. Find the commit that caused the problem: e.g. if you realised that the problematic project is Lilu, you need to tell us when it broke.

To help you with that you could use prebuilt binaries from every commit: https://github.com/dhinakg/ktextrepo/tree/builds

[dhinakg]

This is not an issue with OpenCore. In Big Sur, Apple removed the AppleIntelPchSeriesAHCI class from AppleAHCIPort.kext (although there are still personalities that refer to it in the plist?), which was used in Catalina and below for your SATA controller (with the spoof from pci8086,a103 to pci8086,a102). However, there is still a generic personality in the kext that matches based on class-code and uses a different class, and this is the reason why some people with Intel controllers have SATA still working and why it shows up as Generic. Unfortunately, this generic personality does not work well with all controllers, like pci8086,a103: it attaches, works for a few seconds, then fails very early after attaching (IOAHCIBlockStorageDriver: could not recover SATA HDD after 5 attempts, terminating, as seen in your picture), and then detaches. The end result is that SATA does not work. The only solution I have found so far is to backport the kext from Catalina.

As per why your new EFI does not work and you encounter a kernel panic, like vit9696 said, you must isolate the product and commit that is causing the kernel panic.

[Vitoli-o]

This is not an issue with OpenCore. In Big Sur, Apple removed the AppleIntelPchSeriesAHCI class from AppleAHCIPort.kext (although there are still personalities that refer to it in the plist?), which was used in Catalina and below for your SATA controller (with the spoof from pci8086,a103 to pci8086,a102). However, there is still a generic personality in the kext that matches based on class-code and uses a different class, and this is the reason why some people with Intel controllers have SATA still working and why it shows up as Generic. Unfortunately, this generic personality does not work well with all controllers, like pci8086,a103: it attaches, works for a few seconds, then fails very early after attaching (IOAHCIBlockStorageDriver: could not recover SATA HDD after 5 attempts, terminating, as seen in your picture), and then detaches. The end result is that SATA does not work. The only solution I have found so far is to backport the kext from Catalina.

As per why your new EFI does not work and you encounter a kernel panic, like vit9696 said, you must isolate the product and commit that is causing the kernel panic.

Hi @dhinakg, many thanks for your thorough explanation.

You are probably right, the issue is not with OC per se and I will need to investigate this further, which I am doing atm.

Would you be able to tell me whether it is possible to prevent AppleAHCIPort.kext from loading during Big Sur Installer and load the one from Catalina instead?

What I am thinking is copying the kext from Catalina, place it in OC/Kexts and add it under Kernel > Add as usual.

I would then add Kernel > Block with the same values, although I might have to input a macOS version 10.16/11 so it prevents it from loading?

I am not sure whether it is possible to load the kext from Catalina during the Installer using OC, hence looking for a work around.

I have made a plist based on the SATA-unsupported.kext which loads the pci8086,a103 successfully, yet I get the same error during Installer and cannot see any SATA drives. Ioreg shows the same values of Catalina with my kext... so it should work in theory.

Thanks for you inputs!

[dhinakg]

Kernel > Block is supposed to work, albeit when I was testing with Catalina (I didn’t have Big Sur on hand) to make sure the modified kext still worked on Catalina this did not work and the original kext ended up being loaded anyway, and this caused issues as there were shared class names between the kexts, causing the load to fail.

I ended up binpatching the kext based on someone’s advice to rename all globals so that it would not conflict with the original kext and so both could load. I also increased the probe score of the Intel personality in the modified kext so that the modified kext would be the one to control the SATA controller. I have confirmed this works in Catalina and another person has reported to me that it works in Big Sur. However, I don’t think this is a very good solution and would like to go for a cleaner approach if possible (somehow isolating AppleIntelPchSeriesAHCI and its parent classes and transplanting them into a new kext, maybe?), but that is out of my scope of knowledge.

I can upload the modified kext here in a few hours, but I recommend waiting for another solution, and I think we may be going outside the scope of this bugtracker.

[Vitoli-o]

@dhinakg : I think my expertise my fall outside of your reasoning, what I understand what you are trying to say.

Would you be able to direct me to where I could find the kext you are going to upload?

Thanks!

[extric99]

I am running into this issue on a NUC7i7DNKE. Does anyone have a solution or workaround for the issue?

[dhinakg]

See the Dortania guide for a workaround. Link to the aforementioned patched kext is here