Hervé

Unrelated to ProBook 650 -> moved to own thread.

Answers here and/or here. Do think of using the forum Search facility before posting. Note that you wouldn't be able to do much with such obsolete hardware and the old OS/software it'd support; even old Web browsers will be incompatible with many if not most of today's Internet web sites. Oh, and note that old (Prescot) Pentium 4 530 is 32bit, not 64bit... I would not waste my time trying to install Mac OS X on this old thing if I were you.

These (old) HotPlugging patches for AHCI disks will indeed be of no use if there is no initial support for your ICH10 SATA controller in AHCI mode. Their own stated description says all about their purpose... P43 chipset supports ICH10 (base) and ICH10R controller, so depending on which you have you could be lucky or unlucky. As described in ICH10 datasheet, ICH10 (base) does not natively support AHCI capability; it's conditional... Booting with your disk externally attached to a USB port, you may use Terminal commands to read the various registers that report of disk mode capability and status (you'll need to install tools such as the old lspci toolkit if you can find such stuff in 64bit). But even if the controller were to be returned as AHCI capable, you may find it difficult if not impossible to set it so given that BIOS does not offer the mode... This reminds me of the (fun) days when several of us Hackintoshers were trying to set the ICH7-M controller of the good old Latitude D620/D820 laptops to AHCI but miserably failed. BIOS would not offer the option it even if the controller was technically capable. You'd find threads/posts about this here with a little search. Anyhow, you could easily check the operating mode through any existing Windows or OS X/macOS installation. If disk runs in AHCI mode, it'll show in Windows Device Manager or SysInfo->Hardware->SATA. If your ICH10 only operates in IDE mode, you'll find AppleAHCIPort won't load, so HotPlug patch won't even apply... Rest assured that old Intel I/O controllers from ICH8 to ICH10 remain supported in Big Sur in AHCI mode (cf. Info.plist of AppleAHCIPort kext). It's a long time since I last checked but 'm pretty sure there's been no native support for legacy IDE mode in macOS these last few years in which case you could try and inject one of those old AppleIntelPIIXATA kexts from a previous version; no guarantee whatsoever that it would work... All in all, I'm pretty certain that the bottom line is: no AHCI, no Big Sur on internal disk. Last macOS version with an AppleIntelPIIXATA kext was Mojave 10.14.6; see attached IOATAFamily kext where you'll find the PlugIn; but no entry for ICH10 so you may have to create/add one... IOATAFamily.kext_Moj10.14.6.zip Of course, the best solution would be to opt for one of those supported PCIe SATA-III add-on controller cards. Would avoid all issues and give you full 6.0Gbits/s speed (ICH10 is SATA-II, i.e. 3.0Gbits/s only). Final word about the nVidia patching documentation you've referred to: it's applicable to nVidia dGPUs that are supported by the underlying OS! Not the case here and you must know that Tesla GPUs were dropped with Mojave which means there are no longer any drivers for these... Replace your card if you want to run Catalina/Big Sur.

Can you clarify the situation regarding this Big Sur attempt? Your system freezes whilst booting the USB installer? You have completed the 1st stage of initial installation and system freezes on 1st reboot? You have fully completed the installation and all subsequent reboots freeze as per screenshot? To be honest, I don't even know if Big Sur can be succesfully installed on a Wolfdale platform; I only briefly tried on my old Vostro 200 and failed. Big Sur won't support your old Telsa Geforce 210 card for sure, it'll have to go...

No, no, no, that won't work. 1st I don't even know why you'd use the El Capitan pack for Sierra but, most importantly, you just can't take a bootpack tuned for a Dell Latitude D830, apply it to a totally different computer and expect things to work. There's far too much stuff specific to the D830 in that pack that's neither relevant nor suitable for your Acer computer. I only made reference to the Dell guides for the general steps involved with regards to the installation process, not to use their bootpacks! Go for High Sierra and we'll try to work out a dedicated Clover pack for you. Do not use any Clover version from r5123 to r5126, these are troublesome.

You're gonna have to tell us more. You're trying to install Sierra but with what? What bootloader (Enoch? Clover?)? What pack? Can't see why you'd use boot arg nv_disable=1 on a laptop with a Tesla dGPU expected to be natively supported...

Don't hesitate to post your OpenCore EFI (Config, ACPI + kexts folders) for the benefit of the community.

MacBook9,1 SMBIOS + SKL framebuffer 0x191E0000 for Intel HD515 graphics, it would seem; correct ?

It would really be appreciated if people who use OpenCore would take the time to read the documentation posted at Dortania's. These people must have spent hours to write it and it is excellent. Common courtesy would be to refer to it.

Yes, see our FAQ section. To verify cache update, check presence of CodecCommander kext in Sysinfo->Software->Extensions; it should show there...

CodecCommander always required to be cached before, it never injected. Try to cache it from /L/E as per previous macOS versions.

I would never recommend nor encourage to use the patched DSDT of the E6230 on an E6530 nVidia. Quite the contrary. With regards to dead internal-USB devices or freezes upon wake, it's likely to be a consequence of inadequate settings on USB ports definition and associated power + side effect of injecting SSDT tables that may clash with patches present in the E6230 DSDT (EC, PNLF, etc.). I'm myself to post a further refined E6230 OC pack in the next few days, the aim being to get rid of the patched DSDT and use SSDTs only. I can have a look at your EFI folder & DSDT but I would need you to: run on latest BIOS post your extracted raw set of ACPI tables (the thing obtained by pressing [F4] at Clover main menu)

Looks more like a corrupt installation; try a fresh one on a separate disk or partition. Failing that, investigate eventual faulty hardware somewhere.

You meant Latitude 5480, right? If so, I don't believe anyone has found a solution to date.

Maybe, no way to say for sure.

Core2Duo P7350 is Penryn-3M and GeForce 9300M GS is Tesla G98. This kind of platform should fully support El Capitan but also Sierra and High Sierra since the CPU has SSE4.1 instructions set. I'd go for the latter. You could even push for Mojave with Tesla-specific special patches and Catalina with Dosdude1's patcher. You can read about those in our Graphics section. But that's maybe for a future stage as it gets a little complicated when High Sierra will fully and natively support your graphics card. Download a copy of High Sierra off Apple (via AppStore or Apple download links) and make your USB installer with basic settings. Look at "Our Picks" side panel on forum main page for that. You can look at fine tuning your build for Ethernet, wireless, audio, card reader, etc. once you've finished the macOS installation. You may consult these old guides for general guidance in the process; obviously the pack are not for you but you can extract the core kexts from them (FakeSMC, Lilu, WEG). https://osxlatitude.com/forums/topic/12479-dell-latitude-d630-with-core2duo-nvidia-quadro-nvs-135m-el-capitansierrahigh-sierramojavecatalina/ https://osxlatitude.com/forums/topic/10370-dell-latitude-d830-with-core2duo-and-nvidia-quadro-nvs-135m-mavericksyosemiteel-capitansierrahigh-sierramojave/ The one thing that will not be supported for certain is your Intel wireless card and it'll have to be replaced by a supported model. Plenty to choose from and you may consult our inventories published in the Wifi section to that effect. Good luck.

Big Sur brought significant changes to the way kexts operate with the kernel and further tightened filesystem protection. It's now most difficult for anyone to make any changes to /S/L/E folder. As such, kexts should be considered cacheable only from /L/E. To repair permissions after any any kext addition, removal or modification in /L/E, type the following Terminal commands: sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /L*/E* ` To rebuild the cache, type the following Terminal commands sudo kextcache -i / -> will invoke the required kmutil command sudo kcditto For additional information on the commands: man kmutil man kcditto

Please consult the available documentation. Thank you.

No, E5550 is a Broadwell platform when your E5540 is a Haswell one. So they're of different chipset families, different CPU families, different iGPU families. As such, the EFI meant for an E5550 will contain configuration elements not suitable for your E5540 (graphics property injection SMBIOS, etc.) and your Hack would not work. On the other hand you can seek inspiration from existing packs and threads relating to other Haswell Latitude laptops such as the E6x40 or E7x40. By far and large, all these will share similar not to say near-identical configuration, the only differences being on the hardware accessories side (eg: LAN, audio, card reader, etc.). I strongly recommend you start here...

We'd all be grateful if you'd go easy on the permanent quoting; it really isn't necessary and quite messy. I gave you packs, obviously without the CPU PM ssdt since I could not guess what CPU you had. As clearly stated, they're not full OC EFI folders! If you tried to boot with nothing else, you indeed must have failed miserably... All you have to do is make your OC EFI folder following Dortania's current documentation and then, update it with the stuff in the packs I gave you. Then add your CPU PM ssdt and update the config accordingly. I thought it would have been common sense and easily understood. With OC 0.6.3, your default EFI updated with my pack's contents and SMBIOS MBP10,2, you'll be able to install Big Sur 11.0.1 as shown in my E6230 detailed guide. Good luck!

I can assure you that there is nothing in the kexts folder of the packs I posted that could be specifically for Clover. You know, kexts are the same whether you boot with Clover or OpenCore and the same goes for caching kexts from /L/E. On the other hand, the OC EFI you posted contains many incorrect items. ACPI: No patched DSDT. SSDT-EC which is Ok for older systems (up to Broadwell) such as your Ivy Bridge E6430. SSDT-EC-USBX which is for newer systems (Skylake and later) and therefore irrelevant for you. Delete this. SSDT-PM is for a quad-core i7-3740QM, I assume this is the CPU you have, therefore correct CPU PM SSDT; if not, you know the drill... Drivers: No need to include them all. You only need to use and declare those drivers you need: Audio (if you want startup chime), OpenRunTime, HfsPlus and, if you use the OC GUI, OpenCanopy. Kexts: Several conflicting drivers here... AirPortBrcmFixup vs. FakePCIID+FakePCIID_Broadcom_Wifi. Remove the latter 2, they've been kind of obsolete for some time now. USBPorts_E6430 vs. USBInjectAll. Remove the latter; it's either USBPorts or USBInjectAll+SSDT-UIAC (which you don't have). OC Config file: calls for a DSDT that's not there. does not call for the CPU PM SSDT that's in the ACPI folder. Therefore no CPU power management... Device Properties: injects correct properties for HiRes LCD but retains limitations to single display port (built-in LCD) only. Further properties are required if you want additional display ports, at least HDMI. Kernel: properly selects desired kexts and removes any contradictions mentioned above Drivers: setup only selects those you want but I don't know if you should have ApfsDriverLoader.efi rather than HfsPlus.efi. I actually wonder where your ApfsDriverLoader module is coming from. Clover? PlatformInfo: there is absolutely no reason why you would use the SMBIOS of Haswell MacBookPro11.1 when you should be using SMBIOS of Ivy Bridge MacBookPro9,2 or MacBookPro10,2. NVRAM: applies -igfxnohdmi. May be you want to revise this once you inject properties that'll support HDMI output. I can only suggest you use the packs I provided above given that current setup looks quite incorrect to me. A particular aspect to pay attention to is your CPU model and the CPU PM SSDT that you need to use or generate accordingly. I also strongly recommend that you post your E6430 specs so that we avoid wasting time on trying to provide assistance in the dark. It's highly desired to post such specs in signature...

You don't "patch ssdt". You generate your CPU-specific power management SSDT through well-known/good old Pike R Alpha's generator script. See here.

You have an i5-3340M but use the CPU power management SSDT generated for a quad-core i7-3630QM. remove that SSDT and generate your own one. remove that CpuTscSync kext too. It's not required. Adjust your OC config (Kernel section) accordingly. You'll find things will work much better afterwards...

I have repeatedly been able to install Big Sur on my E6230 with SMBIOS of unsupported MacBookPro9,2 and MacBookPro10,2 with -no_compat_check boot arg. The issue at hand must be something else. @leppy700m, post a zipped copy of your EFI folder so that we check it out. You may also refer to my E6230 guide for general guidance though I've left out some properties injection out of the OpenCore config given that they were already in the patched DSDT (ECDV->EC, EHCx->EH0x, IGPU properties, etc.). You may use these E6430 HD4000-only packs for your OpenCore setup; just copy the files and folders of the packs to the OC folder of your EFI partition/folder and replace any existing stuff. EFI_E6430_LoRes.zip EFI_E6430_HiRes.zip For an E6430 with nVidia graphics, enable Optimus in BIOS but disable the dGPU through DSDT/SSDT patching. JakeLo posted the necessary stuff in several E6x20/E6x30 NVS x200M threads. JakeLo will correct me if necessary. Meantime and/or in the interim, you may just boot with boot arg -wegnoegpu added to the NVRAM section. See here for more details.

What laptop? What setup? Please post a zipped copy of your OC EFI folder. Add your Hackintosh specs in signature.