Hervé

Yes, it's just one of those little packaged scripts from chris1111 which basically does what is described above after it was updated for Sequoia. Frankly, no need of a 25MB package to mount the EFI partition...

Released August 5th, 2024. Build 24A5309e. Smooth update on Hackintosh, as usual. OCLP root patching required afterwards, also as usual. Same Clover r5159 setup for my Dell Latitude E7270 as used with initial beta3 version and posted here. Post-install issue: As mentioned on other Hackintosh forums, after this update, the EFI partition hosting the bootloader setup no longer mounts properly using tools such a CloverConfigurator, OpenCoreConfigurator, etc. or the line command: sudo diskutil mount <disk id> where <disk id> is the disk reference of the EFI partition; for instance disk0s1. The command executes with apparent success but no EFI icon on the desktop and nothing in mounting point directory /Volumes/EFI which is just empty. admin@macbook-pro ~ % ls -la /Volumes/EFI total 2 drwx------@ 1 admin staff 0 Jan 1 1970 . drwxr-xr-x 6 root wheel 192 Aug 6 11:58 .. A workaround has been posted which consists of manually recreating the directory /Volume/EFI as a mounting point and then mount the EFI partition on it. This can be done as follows: 1) Identify EFI partition disk id: admin@macbook-pro ~ % sudo diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *240.1 GB disk0 1: EFI EFI 209.7 MB disk0s1 <-- This is the EFI partition disk reference/id 2: Apple_APFS Container disk2 119.9 GB disk0s2 3: Apple_APFS Container disk1 120.0 GB disk0s3 [...] 2) If you've already attempted to mount the partition, unmount it, otherwise proceed directly to step #3 : admin@macbook-pro ~ % sudo diskutil unmount <disk id> (for instance disk0s1) This will remove the /Volumes/EFI mounting point. 3) Create EFI volume manually as mounting point: admin@macbook-pro ~ % sudo mkdir /Volumes/EFI 4) mount EFI partition on it: admin@macbook-pro ~ % sudo mount -t msdos /dev/disk0s1 /Volumes/EFI Executing: /usr/bin/kmutil load -p /System/Library/Extensions/msdosfs.kext Your EFI partition will then be mounted and its disk icon will appear on the desktop. Something has clearly changed with this beta 5 update, I suspect something to do with security or Gatekeeper and the mounting tools and/or methods previously used now need to be updated for Sequoia.

The "Generic" entry is just a reference, a name that is supported by the kext. The main thing is, of course, to inject your card's vendor and device ids.

-> Moving to WWAN hardware support, this is not related to a 7000 series per sé. From memory, the legacyQMI kext in question applied to a specific vanilla kext from an older OS X or macOS version; I'm pretty sure you would need to make it up for your current version, i.e. Big Sur so that it matches the dependancies of the vanilla kext. It's basically just an injector matching the syntax of the vanilla kext of the hosting OS. With Big Sur, Apple introduced some significant changes in the security of the OS and you can no longer (easily) patch kexts in /S/L/E. But you should be able to either make your own injector or -and your may find this easier though the aim is identical- inject/add your patch in FakeSMC or VirtualSMC (see here and you'll find a sample of injection through FakeSMC here). You may also look at these threads and draw your own conclusions: https://osxlatitude.com/forums/topic/12154-help-setting-up-dw5808e-on-e7450-dell https://osxlatitude.com/forums/topic/13027-dell-dw5811e-sierra-wireless-em7455-wwan-not-working Unless you have a dedicated SIM card for mobile computer data, such cellular cards are kind of deprecated today since it's much easier to simply pair a computer to a cell phone through Bluetooth or hook it by USB cable.

-> moving to the Dell Desktop section. Re:SMBIOS, see our previous June announcement on the unveiling of Sequoia: https://osxlatitude.com/forums/topic/20327-macos-sequoia-unveiled Then we have a dedicated section about Sequoia beta if need be. If things work as they are and you're happy with them, don't change anything.

You're not making much effort to try and understand... Anyway, Okay, closing and archiving this thread.

Given that you don't seem to be fully familiar with OC config files and manual adjustments, I suggest you experiment with OpenCoreConfigurator (OCC) tool and a blank/empty config file first; then you'll see where such patches go. In fact, I dare suggesting you stick to using such tools.

You don't understand. The patches are about IONVMeFamily vanilla kext, not about an add-on kext you inject in your bootloader setup. It's an integral part of macOS, located in /S/L/E. Prefix "com.apple.iokit." should have been enough to suss that out. Looks like you have some reading and learning to do. A hint for eventual future needs: look at kexts info in SysInfo->Software->Extensions. You'll see what we're talking about and why...

No, in your OC config; patches then apply to the targeted kexts.

Sorry can't help you without substance. Check your BIOS settings. Ensure you apply suitable OpenCore settings according to the Dortania configuration. Maybe make a fresh USB installer. Switch to Clover. You know, that kind of things.

Ok, let's try with a more basic setup with a revised config: if you inject ACPI patched table SSDT-UIAC for USB ports, don't inject USBInjectAll at the same time; it's either/or, not both. given that you stated you have an Intel combo wireless/Bluetooth card, I don't see why you inject all those Broadcom kexts for Bluetooth and Wireless; disable them all in your config at minimum; ideally delete them all since they're of no use to you. disable SystemProfilerMemoryFixup kext; I'm not convince you need that to begin with. disable VerbStub + CodecCommander kexts. disable CtlnaAHCIPort kext update Lilu and its Plugins to latest versions (AppleALC, Whatevergreen) update VirtualSMC and its PlugIns to latest version Make sure to reset NVRAM at OC Picker when you reboot, then reboot again.

As stated when 1st beta was released and confirmed when it was officially released, Sonoma dropped support for Broadcom cards that were supported up to Ventura. A solution based on OpenCore bootloader and the OCLP Patcher has been available since mid-summer of 2023. Nothing new on the matter as I post this article in January 2024, except that, good news for Clover users (yes, we still exist!), the solution now works with Clover too and is no longer limited to OpenCore. The issue for Clover users was that there was no readily available solution to block vanilla IOSkywalkFamily kext from being loaded at startup, even when trying to do this through patching the Info.plist file of the kext in the Clover config. No matter what, as long as the vanilla kext loaded/was cached, injecting the replacing kext would result in immediate Kernel Panic. This was finally resolved in Clover r5157 which integrates a kext patch in the form of a flag that can be enabled in the Clover config: BlockSkywalk (NB: it does not work with version r5155 or r5156). With this patch enabled, the abandoned IO80211FamilyLegacy from previous macOS version can be loaded/injected and so can the older/replacement version of the IOSkywalkFamily kext that is required. This being put in place, the OCLP patcher can then be used to apply the wireless root patch (whether Modern wireless or Legacy wireless) to finalise the Sonoma wireless fix. Broadcom cards that we all previously used up to Ventura, whether DW1560 (BCM5352 chipset), DW1820A (BCM4350 chipset) or Apple's own BCM94360xxx (BCM4360 and related chipsets) can now be used in macOS Sonoma exactly as they could in Ventura and earlier macOS versions. See our dedicated thread on the matter for full details. View full article

Further to troubleshooting made with @robi62 here, cards that require device id injection and/or binary patching of the IO80211FamilyLegacy PlugIn AirPortBrcmNIC like BCM4352-based DW1560, a new version v2.1.9 of Acidanthera's AirportBrcmFixup is under development but not officially released yet. This new version is being updated for Sequoia. Pre-release versions are available here. Downloads are only available to people who log in with their GitHub account. Here's a copy of the latest version at time of writing: AirportBrcmFixup-2.1.9-RELEASE.zip Just add the kext to your injected kexts folder and you'll be good to go with the above OCLP process. OpenCore users only need to select the AirPortBrcmNIC injector in their config file, AirPortBrcm4360 injector being irrelevant since Big Sur.

Important note about BCM4352 cards (eg: DW1560), given that these are not supported OOB. Injection of the device id or injection of compatibility statement was always required so that it could be activated through AirPortBrcm4360 (older OS X/macOS versions up to Catalina) or AirPortBrcmNIC (Big Sur & later) kexts. In addition, a binary patch of the drivers was required to obtain operation on 5Ghz networks. Injecting the property "compatible pci14e4,43a0 STRING" only provides operation on 2,4GHz networks. In Sonoma, BCM4352 cards can be fully activated with the above process + injection of Acidanthera's AirportBrcmFixup v2.1.8. With OpenCore, only the AirportBrcmNIC injector needs to be specified for loading in the config, AirportBrcm4360 injector being irrelevant (target kext not present). The injector does exactly what its name implies: it injects the missing device id (eg: 14e4:43b1 for the DW1560) in the AirPortBrcmNIC PlugIn of IO802FamilyLegacy kext. The binary/executable module of the kext handles the binary patch required to obtain operation on 5GHz networks. For BCM4350 cards (eg: DW1820a), no changes to what was required with previous macOS versions. It's a simple matter of applying the above process is + injecting the property "compatible pci14e4,43a0 STRING". No need of AirportBrcmFixup.

Got it, so AirportBrcmFixup injects the required id into the relevant wireless kext (AirPortBrcmNIC here) and I guess the binary/executable module applies the binary patch required for 5Ghz operation. Thanks.

For the benefits of others, would you care to explain how you met success? It looks like you use what I guess is a Sequoia-specific, yet unpublished version 2.1.9 of AirportBrcmFixup.

Never seen this KP on "watchdog" before; that's a first. Can't see any obvious mistake in your setup arrangements or config file. Nothing wrong with the patched ACPI tables or the injected kexts. So, I'd say the issue is somewhere in your OC config, maybe the quirks. I'm not too convinced by those boot args: agdpmod=vit9696 (isn't this for external GPU?) gfxfcms=1 (that's invalid, it's igfxfcms=1) and igfxdvmt (it's for Ice Lake platforms). I don't believe you need any of those at all. You would need to read the Whatevergreen documentation: https://github.com/acidanthera/WhateverGreen/tree/master https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md Regarding the properties you inject for HD530, faked KBL device id and injected KBL framebuffer layout id look Ok to me. Not so sure about the injected HDMI 2.0 properties but I can't see them do any harm. Re: quirks, a few suggestions: Booter: enable "SyncRuntimePermissions" Kernel: I think you can disable "AppleXcpmCfgLock" UEFI: not sure if you really need "RequestBootVarRouting" Kernel -> Scheme set to Fuzzy match. Do you really need this? Pretty sure you can also leave KernelArch to auto.

So you: inject the property "compatible pci14e4,43a0 STRING" against your card's location/address in your config? block/exclude vanilla IOSkywalkFamily in your config? inject IO802FamilyLegacy + replacement IOSkywalkFamily kexts? apply OCLP "modern wireless networking*" root patching? What about AirportBrcmFixup kext? I wouldn't use it to begin with. Injecting the compatibility statement normally removes the need for it. What is showing in SysInfo->Software->Extensions as injected kexts? Can you post a new IOReg extract? Edit: Oh, I had forgotten that, for 5GHz networks, as stated in the old BCM4352 thread I linked above, DW1560 used to require to binary patch AirportBrcm4360, then AirportBrcmNIC PlugIn kexts. I guess this is most likely still required. AirportBrcmFixup used to take care of that but I don't know how things operate now with OCLP. Maybe the patcher handles it all. https://www.insanelymac.com/forum/topic/292542-airport-pcie-half-mini/ https://github.com/acidanthera/AirportBrcmFixup

I really don't know how you managed to obtain working wifi considering I'm seeing a significant error in the property you inject which makes it invalid : You need to fix this and, ideally, describe the actions you took, the settings you applied. You probably got by thanks to AirportBrcmFixup which I now see injected. NB: to avoid scoring out personal info in your PrefPane screenshot, just scroll down the menu on the left before taking the shot!

DW1560 never was supported (OOB) with its native BCM4352 device id. See this very old thread going back to the good old days... So, you need to fake the device id of a BCM4360 chipset, i.e. inject the following additional device property in your config: compatible pci14e4,43a0 STRING If it still does not work, try injecting the following kexts in that order: AirPortBrcmNIC_Injector.kext + AirportBrcmFixup but I doubt you'd need this today. Remember that, before Apple decided to drop all the Broadcom legacy cards in Sonoma, the only remaining Broadcom cards still supported in Big Sur, Monterey and Ventura were: <key>IONameMatch</key> <array> <string>pci14e4,43ba</string> <string>pci14e4,43a3</string> <string>pci14e4,43a0</string> </array> i.e., BCM43602, BCM4350 and BCM4360 chipsets. That's all that the IO80211FamilyLegacy kext you inject supports.

-> moved to Sequoia beta section. As clearly indicated, no support requests in our Technical Info threads please. I don't understand that screenshot. Just how do you run Sequoia beta here? Or is it a screenshot of a screenshot? Did you apply OCLP 1.6.0 root patching? What did the app show in terms of patches when you ran it? Basically, if you were able to patch Sonoma for that DW1560 and obtain wireless + Bluetooth services, it's the exact same process and with the exact same parameters + add-on kexts for Sequoia beta. See this thread on the matter. I noticed in your config that you inject AMFIPass kext but that you do not use the -amfipassbeta boot arg as expected and stated in Jake's guide for Sonoma. Is that deliberate? Strange that the card shows in SysInfo but not in Hackintool. What do you see in SysInfo->Software->Extensions for the injected kexts? What about in IOReg?

Make sure to reset NVRAM at OC Picker when you reboot after all config changes.

Do you boot in verbose mode (-v boot flag)? If so, where does it hang or fail? What are the last messages?